Hire Only When It Hurts!
Hire only when it hurts! Why is this generally good advice, what does it have to do with Brooks, Conway, DHH and Vassallo? Find out more!
Recently I stumbled upon a podcast snippet by David Heinemeier Hanson (“DHH”) explaining why you should hire someone only “when it is painful not to have this person“. This made me think about the currently hot topic of job/project search and hiring. Watch the whole snippet here:
The key message:
- avoid speculative hiring decisions based on what you might build in the future
- mind the negative productivity impact of adding more people
- when you hire to build a product, consider that your product will be quite different when designed by a large number of people
I tend to agree with this. But with a twist. Let’s discuss why:
Empiricism over speculation
DHH gives the example of venture capital (VC) backed companies / startups that are under a pressure to scale fast and therefore hire people continuously to be up for wild future growth projections without knowing if they will actually need them.
From a VC perspective this makes perfect sense when you are invested not only in one company but in a portfolio with your assumption being that most of these companies will fail while a small number will actually become successful and ideally reach “unicorn” status within the shortest time possible.
The KPI here is something like: profit from exit / (invested capital * time to exit)
VC funded founders may have a relatively smooth landing even when they fail (which most do) since they are often protected by their VC’s network and will be able to move on to the next blitzscaling entrepreneurial project (rinse and repeat).
From the perspective of an independent, bootstrapped company things look very different. If one crucial assumption behind the decision to scale up turns out to be wrong, this can put a quick end to the growth story and leave the founders with not only shattered hopes but also personal bankrupcy.
So it depends largely on your situation:
- Are you a VC backed blitzscaling startup that shoots for the moon and must engage in speculation to justify its existence?
- Or are you are a less (hyper-) ambitious enterprise – either coming from a traditional business background or a bootstrapped startup or solopreneur – that needs cashflow and a sustainable business model not just after a frantic scaling episode but asap?
When speculative “10x” growth is not part of your DNA and raison d’être, you may want to avoid such risks and instead go for slow, organic growth.
Dependencies vs productivity
The “Mythical Man-Month” by Fred Brooks, published already in 1975, is a classic of (proto-) agile literature. It explains how software development work can not simply be broken down into independent chunks in a way that would help with getting the whole thing done faster by parallelizing the work.
The way software – or generally complex integrated products – are constructed puts a limit to atomization and task breakdown. Especially when you aim for an integrated customer experience, things interdepend with each other. Touching one part may have unexpected or unforseeable effects on others.
Optimizing the output is limited by the channels of communication. Building products or delivering projects are social activities involving information-sharing across a social system.
So in short: adding people to a team – or adding teams to a team of teams – increases the complexity of communication leading to an increase of channels that already at numbers around 50 makes things extremely hard to communicate across the whole organization.
In more technical yet simple enough terms:
Potential structural complexity = n(n − 1) / 2
We can adapt Fred Brooks formula to show that the potential complexity of a system’s structural rises disproportionately with the size of the structural.
For example: given 50 components there are 50(50 − 1) / 2 = 1,225 potential interdependencies between them.
For example: given 100 components there are 100(100 − 1) / 2 = 4,450 potential interdependencies between them.
Quoted from G. Berrisford (here)
In technology project management this amounts to: things take much longer. The duration and / or the effort needed to keep up quality levels across team members increase at geometric rates when adding people beyond the number that you absolutely need.
Product and team complexity
And now add Conway’s law coined by Melvin Conway to the picture. It states that the way a system is designed corresponds to the structure of the organization that built it:
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.
M. Conway (see link)
Example: You aim for an easy to understand, user-friendly product: Then look at how you set up the team that is expected to build it. If you want to make your product very complicated, then set up a complicated org structure that needs org charts and handbooks to navigate.
On the qualitative side many things can be done to improve and optimize communication, transparency, reduce silos etc. Modern development tools as well as basically all lean and agile methodologies play their part to ease the pain of collaboration while keeping focus on delivering valuable products that are smoothly integrated across components, functions and features.
Still, also here there is an aspect of quantity. As described above, communication channels increase with the number of people involved. The larger the organization, the more one must invest in reducing the effects of scale on communication. And even with the best efforts (such as agile scaling frameworks, thing e.g. of SAFe) – there are limits.
Small bets over all-in
Here is something I learned from an amazing little online community called smallbets.com run by Daniel Vassallo and Louie Bacaj.
Being kind of vocal against VC funded startup culture, their main belief is: “Don’t be a bet in someone else’s portfolio!“
Instead, based on insights like the ones cited above along with a pinch of Talebian philosophy: build your own portfolio – and build it in the form of small bets.
This means for our context: Start small and stay small until there is empirically founded reason to believe that scaling will add value.
The smallest unit to start with which does not suffer from the negative effects of scaling the communication or the organization is a micro team or solopreneur.
By following a small bets strategy, one can effectively:
- Stay down to earth even when aiming for big growth targets, treating your projects like cattle, not like pets, i.e.: leverage upsides while avoiding big downsides.
- While not being able to “blitzscale”, operate at high level of productivity while growing organically, gathering experiences, adapting and pivoting without much inconvenience (other than leaving your own comfort zone)
- Build products that are super adapted for their niche and scenario. Being forced to cut corners in terms of big feature roadmaps and multi-year visions brings an almost automatic drive towards the shortest path from idea to value creation and customer delight!
Where does this leave us?
For employers these are tempting times. Being in an employers’ market where many tech experts have been laid off and are available, it may seem attractive to scale up your team hoping for better times to arrive when the one who secured all the precious talent will have an advantage.
This may happen – or not. And if it happens, who knows when it will happen?
The DHH / Conway / Brooks / Vassallo / Taleb strategy would say: be careful when speculating on the benefits of scaling and when betting too big. Be aware of complexity, risk and uncertainty! Keep things at a human scale, lean and agile – at least while you still know that you don’t know …
So finally, to come back to the beginning of this post … this is exactly why you should …
Hire only when it hurts!
… and of course you should: subscribe to The Pragmatic Agilist Newsletter:
And follow us on LinkedIn: https://www.linkedin.com/company/pragmaticagility-agisolve