The Giant Swarm Model Explained

by Larissa Lanz on Sep 4, 2020

The Giant Swarm Model Explained image thumbnail

It’s not just what you do, but how you do it.

Describing the way we work is something I do on a daily basis during our interviewing process. And in that sense, describing the way we work is fairly easy. But when it comes to the question of whether this is actually working well, we get to a whole new level of discussion… This is especially true as we’re working in a very agile way and adapt and change processes and set-ups fairly regularly.

However, for the sake of it, let’s start at the beginning and I’ll give you an overview of what we mean by these terms and how exactly we work at Giant Swarm.

team

Teams

Teams at Giant Swarm are cross-functional groups of people.

Firstly, we distinguish between tech and non-tech teams. Our tech teams always consist of the same sort of roles, namely a Product Owner and a Kubernetes Platform Architect (they sometimes take part in more than one team), ideally two to three Platform Engineers, one Site Reliability Engineer, a Solution Engineer, and sometimes a Frontend Engineer or UX/UI designer.

As a team, they roughly follow the SCRUM process with daily standups, planning, and retrospective sessions. Our teams have fancy and fun names such as Batman, Ludacris, Biscuit, Rainmaker, etc.

Chapters

Chapters are groups of people who hold the same role.

This means all Platform Engineers are in Chapter Platform Engineering, all Solution Engineers are in Chapter Solution Engineering, etc. As a chapter, they have their own habits. For example, they may have their own Slack channel or GitHub boards. The chapter decides how to organize themselves.

SIGs

Special Interest Groups (SIGs) are groups that focus on one particular topic.

Ideally, team members are from different functions and teams within our organization. Currently, we have around 20 different SIGs ranging from deep tech topics such as SIG Infrastructure or SIG Releng (Release Engineering) all the way through to non-tech topics such as SIG Culture or SIG Recruiting. The reason why people join these Special Interest Groups is that they have a strong interest in a specific topic, can pass on their knowledge and/or gain more knowledge in return. Ideally (and importantly) they take tasks of these SIGs into their teams to work on.

Kubernetes_for_Platform_Teams

Work Groups

Work Groups (WG) are groups of people who come together to work on a project that has a certain lifespan.

For example, if our website needs a facelift, people get together in the WG Website and brainstorm from there. This concept might sound very familiar to anyone who’s heard about the Spotify model. And in that case, you might also be familiar with the fact that Spotify doesn’t actually use this in their company anymore as they figured out it didn’t work for them.

So how are things going for us? When I joined the company in late 2018, we were only 22 people and the only concepts we had were teams and SIGs. We had fewer people to exchange ideas with and therefore the exchange of information and the number of people participating in meetings was considerably lower. However, as the years have passed, the team has grown to almost 60 team members and with this, we needed a different approach. This was when the Spotify model came in handy. But as it’s only been a few months since we adopted it, we can’t really give any proper evaluation on how it’s been working out for us. But who knows, maybe this post will get a sequel in the future. Until then, let us know your thoughts @giantswarm on Twitter.