Guilds solve two problems

Guilds at Spotify solve two problems:

There’s usually a blend of these problems in any Guild but there are generally two archetypes which I’ll call “strategic capability guilds” vs “hobby guilds”.

Hobby Guilds build “friend at work” type engagement; Strategic Capability Guilds build strategic capability.

Guilds have three kinds of activities

When I critique writing or presentations, I tend to follow an ordered 3 stage approach: 1. structure; 2. content; 3. style.

Logical structure

My first concern is logical structure. What is the logical structure of the message? What should be the logical structure of the message given the purpose and context? Typically, whether to use a deductive structure, aka telling a story from the beginning, versus an inductive structure, aka getting to the point first and explaining it after if necessary. A deductive structure is for entertainment, an inductive structure is for efficient communication and decision-making.

The structure is about the context…

Eric Ethington wrote an article for The Lean Post about “5 easy steps to simplify the A3 process”. Essentially…

  1. Create a collection template, that is, predefine the categories you’ll use to organise;
  2. Dump your thoughts out first without categorising;
  3. Sort the thoughts into your collection template;
  4. Organise the thoughts in each category to create a better narrative flow;
  5. Refine to create your first overall draft.

This approach reminded me of something called “Spew, Then Organise”, that is, write out all your thoughts first and worry about organising it into a coherent structure later. …

Some individual productivity practices translate well to team productivity

Team productivity has factors that overlap with individual productivity:

  • Increasing focus, by reducing multi-tasking and interruption;
  • Frequent customer feedback, via regular demos, user testing, releasing to early adopters, etc.;
  • Reducing friction. For teams, this is typically around lack of clarity of direction, lack of agreement on how to work together, clunky tooling and/or technology, etc.

However, team productivity goes beyond just a translation of individual productivity practices.

  • Watching the work product, not the workers;
  • Frequent integration

Watch the work product, not the workers

Let’s imagine that you optimise for team member utilisation, that is, team members should spend most of their time on value-adding activities, especially activities…

From the perspective of an individual, increasing productivity comes down to a few things:

  1. Increasing focus (reducing multitasking, reducing interruption);
  2. Frequent customer feedback;
  3. Reducing friction.

Multitasking feels more responsive and is guaranteed to slow completion times

Let’s say you get 4 requests.

Image for post
Image for post
4 new requests… how should you respond?

In order to appear responsive, you work on all of them at the same time. In reality, given it’s just you working on them, you’re not actually working on all of them at the same time so much as switching between them.

In the end, every requester will feel like you responded to their requests and, assuming similar sized requests, all of the work is completed at roughly the…

The Rise of Worse is Better

In 1991, Richard P. Gabriel, then CEO of Lucid Inc., a company promoting the Lisp programming language, wrote about why Lisp was losing out to C, which he described as “worse is better”.

Lisp followed the “MIT/Stanford style of design”. In priority order:

  1. Correctness;
  2. Consistency;
  3. Completeness;
  4. Interface simplicity;
  5. Implementation simplicity

In other words, correctness, consistency, and completeness is seen as more important than simplicity.

Unix and C followed the “New Jersey approach” (aka Bell Labs). In priority order:

  1. Implementation simplicity;
  2. Interface simplicity;
  3. Correctness;
  4. Completeness;
  5. Implementation consistency;
  6. Interface consistency

In other words, simplicity, especially simple implementation, is seen as more important…

According to Marty Cagan, John Doerr has argued that “we need teams of missionaries, not teams of mercenaries.”

From Marty’s Missionaries vs Mercenaries post:

Teams of missionaries are engaged, motivated, have a deep understanding of the business context, and tangible empathy for the customer. Teams of mercenaries feel no real sense of empowerment or accountability, no passion for the problem to be solved, and little real connection with the actual users and customers.

When I first read this, a US missionary was being sued in Uganda, after she, without any medical training, had been running a medical centre, and 105…

Apparently, either WW1 fighter ace Harry Day or WW2 fighter ace Douglas Bader said the following (I originally saw this attributed to David Ogilvy in the book Decision Traps):

“Rules are for the obedience of fools and the guidance of wise men”


“Rules are for the guidance of wise men and the obedience of fools.”

I’m going to replace “rules” with “model” and remove the unnecessary gender-specificity.

Models are for the obedience of fools and the guidance of the wise

A fool reads a case study and/or watches a video, maybe two, and thinks:

  • This must be a utopia!
  • If I just copy this, then my workplace will also be a utopia!

Original 15 March 2020 Twitter thread.

The key overall problem I see we’re solving with OKRs is strategy deployment OR “how do we get a lot of people aligned and coordinated to achieve a shared outcome?”

My particular concern is strategy deployment when multiple teams are involved. This is one reason why I don’t particularly care about individual OKRs (the other being undermining team focus).

Problem #1: Alignment to nonsense

The first issue is Alignment to Nonsense. What data and rationale led to the Objective you’re setting, never mind how to achieve it?

Toyota people talk about this as “no hoshin kanri (strategy deployment) without…

Original 8 March 2020 Twitter thread.

Objectives and Key Results (OKR) are not “just Management by Objectives (MBO)”. The whole point was that Andy Grove was trying to correct problems with MBO, borrowing from what he understood about “Japanese management” (I suspect, specifically, Hoshin Kanri). The result was iMBOs, aka Intel MBOs, aka OKRs. So how do OKRs and MBO differ?

  1. What AND How, not just What. This is the Toyota/Lean rejection of the laissez-faire leadership style. See Kurt Lewin’s “leadership climates” for more on that;
  2. Quarterly and monthly, not just annually. Really a reinforcement of What AND How. Note…

Jason Yip

Senior Agile Coach at Spotify, ex-ThoughtWorks, ex-CruiseControl

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store