A general framework for coaching/consulting a new team or organisation

Jason Yip
2 min readFeb 13, 2023

--

Problem → Stated problem → Actual problem → Causal analysis → Prioritise → Improvement experiments. Loopback from Improvement experiments to Actual problem.
A general framework for coaching/consulting a new team or organisation.

Why does the team / organisation exist? What is their purpose? What problem(s) are they trying to solve?

  • What do they have published?
  • What do they say when you ask them?
  • What does their boss say?
  • What do their partners/stakeholders say?
  • What is the larger strategic context and how does this team/organisation fit within it?

What is their stated problem?

Usually, I find it’s one or more of the following:

  • Speed? “We’re not delivering fast enough”
  • Throughput? “We’re not delivering enough”
  • Productivity? “It takes too many people to deliver too little”
  • Quality? “What we’re delivering is not good enough”
  • Morale? “Everyone is disengaged”

What are the actual problems?

How does the work work?

My go-to technique for this is value stream mapping, which can be more or less sophisticated:

  • Information flow, that is, how teams are signalled to prioritize something, not just work flow;
  • Consumption value streams, not just production value streams. This is similar to the “front stage” vs “back stage” concepts with service blueprints.

What do they see as the actual problems?

Simpler and faster than value stream mapping (though also less likely to have as large of an impact) is running a health check or a retrospective. Sometimes building improvement momentum warrants doing something quicker.

I wrote about different categories of team assessments back in 2017. Which one to choose really depends on context and what the team/organization finds appealing.

For retrospectives, my favourite style is still solution-focused, goal-driven retrospectives.

Why are the problems occurring?

My go-to technique for this is a root cause analysis diagram using Six Sources of Influence to ensure different contributing factor categories are considered. I have found that many people don’t connect with root cause analysis diagrams so I might use a simpler tool when facilitating exercises or presenting results.

Table with 2 columns: Motivation, Ability and 3 rows: Personal, Social, Structural.
6 sources of influence

What problem(s) should we target first?

I tend to prefer starting with non-controversial problems to build momentum but specific problem prioritisation really depends on context. A simple impact vs effort assessment is typically useful.

Propose and run improvement experiments.

This is the part I want to be more disciplined about.

  • PDCA!
  • Limit how many improvement experiments are run at the same time;
  • Pre-commit what you expect to happen;
  • Make sure to follow up and check results — both to keep yourself honest AND to demonstrate impact

--

--

Jason Yip

Senior Manager Product Engineering at Grainger. Extreme Programming, Agile, Lean guy. Ex-Spotify, ex-ThoughtWorks, ex-CruiseControl