Spotify Model, Communities of Practice (CoP), Task Forces (a.k.a. Tiger Teams), and Internal Communities each have their value, but none fully meet my needs. The Spotify Model feels slow, CoPs focus too much on discussion, Task Forces feel more like a symptom of a bigger issue, and Internal Communities are too static and limited. I am looking for a more practical, lightweight, and dynamic approach that can quickly respond and adapt to real and timely needs.

Listen the podcast version of this article, below (AI generated).

Abstract

In this article I am proposing an alternative, or complementary structure to traditional, static internal communities, which are often organized around specific technical areas and can be limited in scope and participation. Instead, the idea of “Themed Groups” is introduced, emphasizing their dynamism as they are formed to address specific, current needs, and disbanded once solutions are found. These groups are designed to be cross-functional, involving people with diverse set of skills and experience to find concrete and efficient solutions to real needs. Opposed to task forces that are formed because of external pressure, focused on deadlines or technical debt, themed groups emerge organically, and in full autonomy, with the purpose to produce tangible outcomes (or improve knowledge areas and awareness around a specific topic), with the responsibility that the actual implementation is done in the relevant sponsor product team.

Themed Groups: A dynamic alternative to Internal Communities

This article explores an alternative or complementary approach to the structure often found in tech organizations, well known as “communities”. While communities, such as backend, frontend, or app communities, and so on, are of great value to promote a better, shared understanding on specific themes, and keep the overall organization technical direction well aligned across different teams, they often face limitations.

Limitations of “traditional” communities

Traditional communities, organized horizontally around specific technical areas, can suffer from static characteristics, and these characteristics can manifest in several ways:

  • Limited Scope: The topics discussed tend to be strictly confined to the community’s scope, making it difficult to explore areas that span cross-functional areas of competence.
  • Static Participation: The same people tend to attend these communities consistently.
  • Difficult to operate vertically/cross-functionally: When communities are cut horizontally, it is difficult for them to address themes or needs that require involving people with a diverse background knowledge (e.g., a backend/infrastructure topic that needs input from app developers).
  • Static Leadership: The role of coordinator, moderator, or facilitator is often consistently held by the same person, who might be a lead or staff engineer, controlling the direction of the sessions.

Introducing Themed Groups

As a proposed alternative or complementary structure to the traditional communities, I want to introduce the concept of themed groups, highlighting the main key difference between the two: their dynamism.

The dynamism of themed groups

Unlike static and permanent communities, themed groups are formed and disbanded as needed:

  • They are formed based on a specific and timely topic of interest connected with a real need.
  • Their purpose is to find concrete actions and solutions to these real, concrete necessities.
  • Important, they involve all the people who can actively contribute finding the solution.
  • They are disbanded once the need is fulfilled.

Key characteristics and advantages of themed groups

This dynamic nature of themed groups offers several advantages, and they have important key characteristics:

  • Dynamic lifecycle: Formed with the emergence of a concrete need, disbanded once fulfilled.
  • Cross-Functional and Vertical: They promotes participation among a diverse group of people, competences and roles, not only limited to tech but to non-tech as well, when its necessity requires a broader context. This is how themed groups can complement the horizontal cut of traditional communities.
  • Diversity: They are naturally formed by a diverse group of people, competences and roles. This contrasts the static participation of traditional communities.
  • Focus on concrete and timely needs: The main driver is to find an efficient solution to a real need of the moment. It is not yet another recurring meeting scheduled in the calendar of traditional communities.
  • Solutions are based on consensus: Outcomes are only agreed on widely accepted consensus of all parties involved.
  • S.M.A.R.T. goals: the outcome that the group agreed to achieve should be a S.M.A.R.T. goal (Specific, Measurable, Achievable, Relevant, and Timely).
  • Efficient and Time-boxed: The expectation is to find a solution for a concrete need, in the most efficient way possible, and not dragging on for months. This is one of the crucial characteristics of themed groups.
  • Organic and bottom-up: They are formed organically and autonomously from proposals originated from the people doing the real work, so it is a bottom-up approach. They are NOT formed following a mandate forced from top-down (e.g., task forces, which will be discussed later in the section “Themed Groups vs. Task Forces”).
  • Focus on What and How: While a themed group discuss the strategy and the approach to follow to solve a concrete need, the actual execution (and/or implementation work) is delegated to the sponsor product team, particuarly if the outcome is expected to be a tangible artifact.
  • Not limited to problem solving only: They can also be formed, simply for improving knowledge sharing, achieve a better understanding and clarity, and/or spark awareness on a specific topic. The real need here is “better and shared understanding”, once that is met, the group is disbanded.

Themed Groups and the Sponsor Product Team

