You've got a problem that appears unsolvable. At least, you and your team have been banging your head against this problem for some time with no progress. It's led to frustration, angry customers, and probably lost revenue. Or at least very unhappy colleagues and you're worried about employee disengagement and turnover. 

I can't guarantee this will solve the problem, but it's been pretty reliable for me, so I guess this is another free Betts Guide.

First, identify the problem and the behavior around it. Yeah, I know you've done this a million times. But this time we're going to make it more uncomfortable. Copy and paste this list, and then answer the questions with as much detail as possible.

1. Name the problem. Literally, like give it a name. Call it George for all I care, but you need to have A Name that everyone can refer to it by. If its so big and uncomfortable you're probably already calling it something, but just in your head. Get it out here. Name it. Socialize the name. Ask what others are calling it. Someone already has a great one, I promise.

2. Who is affected by this problem? Role, name, region. Get specific. Include your partner who has had to listen to you whine about the problem for 6 months running.

3. What are you doing with the problem? Be real. Avoiding? Whining? Spending money on it? Hiring? Firing? Reorganizing? How big is the Slack channel/Google drive/calendar load? What does the behavior look like when dealing with this problem? Avoidance? Arguing? Analyzing? Private messaging and or personal texting off company servers? Shitposting on LinkedIn? Write paragraphs about this if you have to. Put it down on paper if you prefer so it can be tossed because you need space to get really raw about the feelings and behavior around this.

4. What is the actual impact, having written all that down? Time, money, trust, all of it. 

Ouch, I know. But you can't solve a problem you haven't got real about. Especially not one that has come to this point. No, don't pour a drink. It won't help, I promise. Maybe a walk. Or a hot shower. Breathe.

Now, find the trigger. It's probably not a constant or you would have solved it by now. 

What makes this problem flare up? Sure, the effects are probably constant, but the actual problem probably has a trigger. Is it a certain customer? A particular report that gets run? The quarterly meeting? A product release?

What is the outcome from the trigger and the responses to it? What is the response by your team or the individuals involved? What is your response? If you aren't sure, go back through that slack channel or recent communications around this issue and look at what you did. Did you ignore it? Say the same thing you say every time? Go text your work bestie? We're are looking for this pattern:

Trigger > Response > Outcome

Seriously, no drinking

Your instinct now is to go mess with your responses or the trigger. Or set up a process around the outcome. DON'T DO THAT. Just stop and sit.

You are actually a fish and you're surrounded by something you can't see, and trying to fix it without that awareness won't solve anything, and might actually just complicate it. The next step:

Take a hard look at the system

When you review those triggers, what is the system that is creating those? This is where we veer off what I can actually get specific about but I can share an experience that might help. You need to back up and ask "What is the system that is running all of this? What tools, structure, or ritual are we using that makes THIS particular trigger and response rational?" To put it in the immortal words of Dr Phil "So, how’s that workin’ for ya?" Meaning, how have you structured the environment to make these actions the most rational actions?

An example problem: A company had a data team that worked really hard building a framework that allegedly would eventually be automated. They largely returned excellent data, but sometimes they were taken offline for a day or more because their tool would break. Or they would have to turn over large amounts of work to another team because they were blocked by their tooling. This frustrated them of course. It slowed work, it impacted the other teams who had to pick up the work that couldn't be done. Whenever this issue would come up, it would get escalated to Support or even Engineering, where it would get glanced at, and then dropped. Eventually the tool would come back online and the process would repeat. So, tool breaks > escalated to Support/Eng (ignored) > eventually works > frustration and animosity abounds.

The real system at play looked like this:

The assumption by the org was that this was a temporary system. They had employed a team in Manila to do the work. That team was basically cut off from the rest of the org, and had no power whatsoever to advocate for change. Because leadership saw the tool as temporary, it was not prioritized, and since Engineering did not have any structure for this tool (boards, metrics, knowledge sharing), no one was incentivized to do anything about it. 

So the functional system was power dynamics and incentives, not that the tool was breaking. 

Now name the Unstated Belief

They had to get really honest about that "temporary tool." The stated belief was "it's temporary and we have other workarounds." The real belief is "this is an offshore team doing work we don't see as important and they don't have a seat at the company table and we aren't motivated to give them one."

Harsh, for sure. But it was the real belief. Of course no one wanted to say it! It sounds terrible, and when you get down to it, kinda racist. But it's real. 

You can't fix what you can't name, and part of that is naming the beliefs behind the system.

Now that the hard, uncomfortable part was said out loud, they could decide where to go next. At this company, that wound up being letting that team go. There were workarounds, the system was outdated, and the cost of bringing it all up to date with the rest of the business systems was too much cost for too little reward. However, some onshore teams were able to absorb some members of the offshore team. That infused the company with valuable data knowledge and built new relationships that made the whole company better.

By starting with the problem and going backwards, up the chain of linked problems, causes, beliefs, and systems you can get to the heart of where your current problems come from. Instead of playing whack a mole with issues that will keep popping up, no matter how many solutions, processes and projects you launch, you instead tackle the problem at the source. It's not easy. It's messy and hard. But once you do it and see the impact, it will become your favorite (if most resisted) tool.

Since I know you're stressed, here's the summary you can grab and put in a saved note somewhere:

THE BACKWARD CHAIN — QUICK CARD

Step 1: Name the Problem

• Give it A Name (steal one if the team already has one)

• List who's affected — role, name, region, including the poor soul who's heard you whine about it for six months

• What's the behavior around it right now? (avoidance, arguing, shitposting on LinkedIn, all of it)

• What's the actual impact — time, money, trust?

Step 2: Find the Trigger

• What sets this off? A customer, a report, a release, a meeting?

• Map it: Trigger → Response → Outcome

• Don't fix anything yet. Just see the pattern.

Step 3: Takes a hard look at the System

• What structure makes that Trigger → Response → Outcome pattern rational? What tools, rituals, or incentives are quietly running the show?

• Ask: how's that workin' for ya?

Step 4: Name the Unstated Belief

• What's the stated belief about why things are this way?

• What's the real belief underneath it? Say the uncomfortable version out loud.

Step 5: Decide

• Now that it's named, what do you actually want to do about it?