5 Things Squads and Guilds Need to Soar
I‘ve made bold statements about the bliss of squads and guilds. What I didn’t tell you is that they are just some of the tools you need in your toolbox to make magic happen. Here’s a few things that need to be in place before the structure to really help it reach its maximum potential.
1. “Team First” Attitude
A really important aspect of operating in the squads and guilds model is filling the structure with people who strive to win as a team and are prepared to lose as a team.
Rockstars, ninjas, warlocks and other weird unicorn creatures are nice and all, but they don’t necessarily play well in teams.
You need mentors, teammates, teachers, guides, and healers. If I hadn’t already used my one annual sports metaphor, I’d say something about offensive lines and star quarterbacks.
You need people who want to be 10x developers. But not individually. The real heroes are 10x by 2x’ing everyone around them.
You need to establish an environment where squad members truly embrace collective output and don’t pass blame on other competencies in the squad when things fail. The squad wins or loses together. Everything from the shiniest pixel on the UI to the deepest darkest pits of the database has to sing in harmony.
You need guildmembers that truly care for their craft, across all squads. If one squad only has a junior front-end engineer, the way more senior front-end engineer of another squad should selflessly keep reaching out to make sure the junior is doing good.
Here’s a great article from my colleague JP LeBlanc on focusing your hiring on great people: Looking to Hire the Best Tech People? Focus on Non-tech Skills First
2. Leadership
While squads and guilds provide a nice tool to elevate mediocre leadership to ok and good leadership to great, it can’t save you from the inevitability of doom when a strong culture of leadership doesn’t exist.
As most systems, S&G is “garbage in, garbage out” — low quality input gives you 💩 output.
The clarity S&G gives for managing “the barracks” (humans & competency) and “the missions” (outcomes) should help make expectations for leadership clearer, but you still need people at the top layers who know what they are doing.
Read more about how to become an efficient leader of humans.
3. Respect for the System
The best way to torpedo a system is to not respect it throughout.
Examples of this are
- Product’s backlog ownership not being respected
- Product going too far dictating how things are done
- Squads not allowed to be truly autonomous
- Chain-of-command regularly bypassed by leadership
Diluting a system, structure or process by choosing to bypass it when it feels a bit inconvenient is the best way to make sure it becomes nothing but overhead.
Consider your morning routine as an example. You probably have a clear order of actions you take to make sure you remember to do all the essential activities: brush your teeth, eat a healthy breakfast, grab your phone & keys etc.
When you wake up late, do you panic and trash the routine or do you stick to it, just skipping the activities that aren’t necessary?
If you trash the routine, I bet you find yourself going to work with bad breath, underwear inside out, and without your phone and keys.
That’s you disrespecting your process.
4. Internal Open Source
To make sure squads remain fully autonomous while things are still shared when it makes sense, the whole organization should be conditionalized to operate like the open source community in the real world out there.
If I built my application on Drupal and it lacked a feature I needed, I wouldn’t send a whiny issue ticket to core Drupal maintainers and wait for them to deliver. I would build what I need as a custom module that extends the system.
If I was a responsible person, I would publish what I did as a reusable module.
Now when the next person who comes along with the same need with a few tweaks comes along doesn’t have to whine at the core Drupal maintainers nor me to get what they want. They can take what I did, extend it, tweak it, or fork it. They’d get what they want and would be able to contribute their addition back.
This is how a healthy company operates and builds out shared functionality internally. Loosely coupled and based on need.
This sounds technical, but it works for product and design as well. Replace technical functionality with “UX toolkit” or “brand guideline”. Squads and guilds give the perfect lines of communication to govern things like these through guilds.
5. Modern Tech Infra, Stack & Architecture
Sorry, product people. There are technical prerequisites in play too. Especially if we’re trying to transform a legacy organization.
You need suitably decoupled services, sophisticated feature flag mechanisms, robust infrastructure, really kick-ass dev ops and other hallmarks of a modern tech infrastructure that removes a lot of the obstacles that require teams to be tightly coupled and strict central governance over implementation.
If you try to implement this on a fragile old-school monolith, you may find yourself frustrated quite often. Sorry, COBOL friends!
While this list is framed as prerequisites for operating squads and guilds efficiently, they are equally beneficial for any Agile environment. Whether you’re running flat, going old school or running some weird advanced fifth dimension tesseract model, you should get mileage out of checking whether you’ve got these five things on fleek.
Interested in how to apply this to different sized organizations? Read this.
Like What you Read?
- Join my Email Gang on TinyLetter! One weekly email, no spam, no ads.
- Please join the discussion in the comments below!
- Read more about why I’m writing these posts:
