When I manage technical teams, I want to maximize developer efficiency. That’s not just good for the business (we want more and better stuff now!) – developers also want to be as productive as possible. Developers may not consciously seek roles where they can be productive, but if they’re in a situation where they aren’t efficient, they’ll want to leave. After looking back on previous teams I’ve managed and talking to former team members, I’ve compiled the following advice for developer efficiency:
Give your developers the space to do their work
1. Give developers the option to occasionally work remotely.
The number one thing that makes me less productive as a developer is a distracting work environment. This can come in many forms: open offices where you can’t help but hear your neighbors’ conversations, chat programs like Slack or HipChat, and regular interruptions from coworkers asking you questions.
You probably don’t have the power to fix these problems. If you’re in tech, you probably work in an open office and don’t have any influence to get your company into something better for developer efficiency.1If you do have the power to determine your company’s office space, Peopleware’s section on office spaces is great. Office etiquette is tough to establish: you probably can’t stop your employees from interrupting each other with chat notifications that imply urgency (regardless of how important something actually is). And when an employee wears big, noise-canceling headphones, not everyone will think, “okay, I shouldn’t interrupt them.”
You may not be able to fix these problems, but you can give your employees the freedom to escape these distractions. Not everyone works well from home, but some people thrive in that environment. Empower your developers to choose this for themselves.
I am not an advocate of fully remote work, but I like it as an option. There are a lot of intangible benefits to face time in an office. It builds comradery and trust among the team. And for an individual, face time really helps career-wise: when you work remotely, it’s easy to be out of sight, out of mind. Optics do matter, and if people interact with you face-to-face, they’ll have a higher opinion of you, even if you actually get more done when you’re working remotely.
2. Encourage your developers to hide in the office.
This goes along the same lines as letting your employees work remotely: if a developer is in the office and they really need to get something done, encourage them to find a quiet and isolated space. Have them grab an empty conference room and work out of there, or find a couch somewhere away from where they normally work. If other employees go looking for your developer for something urgent, they will find the employee.
Just like working remotely, this isn’t something you want your developers doing 100% of the time. It helps other employees, like QA engineers and product managers, when developers are available for spontaneous questions and brainstorming, even if that negatively impacts developer efficiency.
3. Set up core working hours when there aren’t any meetings.
Give your developers a few uninterrupted hours each day to use as a core working time. Block a time on your team’s calendars so that other people won’t schedule meetings during this time. Many challenging development tasks take a significant period of uninterrupted time to complete, so make that available to your developers. You don’t want them unable to start on their big important task because they have a meeting every other hour of the day.
Improve your development and product processes
4. Dedicate time to gradually improving your development processes.
You should be continually improving your development processes by assessing what’s working and what isn’t. I can’t tell you the next thing you should do to improve your processes: it’s very dependent on your company and team’s situation. Maybe you need a better build process. Maybe you need more standups. Maybe you need fewer standups.
As a manager, it’s easy to let process improvement slip among everything else you do. So, schedule regular meetings with yourself: block off time to think about process improvements and where your team struggles with developer efficiency. I typically set aside one hour a week where I’ll physically leave the office to go to a nearby coffee shop for a brainstorming session. Then, set up regular meetings with your team to suggest process improvements.2If you use agile methodology, your retrospective is a great time for that. Take things slow by implementing one process improvement at a time, and be sure to assess how it’s doing a month or two later.
5. Write detailed product requirements.
Sometimes, there just aren’t enough product managers to support the developers. If this is the case, sometimes you as a technical manager will have to step in and help write product requirements. Good product requirements can save your developers tons of wasted hours that are spent pursuing the wrong requirements. This is especially critical for remote teams since there might be language barriers and your team may not have the same working hours as your product managers.
6. Have extra work in the backlog.
This is another product department item that is especially important for remote developers. You want to have more work planned than your developers are currently working on. That way, if a developer gets blocked on their current work, they can pull in a bug or story from the product backlog and start working on it.
7. Have documentation. And, overexplain in your documentation.
If I’m training someone, I try write documentation for it. First, it’s a great tool for people to refer back to. (Do you retain everything you learn in a training session? I don’t.) Second, it helps your team scale since it makes training the next person easier.
Overexplain things: rather than say “check the code out from Bitbucket”, I state steps like “Download SourceTree” and go through the individual steps for setting up an SSH key with Bitbucket. When you write documentation, don’t assume. If you’re using nginx, keep in mind that whoever is using your documentation may have only ever used Apache. The minutia of your particular environment is not always intuitive. If you lay out specific steps, you can save someone a lot of time and therefore improve developer efficiency.
Empower your developers
8. Encourage feedback from your team on developer efficiency.
Let your employees know that you are open to feedback on the development process. When they do provide feedback, thank them for it even if you can’t immediately implement it. You want employees to feel free to make suggestions – after all, they’re closest to the work. As a manager, sometimes I’ve only spent 10% of my time in the code, so my team members were the experts on pain points in the development process.
Your team members may not give you immediate feedback, so stay persistent with letting them know you’re always open to suggestions. Your developers have probably learned to live with whatever processes are in place, and it may take them a bit to realize that the way things are currently done isn’t the best way to do things.
On the other hand, you may have developers who are always complaining about problems. For these developers, I say, “Thanks for pointing that out. When you get a chance, can you spend some time suggesting a solution to this problem?”
9. Be sure your team is aware of the bigger picture.
As a developer, it’s easy to get pigeon-holed into your day-to-day tasks. You work on stories or bug fixes, you roll them out, then you move on to more stories and bug fixes. It can be easy to lose context around how your work matters to the company. So, as a manager, I try to stay engaged with the business. If I see interesting metrics related to something my team did, I pass it along to the team. I might forward an email with email marketing metrics and say: “Hey guys, remember that email campaign we developed three months ago? Well, it’s now our best performing email. See the message below.”
I’ll also be sure to communicate company-wide efforts to my team. You want to be sure your team is aware of why you’re doing the tasks you’re currently doing.
