Don’t Destroy Your Dev Team By Growing
“We’ve got a huge sale we can close if we can add these 5 features” the sales manager was saying. “They simply won’t buy without them.”
“Great, we should be ready with those in the next 8 months” responded the team lead.
The sales manager’s brow furrowed. “That simply won’t do, they’ll definitely buy another solution by then. We have 3 months if we want to have a shot.”
“We’d have to have 6 more people to even get close” the team lead fired back.
The president spoke up. “This sale could make our year, lets 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 teams 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 5 tips on how to grow safely before and after the interview.
Take the time to grow sustainably
9 women and 1 month do not a baby make
Every single person who is eligible to fly a jet with the Blue Angels is already an elite pilot. Even then, the Blue Angel’s can’t just add someone to their team and start flying with them on day 1. Similarly, when you hire someone, it takes them at least 2–3 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 2–3 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 2–3 weeks it hurts productivity. Hiring at a pace faster than 1 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
“Individual commitment to a group effort — that is what makes a team work, a company work, a society work, a civilization work.” — Vince Lombardi
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. Maybe your team goes out to lunch together on Thursdays, make sure you invite them to this outing on Tuesday. Maybe 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
“Coming together is a beginning; keeping together is progress; working together is success.” — Henry Ford
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
“We are all apprentices in a craft where no one ever becomes a master” — Ernest Hemingway
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 one 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
“If you’re any good at all, you know you can be better.” — Lindsey Buckingham
Just because you want a new member to become “part of the tribe”, doesn’t mean you can’t learn new things from them. Maybe they 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 short cut 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.
About Me
I’m Amir Yasin, a polyglot developer deeply interested in high performance, scalability, software architecture and generally solving hard problems. You can follow me on Medium where I blog about software engineering, follow me on Twitter where I occasionally say interesting things, or check out my contributions to the FOSS community on GitHub.
If you enjoyed this post, I’d really appreciate a recommend (just click the heart below).
Published in #SWLH (Startups, Wanderlust, and Life Hacking)
