Get Everything Done

Jesse - This seems similar to the Theory of Constraints approach of assessing a situation by listing whatever is bothering you -- fears, pains, frustrations. Then think through them and decide which of them is bothering you THE MOST.

It is useful to start with negative things like fear and pain. We usually feel it more sharply than we feel aspirational things -- so it's easier to put them into words. And the aspirational things are always there, implicit in the fear. The reason something is causing fear or pain is because it is threatening an important aspiration, but the aspiration is a lot harder to put into words.

So, once you have identified the fear or pain that is bothering you the most, you can put it into a conflict diagram to sort it out. The premise is that any persistent fear or frustration or pain is *persistent* precisely because it is the result of an unresolved conflict. We keep oscillating between the different choices, we can't choose between the different polarities.

Here are the steps:

(1) Describe (in a short paragraph) your undesirable situation (the fear, the pain, the frustration, the vicious cycle, how it impacts you, how it blocks you from doing what you want to do)

(2) Describe (in one sentence) the important need is jeopardized by (1)

(3) What action do you want to take in order to satisfy (2) ?

(4) Describe (in one sentence) the important need that prevents you from doing (3)

(5) What action do you take to satisfy (4) ?

(6) What is the common need satisfied by both (2) and (4)?


Typically you end up with a succinct definition of your conflict. You need (2) and (4) -- but to get them, you need to do (3) and (5), and you CAN'T do both (3) and (5) because they are mutually exclusive.

Example:

(1) The engineering team is trying to develop the next-gen product, but is continually interrupted to provide support for the current (old) product. The interruptions are driving everyone crazy and not allowing anyone to focus. The engineers are frustrated that the support team is always asking the same basic questions and seems really disorganized. The lead developer is especially frustrated and even wants to quit and go work on something where she can really make use of her skills. The support team is frustrated because the old product is poorly documented and they can't get the engineers to write anything down (they are too busy).

(2) Important Need: We must complete the new product in time to reach the market window.

(3) Action: Engineers focus 100% on new product development.

(4) Another Important Need: Protect current revenue from the older product.

(5) Action: Engineers provide proper support for the older products.

(6) Common Goal achieved by the two needs: The company continues as a profitable going concern.


(3) and (5) are mutually exclusive -- thus you have a conflict. Everyone is taking sides around the conflict, and blaming each other for not respecting their needs, etc.

Once you frame the conflict like that, you can start to see more clearly what is really going on. You can come to realize that everyone really does accept the needs (2) and (4) and the ultimate goal (5), and can also see that the conflict is really with (3) and (5). Then you can get some ideas how to meet both the needs without any compromises and without any blaming.

It works for personal issues just as well as for team or organizational issues.

Basically that approach puts all the blame on one party -- and the scenario already describes a lot of blame going around. It might force some short-term focus but is unlikely to get to the root cause of the frustrations and will likely have longer-term undesirable effects. For example, the lead developer is already frustrated and thinking of leaving. Now she is essentially being blamed for the situation, and maybe even suspected of incompetence -- that just might push her over the edge. That would put even more pressure on the engineering team, which could threaten both objectives even more.

It is uncanny how closely this conversation resembles real life. :D

When faced with a situation like this, a very common response is "We need find out who is responsible for this situation and hold them accountable!"

Or maybe "Let's bring in someone who knows what they are doing who can fix this!"

But this fails to recognize that this is system problem, not a person problem. Pinning it on a person just exacerbates the blame game -- and to get back to Jesse's original theme, it exacerbates the fear, the pain, the frustration.

It might end up being a person problem -- maybe there is an individual who is responsible for the overall system, and these outcomes are a direct result of their negligent or malicious choices.

But usually these things evolve over time as complex adaptive systems respond to the volatility and change that is happening all around us. A good situation can devolve into a thorny conflict like this as a result of some change in the system dynamics that escaped everyone's attention.

The best approach is to learn and adapt. But it's very difficult to do that when there is a culture of blaming -- nobody wants to take any risks, to probe, to experiment, to explore, when they will be blamed or "held accountable" if things go wrong. So everyone just entrenches themselves more deeply in their own position -- deepening and prolonging the conflict.