A key concept of the themed groups is that while they have the responsibility to explore and find the best solution, the actual execution and implementation is handed over to a relevant sponsor product team. This helps to give the outcome of themed groups a clear ownership, and also guarantee for possible follow up work, if needed.

However, some objections and doubts may arise at this point, and I would like to address some of them, as it is important to provide more clarity over the concept of Sponsor Product Team.

How the current scope of the sponsor product team is affected?

The goal is not to block or change the current scope of the sponsor product team to the one of the themed group. Rather, the purpose of having a sponsor team is to make sure the proposed solution has a clear ownership within the existing organization, and won’t be left in a limbo. The sponsor team already have a proper domain knowledge or full understanding on the matter.

For example, in a themed group focused on improving some parts of the infrastructure, the sponsor team might be the one that is already responsible for that area (e.g., platform, infrastructure, or architectural team, or else).

What if the sponsor team lacks familiarity with the proposed solution?

The themed group is formed to bring together various perspectives, help to uncover hidden spots, and gather as many insights as possible. Once the group agrees on a well-informed consensus, the sponsor team is now in the best position to do the work. They have the domain ownership, background context, and more fresh inputs from the themed group. This balance between existing knowledge and newly gathered insights should help the sponsor team to reduce blind spots and build more confidence.

Also, keep in mind the outcome should be S.M.A.R.T. If the proposed solution is at the time not achievable (reasons may vary here), then consider to disband the themed group and try when better times come.

Balance between well-informed consensus and quick solution

I have said that themed groups should be short-lived and emerge to address timely needs, in a quick way, especially when there is a need to gather more input from different perspectives: to help manage the limited scope of internal communities or to uncover unknowns in the sponsor team.

In my view, being quick to find a well-informed consensus is part of the process of finding a quick solution. If a themed group is too much invested to find consensus, and/or the solution they found would take too long to implement (or execute), then I would suggest disbanding the group and waiting for better times. Sometimes slow consensus, or the lack of feasibility to design efficient solutions, can be a symptom of something else: Why was it difficult to find consensus? Why we couldn’t find a quicker solution?

Themed Groups vs. Task Forces

There is a crucial distinction between the two groups, and it is important to have a dedicated section here to better highlight the differences:

  • Task Forces are generally forced and formed because of a mandate from top-down to boost up initiatives, often this happens because under the pressure of “important” deadlines, or stagnation with technical debt. They drain capacity from product teams.
  • Themed Groups are not formed because of external pressure, and they are not forced. Instead, they form organically, in full autonomy from the bottom-up, focused on real and timely need.

Themed Group: An example

For example, consider the need to improve the process of setting up a local development environment for non-backend developers. This necessity might first appear in a backend community meeting, triggering a bell for a possible real need. A themed group could then be formed specifically to address this need, in a efficient, and timely manner. The group would possibly involve the right people with different roles and competences (backend, frontend, apps, infrastructure) who are either directly impacted or can actively contribute to the solution (e.g., some representatives from the sponsor product team are expected here). Their goal would be to explore options, reach a consensus on the best approach, and then hand over implementation details to the sponsor product team. Once the improved setup is in place and shared, the themed group is disbanded.

Themed Group: Alternatives

Although there are existing models that share some characteristics with Themed Groups, none fully capture its dynamism, time-boxed nature, and outcome-focused approach. Some of these models include:

  • Guilds & Chapters (a.k.a., Spotify Model)
  • Communities of Practice (CoP)
  • Working Groups or Tiger Teams (a.k.a., Task Forces)

While all of them provides value from their own, they often lack the flexibility to quickly adapt to real, timely needs and can suffer from too much process or static participation.

Wrapping-up and Takeaways

The key idea of a themed group is all about finding a better structure to respond and adapt to a real and timely need in a quick and efficient way.

Traditional internal communities continue to play a significant role, however they often struggles with the limits of their static nature. On the other hand, themed groups propose a more dynamic and complementary structure, promotes a more diverse, cross-functional, vertical and well-defined scope, oriented to solve the emergence of a real need.

Adopting themed groups do not require any changes to your existing organization structure. They are completely independent and can be easily tested: simply create a theme group to address a specific need, address it, and disband the group once done. Repeat!

Takeaways

  • Themed groups form around specific, real, timely needs and disband once they are fulfilled.
  • They complement traditional communities by involving a diverse, cross-functional set of roles and competences.
  • Unlike task forces, they are bottom-up initiatives, formed organically and in full autonomy.
  • Their focus is on practical impact, and make sure the sponsoring product team can do the real work.
  • They are not limited to problem-solving only! Knowledge sharing and building awareness are valid and great triggers for their formation.
  • Themed groups do not require any changes to the current structure of an organization.