Cross-Dysfunctional Product Teams

To Spotify or Not to Spotify

Spotify is famous for their agile software engineering culture (watch Kniberg himself describe it circa 2014 here and here) which—amongst other things—championed ‘squads’ as the primary unit of product delivery and ownership.

Squads are meant to be cross-functional (X-func) and self-organising, owning a product domain with full autonomy and pushing de-coupled releases to the platform. It also came with nomenclature around guilds, chapters, tribes etc. that tends to confuse people more than it helps them.

When I hear it introduced at an event or a workplace, the sequence usually goes like this:

Announcer: We follow the Spotify X-func product squad framework!

Also Announcer: Actually, they stopped using it themselves because it’s not working lol

And I always wonder what’s the real message there? The fact that:

• We should implement the framework because it is/was popular; or

• Because it is the best framework even though it is flawed a la Churchill’s “democracy is the worst form of government—except for all others that we have tried”?

Let’s dive in.

The Benefits of Local Cross-Pollination

It is easy to see where X-func product squads can shine: you delegate a product domain to a group of professionals—product managers, software engineers, designers, data scientists etc.—and give them autonomy (and authority) to address customer pain points. You don’t dictate what they should build, but you delegate the customer problem to them—congrats, this is now your problem, fix it as you see fit.

In the image below, this is captured by the alignment enables autonomy crosstab; the ideal scenario is management relaying the company objective (‘we need to cross the river’) and let the relevant team figure it out—rather than dictating ‘build a bridge’, which may or may not be the best course of action.

Spotify Engineering Culture Part 1 by Henrik Kniberg (2014)—click to enlarge.

Add the fact that the members of the squad represent various professions which allows them to address the issues in a more holistic manner—cross-pollination > standardisation—what’s not to love?

Also, small & frequent and decoupled releases👌

Enter Cross-Dysfunctionality

In many startups, what gets adopted from the Spotify experiment is the product squads and the community > structure bits. A bunch of squads are spun, which seems to happen every six months or so. Tribes move around as domains change rapidly. Scrum masters (agile coaches in Spotify lingo) are hired & fired—which tends to match the six-month cadence. Why does this happen?

Spotify Engineering Culture Part 2 by Henrik Kniberg (2014)—click to enlarge.

This happens because startups selectively adopt parts of the framework. Also, as it was the case in Spotify, lack of engineering managers/management oversight (curtailed deliberately in favour of maximising squad autonomy) didn’t simply pan out as intended—turns out management exists for a reason🤭

What startups tend to adopt:

• Product squads

• Community nomenclature

• Small & frequent, decoupled releases

• 10% hack/adventure time

• Mostly cheap talk around failing fast/no blame culture

The last one I caveated with cheap talk because it is something the senior leadership says, but mostly ends up applying to them rather than the rank-and-file🤷🏻‍♂️

What startups don’t tend to adopt:

• Agile > Scrum

• Principles > Practices

• Servant > Master

• Trust > Control

• Impact > Velocity

• Value delivery > Plan fulfilment

Now every single one of these can be a full blog post, but one unifying theme is doing stuff for the sake of doing it.

Rituals? Let’s have them all, whether they help or distract.

Daily standup—sure, 30 mins every morning (agile?!).

This many tickets closed in last sprint—does burndown look good? Also see: who cares about business impact?

Plan product roadmap for the next 12 months, things change; oh well we should stick to the plan™️

If we go one level deeper, what underlies doing stuff for the sake of it is lack of trust. Lack of trust, in terms of senior leadership not delegating power (because they believe—rightly or wrongly—things won’t get done if they do); and people’s lack of trust in themselves (i.e. to do the right thing).

The former is the more publicly discussed variant—execs don’t delegate power, because middle management/leads don’t get it. But the second variant is the silent killer. This is

• A product manager sticking to a sinking ship product roadmap, because they don’t have the courage to manage up—safest option is to keep course, because plan creates psychological safety (and perhaps, it’s a higher-up’s fault—above their pay check).

• An engineer manager not building bridges with fellow EMs and peers in other domains when a work touches multiple squads, choosing to internally complain to their squad instead of reaching out and fixing the situation.

• A data scientist not taking responsibility of an end-to-end data product/ML model, opting to play hot potato with data engineers, backend engineers, and platform/SRE teams instead of involving the PM and own the product.

• Everyone is a squad having short-termism/tunnel vision on what their profession should do in the squad, rather than focusing in delivering business impact now and in the future.

The last point is one of confused identity. My line reports, who have been mostly embedded in product squads from day one, usually end up asking at some point—What comes first: the function (e.g. Data & AI) or the squad?

To me, this is a quite indicative question—that employees lack clarity on the fundamentals. I tell them that professions are represented in a product squad; e.g. if you are a Data Scientist, you represent Data Science in [product] squad. You don’t represent [product] squad in the Data Science chapter. What you bring to the table is your unique DS skills; and you peers in the squad bring theirs—hence, cross-pollination. You join a squad to expand their imagination; show them what is possible, and contribute to the overall business impact delivery by providing a skillset that the squad lacks.

This requires self-esteem and trust in one’s own abilities. If you think about it, it’s not easy—we send our people away immediately to join a squad with perhaps no peer from their domain, and expect them to flourish. They can, but it takes time to build that trust as well as the psychological safety.

So next time people are piling up on Spotify culture, ask them—have they really given it a real shot, by adopting what works and amending the rest, or did they just try—also commonly applicable to implementing OKRs—product squads for a year or two?