So how to solve it?

If we explore the Important Needs a little more deeply, we can usually find a good solution that eliminates the conflict. Ask yourself -- why do we want Important Need (4)? Why do we want to escape from it? Then ask -- why do we want Important Need (2)? Why do we avoid it?

Here are some answer I came up with.

Why do we want to protect current revenue from the older product?
-- Because the old product is our bread-and-butter.
-- Our cash flow comes from the old product.

Why do we want to escape from focusing on the old product?
-- Because we want the engineers to focus on the new stuff.
-- The engineers are expensive, we need them to do the highest-level work that nobody else can do.
-- The support team should be able to handle the old stuff on their own.

Why do we want to complete the new product in time to reach the market window?
-- Because we want to continue being competitive in the future.
-- Because we want to go after new customers / new markets.

Why do we avoid focusing on the new product?
-- We need to protect our current cash flow
-- We need to protect our current customers

Looking over these assumptions, do any of them speak to our behaviors that are under our control? Yes, several do -- and one specifically jumps out at me:

"The support team should be able to handle the old stuff on their own."

This seems like an obvious direction. Why isn't it happening? I don't mean "Who is to blame that this is happening?" I mean rather, "What is missing from the system that would allow the support team to handle the old stuff on their own?"

The clue is in the original problem statement. "The old product is poorly documented."

OK, how can we solve this?

Here are some ideas:
1-- Get agreement from management that the service level agreement for handling any issues that require engineering support be temporarily extended by 24 hours. This is a prerequisite for idea #2.
2-- Set up a dedicated meeting every day where the support team can get answers from the engineering team on whatever they need. If the lead developer is the one who knows a lot of the answers, then require the lead developer to attend this meeting -- but otherwise, protect the lead developer's time from any other interruptions.
3-- These measures will give breathing room for everyone to respond to issues without constant interruptions -- providing immediate relief. The engineers can spend the rest of their time focusing on the new product.
4-- Ask the support team to list the issues that have come up over the last N days where they need to escalate to engineering. Use the 80/20 rule to identify the most common problems that are having the biggest impact.
5-- Assign an engineer to work with the support team to make sure the issues identified in #4 are properly documented and the support team is properly trained to handle them. Maybe just roll this activity into the daily meeting, if possible.
6-- Following this process, the engineers get immediate relief from the interruptions, and the support team becomes more and more independent over time -- thus eliminating the conflict.

I am sure others could come up with similar or better ideas. The main idea is that this approach takes no sides, does not indulge in blaming, and eliminates the conflict altogether by eliminating its cause.

To tie it back to Jesse's original post -- the idea is that the fear and the pain hold the clues to our real underlying objectives and needs, but it can take some effort to put them into words. This framework helps do that, and then helps guide us toward finding simple but comprehensive solutions.

The solutions are substantially different. The teams already had enough resources.

Starting with blame usually obscures the real root causes, and taking action on that basis usually makes the problems worse.

Sometimes you have to replace people anyway, and do it quickly, because you need someone who can immediately take control of the situation. I imagine this applies to your army example. But when the crisis has passed and you have time to sort out the situation without the bullets flying over your head, an After-Action Review can help find the root causes so you can find a more permanent solution.

And of course, sometimes there really are sub-standard players who are not in the right job, or are negligent, malicious, or hubristic. And you have to remove them quickly, especially if they are in leadership positions and poisoning the whole organization. But it's counterproductive to have this as one's default response to difficult situations.

I think all of this applies to personal time management as well, and to Jesse's original post.

When our time management isn't working -- there is fear, uncertainty, procrastination, overwhelm, etc. -- blaming myself (or others) and forcing myself (or others) to get something done can work in the short term. Deadline pressure is a great example. But brute force and self-blame doesn't work for sustained periods, especially for sustained innovation and creativity. Resolving the systemic issues that are creating the procrastination and overwhelm is a lot more effective.