Address both the symptoms and the causes

“Hold on, let’s take our time to understand the root causes of fires otherwise we’re just treating the symptoms.”

We want to address current symptoms BUT we also want to remember to explore and address underlying causes.

The Toyota/Lean community describes these activities as “containment” vs “countermeasures”.

I see it as acknowledging the importance of timing when responding to problems.

Contain the symptoms to buy time

I’ve noticed that consulting companies, at least the best ones, seem to be typically faster than even leading tech companies in building high-performing teams.

Why is this?

“You’re billing for team setup time? Haha, that’s what I like about you, all the joking!”

When revenue is based on billable hours AND the typical client doesn’t like paying for setup time, you learn how to get fast at building teams.

The 3 things that matter when building high-performing teams fast:

  • Same training, same assumptions;
  • Focus on the craft, not on the mission;
  • Practice teaming and re-teaming.

Same training, same assumptions

By “high growth”, I mean in terms of employee count and roughly doubling or more every year. Even at slower growth rates, some of the phenomena I’ll describe may be relevant.

Two reasons why building teams in high growth is difficult: can’t assume stable teams, can’t rely on cultural osmosis.

In high growth, the odds are the teams won’t be stable

There are several options to accommodate new people:

Sink or Swim; Split and Absorb; Absorb and Split
  1. Sink or Swim. Keep the older teams as-is and add the new people to brand new teams. This keeps teams stable and likely ensures that all new teams will struggle;
  2. Split and Absorb. Split up the older teams (aka not stable) and absorb new people in the new teams. This means there’s a mix of veterans and newbies;
  3. Absorb and Split…

Just talking

Problems with just talking

The simplest meetings have people just talking to each other. The just talking pattern is vulnerable to the following problems:

  • false agreement, that is, people believing there is agreement due to misunderstanding what was said;
  • repetition due to exceeding working memory, that is, people forget that they’ve already talked about something so they keep cycling on the same points;
  • repetition due to unclear acknowledgement, that is, people keep repeating points because they’re not sure they were heard.

Live notes

Autonomy, in a workplace context, is not about “I can do whatever I feel like” but rather “I feel free to act and fully engage to achieve a greater purpose.”

The Art of Action calls this “aligned autonomy”.

Two reasons aligned autonomy is difficult: air sandwich and politics.

Aligned autonomy is neither easy to obtain nor easy to sustain. I’ve generally seen two reasons for this:

  1. the air sandwich;
  2. politics (specifically, the ignoring of politics).

An Air Sandwich is vision and day-to-day action with nothing in the middle.

“An Air Sandwich is a strategy that has clear vision and future direction on the top layer, day-to-day action on the bottom, and virtually nothing in the middle…”

Nilofer Merchant, “Collaborative Strategy: A Q&A with…

PDCA is a model for structured problem-solving

Plan Do Check Act
  • Plan: Expressing our model of reality that leads us to believe a particular action, or set of actions, will have a desired effect. NOTE: this is not just blindly proposing a change;
  • Do: Taking, or attempting to take, action;
  • Check: Reflecting upon the effect of action(s), including on any problems with implementation. NOTE: this is not just measuring results with no reflection;
  • Act: Take appropriate action in response to our reflection, whether validation of our model of reality and capturing this in standards, or adjustment of our model of reality.

PDCA is a false, but useful model to avoid common errors

PDCA is a simple, not entirely accurate, but useful model…

What would Extreme Programming (aka dials to 11) look like if it was invented today?

Summary of the answers

Kent Beck suggested it would start with Limbo (essentially live, shared programming) and build upon that.

Chet Hendrickson pointed to a talk he and Ron Jeffries gave at deliver:Agile about turning the dials to 12 (Complete Team, Bracketed Intervals, Valuable Working Software Product, Example-Based Transparency).

Victor Cessan suggested decreased feedback loop lengths and a WIP limit of 1.

Dan Abel suggested a number of ideas including observability, continuous delivery, scaling without losing autonomy, budgeting for learning, testing loops for user experiments, and “eXtreme User Design” [I knew this previously as “Continuous Design” at ThoughtWorks].

Chris Young suggested mobbing (aka ensemble…

Harder to rely on role modeled behaviour for unwritten rules when remote

“No unwritten rules” is Gitlab’s simpler expression of what the Kanban community would call “make process policies explicit”. Being explicit about “how things are done here” is worthwhile whether co-located or not. It levels the playing field for people who don’t necessarily have exposure to hidden interactions. Remote makes this more critical because it can be more difficult to see how people are behaving.

Distribute decision-making with context and decision rules


Replacing accidental with intentional.

Communication capability = communication habits + what you get for free by being co-located

Good communication habits, that is, being clear, being concise, having a logical message structure, etc. are valuable whether remote or not, but remote makes them more critical by removing the ability to compensate by being co-located.

Replace implicit, non-verbal cues with explicit communication and intent

Team Topologies describes 3 team interaction modes:

  • Collaboration: “two teams work together on a shared goal, particularly during discovery of new technology or approaches”;
  • X-as-a-Service: “one team consumes something provided by another team (such as an API, a tool, or a full software product)”;
  • Facilitating: “one team (usually an enabling team) facilitates another team in learning or adopting a new approach.”

Here are a few more (via Cara Lemon, another Agile Coach at Spotify):

  • Consult to Not Own: Asynchronous support and review for another team that will eventually own the results of an effort;
  • Consult to Own: Asynchronous support and…

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