Autonomous teams vs ‘resource’ management

How often have you heard the phrase “We don’t have the resource” or “How many resources will it take?”

Quite apart from the dehumanising nature of the word “resource” (should we, in response, say “that’s a good question, management resource number 3”?), people are not automatons who are all equally skilled/motivated coding machines that can be assumed to be equally effective in all scenarios.

People each have unique skills, ways of working, areas of experience, interests and relationships with others that all matter heavily in terms of getting the best results, or getting anything at all.

“Put two resources on this…”

This is the challenge and the joy of managing a team, as you get to know each member of the team, you start seeing how each members works, what keeps them engaged and effective. In return, engaged and effective people make for an excellent team to manage.
This is why it kills me a bit every time I have to grin and bear this idea that it’s sensible to “put N resources on this”. 
Now, an experience team manager might just nod and manage the gap between the ask and the reality on the ground, but it wouldn’t manifest as two full time engineers beavering away on only that task every day.

While we’re on the subject, Scott Adams, as usual, hits the nail on the head: https://dilbert.com/strip/1995-09-22

Have you seen this before? A resource mountain chart where the total capacity of your development function is lower than the identified work and people are expected just to move from one project to the next, unhindered – perhaps you hear mutters of concern before we move quickly on to the next slide. How does this represent whether someone on project 3 can effectively contribute to project 4 or not, the unknown unknowns, the bring up time, the cognitive load, to name but a few. I’ve often wondered whether it’s secretly seen as a good thing that the staff are having to deal with more work than there’s capacity to handle (assuming the estimates mean anything much at all) – it comes up a lot in phasing such as “keeping their feet to the fire” or “running lean”.

It’s a bit more complicated than that

Generating resource mountain charts are a fantastic way to distract your teams from doing valuable work in order to give the illusion of control and comfort that everyone’s fully utilised. 

My experience as a technical project manager who prefers to locate and work closely with the technical teams, is that they are almost *never* working on what the mountain chart says they should be. 
Why? Because the reality on the ground is that priorities change, people are complex, the work is complex and the very idea of detailed predictability around who’s working on what beyond a few weeks is pure fantasy, especially in larger companies, particularly in software.

What’s the alternative?

Would it sound unprofessional to say that we perhaps shouldn’t fully load everyone with necessary work? It sounds non-intuitive, but it’s beneficial for several reasons & a subject for another blog. For now, bear with me on this idea.

How about we create cross-skill teams that can manage autonomously? Depending on the number of independent skill sets required for your business, it may be possible to create multiple, similarly capable teams. In the case of businesses with a high number of specialised skills required, teams that can manage specific aspects of your product or service.
The key is that these teams need to have all the skills embedded in the team to allow them to complete tasks end to end. This vastly reduces the need for expensive coordination effort across teams when coupled with a modular architecture and decent CI/CD infrastructure.

Once you have your autonomous teams, the input simply becomes a prioritised list of features/stories/business needs that the team can own and deliver by themselves.
What are your thoughts? Have you tried this approach? Did it work for you?

Some handy references

https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/
https://blog.newrelic.com/culture/autonomous-teams-what-they-are-and-why-you-should-care/
https://www.mindtheproduct.com/2018/02/team-smarter-autonomous-product-teams-work-better/

Thanks for reading!