Go after root causes like you give a damn!

A root cause is not a singular gem buried within a complex problem, waiting to be unearthed, polished, and put on display for all the world to see while you soak up plaudits for your geological prowess.

And yet we often hear root causes bandied about in precisely that way. Statements like "the sales team didn't understand the product specs" or "the engineering team wasn't aware of all the use cases" might be put forth as root causes when things go awry, but rarely do statements like those about groups actually come from the groups themselves. 

Why do we suggest root causes originating outside of our domains? It might feel safer than calling out our own shortcomings.We might feel as though we need to maintain our own "credibility" or "status" or "subject matter expertise" or whatever you call the corporate rendering of a be good mindset, as opposed to a get better mindset. 

But does that really help things? Does attributing causes of complex problems to others actually help us make progress in addressing those problems? If we aren't actually interested in making progress on those problems, why are we talking about them?

When looking for root causes, understand that you're evaluating many options and looking for leverage points that you can impact within your action radius. Your action radius is shaped by your range of motion and your time horizon. Think about your time horizon as a spectrum; whether you have three days or three months to address a problem will change the actions you take. Neither time horizon is wrong, but being blind to the influence of the spectrurm is.

Similarly, think about your range of motion as made up of both the level of change you can effect (e.g. resources) as well as the level of risk you're willing to accept in addressing a problem (see: blast radius). The ways a front-line worker and a regional ops director work on problems will vary by their station. Again, neither is wrong, but ignoring the spectrum is.

Once you understand your action radius, use that as a lens to view the problems you face. What can you do about something? What can you do that will have the biggest impact on your problem with acceptable follow-on effects? What you start to see are the root causes that you should be addressing, and you should be addressing them because you can address them.

When viewed this way, your new lens can help ensure you're building logic chains that hang together both up and down the levels of detail. This will help you avoid the temptations of mental traps like solutioneering and pushing solutions in search of problems.

At this point you might be thinking that's all well and good, but you're facing some really big problems with some really tough root causes that are way outside your action radius no matter how you slice it, but you've still been tasked with getting it done. In that case, think about who does have an action radius that can address root causes you've identified and go talk to them. Lay out your situation, your understanding, your assumptions, etc. Ask questions. Understand the problem from their perspective. In other words, help them come along with you and go after problems together!

Grounding root causes in what you can actually do about something turns problem solving from a disassociating blame game into a meaningful set of steps you can take to move through complex environments, and in doing so you learn more about the actual obstacles holding you back from doing what you want to be doing. 

What's my blast radius?

Rapid experiment cycles can be applied in many settings to speed up the pace of learning and reduce the gaps between expectations and reality. One of the common terms in literature dealing with that concept is the idea of minimizing the "blast radius".

In short, minimizing the blast radius means making sure you don't screw up something major in your worst-case scenario. That way you can keep executing experiment cycles and improve the pace of your learning. So how can one think about mitigating their blast radius in order to continue uninterrupted learning cycles? I recommend a three part test:

• Are you acting unilaterally?
• Are your actions irreversible?
• Is the potential damage unacceptable?

If your planned experiment only violates one or two parts of the test, proceed! If, however, you find yourself tripping all three, you might want to reconsider your next experiment. What does it mean to trip one of those tests? Let's take them one by one.

Acting unilaterally. In a classic unilateral setting, one person is making a decision to do something without consulting anyone else. That definition can apply quite readily to testing blast radii, but it should also be noted that groups can act unilaterally. In the case of groups, "unilateral" can be equated with "one perspective". Multiple people in a group might all agree to an action, but if their perspectives are mostly overlapping, then that action is still unilateral. In a setting of us vs. them, you need to get input from them if you want to avoid acting unilaterally.

Irreversible actions. Technical domains often have an ability to "undo", "restore", "revert", "roll back", or otherwise reverse an action just taken, but by no means is that capability restricted to technical domains. Putting a physical item somewhere can be reversed if you can just move it back. Announcing a change to a tight-knit team can be "reversed" with a similar level of communication. Limiting the population exposed to a change means the bulk of the population stays with the current reality, essentially letting you revert to old norms easily.

