Don’t Destroy Your Dev Team By Growing

Oct 27, 2015 · 6 min read
Image for post
Image for post
The Blue Angels — If they don’t work as a team they all die a fiery death

“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

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

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

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 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

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).

Image for post
Image for post

Published in #SWLH (Startups, Wanderlust, and Life Hacking)

Image for post
Image for post
Image for post
Image for post
Image for post
Image for post

The Startup

Medium's largest active publication, followed by +756K people. Follow to join our community.

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store