Created at: 2024-10-08
I've been managing for the past 3 years at my current job. This is not extensive experience and I still see myself as a junior manager.
As I reflect on my journey, I talk through lessons learnt from managing other developers and on recurring patterns I have observed.
Now, a post about management is not cringe enough unless it includes an "advice top list".
The one I could come up with is made of 5 must's.
Note: Having innate charisma would greatly help. It'd make easier to perform most points above. Sadly the nerdy type often lacks charisma. We need to work harder on it. More on that later.
“The manager’s function is not to make people work, but to make it possible for people to work.” (Peopleware)
Being promoted to manager after performing well as a developer is a regular occurrence in many companies. Another regular occurrence is for a former developer to not be good at managing their peers.
Promoting a good developer has many positives. It ensures that the new manager won't be a mere conduit for communication. Having experience in the field helps facilitate technical discussions.
However, The Venn diagram intersection between skills required to be a good developer and to be a good manager is narrow. Facilitation skills do not regularly feature on the good-developer skill set as much as they should.
I did not have guidance and mentorship once I became a manager. On top of that, I wanted to keep coding at the same pace as before. This situation made it harder for me to manage my own conflicts of interested between coding and managing.
That meant that I wasn't facilitating much. The lack of leadership and direction quickly hampered the development of one of my teams.
Once that team grew to about ~7 developers the situation became unsustainable.
I wasn't having quality time to spend on important coding tasks because I was constantly on management duties. At the same time I wasn't helping to unblock my team's work as well as I could since I spent considerable time coding.
By sheer luck, the team was independent enough to perform well without strong management guidance. That could equally have been the other way around.
I had to step back and rethink my approach so that I could balance facilitation duties against coding responsibilities.
Being proactive about facilitation helped save time for myself and to relieve stress from my team. It sounds cliché, but finding problems before they happen and answering the questions before they are asked are important to help reduce stress across your team.
The most important thing was realising that unblocking 7 people and letting them do good work was more important than me, as a single contributor, writing some of the code.
This didn't make my work easier, though. There are many ways to facilitate progress, and some situations are harder than others.
Technical facilitation is usually straight forward. For example, the product manager asks for a feature but the details aren't clear enough for a developer to jump on the task. You pop a meeting with the client and the P.M. Together you clear up requirements so that a developer is not stuck with vague requirements and lack of direction.
The goal isn't to detail the design for the solution (the developer will do that). Instead, the goal is to make sure requirements are understood and there is a definition of what "done" means for that task.
Technical facilitation only takes time and organising. I.e., getting the relevant people together and taking the time to write up the details of what was discussed and agreed.
My experience as a developer helped greatly in these areas. I was already used to going to client meetings and explaining what was possible versus what was not possible. I also frequently helped clients with estimations backed up by my knowledge of the tech and current architecture of the project.
The hard type of facilitation is the human one. For example, when a team member is having a hard time because of external factors or conflicts between colleagues. This is the real human-factor part of the job. I have little experience on this.
These situations take a lot of time and energy to solve. Each situation of this type is different and facilitation might have to be defined on a case-by-case basis.
The tools available by the business will be relevant here and the manager needs to be aware of them to be able to put them to good use. E.g., unlimited leave, team rotation, mental-health days, external mediation, etc.
My general observation is to treat the situation with compassion and empathy. In the end of the day a manager will be dealing with people-problems frequently. In the eyes of the person being troubled, their problems will be be more concerning than they may be comfortable telling you. You are at the risk of miss-characterising the problem if you don't take it seriously.
There is little point in trying to play a hard hand as an authoritarian manager that only dictates solutions without taking the time to care and understand the situation. "It's your job, just do it!". This almost always goes wrong and makes the manager lose respect even from the people not involved in the situation. Luckily this is something I learned from observation and not from direct experience.
Of all the "musts", this is the one that took me the longest to think and write about. It's hard to find a recipe for what "taking an active interest" is, even though most people have a good intuition about what this phrase means.
Different people need different things depending on where they are at their careers, what they want to achieve, and who they are.
The first step is understanding what each report needs based on their career stage, goals, and personality. But there is a meta step here too. Both you and the report need to be willing to learn and improve together for that relationship to work and those questions to be answered. It's not just about the report's growth but also the manager's willingness to evolve in response to their team's needs.
In the best manager-managed relationships I have had, both people were learning together what they needed from each other and what they could provide.
To use an analogy from pedagogy theory:
Through dialogue, the teacher-of-the-students and the students-of-the-teacher cease to exist and a new term emerges: teacher-student with students-teachers. The teacher is no longer merely the-one-who-teaches, but one who is himself taught in dialogue with the students, who in turn while being taught also teach. They become jointly responsible for a process in which all grow − Paulo Freire.
Having a manager that allows themselves to not know but are comfortable asking dumb questions is a great thing. I had managers on the other side of the spectrum who pretended to be acquainted with things they had no clue about. I believe they were insecure about showing potential shortcomings to their reports. This strikes me as a bad thing.
It is difficult to provide quality help to develop a report's career if the manager is not an active member of the team in some capacity.
It is hard to relate to the work of a report if you have no skin in the game.
This is why I am in favour of managers that get their hands dirty on the factory line at least some of the time, even if only on smaller tasks.
This helps building team spirit and camaraderie. Frankly, you can provide a much richer feedback as a manager if you are close to the work yourself.
That is not to say that there aren't exceptions where the manager cannot be part of the team. For example, a project may be so novel that no one except the few reports deep in the weeds can actively contribute to the advancement of that project.
This problem also seem to occur the higher up the management chain you go. It must be difficult for the manager-of-managers to stay on top of each manager's team work.
However, this does not mean that the manager shouldn't try their best to understand the project. Even if it is to support the team when collateral damage happens.
It is hard to take an active interest in someone without getting to know them. Make sure to invest in the relationship early as it takes time to build trust.
This is not necessarily popular advice. The book Peopleware makes this observation below.
managers are usually not part of the teams that they manage. Teams are made up of peers, equals that function as equals. The manager is most often outside the team, giving occasional direction from above and clearing away administrative and procedural obstacles. By definition, the manager is not a peer and so can’t be part of the peer group. (Peopleware).
I recommend to not take the hierarchical manager as an example. It may work in certain business areas, but I haven't seen it working well in software development so far.
"Listening is an active skill". In this case not only one of "paying attention" but taking proactive effort to reflect on what has been reported and to act on it.
A good way of creating space for listening is through recurring one-on-one meetings. Those are the minimum to keep a relationship flowing. Otherwise, without the space to exchange ideas, get feedback, or otherwise just rant, there'll be a barrier between manager and report that might not serve either.
It is easy to get caught on the "busyness-of-it" and put off 1:1's - both as a report or as a manager. If this becomes a frequent occurrence it might be because of a potential underlying problem.
Here is a small list of tips for active listening. It serves well just to be aware of these things before you jump on a 1:1 with a report:
“People who feel untrusted have little inclination to bond together into a cooperative team.”
A pat on the back goes a long way, specially when it's done publicly. But reassuring is not just about rewarding but building trust and cooperation.
Everyone likes to feel like they're winning and getting validation for their good work. Many software development managers are introverts who struggle with giving compliments.
I think that more than a skill that can be learned, you need to be constantly aware of opportunities to provide recognitions (this is harder than it sounds).
I have worked for companies that had free-pizza events (or insert another snack here) to celebrate team achievements. There's nothing wrong with that.
Celebration is necessary for a team to function. However, some organisations tend to over-characterise such acts as proof of their generosity and reassurance that employees are doing a good job.
I think that most employees can see through this over characterisation and that leaves them with a bitter taste in their mouths. Without proper reassurance and true recognition, it doesn't matter how many pizza events there are, people won't feel reassured and valued in their job.
It might even be the opposite: "why is the company going a long way with such events whereas people aren't getting paid enough?". panem et circenses
One of the best kinds of recognition is the financial one, specially when that financial acknowledgement is made proactively from the manager-side before "official" raise ceremonies take place.
It might be harder to give financial recognition in start-up companies struggling for cash. There are other means to account for that like granting share options or title promotions.
However, navigate the "title promotion" situation with care. Although such promotions are a good way to recognise the work that someone has done, they can also be a problem. Eagerly promoting people who aren't ready for the role as a retention strategy can backfire. This is not true recognition.
It is incredible that in certain places salary raises only happen once a year. If you missed the date but got a lot of responsibility on your back, you need to perform the role for a year without financial recognition.
It is very hard to be a manager in such companies as you don't have freedom to really manage your team.
The same divisive effect occurs in connection with the so-called “leadership training courses,” which are (although carried out without any such intention by many of their organizers) in the last analysis alienating. These courses are based on the naïve assumption that one can promote the community by training its leaders—as if it were the parts that promote the whole and not the whole which, in being promoted, promotes the parts.
Paulo Freire.
Managing is hard, and there is so much material out there that isn't necessary relevant or particularly useful to your situation.
From that, it is easy to grow cynical thinking that "no one can teach management". But that is also not a helpful way to see things. I bet your reports would raise an eyebrow if you said that to them.
Material on how to manage creative workers like software developers seems particularly scarce. The creative-types also seem to require a different kind of management than the general "KPI-based" literature teaches.
To make matters worse, there is usually not many clear metrics you can track on how much impact a creative has made (usually in terms of revenue) to the business. Of course you should be able to tell whether someone is performing to the level of their role, but overall impact is a harder thing to measure.
For example, you might have productive developers that look good on paper but aren't generating tons of concrete value. They may, at the same time, demand a lot of resources from across the team for code review.
In the same way, you might have workers that seem slower but always provide high-quality and impactful changes (and feedback) that are aligned with core-business values.
These situations are tricky. Part of growing as a manager is recognising those types of workers exist and providing feedback that enables them both to grow.
Even though improving-as-a-manager is a slow process and difficult in a different way than improving-as-a-developer, progressive improvement is possible.
Managing takes a different source of energy than coding. If you are not a real people person you have to be prepared to spend more time and energy being a manager.
Quite frankly, it's already very hard to keep on top of these "5 musts", specially as the number of reports goes up.
The final advice here is to keep an open mind. Check the literature and try and read some books on management. Observe how your team members interact with each other and listen to what they have to say. Learn from teams that perform well, and from teams that don't perform well. What are the differences? Read other posts like this one about what other managers are thinking and think critically about what you read. Don't take our word for it!
Some recommendations for reading:
Even after writing about all of these topics, I myself am not able to perform these advices to the dot every single day.
If not by an act of human fallibility, in some situations it is just not possible to follow general advice. I think that this is OK.
What matters the most is: