If you’ve ever been a software engineer, you probably have experienced thrash: when priorities change overnight and you’re expected to drop everything. And then they change again. And again.

How does this happen?

Thrash happens when an organization is not able to see the effect of its decisions on priorities. It happens because people cannot make decisions based on on what they do not see or do not know. It happens when there is no clarity about what’s important.

Compounding Problems

When software delivery priorities change abruptly, it creates WIP (work in progress). This WIP is left off to the side, where it decays. Decay in knowledge work means the assumptions about reality or the code change (because time passes) or people forget what they were doing and have to figure it all out again.

After the abrupt change, other priorities that were also important are remembered. But they’re behind. Why are they behind? People acknowledge the changing priorities as part of the cause, but rarely its full impact.

More things are late. And then the things that were coming after those things are late.

Sure, we had one bad problem, but we can’t keep blaming that forever. The engineers are obviously to blame. This creates some tension, and some awkward conversations. Everyone agrees it shouldn’t happen and they start padding estimates.

Padded estimates are obviously BS, and trust starts to drop, especially after the first 2-month piece of work is delivered in 3 weeks without any explanation as to why that’s possible.

Then, in an effort to save face, some engineers give wildly over-optimistic estimates that don’t include all of the responsible work they should do to make sure software can continue to be delivered.

Nobody believes the engineers either way, and suddenly everything is completely dysfunctional.

Whose fault is this?

It’s easy to throw blame around, and honestly it’s probably deserved on the engineering side.

But more importantly, why does this happen?

You can’t work with what you can’t see

If you can’t see it, it’s not there.

Sometimes priorities are not enumerated and written down.

Other times, the work that represents the commitments to those priorities is not represented in a place that can be seen.

But most often, the work can be seen but is not accessible. Or not discoverable. Or buried in noise.

JIRA, for instance, allows you to create 1000’s of tickets in your backlog.

A backlog, when used well, is something like an action plan. It’s a prioritized sequence of events. But when the backlog starts to also include “maybe” or “should” items, the real work streams can start to get buried.

How will a given change in priorities, which means changing the order work is done, affect all the existing commitments?

This question usually cannot be easily answered. Because while the information is technically “there” it is not there in a way that is comprehensible. So it’s not a real part of the discussion.

So most of the consequences of changing priorities are discovered later. And that creates mistrust and division.

The simple, not easy, solution

In order to talk about the effect on the plan, there has to be a plan. The plan needs to exist in a way that can be seen at different levels of definition depending on who is looking.

A CEO should be able to see when things will happen, and what the likely effect of things happening will be when a change is made. All the downstream plan effects, with relative certainty (depending on how far away they are) should be easy to see.

Effectively, we make the invisible visible. We make the effect of the plan changes something that can be discussed, weighed, and measured. The costs can be compared to the benefits.

Should we drop everything right now? Let’s turn that plan into numbers, and likely impact.

At the very minimum, you should know what will be delayed by 3+ weeks when you add 3 weeks of work (and the delay will be more than 3 weeks, because knowledge work decays when it sits as WIP).

You can’t use what you can’t see. You need to see impacts to make them part of the decision-making process.

This helps create trust, because everyone is looking together, and discussing the same reality.

Benefits of plan changes are always visible. The costs are usually hidden.

In a further post, we can discuss how this works.