Unacceptable damage. Of the three parts of the test, this is probably the trickiest, and can seem a bit recursive: isn't the whole point of thinking about blast radii to avoid unacceptable damages from an experiment gone wrong? Thinking about the other two parts of the test can help one suss out unacceptable levels in a given situation. As an extreme example, if you decide to make an omelette for yourself, you're acting both unilaterally and irreversibly, but clearly it's an acceptable level of damage. Perhaps more realistically, if you're considering a major product change that you think will be irreversible, you can strengthen your case by seeking different perspectives.

The point of your experiments should not be to do, but rather to learn so that you can do better. Not every experiment will turn out as you expect it to, so you should mind your blast radius, but odds are if you haven't critically assessed your blast radius, you're either being too cautious and taking too long to learn or being reckless and inviting unnecessary risks. 

Strategy vs. operations is the wrong dichotomy

A common framework in business writing is to refer to strategy and operations as a mutually-exclusive-collectively-exhaustive set of categories to describe what happens in an organization. Colloquially, the strategy side of the house "decides what to do", and the operations side of the house "does it". 

Plenty of words have been spent declaring one "more important" than the other, but what I don't often see is an articulation of something other than the two options. Stepping outside the strict business realm, I think the way the US military describes levels of warfare can provide a helpful way to view activities within a company.

In the military, the strategic level deals with broad objectives, like being in a given region for a given purpose. The tactical level is the "boots on the ground", or the "tip of the spear". The operational level connects the two by looking at things like: what kind of boots do you need? where on the ground do you need to be when? do you have the equipment you need? are your batteries charged? are you well fed? are you able to talk with each other? are you dressed for the weather?

In other words, the operational level enables the tactical level to achieve the objectives of the strategic level. 90% of our armed forces work at the operational level. If you think about the "tip of the spear", a spear tip only becomes a truly deadly weapon when it is attached to a shaft. The operational level is that shaft; providing heft, range, and support to the tip.

As the connector between strategy and tactics, the operational level needs to be able to both speak the language of strategy as well as understand the reality of the tactics. Strategic objectives need to be deepened via specific operational contexts, and key tactical details need to be surfaced in order to make better strategic decisions.

In a company, you might think about salespeople, engineers, customer service reps, and other front line employees as the tactical level. If they are to succeed in achieving the strategic objectives of their organization, they need operational support. Supervisors, middle managers, IT departments, finance departments, HR -- these are all examples of the ways organizations support their tactical level employees, even if they're not traditionally thought of as "operational" roles. From that view, the questions flow naturally. Does your operational level understand your strategic objectives? How are operational observations informing strategic decision making? How effective is our tactical level able to be? Is the tactical level effective in a way that supports our strategy?

We don't expect Soldiers to buy their own weapons and arrange their own ride to the fight, why would we expect other front-line actors to take on burdens that will hamper their efficacy?

People love processes!

The hard charging, results focused leader is a well worn business stereotype. Browse LinkedIn and you'll see professionals proclaim that they're "able to deliver", "goal oriented", or "focused on the bottom line". Expressions like "the end justifies the means", "a win is a win", or "any landing you can walk away from" also embody this belief that all that matters is what we end up with when the dust settles.

Combine that with what often seems like a general distaste for "process" and it's easy to see the allure in a results orientation. Moving from end-state to end-state with a measurement only for results achieved gives us an impression of concrete movement through an ambiguous world, like moving a game piece from square to square across a board.

A focus on results, however, flies in the face of so many human experiences that we crave. When playing a game, for instance, we don't want to just find out the score at the end -- we want to play the game. We want to exert our creative energies within a defined set of options in pursuit of an overarchingly understood goal.

Think about watching sports. Again, we don't just want the score at the end, we want to see how the teams got there. If we can't experience it for ourselves then we clamor for highlight reels and sports-writing, or even something so humble as a box-score. The baseball almost as old as the game itself and still just as useful for its ability to tell us how a game was played that led to the result we see in the score.

