This episode is part of a recruitment mini-series; where I will be focusing on various characteristics that I believe are important in recruitment. And while I believe many of these themes are universal, I will of course be focusing on software development. Somewhat at odds with the title of the mini-series, I first ask the question: "should you be recruiting at all?" I find many organisations are recruiting when they shouldn't be ... Along with more than a few that should be recruiting and aren't. I believe our traditional management techniques would have us recruit to solve the wrong types of problems - which can often produce the opposite of the desired outcome. In this episode, I will be looking at some of the reasons why recruitment may not be solving the right problem.
Or listen at:
Published: Wed, 05 Feb 2020 16:44:24 GMT
Transcript
Your software development work is going slower than you'd like.
The team are working flat out.
Is you first instinct to recruit more?
If so, then you are exactly why I wanted to start a mini-series on recruitment with the question "Should you be recruiting at all? Is it solving the right problem?".
We often think that by increasing the number of developers we will linearly increase the output of the team.
By increasing a development team from 5 to 10 we expect 100% more development to be done. We've double the number of people, so surely that doubles the amount of output.
Unfortunately, no.
If anything we will normally find that adding those additional developers greatly impacts the additional developers to the point that the overall output drops to a fraction of what it was prior to the recruitment effort.
This seems counter intuitive and I'll come back to the reasons why later in this episode.
Before we go into that however I want to talk about why the quantity of hands on keyboards isn't the problem you should be focused on.
Its common for the perception to be that the act of developing is slow and laborious.
We make a request for a change ... And months later we may finally receive it.
It certainly isn't uncommon to feel that requests are made to a development team - and that it can take months to be done - if at all.
And the common perception is that everything is stuck with the developers - and the obvious question of why are they taking so long?
And this misconception is one of the fundamental reasons why I do this podcast.
From the outside, it often feels as if its stuck with the "developers" - thus increasing the developers would improve the situation.
Let me give you an example of a recent project I was involved in;
A director requested that we integrate with a third party organisation.
The technical development work of integrating with the third party was maybe 2-3 weeks worth of work at most. But for the director it appeared to take closer to 3 months.
When the request first arrived with me, it was clear that there was some important contractual conversations that needed to occur with the 3rd party. It was clear that the outcome of that conversation would greatly affect the technical development work - or indeed if it could be done at all.
Around 6 weeks after raising this through the appropriate channels. We received the confirmation back that the everything has been agreed.
We could start on the technical development work.
So we spent an afternoon outlining the solution - which systems it would impact, how sensitive data would be stored and how it would work.
After a further two weeks gaining approvals from the relevant authorities that the solution was acceptable - which was around 3 half hour meetings - we had the green light to start building the solution.
Unfortunately due to the timing, I pretty much immediately took leave for two weeks over the festive period.
With only myself really working on the project, this effectively meant all worked stopped until I returned.
On my return, I ploughed on with producing the majority of the solution.
Only then to be halted by the 3rd party requiring additional contract changes before they would release the relevant access to their system.
And it went on and on and on.
So while the frustrated director felt that it had taken 3 month to do the work, I was probably only working on it 2-3 weeks in that time.
Everything else was outside of my control.
So would it have helped to have recruited additional developers to help me?
Not in terms of providing value - we wouldn't have produced the end result any quicker - because it was outside of developer control.
The system around my development work is what consumed so much of the time.
Edward Deming wrote:
"the system that people work in and the interaction with people may account for 90 or 95 percent of performance."
In effect, me working harder or faster was not going to impact the outcome significantly - due to that organisation system I was working within.
I've previously talked about Lean and the act of minimising any work that isn't adding value.
Its common with Lean analysis to use value stream mapping to look at the end to end organisation system to identify those things that add value - and those that are waste. Then work to reduce those wastes as much as possible.
And it is this work that I find generally hasn't been done before an organisation starts recruiting.
The organisation is in a poor place with its operation practices and systems - and it is this that needs to be addressed rather than recruiting more people.
Recruiting more will simply lead to more expense ... And generally less outcome. And this quickly can become a spiral.
Many high profile projects in history have failed because of the lack of this understanding. They have failed to identify and resolve the core problems - thinking that throwing more people at it would save them.
So, before we jump into the recruiting activity we should be confident that it is the right thing to do.
We should be aware of how mature our operations practices and systems are. We should be organisationally self aware enough to understand if that additional recruitment is actually going to help ... Or should we be investing the time and effort into improving those practices and systems.
In the last episode I introduced this mini-series by saying that recruitment should be a thoughtful, thorough activity. It shouldn't be rushed - and this is a key reason why.
Understanding and improving your organisation's maturity is a sizable subject and is something at the core of this entire podcast series. We've already covered many primers on how to think about your organisation in terms of understand this maturity.
I'd certainly be looking at many of the practices I've discussed previously such as Continuous Integration, Delivery and Deployment, Pair and Mob programming, testing and monitoring.
I would also strongly advocate comparing your organisation against the State of DevOps report I talked about in episode 13. This provides not just a great means of measurement - but also concrete advice on where to go next.
Measuring the maturity of your organisation and implementing any improvements are not quick activities - and certainly aren't practical if you are in desperate need for more developers.
Again, going back to what I was saying, you need to have the time for that thoughtful and thorough activity.
Again, when is the best time to plant a tree?
Ok so, lets close out this episode by returning to the statement I made earlier - why does adding more developers to a team make it perform worse?
Adding extra members to any team will initially slow them down.
There will be effort required to integrate those individuals into the team, how they work, what they are working on, etc - a lot of getting the new person up to speed.
The amount of effort to get that person "up to speed" is dependant on how complicated the work is.
Software Development is complex by its very nature - so there will be more effort by default than most new employees.
But then it becomes more complicated by the complexity of any given project - and how well it is understood.
And a lot of this depends on how good the organisation and the development team are providing everything needed.
In the worst cases, its more than possible for new hires to be still struggling months in to be up to speed. Largely because everyone else is running around doing super important things.
The other think to consider is team size.
According to Jeff Bezos, founder and CEO of Amazon.com, the ideal size is a "two pizza team" - if a team cannot be fed with two pizzas, then its too big.
This comes from once a team reaches a certain size, the overheads to operate it start to outweigh the benefits of the additional individuals.
The simple acts of communication and collaboration between 3 people is magnitudes easier than 30.
Thus Jeff's "two pizza team" comment. If that team has grown beyond that point you have to start considering breaking the work down in a sensible manner and spinning off a new team.
The Scrum Guide, a set of practices and rules based on the agile principals, says:
"Optimal Development Team size is small enough to remain nimble and large enough to complete significant work [...]. Fewer than three Development Team members decrease interaction and results in smaller productivity gains. Smaller Development Teams may encounter skill constraints [...], causing the Development Team to be unable to deliver a potentially releasable Increment. Having more than nine members requires too much coordination. Large Development Teams generate too much complexity for an empirical process to be useful"
Again, its not uncommon for large teams to effectively stagnate due to the complexity. And of course this is only made worse by well meaning executives "adding more bodies".
What is meant as an attempt to move the team forwards is causing the exact opposite affect.
In this episode I've asked the question "Should you be recruiting at all? Is it solving the right problem?"
I've talked about how, often recruitment is either addressing an entirely incorrectly perceived problem or is actually having the complete opposite of the desired result.
Taking the time to consider your own organisations situation will help to avoid very costly negative recruitment.