Different ways of growing teams
Different companies have different growth needs, and they undergo their growth at different times and paces. Within companies that grow their development workforce, you can find companies that are almost always looking to hire people, at a stable pace, because their business and business prospects are also growing linearly. On the other side, you have companies that are about to take on a big challenge (in terms of the organization’s history) and need to grow fast to avoid missing the current business opportunities.
My last 4 jobs have been in companies that need to grow fast (some faster than other ones), and I’ve mainly experienced two different ways this growth usually takes place:
- Burst: understand how much more capacity (in terms of talent or manpower) you need and hire it as fast as you can get a hold of the talent. You will feel the output difference very early, as you get all your capacity “working” straight away. The biggest challenge lies in making sure more output is actually contributing to the original company goal, or if so many people were hired that some are pulling in a direction that does not contribute to the overarching goal. Another thing to take into account is whether your HR solution is able to onboard talent in big batches and follow up properly.
- Controlled: instead of hiring all at once, do it iteratively. Build individual teams “one by one” (or a rate that allows you to pivot and learn from your own process). This approach is less risky. It allows you to learn about your own process and is less tricky for new-joiners, but the growth is slower and the output difference takes more time to become a reality.
When deciding how to grow, remember the following:
“Adding manpower to a late software project makes it later.”
Fred Brooks in his 1975 book The Mythical Man-Month
What makes up a team?
A group of people assigned to work together is not a team. In order to build teams that produce greater results than the sum of the individual team member’s contribution, one must look at the soft side of software engineering.
In his book Peopleware: Productive Projects and Teams from 1987, Tom DeMarco and Timothy Lister introduce the concept of jell to define a particular phenomenon:
“Once a team begins to jell, the probability of success goes up dramatically. The team can become almost unstoppable, a juggernaut for success. Managing these juggernaut teams is a real pleasure. You spend most of your time just getting obstacles out of their way, clearing the path so that bystanders don’t get trampled underfoot. […] They don’t need to be managed in the traditional sense, and they certainly don’t need to be motivated. They’ve got momentum.”
When we understand that teams are made up of people that will work together (hopefully) for a very long time, the personality and ways of working of individuals play a big part in the team’s success. Even in the same organization, two teams can be very different and have different expectations for a new team member.
If you have 2 teams that need a front end engineer it is worth doing a debrief focusing on soft compatibilities and personalities, and not just team priorities in terms of business deadlines. The roadmap and future challenges a team will have can also be key differentials in retaining and motivating new joiners.
Thinking about your growth in terms of capacity requirements (man-hours, number of projects) instead of team requirements (teams that can solve problems within a domain), might lead you to a bunch of very good talent that doesn’t know how to work properly together. It might also lead you to the best possible talent that also works well together, but it is a gamble.
The role of the Engineering Manager
What is expected and what success looks like for an engineering manager (EM) changes widely from one company to the next one. The level of importance each company gives for business or completion objectives varies, and it should. What usually remains constant is the importance of the EM to hire new talent, retain existing talent, and helping team members in their career path.
Different stages of a company may require the role of the EM to have a bit less or a bit more of software involvement. In very mature and usually big companies, it is not very common to see EMs coding or discussing implementation details. Their day to day work revolves around identifying and resolving team blockers. In smaller startups, EMs are expected to help more with development tasks. At the end of the day, developers will do the heavy lifting in terms of work, so company objectives cannot be the responsibility of a single person (there are different ways to align goals, like OKRs). A manager can have different incentives to do so, but help from the development team is inevitable.
In terms of the number of direct reports, magic numbers are usually not very accurate. Some say a manager cannot have more than 7 direct reports, some say 10, some say more is possible. Being a role that requires so much soft skill, the number of people a manager can “take care of” depends greatly on the specific people he is managing and his own skillset in the current context. One thing is clear, at least for me: there is no way that a single person can be responsible for the growth and development of 20 people while still doing the rest of his job.
