Making the leap from being a software developer to a development manager is hard. Suddenly, you’re not judged on your own performance, but on the performance of your team as a whole.
The skills you need to be a good manager are very different to those of a developer. Unfortunately, these skills are not taken into account enough when promoting.
When you’re a developer, you’re mostly valuable if you write good code and deliver features. If you write better code and deliver more features, you’re more valuable.
That’s a bit of a simplification, but the general point is true: you can increase your value by optimising your own contributions.
However, when you become a manager, you’re more valuable the more your team delivers.
The maths is simple. If you can make a process change that will increase the productivity of each developer in the team by 10%, that’s potentially a huge difference when multiplied by the number of developers. Compare that to some work that increases only your output by 10%, and the choice is clear.
In this guide, I’ll go through:
To find the right things to focus on, start by thinking about what demotivates developers and stops them from performing at their best.
Below are common examples; you may think of others. I’ve loosely grouped them by category:
Clarity:
Autonomy:
Wellness:
Relationships:
Purpose:
Personal growth:
Impact:
The precise grouping isn’t important, but the groups help shed light on what the basic needs of a developer are in their job. Your groups may be slightly different, if your team has a different focus.
It’s possible to take my list of needs and sum them up in a couple of sentences:
Developers need to know what to do and why they are doing it, but how to do it should be up to them. They need to do it in an environment which fosters wellness, where they are supported by their peers and where they can grow.
You should be able to do something similar with your list of needs. If you can’t, it’s probably a sign you have too many.
When a developer is not performing well, the cause is usually one of these things.
It’s your job as a manager to make sure these needs are met.
Sometimes, these things can occur as one-off incidents that only affect one person in the team. But usually, these problems are widespread.
Therefore, an improvement in one of these areas usually has a multiplier effect. These should be your focus.
You can’t make improvements in these focus areas by will alone. You need concrete actions that are within your power to carry out.
For each basic need, I’ll list some such initiatives you can try. These are just examples; you should think of ones that are relevant to your own team.
Then in the next section I’ll consolidate and prioritise them in the form of a 6 month action plan for new managers.
Write a role description for every role in your team, or update them if they already exist.
There are common responsibilities in technical teams where it’s not obvious who should do them. These include things like:
Make sure all these things are covered in the role descriptions, and that the whole team is clear who should do them.
Set regular goals for every team member, using a framework everyone understands. If you can choose the framework, it may help to use a widely known one such as OKRs.
Set up recurring calendar entries to set and review these goals at the appropriate frequency (for OKRs, quarterly). Take notes in every review, so you can refer to them in future.
Get the team to agree a standard format for work items. Often these are being tracked as tickets on a system like JIRA or Trello - the standard format could include things like ticket titles always being user stories, tickets always having acceptance criteria, or every ticket being linked to some company objective. It’s up to the team to decide, whatever they think the appropriate level of clarity is.
These initiatives all help to fulfil developers’ needs, and make the team more effective, which is the definition of being a good manager.
Your list will be similar.
But the initiatives will be of different types: some will be one-off actions, will be recurring things to do on a schedule, some will be things to do in response to certain events.
Also, some of the initiatives will have implicit prerequisites built into them. And some will be more important than others.
Presented like this as a list, the initiatives aren’t that useful. It’s not clear where to start.
In the next section, I build on the list of initiatives and present it as an action plan, specifying what to do when.
From day one onwards, you need to always make time for your team when they need you, you need to be quick to reply to people, you need to follow through when you say you’ll do something, and you need to meet deadlines. You need to do this all consistently.
If your team can’t trust you to reply to emails, then they won’t trust you to change their ways of working.
But if you can get these basics right (which, by the way, most people don’t), you’ll get a reputation as someone who gets things done. And people will buy into your initiatives.
These are the most important things to get right, from the very start.
Your aim in the first week is to put names to faces, introduce yourself, and find out just enough about your team’s situation that you can plan the coming weeks appropriately.
Meet with every member of your team individually (or just your direct reports, depending on the structure of your team). Find out what their understanding of their role is, what they like about it and what biggest pain points are. You should focus on asking questions and listening more than talking, but do make it clear that one of the main parts of your job is to help them get unstuck.
Set up recurring one-to-one meetings with each of your team members. Weekly is preferable, at least at first, while you’re still getting to know everyone. Keep the agenda flexible and give your team space to add their own items, but make sure you regularly discuss pain points, blockers and workload.
The rest of the plan below, covering the rest of the first month and beyond, should not be rigid. Use the information you’ve obtained in your early one-to-ones to shape your priorities.
The rest of your first month should focus on quick wins - things you can do or systems you can put in place, without much effort, that will give the team a boost and help lay the groundwork for future changes.
If they don’t already, make sure your team has a convenient way to communicate and make decisions as a group without always needing a meeting. The usual tools for this are Slack or Microsoft Teams.
Similarly, make sure the team has a place for documentation, so that information and decisions don’t get lost in the ether. Typically, teams are bad at documenting things, so reduce some of the friction by choosing a simple, flexible tool. A wiki like Confluence or Notion would be good here.
Get the team together to talk about working arrangements. If it’s within your power, tell your team they are free to work wherever and whenever they want, as long as it doesn’t prevent the team from working effectively. Agree as a team what the parameters and rules should be. If you have regular recurring meetings or rituals, let the team decide when these should be. Document any decisions.
Introduce some sort of anonymous suggestion box that your team can contribute to, and make sure you regularly review it and respond to the suggestions.
Set up a system where your team regularly recognise each other for their hard work - perhaps a vote every Friday for the “hero of the week” or something similar.
Of the longer term initiatives that you won’t be ready to implement yet, the ones to start thinking about in your first month are the ones relating to purpose.
Internalise the company’s purpose and vision (or your conception of it, if no such thing has been written down), and make sure you can communicate it to your team.
By the end of your first 3 months, you should aim to have the team aligned on purpose, values and goals. They should feel like it’s within their power to act on these.
Let your team know they are free to approach a piece of work in whatever way they think is best. They are responsible for the technical solution, as long as it meets the requirements. In situations where two individuals (which could include yourself) can’t agree on the best way to solve a problem, get the whole team to come to a decision together.
Get everyone together to discuss the team’s purpose, and how it relates to the company purpose. Come up with a succinct way of expressing the team’s purpose, and document it somewhere highly visible, like the front page of your wiki.
If the company has clearly defined values, reflect on them and think of specific ways you can live those values in your team. Document these.
If your company doesn’t have clearly defined values, get together with your team to define your own at a team level.
Set regular goals for every team member, using a framework everyone understands. If you can choose the framework, it may help to use a widely known one such as OKRs.
Set up recurring calendar entries to set and review these goals at the appropriate frequency (for OKRs, quarterly). Take notes in every review, so you can refer to them in future.
Get the team using a methodology like scrum agile that breaks work down into small units, keeps the total workload at any given time to a reasonable amount, and means the amount of work the team commits to is in their own hands.
Get the team to agree a standard format for work items. Often these are being tracked as tickets on a system like JIRA or Trello - the standard format could include things like ticket titles always being user stories, tickets always having acceptance criteria, or every ticket being linked to some company objective. It’s up to the team to decide, whatever they think the appropriate level of clarity is.
After purpose, goals and values are in place, you need to focus on delivering.
Make it part of your team’s process to identify potential blockers to completion of an item of work, and attempt to address them, before committing to that piece of work. Perhaps have time in each sprint dedicated to identifying and clearing future blockers.
Make it part of your team’s ethos to finish and release items of work. Send clear messages to product owners and stakeholders that you won’t reprioritise in the middle of a sprint unless it’s absolutely necessary, and that current items of work will be seen through to completion before starting new items.
By 6 months, you need to be thinking longer term with your team, and making sure everyone can grow.
Write a role description for every role in your team, or update them if they already exist.
There are common responsibilities in technical teams where it’s not obvious who should do them. These include things like:
Make sure all these things are covered in the role descriptions, and that the whole team is clear who should do them.
Define a progression framework for each role type in your team. This could take the form of a competency matrix with attached salary bandings.
Schedule regular career progression sessions with your team, in which you talk through where they might want to go next in their careers and how they are progressing towards that goal.
After releases of new projects or features, solicit feedback from product owners and other stakeholders on the value of the work, and pass this on to the team. Shout about your successes.
Of course, your job isn’t done after 6 months. It will take hard work to keep all these initiatives going, and new problems will crop up along the way.
But now you have a framework to work with. Conduct periodic reviews of your team’s health, carrying out the following steps:
Do this regularly, and there’s no doubt you’ll have a healthy, happy team that is great at what they do.