Ray the Scientist, Egon the Engineer, Peter the Charmer and Winston the Muscle. Different competencies putting on matching overalls and embarking on a shared mission: saving NYC from ghosts.
Here’s how you can inject the same level of awesome to your Agile organization.
As I wrote earlier in The #1 Reason to do Agile, one of the key stinks of an Agile-hostile environment is organizing teams by competency: Tech teams, QA teams, UX teams etc. This setup is ripe for bottlenecks, handoffs and weird cross-prioritization exercises that kill autonomous end-to-end value creation.
The Ghostbusters didn’t have these problems. They were fully autonomous and cross-functional!
But what if they didn’t successfully eradicate the ghost problem in one fell swoop like in the movie, and had to scale up their operation? Should Egon hire and lead a team of engineers, and Ray a team of scientists? How will they organize when multiple ghosts need to be dealt with simultaneously?
The natural benefit of Egon setting up Ghostbusters Engineering is that every professional deserves to be managed by someone who understands their craft. Someone who can guide them to learn new skills, take their expertise to a new level and guide their career growth.
This isn’t possible when you’re managed by someone whose expertise isn’t the craft of your choice.
But you should also be able to exercise your craft in a group containing all the required skills to execute on their mission. Four Winstons would be useless in catching ghosts, but having exactly one Winston is critical for successful ghostbusting missions.
Decoupling Work and People Management
What the Ghostbusters need to do, is just read my earlier post on Product’s Job and consider the simple split between product and competencies outlined in it:
Product: Do the right things
Competencies: Do things right
What this gives us is a simple way of splitting the concept of “management” right down the middle.
Work
- What things are we working on?
- Why are we working on these things?
- When are we working on a thing and when do we expect to deliver it?
- Why is thing X more valuable / important than thing Y?
- Who is impacted by our work and how?
ie. “Do the right things”
People + Competency
- Who works for us?
- Are our people getting better at what they do every day?
- Are our people happy and motivated?
- Is person X solving problems with the same tools, approaches and methodologies as person Y?
- Are we staying current with the industry’s progress and best practices?
- Are we managing the shortcuts we take?
ie. “Do things right”
Allowing a do-the-right-things specialist to take over the first bucket and a do-things-right specialist take over the latter, everyone wins!
The “Spotify Model”
NOTE: I’m aware of all the criticism blindly following “The Spotify Model” has received in the past few years and it is completely valid: just copying a company’s playbook whole hog is an incredibly dumb idea. Context matters.
But just because copying Spotify 1:1 might not work for your org, it doesn’t mean the tools they’ve used are somehow faulty. You just need to put in the work to adapt to your organization and context.
The most famous real world implementation of this split is Spotify. Their essential presentation (part 1, part 2) on their Squads & Chapters model is a great example of a well-managed truly Agile environment that scales beyond a single team or product.
The foundation of this organization model is two views into one organization: by competency and by mission. Squads and Guilds.
Guilds
Everything starts with the classic competency-based org chart as the basis of your reporting structure and chain of command. As usual, it is built 100% based on crafts.
The teams at the branches of the org tree should be centered around a certain competency, like QA, front-end engineering, back-end engineering, UX and dev-ops.
Every team should be managed by a people + competency manager. UX designers reporting into a UX Manager, front-end engineers into a front-end engineering manager… and paranormal scientists into Ray Stantz.
This creates the backbone of your organization. Spotify calls them “chapters”, but I personally prefer to call them “guilds” as that’s a far more accurate description.
The word “guild” starts making sense if you view your organization as a classic fantasy role playing game (who doesn’t, duh!) To go do fun stuff, like slaying dragons or raiding dungeons, you’ll need a balanced party. To get that party, you need to assemble it from the various guilds of different character classes: warriors, mages, priests, thieves and so on.
This competency-based org chart is exactly that: your “character classes”. This redefines the role of the competency manager (or “guildmaster”) as the maintainer of the barracks.
- The master mage makes sure their guild attracts all the right mages, develops the most potent new spells and recognizes obscure new wands and staves.
- The front-end guildmaster makes sure his guild stays on top of the latest javascript frameworks (there’s always one), defines best practices for front-end engineering and makes sure all developers in the guild are leveling up.
Squads
While having guilds with proper barracks in town is the backbone of your operations, they’re useless unless the members of those guilds embark on valuable missions organized into balanced parties, or squads.
To kill a dragon, you need a certain composition of a squad, to rescue prisoners a different one. What makes a balanced squad depends completely on what talents are required to execute on its mission.
To succeed, a squad also needs a “squadleader”. Somebody who can guide the squad members coming from different backgrounds to unify into a holistic team.
Enter: the “do the right things” people. Product!
Just for the record, if RPGs aren’t your jam, I can also do this with an ice hockey analogy. Guilds are positions (wingers, centers, defenders and goalies) and squads are lines. To become a great player, you need to master your position and be trained by someone who knows how that position is played. To win games, you need to come together with a group of people of different positions and learn to pool your complementing skills.
All Together Now: Squads and Guilds
This model instantly removes the inherent overlap in having multiple managers for each team: a tech manager and a product manager. When both forms of management have their own unique view into the organization and clearly defined responsibilities, they can focus on what their strengths are in harmony.
This format allows competency specialists to focus on managing their craft and the people executing it. Instead of dates, commitments, deliverables, change and other boring stuff competency managers usually hate.
It also empowers Product Managers to take full control over the backlogs and commitments of their cross-functional Scrum teams. Us product folk are weird enough to enjoy that stuff.
Additionally, it gives clarity, purpose and identity for team members. Their guild defines who they are and their squad what they do.
The real secret sauce of the system is the interplay between squads and guilds, especially the communication between squadleaders and guildmasters. Guildmasters need to respect the sovereignty of the squadleaders to manage the work of their squad members and squadleaders need to view guildmasters as stakeholders of the highest order.
When done right, this structure provides the most fertile ground for doing Agile and Scrum in a larger organization. It provides responsible autonomy through a clear chain-of-command, not just for the competencies, but also for the outcomes of the work. It helps abolish handoffs and dependencies while elevating accountability. That sounds like true Agile to me!
When you couple this structure with executing Scrum meticulously in every squad, you also get clear visibility into what the organization is doing and where it’s headed.
But most importantly, it fosters an environment that gives focus, clarity and a sense of purpose for the actual people doing the work. It surrounds them with two equally important peer groups: their guild to support their growth as a practitioner of their craft and their squad to help them complete missions successfully.
Even if their mission is busting the Marshmallow Man.
Disclaimer
I am aware that in and of themselves, squads and guilds don’t scale infinitely. That is ok. I’m intentionally leaving out concepts, like “tribe” that the Spotify model defines. I will absolutely be following up soon with an article on “scaling squads and guilds”.
Squads and Guilds also need a certain set of prerequisites. More on that in 5 Things Squads and Guilds Need to Soar.
How does this scale up or down? Read Stages of Agile Product Organizations.
