We all know the story. One minute you’re a junior developer learning your first regular expression. A few years and promotions later, you’re put in charge of a team of developers. Simple right? Just keep on cranking out the code, review the teams work and everything should fall into place. Except it doesn’t. It turns out being a manager is a completely different job to be being a developer and most people feel the pain as they make this transition. So having been through this myself, I thought I would share some of my personal lessons learned as a manager.

Act as a floodgate whilst clearing blockages

Now you’re no longer in the trenches, you need to realise your job is not to cut code. You may, to some degree, add lines here and there but this is not your primary function. You are now tasked with acting as a floodgate, holding back the torrent of unending questions and curve balls from outside the team. Anything that stops the developers writing code is your responsibility. They need a new laptop, your job to deal with procurement. Leadership wants to see a demo of the code, your job to show them. Cups of coffee running low, you may as well top them up.

The point is that being a manager is about leveraging your team to do what they are best at. You could spend time writing code, but it would be better spent clearing a blockage that allows your 5 developers to be more productive. It took me a while to get used to this as my career had revolved around the code for so long.

People are hard

They most certainly aren’t code. Code is easy. You can reason about code. It’s black and white, binary. People on the other hand are like a rainbow. They flow with emotions which you need to account for. People have strengths and weaknesses you need to understand and optimise for. They have complex social dynamics throughout the team and beyond which you must pay attention to.

As a manager it’s your job to get the best out of your team whilst helping them get the most out of their role. You will have some intuition on how to do this through life experience, but this will be limited and often misguided. I learned a lot of valuable tips through attending the soft skill courses most developers shy away from. I make sure I read a lot around the subject. And finally I network and discuss my issues and findings with like-minded people.

“Optics” are a thing

As a developer I never truly understood why people would always talk about the “optics” of a situation. But if you take the stock market as an example, it rises and falls based not necessarily on facts but on faith, on the optics of a given situation. The company may be performing well but if the media spin it as a loss, then the optics and perceptions change. And the same is true throughout all walks of life, such as being a manager. You may be acting in the best of intentions when you make decisions, but unless this is communicated and framed properly it can be taken out of context.

The main lesson here is to think about how you want people to perceive what you are doing. Deploy some empathy before you act. How would you see the situation if you were in their shoes? What could you say and do to clearly communicate the right message? Is there anything you are doing which could jeopardize the perception?

Set a clear career progression

It’s vitally important people know where they stand and what they are aiming for. I made the mistake early on by setting a somewhat vague career progression roadmap for developers. Whilst I had the best of intentions and believed it would work for the team, the language was too business-like and there were not enough quantifiable goals. This had two effects. Firstly the team thought they needed to become business focused and move away from the technical side. Secondly, the optics of justifying promotions were not great because there were no clear measures I could point to.

There are countless examples of developer roadmaps from large to small organisations and I suggest you read through them. Spotify in particular generated a lot of buzz when they released theirs. Tailor these examples to how you want your team to function and then clearly communicate this to the team.

Hire team players, not rockstars

You’ve all heard of the 10x developer. The fabled rockstar who can build your app in a long weekend. These guys can code like nobody else so of course you want to hire them. Except you don’t. I favour building teams from team players, people who may only be 3x, 2x or even just 1x developers. As a unit they will pull together and be strong, work well and support each other. Team players help to build a positive culture. My experience of rockstars is that they often come with emotional baggage which will disrupt this unity. They may have an ego the size of Jupiter. They may play by their own rules and not turn up to daily stand-ups or other team events.

It can be easy to be seduced by the quick wins of a rockstar, especially if you’re pressure to ship. But take a step back and look at the long term and how the hire will affect you down the line. How will the team react? What damage might be caused? I have had to attend my fair share of HR sessions caused by these guys and can attest the short term wins were not worth it.

Keep learning

Before I wrap up, there is one last lesson to keep in mind – we are always learning. These are just a few of the lessons learned along my journey to manager, but I will still make mistakes as I progress further. Don’t be afraid of failing as this means you are pushing yourself. Just ensure you look at the failure and learn from it.