One of the greatest benefits from Agile ways of working is the metamorphosis of a disparate collection of independent thinking individuals into a cohesive team of codependent individuals bonded together by a common goal and vision, all rowing in the same direction.
From fully dependent teams waiting to be told…
- What to do
- When to do it
- How to do It
- Who to do it with
To semi-autonomous teams.
Semi-autonomous?
Why not fully-autonomous?
Most teams practicing agile ways of working have plenty of agency for everything they do except for a few sacred cows:
- Compensation – the team doesn’t decide who gets paid what
- Authority to hire/fire – the team doesn’t make its hiring or firing decisions
- Enterprise or corporate wide objectives – the team must accept those objectives as its guardrails
A key catalyst for this metamorphosis is evolving the team’s ability to
- Self-organize
- Self-manage
- Self-monitor
- Self-correct
- Self-heal
- Self-sustain
So much attention has been placed on achieving self-organizing, semi-autonomous development teams that far less attention has been placed on management teams and their ability to self-organize.
Why is that?
In my experience, there are a number of impediments and/or obstacles to developing any sort of self-organizing management team.
- A single corporate vision supported by multiple management missions. All managers may align on a common vision for the company but each manager will contribute towards achieving that vision in their own unique way following their own path.
- Few opportunities to work together. Unlike dedicated, stable development teams who work with each other all the time, management teams operate more like committees or decision-making bodies that come together only when needed.
- Ego (always) gets in the way. Managers who follow their own path and mission will often be oblivious to everything else around them. They are the centre of their own universe. Nothing else matters.
The consequence of this inability for managers to self-organize results in the company’s products and services falling prey to Conway’s Law.
“Organizations, who design systems, are constrained to produce designs which are copies of the communication structures of these organizations.”
Melvin Conway 1967
During a recent gathering of Product Managers, I got a glimpse into the birth of a self-organizing management team.
One of the Product Managers proposed an integrated end-to-end joint demo cutting across each of their individual products. Each developed by their own individual development teams.
It was an opportunity to
- Field test a new orchestration technology
- Verify the interoperability between their individual products
All towards delivering a new customer feature. The other Product Managers unanimously agreed.
And then, someone asked,
“Who will lead and coordinate?”
There was an awkward silence as the Product Managers looked at each other – hoping that one of them would volunteer. As long as it wasn’t them.
No one did.
Instead, each explained why they couldn’t do it.
“We’ve got too much on our plate right now”
“My product isn’t part of this end to end flow”
“I’m just the back end data guy. Shouldn’t this be coordinated from user interface perspective?”
I wish I could say that one of the product managers eventually stepped up to volunteer.
That didn’t happen.
What did happen was one of the Product Managers volun-telling the Release Manager to help lead and coordinate the joint demo.
Oh well, baby steps.
Nevertheless, I was just happy to see how a group of managers organically and spontaneously self-organized around a common goal that one of them proposed and that they could work on together to achieve.
Of course, their egos prevented them from doing more than they absolutely had too.
But, it was a start.
And hopefully in the end, prevent customers from experiencing Conway’s Law!
Next Chapter Consulting 