Your "simple rebuild" is lying to you

Six weeks into what was supposed to be a straightforward modernization project, someone on the client’s team mentioned, almost in passing, that we’d need to track their hedge transactions too.

We thought our goal was to take a 20-year-old PowerBuilder application and rebuild it on modern technology. The app calculated location-specific prices for corn, soybeans, and wheat every ten minutes, prices the company would offer farmers for their seed. The company had been using it for two decades. The two people who used it said they knew how it worked. How complicated could a rebuild be?

Then discovery started peeling back layers. Grain elevator prices needed an API that didn’t cover every elevator, so someone would still enter some by hand. And now: hedge transactions, options trades on the CME the company used to protect itself from setting prices months in advance.

On top of that, we realized that the main problem wasn’t aging technology, although it was a problem. The main problem was the existing app made it too easy to introduce pricing errors that could add up to real money when multiplied across thousands of bushels.

Turns out we were doing more than moving a pricing calculator to new technology. We were building a piece of financial infrastructure that needed to prevent errors.

Old and familiar isn’t the same as simple

Complexity and uncertainty don’t stay fixed once a system launches. They grow as the business around the system changes, and the system doesn’t change to keep up.

The pricing app started as a straightforward calculator. Over twenty years, the ag company added new processes and new risk management practices. The business analyst maintaining the app touched the PowerBuilder code plenty, but only to fix bugs or accommodate one off workflows users built up around it. Nobody reviewed the system to determine whether it was fully supporting the business process it was meant to enable. As a result, everyone assumed the app was fine, until it wasn’t.

That assumption is easy to make. A system that’s old and familiar feels safe. Nobody’s complained in years, and the team that built it moved on long ago without incident. But familiarity measures how comfortable people are with a system, not how complex or uncertain it actually is underneath.

Reopening the system and rebuilding every calculation and data source from scratch forced us to see it clearly for the first time. The business had built something carrying real financial exposure. It depended on outside institutions none of us had dealt with before.

Complexity and uncertainty need separate scores

The framework that finally explained what we were looking at is the Context Leadership Model, built by Todd Little and introduced in Stand Back and Deliver.

It scores a product on two dimensions: how complex it is, and how uncertain it is.

Complexity comes from things like team size, how many other systems depend on you, and how much domain knowledge your team already has.

Uncertainty comes from things like how well you understand what stakeholders actually need, and whether you’re using proven technology or something new.

Score high or low on each dimension and you land in one of four quadrants, each with its own risk to watch for and its own way to handle it:

Sheepdog

(low complexity, low uncertainty) Your team already understands the domain and the technology, so the real risk is over-managing it.

Build a shared understanding of what “done” looks like, then stand back. A simple kanban board is usually all the process you need.

Colt

(low complexity, high uncertainty) Your team is small, but nobody knows exactly what the answer looks like yet. The risk is building the wrong thing with confidence.

Reduce it by narrowing scope to one specific, well-understood group of stakeholders. Mitigate what’s left with fast iterations and real feedback before you commit to a direction.

Cow

(high complexity, low uncertainty) Your work is well understood, but it touches a lot of people and systems, so the risk is breaking something else when you change it.

Reduce it by splitting a large team into smaller groups tied to pieces of the system that can move independently. Mitigate the rest with clearly published interfaces and regular checkpoints with every team that depends on you.

Bull

(high complexity, high uncertainty) The work on your product is both complex and uncertain at the same time, which makes it the highest-risk quadrant to run.

Where you can, reduce the risk by decomposing the bull into cows and colts you run semi-independently. Where you can’t, mitigate with both tools at once: fast feedback loops for the uncertain parts, published interfaces and coordination rhythms for the complex parts.

Six weeks in, the ag pricing app stopped looking like a cow, a big, familiar system we mostly needed to coordinate around, and started looking like a bull. It wasn’t just the stakeholders and legacy logic we had to account for. There was genuine uncertainty underneath: a hedging domain none of us knew well, and a live dependency on a data source we’d never integrated with before.

Score your product before you commit to a plan

If we’d run this assessment before committing to a rebuild plan, questions like the ones below would have surfaced the risks we faced before we’d already promised a timeline.

The Context Leadership Model assessment:

Complexity:

1. How many people actively build and maintain this product?

2. What actually breaks if this product is wrong or goes down?

3. Is the team in one place, or spread across locations and time zones?

4. Is this an established team that knows the product cold, or a newer team still learning it?

5. Does your team understand the business domain as well as the people who use the product, or are there real gaps?

6. How many other systems or teams does this product depend on, or depend on it?

Uncertainty:

1. How well do you understand what your internal stakeholders actually need, versus a guess likely to change?

2. Are you extending proven technology, or working with something new to your team?

3. Is there one clear owner of requirements, or several stakeholder groups with competing needs?

4. How far out is your next release, and how much could change before you get there?

5. How much control do you have over scope once the work starts?

Average your complexity score and your uncertainty score separately. Score high on either dimension, and you’re carrying risk on that dimension. Score high on both, and you’re running with the bulls whether you meant to or not.

You can take the Context Assessment on Inside Product to assess your product and receive recommendations for mitigating the high risks the assessment reveals.

You don’t have time to score every change, and you don’t need to

Two objections come up most.

First, who has time to run an eleven-question assessment before every change to every system? You’d never ship anything!

Fair, but that’s not what I’m suggesting.

Small bug fixes and routine configuration changes don’t need a fresh score. The business analyst maintaining the pricing app made hundreds of those calls over twenty years without reassessing anything, and that was the right call.

The assessment is appropriate at specific points in the product lifecycle such as before a rebuild, or before you commit a timeline for something the team hasn’t done before. Those are the moments when assumptions are most likely wrong, and being wrong is most expensive.

Second, we only knew to ask about hedge tracking after discovery found it. Isn’t the assessment just hindsight, dressed up as foresight?

Not quite. The questions don’t ask you to predict specific requirements, like needing to track hedge transactions.

They ask you to score your own confidence, like whether your team understands the domain as well as the people who use the product, or how many other systems your product depends on.

Answer those honestly on the pricing app before discovery, and you land on a high score on both, not because you knew about hedging, but because you’d have admitted you didn’t fully know what the system touched. That admission is the signal worth acting on.

Twenty minutes of scoring before you set a delivery date is cheap. Discovering the real scope six weeks into a project you already estimated is not.

Before your next “simple” rebuild

We ended up treating the rebuild like the bull it actually was: fast iterations to work through the hedging and pricing-source uncertainty, paired with clear interfaces to the elevator API and the CME feed to manage the dependency risk.

When the whole team went remote in March 2020, adding another complexity risk overnight, we adjusted our coordination rhythm and kept going. The system launched on April 1, 2020, on time, doing exactly what it needed to do.

Next time someone hands you a “simple” rebuild, or a request that seems too small to think twice about, run it through the assessment before you commit to a solution. A system’s age and its user count won’t tell you what you’re walking into. Its complexity and uncertainty will.

Have you ever worked on a system that turned out to be way more complex or uncertain than everyone assumed going in? Reply and let me know.