Learning with Guilds

Some time ago, we stumbled on a way of looking at organising development teams courtesy of Spotify. According to this paper (PDF, and also an excellent read), Spotify organise their teams in several orthogonal ways.

We are quite similar.

Introducing Guilds

Spotify has Squads, Tribes, Chapters, and Guilds. Here, our Web Product (aka Engineering) Team has similar groupings; we have Initiative teams (like a Squad) focussing on an area for a defined period of time. Each one of these is roughly grouped into a Customer Development Area (Tribe), which might be “artist users”, for example.

We don’t have formal “Chapters” in the same way that Spotify does. In each Initiative Team, there are usually a range of skills represented, e.g. design and UX, programming, research and analytics, etc. The composition of each team depends on its needs.

What we do have is Guilds. They’re even called the same thing. This is where people with a shared special interest area can get together, discuss and learn more about that area. We currently have:

• The Technology Masons – looking at infrastructure/DevOps, information security, cloud technologies, etc.
• The House of D&D (Design & Development) – Design, UX, Front-end technology
• Product Scientists – How do we go about (Web) Product Development? What research skills can we use? How do we know what our users want?
• Software Craft – How can we be better programmers? Do we have the right application architecture? Are we good at software design?

A first attempt

At first, we assembled a set of “Guild leaders”, a pair to each guild, who went about defining areas that each guild would be responsible for. They outlined where our current weaknesses were, where there was risk in not attending to those areas, and what might be done to remediate them.

Several projects emerged from that process. These included some server capacity planning, security audits, code clean-up, and build improvements.

Although these projects were useful, there was little involvement from the rest of the team. Also our regular sharing meetings had become status updates for those projects.

Where we are now?

Once we realised that this model was not sustainable, we reflected on what we wanted to gain from having Guilds. Primarily, their function was to collect and distribute knowledge, provide guidance and to look ahead at wider trends relating to a subject.

To that end, we re-grouped the guilds to act more like a meet up group; gatherings of like-minded people, who want to discuss and learn about topics in that interest area. The topics of discussion and how the members go about learning about them is left up to the guild members themselves. These guilds include more people who have volunteered to take part, than the original pair.

We are also attempting to apply Lean’s Build/Measure/Learn cycle to how we approach things. As with Lean, the primary output we are looking for is Learning.
We are experimenting with different ways of developing that learning, and trying to apply the idea that we have a “customer” that we are trying to develop for. In this case though, the customer is us!

So far, the guilds have run some “Code Kata” workshops, and have investigated some of the less understood underlying technologies powering our site. The things we have learned from these activities are going to be presented to the wider team, and no doubt we’ll be seeing some blog posts on here about them as well in the coming weeks.

Where to next?

We’ll be keeping this blog up-to-date with anything interesting we learn from the efforts of the guilds. No doubt the form the guilds themselves will change over time, and we’ll write about any interesting developments there as well.