This article is part of a series on Tech Hiring and Team Building by Amir Yasin. It first appeared on Medium.
“We’ve got a huge sale we can close if we add these five features,” the sales manager said. “They simply won’t buy without them.”
“Great, we should be ready with those in the next eight months,” responded the team lead.
The sales manager’s brow furrowed. “That simply won’t do. They’ll have another solution by then. We have three months if we want to have a shot.”
“We’d have to have six more people to even get close,” the team fired back.
The president spoke up. “This sale could make our year. Let’s get staffed up this month.”
This story plays out in lots of companies all around the world. I’ve seen it myself numerous times. The president of our fictionalized company doesn’t want to damage the team; he wants to make the sale. Unfortunately that single statement has probably lost him the sale and potentially doomed the team.
Dev team growth is about expanding your team’s working output while maintaining cohesion. Doing this properly is much harder than it sounds because of external pressures like “we’ll miss the sale of the year.” I’ve already written about how to interview tech candidates. Here are five tips on how to grow a team safely before and after the hiring interview.
Take the time to grow sustainably
Every single person who is eligible to fly a jet with the Blue Angels is already an elite pilot. Even then, the Blue Angels can’t just add someone to their team and start flying with them on Day 1. Similarly, when you hire someone, it takes at least two to three weeks to become productive. Most people accept that. Another truism that almost everyone in the trenches of tech already knows, but fewer accept, is that during those two to three weeks new members make the team worse. It’s not because they’re bad. It’s because they drain time and attention from other team members to answer questions and get information. Ultimately this makes them a productive team member, but for those two to three weeks, it hurts productivity.
Hiring at a pace faster than one new member per team every month puts a huge strain on the rest of the team. Not only does it drain your team’s time, but it can also increase the amount of time it takes for new members to become productive. It can even cause your team to fall apart as the pressure to produce “now that you have the manpower” increases while real productivity has actually gone down. The people you lose will, more likely than not, be people you can ill afford to lose.
Ensure team cohesion
In addition to reducing team effectiveness for a period of time, adding people to a team faster than once a month slows assimilation. When team assimilation is slowed, there’s a risk of damaging team cohesion. When a new member arrives to your team, it’s great to help them technically by answering questions about the code base etc., but where we as engineers often fail is the social aspect of making them a team member. If your team goes out to lunch together on Thursdays, make sure you invite the new member to this outing on Tuesday. If you have other social rituals, make sure they’re included. When you understand your co-workers, it’s easier to understand how to have open discussions about things like architecture and coding. Be as open to letting people go who detract from team cohesion as quickly as you would for technical reasons. It’s that important. This doesn’t mean fire people who don’t want to go to lunch with you, but if the team needs to walk on egg shells around a member, that member is probably not worth having around.
Spend time ensuring new member success
If team cohesion is critical, then everyone needs to get involved with it. During the month that you’re onboarding a new team member, it’s part of everyone’s job to help the new member succeed. Proactively ask if they have any questions about the code base. Ask if they have any questions about how things are done at the company (maybe help them find the most helpful HR person). Help them understand team dynamics (this doesn’t mean gossip about other team members). Take an interest in their opinions, and ask how they did things at their previous job. In short, make them feel like part of the tribe.
Maintain a good ratio of senior to junior
Smart, talented junior engineers are amazing. They bring energy and curiosity to a team and are the seeds from which senior engineers are born. Seeds, however, don’t become plants in a vacuum. They require light, fertile soil and water. Junior engineers also don’t become senior engineers in a vacuum. They need guidance from senior engineers. I believe the ideal ratio for senior to junior engineers is three senior to one junior engineer. Why three?
- Three senior engineers ensures that there’s very likely someone to be available to answer questions and provide guidance when needed.
- If one senior developer has a bad habit, there are two others to prevent the junior developer from picking it up.
- With at least three mentors, a junior member doesn’t eat up too much productivity from any one senior member of the team. This means that they are likely to be a net productivity positive to your team rather than eroding senior member effectiveness in equal or greater measure to what they add.
Be open to improvements
Just because you want a new member to become “part of the tribe” doesn’t mean you can’t learn new things from them. They could have advice on how to structure a sub-project more efficiently because they ran into that at their last gig. Maybe they have experience with an idea you’re just now starting to experiment with and can help you shortcut most of the pain. Maybe it’s some other suggestion that you hadn’t thought of. You didn’t hire this person because they were a clone of you. Take advantage of the infusion of this new work energy. In the same way that adding carbon to iron makes it stronger, becoming a melting pot of talent will make your team stronger.
Amir Yasin is a polyglot developer deeply interested in high performance, scalability, software architecture and generally solving hard problems. You can follow him on Medium and on Twitter, or you can check out his contributions to the FOSS community on GitHub.