Telerik blogs

Priority tells you what matters. Timing tells you if the moment is right. Here’s why that distinction changes everything about how you build.

A customer threatened to cancel. Full panic. A board meeting to discuss how to retain him, budget approved and allocated to honor his demands. A scrum team started fixing. I flew to the UK to sit with him.

We had redesigned the entire UI. Not a small fix. We completely overhauled the user experience. From a very old tool with toolbars to an application with a strip.

We didn’t just move buttons to ribbons with tabs. We restructured the entire information architecture. Fixed, opinionated workflows that guided users through the critical steps to model complex geological concepts.

He hated it. He demanded a rollback.

I reserved time to interview him. Asked questions. Listened. Tried to sense his reality, his context, where he was coming from. How he was perceiving the changes.

What I discovered changed everything.

He wasn’t even using the latest version. He hadn’t tried the new UI at all. He had simply refused. While we moved on and developed the next generation of our software, he had not. He was still way behind. And somewhere at the back of the queue, feeling ignored and dismissed.

That feeling made him rage. But it also highlighted a bigger problem.

In the room next door, two junior geologists were being trained on the exact same concept. They loved it. The design was exactly what the team needed. What he needed too.

He was desperate for a transformation in his company. A way to step back from his expert role and become a guide for the younger generation. Once I explained the concepts, he understood. He was appreciative of the work. He was on board.

We almost rolled back an expensive, fundamental shift based on an emotional rant from a customer speaking from expired context.

It was never about the concept. It was about misunderstanding context.

The Linearity Trap

A backlog is not a queue. It’s a context-sensitive collection.

Every item in it was written at a specific moment, about a specific reality. That reality changes. The backlog doesn’t update itself.

The linearity trap is treating it like a queue anyway. Adding new requests. Reorganizing. Managing delay. Shipping. Without ever asking: does this still belong in the collection?

The customer had been reporting improvements and bugs for a long time. But we moved on. We shipped. And while we did, he stood still. By the time his feedback reached the top of the queue, the context it was written in had long since changed.

The problem wasn’t that we were behind. We were committing to work that was already outdated.

Delay Is Not the Problem. Decay Is.

A lot of backlog management is really about managing time. Managing delivery. Focused on shipping as much high-quality work as possible by the promised date.

Managing delay is a conscious decision. It’s about choosing when to push something back. That’s prioritization. That’s what I wrote about in the previous article.

But the bigger problem is decay.

Decay is what happens to the work you’re not doing. While you’re waiting, while you’re delaying, what has been written down is eroding. Rusting. Because context expires.

It’s like the best-before date on a package. By the time you grab it from the shelf, you need to check the date before you consume it.

A lot of backlogs are just queues constantly filled with requests, feedback and bug reports. Nobody checks the date. Nobody asks: is this still valid?

I’ve seen old backlog items treated as still true when the context they described no longer existed. They were no longer worth pursuing. The more context you capture when you write them, the easier it is to later assess whether they still fit.

Something can be very old and still be good. But developing the sense to distinguish that is the work. Understanding whether it’s expired or not. Whether it’s still safe to consume.

In the UK, the right response would have been to delay any work on his requests. To first discover whether his feedback was based on expired context. Instead, urgency won. And decay nearly cost us everything.

Urgency vs. Timing

The urgency that came up was really signaling a demand. Someone pushing. Pressure.

And under pressure, you don’t always make the most strategic decisions. The board panicked. Money appeared. Time was freed up. Nobody stopped to check the return on investment, whether it was worth it. It was an emotional response.

That happens. We’re humans. And that emotion is sometimes also why we close amazing deals and do great things for loyal customers. So it wasn’t all wrong. Part of the response was also recognizing the loyalty of a customer who had been with us through harder times.

But urgency gets the attention. It drives the emotion. And what we need underneath it is judgment.

Timing is a readiness signal. It’s not driven by pressure. It’s driven by context.

  • Is the customer ready?
  • Is the market ready?
  • Is the team ready?
  • Is the moment alive?

Those are timing questions. Urgency can’t answer them.

Compound vs. Corrosion

We’re always looking for momentum. Shipping as much as we can, as fast as possible, without compromising quality.

But without sensing whether the time is right, we create progress without compounding.

Compounding is making sure what you ship ties into the next thing and builds over time into the desired version of your software aligned with your vision. Creating conditions so that what comes next makes sense.

The opposite is corrosion. Work that sits in the backlog long enough starts to corrode. And when you finally act on it, you might ship something that corrodes the foundation of your software rather than building it. Hurting not just momentum but overall quality.

When we made that big shift to the UI, we should have reassessed the entire backlog. Diagnosed it. Made sure there was no outdated work hiding in the queue because of it.

We didn’t. And a decayed issue almost corroded the core concept.

Context Sensitivity

Why did feedback and previous user requests corrode? Because the timeframe wasn’t short. That concept developed over multiple months. We should have been capturing the context shift and using it as a filter on our backlog to stay ahead of it.

But capturing context is the hard part.

The world moves on. Your market, client and economic reality change constantly. The technical reality shifts the moment you upgrade systems and build with new technologies. The context you’re shipping into is constantly moving.

And on top of that, emotional states. Not everybody handles change well. Not everybody’s personal context is aligned with where you’re going.

You need to develop a sense to see those shifts.

Keep a Human in the Loop

AI is very good at capturing context. Writing it down. Cross-referencing it. Flagging patterns. It can help us see and track everything we can’t manage on our own.

But the moment context is written down, it’s already outdated. And managing that expiration date is a collaborative effort. AI can help cross-check against captured context, flag a customer as a potential churn risk, surface old backlog items that conflict with new ones.

What it can’t do is sit in the room.

What I did with that customer—reserving time, asking questions, listening—that’s a nuance. A human sense that becomes more important as we connect more and more data at greater and greater speed.

AI can read the signal. It can’t always hear what’s between the lines. The emotional rage that looks like a high-priority request but is really a loyalty problem. The developer who goes quiet in sprint planning. The feedback that reads as a bug report but is actually a cry for better onboarding.

That’s not in the data. It’s in the room.

Closure

Timing isn’t about managing deadlines. It’s about reading whether the moment is right. Priority tells you what matters. Timing tells you whether now is the moment to act on it or not at all.

The backlog or data alone won’t tell you that. You need to read the room. Develop that sense. Check the expiration date. Keep humans in the loop for the context AI can’t capture.

We ship when it matters. We shred when it’s expired.

On purpose. By design.


About the Author

Teon Beijl

Teon Beijl is a business designer with over a decade of experience in enterprise software for the oil and gas industry.
Formerly Global Design Lead for reservoir modeling, remote operations and optimization software at Baker Hughes, he now helps people who feel stuck through his own business, Unpuzzler. Teon works with leaders on business design and with professionals on career design, leveraging his experience as both designer and leader to help people create clarity and live on purpose—by design. Connect with Teon on LinkedIn or Substack.

Related Posts

Comments

Comments are disabled in preview mode.