Every leadership team needs a current reality tree

Most leadership teams have plenty of information about what happened last week, because the dashboards, the status reports and the weekly round-the-table update all exist to tell them, but very few have a clear, shared picture of why things are the way they are, and that gap is where most bad decisions come from. You can know every number in the business and still spend a quarter fixing the wrong thing, because numbers tell you where it hurts and almost never tell you where it’s coming from.

In the first piece in this series I said that identifying the constraint matters more than all the other focusing steps put together, and this piece is about how to actually do it, using the tool Goldratt built for exactly that job.

Goldratt’s three questions

By the early 1990s Goldratt had realised that the hardest constraints weren’t on factory floors at all, so he developed a set of logic tools he called the thinking processes, and he introduced most of them to a wide audience in It’s Not Luck, the 1994 sequel to The Goal. The tools hang off three questions that I think every leadership team should have printed on the wall: what to change, what to change it to, and how to cause the change.

The current reality tree answers the first question, and it’s the one I’d argue matters most, because a team that gets the second and third questions right while getting the first one wrong will execute brilliantly on a problem it doesn’t have, which is a remarkably common way for good companies to lose a year.

How a current reality tree works

You start by writing down the undesirable effects, which Goldratt called UDEs, meaning the things people in the business genuinely dislike about how it’s going, stated plainly and without blame, so you might write “deals stall after the first call”, “we discount on most contracts” and “customers churn around month three”. Most teams can list fifteen or twenty of these in half an hour, and the list on its own is useful, because it’s usually the first time everyone has seen all the complaints side by side.

Then you start linking them, using sufficient-cause logic, which is a formal way of saying you read each connection aloud as “if this, then that” and check it holds, so “if prospects can’t tell what we do, then deals stall after the first call” and “if deals stall, then sales reps discount to get them moving”. As you work downwards you find that several effects lead back to the same cause, and eventually you reach a small number of root causes at the bottom of the tree, with one, the core problem, usually sitting under most of the symptoms you started with.

The clever part is how Goldratt suggested you test the tree, which is with a set of rules he called the categories of legitimate reservation, and they’re worth knowing because they make it safe to argue. You can challenge whether a statement is clear, whether the thing it describes really exists, whether the cause really leads to the effect, whether the cause is enough on its own or needs something else alongside it, and whether there’s another cause you’ve missed, but you challenge the logic rather than the person, which turns a blame session into a puzzle the whole team is solving together.

What it looks like in a real company

Take a software company of forty people trying to double revenue in eighteen months, whose leadership team lists its symptoms as a thin pipeline, heavy discounting, a long onboarding, churn in the third month, a roadmap that keeps changing and a sales team that complains the website is out of date. Treated one by one, that’s six initiatives, six owners and six lines on the dashboard, and the team would be busy for a year.

Build the tree, though, and most of those trace back to one cause, which is that the company has never agreed which customers it’s for, so marketing attracts everyone, sales discounts to close the wrong fit, onboarding takes longer because every customer wants something different, those customers churn when the product doesn’t quite suit them, and the roadmap lurches towards whoever shouted loudest last month. Agree who you’re for, and four or five of those symptoms start easing at once, which is the whole point of looking for the constraint rather than working the list.

A lighter version for leadership teams

I’ll be honest that a full current reality tree, with forty boxes and arrows going everywhere, is more than most leadership teams will ever build, and I don’t think you need one to get most of the value, so this is the lightweight version I’d use with any team.

• Start from the goal. Name it first, because a symptom only matters if it’s getting in the way of something you’re trying to reach, and you can read how in How to write good company goals.
• List the symptoms without arguing about them. Get every undesirable effect onto the table before anybody starts explaining it away.
• Ask what would cause each one. Read each link as “if this, then that”, and look for the causes that show up under more than one symptom.
• Test the cause before you trust it. Ask whether it’s real, whether it’s enough on its own and what else could explain the same effects.
• Write down why you believe it. Record the evidence and how sure you are, so a hunch is never mistaken for a fact.

What comes out is usually three to five causes in a rough order, which, not by coincidence, is exactly the shape of the constraints in a Clearahead workspace.

Why we built a panel, not a tree

When we were designing Clearahead, the obvious move was to build a tree, because current reality trees are brilliant and we wanted that thinking in the product, but a tree has one big problem, which is that a tree is a snapshot, drawn on one afternoon, and by the following month nobody has updated it and it quietly stops being current reality at all. A map of the truth that goes stale is arguably worse than no map, because people keep trusting it after it’s wrong.

So we kept the spirit and changed the form, and the result is the current reality panel that sits right under the title of every goal, constraint and move in the context area, saying where things stand today, when it was last updated and who by. Nobody types into it; when someone tells AJ what happened, in a sentence, AJ rewrites the current reality and the fields it touches and keeps what was said as evidence, with who said it and when, which is explained in Keeping it up to date.

The categories of legitimate reservation live on too, in a gentler form, because every constraint carries the same questions (why it matters, why we believe it and how we’ll know it’s gone), with a confidence of hunch, fairly sure or sure, and a status that moves from suspected to confirmed to easing. Constraints are kept one level deep on purpose, so symptoms sit as evidence on the constraint they belong to instead of becoming constraints of their own, and when you talk a problem through with AJ, it keeps asking why until it reaches something you can act on, which is the downward walk through the tree without the whiteboard.

Current reality beats a status report

The deeper reason this matters is that a status report answers the wrong question, since it tells leadership what people did rather than what’s now true and why, and that’s why I think the weekly status meeting has had its day, an argument I make at length in Status meetings vs Clearahead. When every item carries its own current reality, written from what the team has actually said, the Monday brief in This week from AJ can tell you what moved, what you learned and what needs a decision, and the time people would have spent reporting goes on deciding instead, which you can see in practice in How to run a weekly leadership meeting.

Goldratt’s question was what to change, and I don’t think you can answer it well unless the whole team is looking at the same current reality, kept true every day rather than redrawn once a quarter, which is a principle we arrived at by stripping planning back to its basics, and that’s what the next piece in this series is about.

Questions people ask

What is a current reality tree?

A current reality tree is a cause-and-effect map from Eliyahu Goldratt’s Theory of Constraints. You start with the undesirable effects a team can see, link them with “if this, then that” logic down to the causes underneath, and look for the one or two core problems that explain most of the symptoms. It answers the first of Goldratt’s three questions: what to change.

What are undesirable effects in the Theory of Constraints?

Undesirable effects, or UDEs, are the visible symptoms a team complains about, such as a thin pipeline, missed deadlines or rising churn. They’re real and worth recording, but they’re effects rather than causes, so fixing them one by one rarely moves the goal.

How is a current reality tree different from the five whys or a fishbone diagram?

The five whys follows one chain of cause downwards and a fishbone diagram sorts possible causes of one problem into categories. A current reality tree starts from many symptoms at once and looks for the shared cause underneath them, which is why it’s better at finding the constraint holding a whole goal back.

What is the current reality panel in Clearahead?

It’s the panel right under the title of every goal, constraint and move in Clearahead, saying where things stand today, when it was last updated and who by. AJ rewrites it whenever someone says what’s changed, so it stays current, and the evidence behind it is kept on the item’s Evidence and history tab.