Our natural love for processes becomes even more evident in our story-telling mediums. We know in books and movies that good will triumph, leading couples will come together, and ne'er-do-wells will be put in their place. And yet we go to see the how of it all again and again. We bemoan plot holes, savor plot twists that expertly breakdown and reassemble our understanding of events, and we even go so far as to warn others when we might reveal key parts (spoiler alert!).

And yet when we put our same human selves in business settings, we often seem to lose interest in the how of the work, until the how becomes critical. Headline scandals at places like Volkswagen and Wells Fargo shock us not for the results they achieve, but for the processes by which they achieve those results. 

I think some of the natural love for processes is beginning to spread in the workplace. Witness the rise of storytelling training for big corporations, emphases on "narratives", the need for brands to have "stories" to connect with customers, etc. When done well these approaches can be transformative because of the deep-seated process-loving kernel in all of us; when not done well they push away customers repulsed by a lack of authenticity. 

If you want to see the world around you more clearly, pay attention to the processes by which you get the results you see. If it's not a compelling story for you, figure out a different way to assemble the pieces of the narrative and you'll unlock not only depths of energy within yourself, but also a well of connections with those around you. 

Rehearsals of Concept

Have a big, cross-functional process you're trying to iron out? Feel like it's full of buffers? Try a Rehearsal of Concept. To get started you'll need to think about the people, the process, and the guidelines. 

The People: Coordinate a time for key participants to rehearse.* Key participants usually look like the following:

• Function reps for each role involved
• E.g. if looking at invoice-to-cash cycles you might include customer support, delivery, collections, and accounting
• Reps for the systems involved
• E.g. if using an ERP to coordinate work, someone should "speak" for the ERP
• A facilitator to keep the group within the guidelines and on track

The Process: To use the group's time effectively, be specific about what will be rehearsed. A rehearsal can't cover everything, and that's okay. 

• Describe specific conditions
• Create a specific example that represents a likely scenario. This may feel limiting, but that's not the point. Your goal is to create a shared sense of understanding among the participants. Coordination and communication problems likely cut across products and services. 
• Start with a written plan
• Similar to a script for a play that gets edited as the actors try it out on stage. For some great reading on building descriptive process languages, I recommend Bruce Silver. 

The Guidelines: I'll lay these out like ground rules, but recognize them for the guidelines that they are. 

• Each rep speaks for themselves
• Including systems reps
• This is the hardest and most important guideline to follow!
• When speaking, think:
• What is received
• What is done to it
• What completes the work
• Mind the gaps!
• Everyone should listen for logic gaps or assumptions as the "work" goes from rep to rep
• Accept change!
• The whole purpose of the rehearsal is to smoke out the little gremlins that always creep into big plans. Be prepared to change your plan based on the interactions you observe in the rehearsal. In the inimitable words of an 82nd Airborne Division NCO, as recorded by Gordon Livingston, "if the map don't agree with the ground, then the map is wrong."

In my experience, "practice" is seen as a nice-to-have that is the first thing cut when resources or time get tight. Consider, however, the last big change you worked through. Did you practice before hand? How did it go?

Remember, the purpose of a rehearsal is as much or more about developing a shared sense of understanding for the participants than it is about the mechanics of any particular process. That shared understanding can then become a foundation for future changes. Without a cross-team understanding, how sustainable is effective cross-team action? Run a rehearsal, reduce the buffers, and learn as you go. 

Say what you will about the military, I think ADRP 5-0 nicely sums up rehearsals, "Effective rehearsals imprint a mental picture of the sequence of the operation's key actions and improve mutual understanding and coordination."

* Can't find a time for all your key participants to rehearse? Consider what that might signal about the long-term prospects of your group's project.

Ask more open-ended questions

Think about the differences between these two questions:

• Do you know why this happened?
  
• Why do you think this happened?

