Sequencing Is Not an Opinion

Good tech companies are the ones where each function does its own job well. Great tech companies are the ones where the functions collaborate and trust each other enough to let each one own its call.

For the functions to work well together, the work gets split into projects, and every project keeps passing through three questions: what matters, how big and in which order.

Priority answers what matters. It is a want, so it should be cheap to change, and a good ranking gets reshuffled every time the company learns something. This is product’s domain.

Scoping answers how big, and it belongs to everyone, because the size of a project depends on the capabilities, the time and the people the company can put behind it.

Sequencing answers in which order, given the software we already have: what has to exist before what. This is engineering’s domain, and the facts in it do not move because someone wants them to.

A project does not go through those once and it is done. Priorities shift, scopes shrink and the sequence gets checked again against a living codebase. The exact process is a separate topic. Here I want to go deeper into the split between them.

Priority and sequencing get tangled because they look like the same decision. Both produce an order and both end up as items on the same roadmap, two sides of one coin, so sequencing gets treated as one more opinion about priority. What a product should be is a matter of opinion, but what makes it keep working rests on established engineering principles.

Everyone knows what happens when that gets ignored. Technical work gets pushed back for business priorities until the company grinds to a halt. At that point fixing it is too expensive, and building from scratch is a slippery slope that many carry long-lasting scars from.

That is the difference between the two orders. Priority is what makes a company prosper. Sequencing is what lets it keep delivering, keep living and grow more capable than it was.

Great companies understand business, and business is all three questions answered well: priorities that point at real value, projects scoped as small as possible and a sequence built for the long run rather than the quick win. A company that only sprints to deliver hacky MVPs ends up with demotivated engineers, and demotivated engineers build bad software.

When Priority Set the Order

Some time ago an initiative came out on top of the priority list. That part was fine. But part of the spec was endless scrolling: the user keeps going and the exercises keep coming. It was written down as a hard requirement next to a handful of others, and product and design built the whole feature on top of it before engineering was asked to scope the work.

By then it was too late. The system we already had could not do endless scrolling easily. At a minimum we needed new storage, delivery, UI and completion logic, running in parallel to the old ones built for batches of exercises. Bending the old system into endless scrolling would have been a huge pile of technical debt.

Because both the deadline and the scope were fixed, people had to be moved around and other product and engineering projects had to be put on hold. Some of them were important infrastructure work, and infrastructure left half-done has zero impact regardless of the time already invested in it, a typical example of bearings.

A better approach would have been to look at the time and the people available and ask what the smallest version of this project is that still teaches us something and gives users something they value. That version might have included endless scrolling or might not. Either way the teams building it would have owned the shape of the work instead of inheriting it, and they would have been far less stressed doing it.

Two things failed in that story and they usually fail together: priority overrode sequencing, and scoping happened without engineering.

Three Debts and a Fourth

Everyone in software knows one bill for that kind of decision. Ward Cunningham named it technical debt in 1992: you cut a corner, the system grows around it and the fix that was trivial when you skipped it becomes an excavation by the time you return. Margaret-Anne Storey’s triple debt model adds two more, and Addy Osmani builds on it in his essay on intent debt. Cognitive debt is code that runs but that nobody on the team can fully explain anymore, which AI-assisted work produces at speed. Intent debt is the missing record of why the system is the way it is. All three live in the system. They grow quietly and they bite later.

There is a fourth debt and it lives in the people. Motivational debt grows when a function’s expertise gets overruled often enough. Tell engineers in which order to build things, treat their sequencing as one more opinion, and they slowly stop owning the outcome. They stop proposing ideas. They stop arguing about architecture. They do what was asked and no more, and in the worst case they stop caring whether it works. A 2020 study in the Journal of Systems and Software found the same pattern in interviews and time-tracking data: technical debt lowers developer morale, and managing it raises morale back.

What makes this debt different is the interest schedule. The other three let you borrow now and pay later. Motivational debt charges from the first day: demotivate people today and the work gets worse today. It is also the hardest to pay off, because the repayment is trust, and people take time to believe that things have actually changed. Employees who do not care about the business or its outcomes are one sure way to end up with a mediocre company that does the minimum to survive.

Not Every Foundation Is a Constraint

Engineers often complain that they get no time for proper foundational work. Product managers, on the other hand, ask why everything takes so long. I will not pick a side here, but I have seen engineers build things nobody needs or cares about far too often. The biggest problem with smart people is that they optimize things that should not exist.

I have spent days automating five-minute tasks that ran once every two weeks, or rarer. I always argued that the system compounds and needs less work in the long run. The real reason was that it was fun, not that there was a business benefit or a decent return on the time. AI has of course flipped that calculation, but the point stands.

This failure is not unique to engineers. A 2015 study in JAMA Internal Medicine looked at what happens to high-risk heart patients in teaching hospitals while the country’s cardiologists are away at their national conferences. Mortality went down. Fewer procedures were done and the patients did better. When you hold a hammer everything looks like a nail, and specialists hold the biggest hammers. Engineering falls into this fast, and every problem starts to look like it needs a rewrite.

The way out is for engineers to get better at business. Companies exist to make money. The value users get from software is usually measured in what they pay for it, and that money is what pays for the engineering. I have seen too many engineers treat that as somebody else’s concern, which leads to fights, resentment and dysfunctional teams.

So how does product tell a real constraint from a preference? It cannot, at least not fully. Bad engineering decisions can bring a company to a standstill, and product managers can do very little about it. Making sure the right calls get made is the responsibility of the CTO and the engineering leaders, who should then delegate and empower the engineers with whom the day-to-day technical decisions and implementation details lie.

Own the Sequence

You should aim to have pragmatic engineers in the room when scoping starts. Partly to help cut the scope down to a good first version and the iterations after it, but also to keep the technical sequence in view. There is no template or system here that you can roll out in your company. It is a few business-aware engineers supporting the scoping and owning the sequencing. Jira, Linear, Basecamp and AI cannot solve it, because deciding the priority, the scope and the sequence is the job.

None of this means leadership makes the interesting decisions. An engineering leader does not say how something gets built. The job is to say, at a high level, whether it is possible and whether the sequence makes sense. A product leader steering the process does not gather all the data and write every spec. The job is to make sure the ship is pointed in the right direction. Everything in between, the many day-to-day problems of actually getting things out, belongs to the people doing the work. Leadership sets the constraints, and inside those constraints the teams get to be creative and own the result.

None of this is about who is right, and it is not politics. You can tell how a company works by watching how its functions treat each other: whether product trusts engineering on the order, whether engineering respects the priority, whether the two of them scope together. Priority answers what we want. Sequencing answers what is true. The functions that own the first question should listen to engineering on the second because sequencing is not an opinion.