A common misconception is adding more people will speed things up. Often this can lead to only marginal gains and ๐ฎ๐ข๐บ ๐ฆ๐ท๐ฆ๐ฏ ๐ด๐ญ๐ฐ๐ธ ๐ต๐ฉ๐ช๐ฏ๐จ๐ด ๐ฅ๐ฐ๐ธ๐ฏ by exacerbating existing inefficiencies.
Here are some of the common reasons why ๐
๐ง Key person dependencies – bottlenecks on particular individuals.
๐ค Lack of automated testing – resulting in lengthy (and error prone) manual testing required for each release.
๐งฉ Complex code – significant effort often required even for small changes.
๐ฏ Lack of clear prioritisation and focus – trying to do too much at the same time and regularly shifting priorities meaning everything goes more slowly ๐.
โ Unclear requirements – resulting in a high change failure rate and lots of re-work.
๐ค Lack of collaboration – working as a group of individuals rather than a team – exacerbating bottlenecks on key individuals and roles.
๐ Low talent density – skill gaps and lack of familiarity with modern best practices, unable to ๐ฅ๐ฐ ๐ต๐ฉ๐ฆ ๐ฉ๐ข๐ณ๐ฅ ๐ธ๐ฐ๐ณ๐ฌ ๐ต๐ฐ ๐ฎ๐ข๐ฌ๐ฆ ๐ต๐ฉ๐ช๐ฏ๐จ๐ด ๐ด๐ช๐ฎ๐ฑ๐ญ๐ฆ (edit: added)
If you’re experiencing some of the challenges above, I generally recommend focusing on improving how your existing team operates ๐ฃ๐ฆ๐ง๐ฐ๐ณ๐ฆ adding more people (which might mean temporarily bringing in specialist support to address specific skills gaps).
The double benefit is in the short term, you get a greater impact from your existing team, and when you do decide to grow, it will increase the impact of any new roles you bring in.
As I’ll regularly say, ๐ฅ๐ฐ ๐ญ๐ฆ๐ด๐ด, ๐ฃ๐ฆ๐ต๐ต๐ฆ๐ณ and ๐ด๐ญ๐ฐ๐ธ ๐ฅ๐ฐ๐ธ๐ฏ ๐ต๐ฐ ๐ด๐ฑ๐ฆ๐ฆ๐ฅ ๐ถ๐ฑ.
Scaling tech teams: it’s not just about adding more people
Leave a reply