Most companies I have worked for, experienced rapid growth of their workforce, by doubling or tripling in size in the span of a year or two. That growth was motivated by the need to meet aggressive objectives, be it meeting a given active users number target, reaching profitability, unlocking new markets, or creating new business units in an effort to uncover new business opportunities.
The most naive growth pattern consists in injecting those new resources into existing feature teams, hoping that they would increase their ability to ship a higher number of initiatives per quarter.
Often I have seen this growth happening too fast, without understanding the reasons why any additional resources would be needed in the first place.
Before blindly adding resources, it is important to ensure that growth happens for the right reasons. If it is the case, it is important to direct that growth at the right places. For instance growth can happen because teams don't meet their objectives, with the assumption that they are under-staffed. While it might be true, it is not necessarily the case. Often, it is due to lower productivity caused by working on brittle engineering foundations.
Working on brittle engineering foundations
The team doesn't deliver fast because they spend too much time dealing with foundational engineering problems, making it hard to do common things such as:
- Properly releasing software in an agile manner.
- Building the project fast.
- Running automation tests.
- Testing their changes on a staging environment.
- Observing the state of their apps and services in production.
- Running experiments easily.
As a consequence, engineers waste time by using the wrong tools for the job, or by re-inventing the wheel to common problems that could have been solved at a more global level.
Simply adding new resources to feature teams experiencing this, will only exacerbate the symptoms caused by them.
- If you can't release easily with 4 engineers, don't expect that this will become any easier with 8 engineers.
- If you can't observe the state of your services and applications when you ship 1 feature per month, what do you think will happen if you ship 2 or 3 features a month?
- If your engineers don't write automated tests, then your teams are probably wasting time doing manual tests. What will happen to the time that it takes to manually test your software, if you ship more features?
Understanding those engineering bottlenecks and their effect on the day-to-day working habits of your teams is important to figure out the right fix for this.
Solution
Address the brittleness of your engineering foundations by creating dedicated teams that will solve those problems. A common mistake, at this point is to hope that the feature teams themselves can dedicate some time to address those problems. This is counter-productive and ineffective as it decreases the focus of the team (a team must stay focused on its mission and on meeting its KPIs), additionally the common feature engineer won't necessarily have the right skills, mindset or desire to work on engineering productivity topics.
Building a specific team, or group, to address those issues has the following benefits:
- The teams can hire engineers who have the right skills for that mission.
- Internal engineers who would love to further their skills in those areas can regain motivation and energy by joining one of those teams.
- The feature teams stay focused on delivering their roadmap items, and meeting their KPIs.
- The risk of having different engineers in different teams working on the same foundational items is reduced.
Additionally, this sends a strong signal to all the teams that engineering productivity matters, and that going forward emphasis will be put on building and shipping software the right way.
Much like in powerlifting where it is important to build stronger foundations before putting additional weights on a barbell, I believe it is important to have stronger engineering foundations, as you grow your feature teams. Stronger engineering foundations don't happen accidentally, they are the result of a deliberate effort that require dedicated teams and engineers with the right skills.
Finally, this thread by Gergely Orosz provides an interesting read on this topic: twitter.com/gergelyorosz/status/14356877958.., including thoughts on when is the right time to start putting together a foundation team.