Over just the past few weeks I have been asked on three separate occasions now for advice on making the move from being a hands-on software developer to a primarily management-focused role. This has given me significant cause to consider this subject and I feel it warrants its own post to fully capture my thoughts.

Resources

I should start by pointing out that I am aware that this is a well-trodden subject and there are plenty of resources available to help developers on this journey. There are two books that immediately spring to my mind here:

• Becoming and Effective Software Engineering Manager – James Stanier
• The Manager’s Path – Camille Fournier

Both books cover a lot of the same ground but I find this to be reassuring in giving you two different perspectives on the same roles and responsibilities. It feels like the two books combine well to give a strong sense of what a development manager role entails. I recommend anyone considering the move into management read these books to get a taste of what is involved, to help prepare for the interview process and beyond.

These books have continued to serve me for years as essential reference guides. Despite these two books providing a comprehensive view of the software development manager role, I feel there is still a significant aspect of taking the leap that is left wanting.

Walk before you run

Sounds obvious but I have seen first hand that some businesses place an expectation on individuals to demonstrate that they can perform the responsibilities of a role before they are promoted to it. This seems like a sensible framework for supporting progression and in many cases it really is the most natural path for employees to attain promotion – consider mid-level to senior-level engineer as a perfect example. The shift from developer to manager though is not so much of a progression, but a leap or even more of a complete role change and trying to meet the expectations of a manager while also performing as a developer – especially a developer worthy of a promotion – can easily result in failure of both responsibilities.

Pat your head, rub your belly, and no mistakes!

The responsibilities of a developer and those of a development manager are almost entirely different. I would argue that the only real overlap is that it is very useful for a development manager to understand, in depth, the work undertaken by a development team. Otherwise the two roles even require different mental states. Developers are focused on analysing issues from the past, solving issues in the immediate present and they require extended periods of deep focus time with minimal distractions. Development managers however are constantly thinking in the future tense, planning weeks and months ahead, managing almost constant distractions and are expected to be available to respond to issues at the drop of a hat. I have tried to mix these two and I can’t do it. Not well, not even badly, simply not at all. I know some people are able to to do this but it strikes me as a more rare talent. I do not see myself as either exceptionally talented or particularly lacking, I am by all accounts decidedly average and so I cannot see my experience here being all that unusual. Failing to acknowledge this distinction between development and managerial responsibilities is in my experience a recipe for poor performance, frustration, confusion and ultimately failure. Furthermore I am convinced that by assuming that developers should step up to be managers before they are given a serious opportunity to prove themselves in the role is also likely to be missing so many potentially great managers!

Instead what I suggest for anyone looking to make the leap is to find a role in a team that is looking to support someone to take this step. I frequently see such roles advertised and each time I am enamoured by the feeling that this is a team that cares about nurturing and growing talent and is prepared to invest in it. I’m sure there is a time and a place for the entrepreneurial approach to allowing individuals to grow themselves but I am yet to find an instance where this is the most helpful option for me.

There’s always the exception

I am aware that there is sometimes overlap between developers and managers and I have seen some teams where a ‘tech lead’ or ‘lead developer’ takes on some project and team management functions while mostly delivering code and so it could be argued that there is a gradated path that can be followed, but there seems to be little industry consensus on this. What I see right now is an industry that has mostly consolidated on a distinction between developers and development managers and this seems sensible to me.

So, who then?

I can hear you ask, how do businesses know who is suitable for investing in a path to management? You can’t know. I think its possible to identify good candidates based on their approach to delivery, communication and other behaviours, but ultimately it will always be a risk. I am certain however that it is better to take the risk on individuals who give you a sense that they would make good managers and to invest in them, help them make this switch. Just having a strong desire to make this move – for sound reasons of course – is enough of an indicator to me that someone is worth considering for this investment.

Overload, prioritise

Prioritisation is something that is covered to some lengths in the books mentioned at the start of this article, however there is a an aspect of the reality of being a manager in a busy environment that I do not feel is given enough attention, either in the recommended books or in general.

In a busy environment, even the greatest delegator and manager will often have too many actions to deliver. Honestly, at busy times I have found myself with easily three times more actions on my to-do list than could be delegated, planned or responded to let alone fully resolved. At the same time I have also found that this doesn’t need to be overwhelming. During particularly busy times I have set myself a limit of 50 items on my to-do list and I continually revise and update this list, many times in a day. I start my day reviewing the list and I end my day updating it. So long as you make sure that you are giving your top priorities the attention they need then you should still be OK. Sure, items will be getting deleted off the list all the time and this will often result in stakeholders not getting what they want. Over time you will come to learn where it is appropriate to notify a stakeholder that their request has been indefinitely struck-off the list of priorities but I have found this to be rarely needed. Similarly I have found that it is rare that a priority I have had to strike off my list is actually important enough to warrant a further discussion with a disgruntled stakeholder. It seems that when I am so busy that I have to enforce a strict rubric such as a hard limit on my to-do list, that most of my stakeholders are similarly busy. By constantly reviewing and updating my list to reflect the big priorities I find that most people are kept happy, even if it feels like I am dropping actions left, right and centre.