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?

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:

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

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: 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…

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…

“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

INTERACTIVE COMMUNICATION

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