The hidden costs of hiring too fastI was making really great progress at instilling a culture of quality until the pressure above from to "hire more people!"
Last year I worked with an early stage VC-funded startup. When my contract begain there were probably 8 engineers across all disciplines (frontend, backend, mobile, etc). I set out to begin instilling quality, through mentoring, defining engineering guidelines, setting up automated hands-off deployments etc.
I felt I was really making great progress, until the pressure from above started coming down to “hire more people!”
On the one hand, this was understandable, at least superficially. We had certain product goals to meet, and we weren’t meeting them with the current engineering team.
On the other hand, from a more holistic view, the current team had just formed, and was only beginning to go through the storming stage. Expecting “performing” results from such a team is just unrealistic.
So the approach dictated to us was to hire as many new joiners as humanly possible (within budget—which was quite large).
The end result is that most of the progress I had made on instilling a culture of quality and excellence, of peers holding each other accountable for high standards, etc, was almost entirely lost within a 3-month time period.
Perhaps an argument can be made that this was the right decision for the company. Maybe for an early-stage VC-funded startup, this is the “right way” and the benefits outweigh the costs. This will have to be determined by those with more than one datapoint.
What I’m certain of is that this approach has a high cost. The human cost in this case was evident by the tremendous turnover that ensued—at one point, more than 10% of the entire company left in the same week (the same week my contract ended). The technical cost is manifest as technical debt, bugs, and unreliable software without quality built in from the beginning.
If you find yourself tempted to hire large numbers of people for your project, just be absolutely sure you know the cost this entails, and make an informed decision about wether the potential benefits are worth the high cost.
Adventures in DevOps 110: Building and Organizing DevOps Teams
The panel breaks down the process of building a "DevOps team".
Core skills vs. company-specific skills
Why are new joiners often quick to offer unwanted advice on how to improve things? Many "newbies" can't distinguish between core skills and company-specific skills.
Improve your software delivery