No More Premature Organization
I have now been in two companies trying to implement guilds. In both cases the first attempt failed.
Before we get to my theories around the reasons why, let’s first start with some background. A guild is “an association of artisans and merchants who oversee the practice of their craft in a particular area.” Guilds are not a new concept, they’ve been around for a solid four thousand years.
Then, about a decade ago, Spotify started to broadcast its internal organization structure, it consisted of four key building blocks:
- Squads: cross-functional teams that focus on one feature area (similar to Scrum teams).
- Tribes: a grouping of multiple squads in a similar area.
- Chapters: a meeting of people in the same functional area (e.g. front-end developers) that align on best practices for their area in their tribe.
- Guilds: a community of interest around a particular topic. Often similar to a chapter, but spanning the entire company.
Even if it is unclear whether Spotify really used the Spotify model itself (or for how long), elements of the “Spotify model” still make their appearance everywhere today. Even though part of the Spotify message always was “don’t do what we do, think about the problem like we do” many companies have cargo culted many of the elements of the Spotify model into their own organizations.
One popular one is guilds.
“We now have all our people organized into these cross-functional feature teams. In practice this means we have one or two front-end engineers, one or two back-end engineers, one Android engineer and one iOS engineer in a team. This worries me. How can those people still grow as engineers? How can we propagate best practices across all those siloed teams? How do we share knowledge, coding standards and all that jazz?”
“Well, Spotify has guilds!”
And so guilds make an appearance in your company.
One per functional area: A front-end guild. A back-end guild. A DevOps guild. A mobile guild. A QA guild.
They meet every week for an hour. Initially there’s a lot of energy in the room. “We are a guild! Let’s share all the knowledges, let’s decide all the things! Yeah!”
After week five there’s a struggle to fill an agenda with topics. After week ten, people are starting to drop off. After week fifteen, a meeting is skipped due to an empty agenda. After week twenty the initiative is canceled.
What happened? It worked for Spotify, so why not us?
There now have been two places where I’ve seen this happen, and I was intrigued. I volunteered to come up with a solution. The solution. To figure out how to do guilds well, once and for all.
I ran a survey. I collected results. I promised to make some recommendations soon.
And then… I got distracted by something else (squirrel!).
If anybody asks, I’ll claim I was practicing the subtle art of not doing sh*t consciously. As you know, sometimes the right action is inaction. So let’s just say that this was by design.
So what happened during this absolutely deliberate time of inaction?
In some (functional) areas the guild continued to meet and have productive meetings. In other areas, no guild meetings happened and everything was fine. In yet others, cracks started to show.
In various disconnected meetings, topics came up like which libraries to use to solve some particular problem. “Yeah, we cannot decide that in this group, we need to agree with this with everybody.” More and more topics like this started to appear left and right. “What about coding standards?” “What about linters?”
Until, finally, somebody raised their hand and said: “you know, we used to have a guild — wouldn’t that be something to try again?”
And so, that particular guild was rebooted, and it seems to be doing quite well today.
“Elephant paths,” or “desire paths” are paths that are not official, planned roads, but naturally form because enough people (or elephants) have taken that route for a path to naturally appear. We’ve all seen these, they’re very common in forests and parks.
The university where I once worked, at some point redid a lot of its campus with fresh lawns. They decided not to put in any pre-defined paths whatsoever, and for a year just let the students and staff roam the grass. Then, once the desired (elephant) paths were known, they’d pave them.
This approach always stuck with me.
In engineering we always have to fight “premature optimization.” Perhaps similarly, in shaping companies we have to fight “premature organization.”
Don’t try to solve something you suspect may become a problem in the future. Let the the organization hit that wall, and only then come up with paths around it — if paths haven’t appeared already in an unpaved capacity. That wall may never be hit, in which case you’ve just saved yourself a lot of organizational complexity. And often, those unpaved paths work just fine, and there’s no need to even pave them.
