You are either afraid or happy to be growing your development team, both are completely rational responses and emotions when considering this task.
You might be happy because your team is struggling, they are drowning in work, they need more bodies, new skills or maybe a refactor to what they are doing and how they are doing it.
Even if you are drowning, you might be afraid to add new bodies, inject new skills or refactor what you are doing because you have a really good thing going on with your current group and you don’t want to rock the boat or shift the balance
I’m going to do this as a series where I look to tackle each of these paths for growth — increasing headcount, adding extra skills, or a straight-up refactor.
Adding Bodies to the Team
When we think of growth, we tend to focus on people, bodies, headcount. It’s an easy metric because if your team is drowning in work, it can be simple — give them these five things and that prevents the rest of the team from being overloaded.
When I think of headcount, I think of a conversation I had with a Database Administrator when we used to manage our servers and we had to do performance tuning of our applications to see what we needed to do to make them perform well.
Sometimes you need to add more memory, sometimes the server is underpowered and we just need more hardware. But we need to exhaust every avenue before we get there.
This is the approach you should think of when considering headcount — not the first, only add heads, when you need them when every other avenue has been exhausted.
Adding three new projects onto our plate that will be multi-year engagements? Probably need some new Developers.
Need someone dedicated to a skunkworks project for a year? Probably need someone.
Don’t Disrupt Delivery
I have a project right now where we are behind a bit on our overall deliverable (one month), but we have two developers that are working so well together that to throw someone into the mix, eight months before we ship would probably ruin the synergy they have going for them. No one is overloaded, our release date isn’t changing, so it’s steady as she goes. I don’t want to add more heads to that group because it will disrupt our delivery and put us into chaos.
When adding bodies, this is one of the most important aspects of adding a new body to consider — what will be the disruption impact to your team? Will it be months? Weeks? How long will someone spend trying to train up the new team member? A month? Will it be ongoing? What will be the impact to you?
Can you handle onboarding someone to your team at the current juncture you are in?
Explaining this to those that sign the bills, those that are in charge of what you do and what you deliver can be hard to hear. They want to add, they want to grow, they want to deliver, the sooner, the better. These are tough conversations, they are not easy, if done right, you can (and you need to get them onto your side).
Integrating them is Key
Now you have that new hire, you’ve grown your team. You can see everyone letting out a brief sigh as they know this means, some tasks will start to be shared around. Now the hard part begins, integrating them into what you are leading.
Integration of a new hire to your team is not talked about nearly enough. Sure we talk about onboarding and “wow, look at all the gifts I got on my first day” but we don’t talk about integrating them and how we can get that new hire to be a producing, contributing member of your team.
Senior Developers still take close to two months to become contributing members of your team — despite being great coders, they have to learn domain knowledge, current practices, team member idiosyncrasies, and what business they are coding for. For Juniors, it’s a bit longer.
My goal is to always get this number to six weeks, sometimes I succeed, sometimes I fail. What I have found in the past to be successful is to start them working on small things that generate large value — bugs. Get them going on bugs, they are in your system, it will force them to talk to your team, your customers, and you as they navigate this world of what they are working on. From here you will start to see how they work, what kind of velocity they can achieve, and get a variety of feedback points from your team and customer.
As they work through each bug you can load them up on more challenging work that pushes them, all while keeping them off the critical path. They are going to get there, but you need them to be a part of the team before they do because when they take on that new feature, they are going to need to be comfortable having people to lean on (you and your team) and not being afraid to ask questions (customers and product managers).
There are other components to integrating a new member into your team, for now I wanted to focus on the skills.
At some point, adding bodies to your team will no longer help you grow. You’ve reached that point where you can no longer grow physically and now you need to find other ways to grow your team, this is what we are going to look into next, how to grow your team but not expand them.