"Do you know..." could be answered with just a yes or no, whereas "why do you think..." could not. These are broad questions, of course, and I find many times people answer them the same way, so consider more nuanced questions:

• Did the third step in our process cause this defect?
  
• What do you think are the likely causes of this defect?

Again, the first question just needs a word, but the second question needs more. Assuming you don't know what caused the defect (hence the questions), will the first question get you what you need to know? Maybe. Who's asking? What's the team atmosphere like? How does management tolerate uncertainty? How safe do people feel when proposing new ideas or admitting they don't know something?

Karen Martin offers a handy guide with examples of the differences between close-ended and open-ended questions. Just becoming aware of the difference is a good place to start. Some methods I've developed or picked up to build this capability in myself and others are:

• Practice deliberately. Enlist a colleague and ask them questions about a project they're working on using only open-ended questions. Switch roles and repeat.
• Ask about what you don't know. Might seem simple enough, but think about the "atmosphere" questions above. Asking people what they thought, what they did, how they reacted, or how they felt are all examples of asking about what you don't know. 
• Know your time, setting, and audience. Avoid putting peers or subordinates on the spot in big group settings if you want to deeply understand something. Be proactive about finding another time and come back to the group with material changes. 
• Use some structure. Open-ended questions don't have to be vague. Consider these questions and think about how you can blend what you know with what you don't know:
• What happened?
• It looks to me like we completed this task successfully eight times today and failed on the ninth. What was different about the ninth time?
• Recognize when close-ended is okay! Sometimes you need to learn and sometimes you need to test hypotheses. Close-ended questions can be great for testing hypotheses, but if in doubt, I would recommend open-ended questions (because of the doubt!). 

Listen carefully in meetings, find a partner for practice and get started, or pause yourself before you send your next email and look at the questions you ask. Think about the types of responses the questions set up and whether that helps or hinders the cause.

Questions that are poorly worded, heavily structured, fraught with bias, or designed to trap people will increase the buffers around you and make it harder for you to see and understand what is truly happening. 

Stars & Guardians

One way to think about the perspectives individuals and teams have on their world is to place them on a spectrum from Stars to Guardians. I first encountered this in a class with Jim Baron. What I'll present below may not follow exactly what his book lays out (I leave out foot soldiers, for instance), but this is how I've come to apply this framework in my experiences. 

Think about the random events we encounter every day. How do they fall in relation to where you are on a spectrum from worse to better. Do your random events generally make things better than status quo? Or are random events for you generally worse than status quo?

Stars generally benefit from random events, whereas Guardians typically dread random events. Classic Star positions might include entrepreneurs who get traction with a product, marketers creating content that goes viral, or consultants that deliver a big project that delights an executive audience. 

Contrast that with some classic Guardian positions that could include a company IT team that has unexpected network downtime, an electric utility that experiences a transmission failure, or an auditor that misses a key bit of data. 

In my experience, Stars frequently have great ideas about how to make things better, while Guardians are often charged with protecting or managing critical resources of all types (e.g. time, energy, materials, labor). Neither position is wrong, but not recognizing the different perspectives can make it difficult for two sides to communicate. How can one reduce that buffer?

Stars: Seek to truly understand what it is the Guardian you're working with is protecting. Understand what some random events are that they've encountered recently and how they reacted to them. Learn their language and talk to them in their terms, developing ideas and approaches that have a grounding in what matters to them. Help them understand all facets of the random events they face, and perhaps they can shift down to the spectrum a little bit. 

Guardians: Don't hide your concerns under a blanket of "everything's fine." Understand that a Star may have different perspectives on the challenges you face that could be beneficial. Don't become lax in your responsibilities, but maintain mental flexibility and recognize that there is almost always more than one way to do something. 

Starting a new team with an expanding mandate? You may find yourselves shifting from Stars to Guardians over time. Facing a decline in relevance of the resources you're guarding? Think about examining the random events you're facing and look for upside you may not have seen before. 

There is no right answer, there is only right effort.