A lot of software development team managers were developers who got promoted into the role. They have all of the technical background needed to do a fantastic job but don’t have any formal management training.
After reading our 17 tips for managing software development teams, any development manager will be in a fabulous position to make their team thrive.
1. Schedule Regular 1:1s
A 1:1, or 1 on 1, is a meeting between you and one member of your team who reports to you. It is a dedicated time to check in with each other.
The meeting should be considered a safe space for your direct report to speak candidly about what is bothering them and what you can do to support them.
Regular 1:1s are one of the easiest ways to get to know members of your team and have a positive influence on the work they do. They are key as to how to manage a software development team.
Your role as manager may put you in the position of project manager as well, so asking your direct reports about their progress from last week and plans for this week and the next will help you guide the whole team on joint projects in an organized fashion.
Aim for once every two weeks, and adjust based on what works well for you and your team.
2. Empower Your Team to Make Decisions
Managers aren’t providing value when they need to be involved in every decision. Any time someone on your team asks for permission for something, and you feel they could have made the call on their own, tell them. Encourage your team to make responsible decisions independently.
The more decisions your team makes on its own, the fewer choices you need to make. In this way, freeing up your time also gives your team autonomy. Things will happen faster, which is better for everyone.
As an example, giving members of your team access to the company card and allowing them to make purchasing decisions up to a particular value is an excellent way to show this empowerment.
3. Distill Information From Management to Your Technical Team
Distilling information means taking it from the form you received it and changing it to suit the people you want to share it with.
Just as you have a support team to translate what developers say so that customers can understand, as a manager you translate what upper management writes so that your team can understand. Especially if you distill the message down to only what your team will care about, means you are respecting your team’s time and skills, and providing value.
An example of this could be if you receive a quarterly report that includes stats from all across the business, but only one of the tables talks about the application uptime, one of your team’s key metrics. Share the table, not the entire report.
4. Set Clear Goals for Your Software Team
Your team will work best when it has clear objectives to meet. They can only know what you expect of them if you share these goals.
These goals must be somewhere public, as new people join the team you don’t want to rely on assumed knowledge.
If you’d like some tips on goal setting, we have a post on setting useful software development metrics.
Pro Tip: Code faster with TextExpander
TextExpander makes it easy to save commonly-used code snippets, documentation comments, and more — then insert them anywhere you type with a simple shortcut or inline search.
Click here to learn more.
5. Set Clear Individual Goals
Tied to your overall team goals are individual goals; these are the expectations and goals set for each member of the team. While they should have some bearing on business goals, the main driver should be personal development.
Setting these goals out early helps to frame any future conversation.
All too often, these goals are discussed once per year, during an appraisal meeting and get promptly forgotten. Having regular 1:1s is a great way to avoid this mistake.
6. Feed Concerns Up the Chain
Some of the concerns that your team has will not be within your power to fix. When this happens, you need to be good at feeding concerns up the management chain.
Communication is vital here. You need to package the concern up in a way that is useful to your manager, and you need to communicate your intent with the person who raised the matter.
If someone raised an issue that needs clearance from your boss, you could respond with the following:
Thank you for bringing this to my attention. I will need to run this by my manager, which I will do today. I’ll have a decision for you by our next meeting.
7. Be Consistent in How You Manage Your Software Team
Consistency as a manager means acting predictably.
If you treat some issues very casually, but others in a very formal manner, then your staff cannot know how best to share a problem with you.
You should also strive for consistency when performing work. If you say you will do something by a particular time, make sure that happens. Doing so helps build trust between you and your team.
8. Have an Open-Door Policy
Having an open-door policy means that any time one of your team members needs help you make time to speak with them.
Your main job as a manager is to keep your team running smoothly. This means removing blockers and being there for your team.
It isn’t enough to have an open-door policy; the policy needs to be communicated to the team.
9. Know the Skillsets in Your Team
Software development teams are made up of people with a vast range of skillsets. Make sure you know which particular skills your team members have. This makes it easier to allocate work on projects and plan for personal growth.
A naive manager might split their technical team into frontend and backend developers, but there is more nuance to these skills than two categories. Knowing who is excited by accessibility means you are better positioned to bring the correct person into a meeting.
You don’t need to be an expert in the skills that make up your team, but you should have enough of a high-level overview to know who to speak to when expert knowledge is required.
10. Get Out of the Way
Getting out of the way is a nice way of saying; don’t micromanage. You’ve hired a team of skilled people, and if you’re doing everything else on this list, then you’ve set them up for success.
Don’t get in your team’s way by micromanaging every decision, or by trying to stamp your authority on their work. Let your people do what they’re paid to do.
A great way to avoid the temptation of micromanaging is to instill a culture of remote work. If you aren’t physically next to your team, you’re less likely to inject yourself in when it isn’t required.
11. Set the Example
Setting the example is about managing by doing. If you want meetings to start on time, make sure you’re always there on time. If you want your developers writing issues with precise details, make sure you always write first-class tickets.
Many managers expect their team to behave in ways in which they do not personally act. By living the example, you are building trust and establishing the expected culture.
12. Give as Much Context as Possible
When setting tasks or passing on a directive, you should strive to provide as much context as possible.
You have a team of smart software developers, by letting them know why they should do something instead of just what they have to do, they can work more effectively. They know what their time is worth just as you do, and they don’t want to waste time if they can find a better way to do something.
Knowing the spirit in which something was asked allows solutions to be more proactive and assures they address the underlying issues.
For example, a request might be to not post about a new product on social media, but without knowing why, they may tell their friends about the product. If the reason is that it is under NDA and telling others would break a contract, then you can see how the context is essential.
13. Explain Your Decisions
As a manager, you will have to make decisions that people don’t agree with.
Sometimes seeking complete consensus isn’t the best course of action. When this is the case, you should be prepared to explain your decisions.
Thorough explanations help to preempt questions your team might have and help justify future decisions.
Stopping paid overtime for the next quarter could sound like a thoughtless move, but if you explain your rationale, your team will be more likely to accept it.
14. Set a Training Budget
By setting a clear budget for training, in both money and time, and setting the expectations of how or when the budget needs to be used, you can help your team plan training that is going to work for them.
Everyone learns differently. Some people want to attend conferences; others wish to access online courses, others still, might want to read books. Let each member of your staff learn in the way that is appropriate to them and back it up with the budget. This couple be as simple as a team plan for O’Reilly.
If your team isn’t spending its budget, you should find out why.
15. Encourage Open Communication
Open communication is accessible to anyone who cares to hear it.
Instead of sending a private message, send it in a public channel. Instead of an email, consider an article on the company intranet.
Practicing open communication helps to manage at scale, reduces duplicated work, and sets an example that excellent communication should be accessible to all.
For private or sensitive matters, of course address these in person, 1:1s are a perfect place for that.
16. Write Things Down
Writing things down is an excellent way of staying consistent, communicating in the open, and sharing your thoughts more constructively.
If a meeting has happened between two people, outcomes should be written up and shared with relevant people. People who weren’t in the meeting can benefit and get much-needed context. It also means the same meeting doesn’t need to happen again.
Some teams will write down their working practices into what is known as a playbook. The dxw Playbook is an excellent example of a team writing things down.
17. Recognize Hard Work
Software development is a hard job, and one with hard-to-quantify results. Unlike sales teams, which can quickly put numbers on their work, it is hard for software development work to get recognized.
When someone has done an excellent job or has exhibited a behaviour you want to encourage in the team, call out that work and publicly recognize it.
Perhaps someone wrote an excellent note to accompany a pull request, share it with the team and publicly thank the person for going above and beyond.
How Do You Manage a Software Development Team?
Do you lead a software development team? What have you found makes for an excellent engineering manager? Let us know in the comments.