Fast-Paced Doesn’t Mean Constantly Changing Priorities

Fast-paced and constantly changing are two different things

I like fast-paced environments. I co-founded a startup where we had revenue in under four months, and the pace was a large part of why I loved it. Decisions were made in a hallway conversation, a problem found in the morning was fixed by the afternoon, and the distance between an idea and a customer using it was short. I have worked in growing companies and larger organizations since, and the teams I enjoyed most always had that same quality: they moved.

Over the years I have learned to separate that from something that looks similar from the outside and feels completely different on the inside. In a fast-paced team, decisions are quick and direction is stable. In a team whose priorities change constantly, decisions are quick and direction is not. The first team moves fast toward something. The second team moves fast, full stop.

A fast-paced engineering team decides quickly and ships often toward a goal that holds long enough to reach. Constantly changing priorities replace the goal every few days, so the team keeps starting and rarely finishes. Speed comes from short feedback loops and clear direction; it does not come from changing direction often.

Everyone in the room usually agrees with that sentence. The difficulty is noticing which one you are in, because both feel busy, and busy feels like progress.

Isn’t Agile supposed to handle change?

The Agile Manifesto values responding to change over following a plan, and I agree with it. The software I have built most successfully was shaped by what customers did, not by what we guessed in a planning document. Iterating in short cycles is exactly how you find out what to build.

But responding to change and absorbing unlimited change are different promises. Agile lowers the cost of changing direction by keeping work small and feedback fast. It does not make that cost zero. A story half built, a branch half reviewed, a design half discussed: each of those is work that has to be finished, parked or thrown away when the direction moves. Agile lets you choose which, cheaply, and it does not let you skip the choice. Changing priorities in an Agile team still has consequences; Agile keeps them small enough to see and decide on.

When Scrum stops fitting

Scrum assumes a sprint plan survives the sprint. The team plans two weeks of work, commits to a goal, and protects it. When that holds, it is a good rhythm. When priorities change several times a week, the commitment becomes fiction. Planning is redone mid-sprint, the board stops reflecting reality, and the retrospective is mostly an explanation of why the plan did not happen. The team ends up doing the ceremony and getting none of the benefit, and the carryover becomes chronic, which I wrote about in what sprint carryover is telling you.

Trying harder at Scrum will not fix it. Pick a process that matches how often priorities change.

The last row matters most. If direction changes daily, no board layout will save the team, because the instability is upstream of engineering. Switching to Kanban there just makes the churn more efficient. That needs a conversation with whoever is setting the priorities, which is a leadership job and the subject of the sections below.

What context switching actually costs

Here is an illustrative week, the kind I think most engineers will recognize. Monday, an engineer starts a reporting feature and spends the morning loading the data model into their head. Tuesday, it is paused for an integration a customer asked for. Wednesday, a production issue takes the afternoon. Thursday, the reporting feature is back, but someone has merged a schema change in the meantime, so the morning goes to rebasing and re-reading. Friday, the integration is deprioritized. Five days of effort, and nothing shipped.

The visible cost is the unfinished work. The less visible costs are worse. Every restart pays to reload context. Every pause leaves a branch that drifts away from main and gets harder to merge. Every re-plan is a meeting. Half-finished work is also inventory: it has cost money and delivered nothing, and the more of it a team carries, the more it costs to keep track of. And people notice. Engineers who never finish anything stop believing the plan, and a team that does not believe the plan stops raising problems early, because what would be the point. Being busy is not the same as being productive, and starting more work does not mean delivering more value. Engineering capacity is finite, so every new start is paid for by something that is now not finishing.

Real emergencies and loud requests

Some things are urgent. Customers cannot use the product. Data is wrong. Revenue is being lost by the hour. A security problem is open. Those should interrupt anything, and a team that cannot drop everything for them has a different problem.

Most requests that arrive marked urgent are important to someone, often for a good reason, and arrived loudly while nothing was on fire. When everything is urgent, nothing is, because the word stops carrying information. I try to sort requests by asking what happens if this waits until we finish what is in flight. If the honest answer is “a customer is blocked”, it goes now. If it is “someone will be disappointed”, it goes into planning, with a date. I wrote about how to ask why a priority changed, and how to tell a strategic shift from a stream of interruptions, in when everything is a priority; I will not repeat it here.

Leaders make the tradeoff visible

The worst thing an engineering leader can do with a new priority is say yes and add it to the pile. It feels supportive, and it hurts the team, because it now carries more than it can finish, and the business believes it is getting everything it asked for. The gap shows up weeks later as a missed date nobody saw coming.

The better response is a question, asked without any defensiveness, because it is a real question:

If this becomes our highest priority, what should we stop working on?

That question does two things. It treats the request as legitimate, which it usually is. And it puts the cost on the table where the person who owns the business decision can see it. Sometimes the answer is to stop something, and that is fine; the business decided with the facts. Sometimes, seeing the cost, the requester decides it can wait two weeks, and that is fine too. What it prevents is the silent version, where everything is accepted and the team absorbs the impossible. As CTO and in operations roles, I learned that executives almost always prefer to make the tradeoff themselves than to discover later that engineering made it for them. Making tradeoffs visible is part of what I mean by working across product and leadership.

Finish before you start

If I could give a team one rule, it would be to finish before starting something new. A work-in-progress limit sounds bureaucratic and works like a release valve: when the limit is reached, the only way to start something is to finish something. It makes the team swarm on the work closest to done, and it turns a new priority into a visible swap instead of an invisible addition.

Smaller changes make that rule practical. A story that takes two days can usually finish before the next priority shift. A story that takes three weeks almost never does. Smaller pull requests get reviewed the same day instead of sitting, and smaller releases are cheap to make and cheap to roll back. A team working this way can change direction often without much waste, because there is little in flight to throw away. That is the real connection between small batches and agility, and why I wrote about smaller user stories and pull requests separately.

Process that helps engineers

Processes should solve problems, not create additional work. I judge every piece of process by whether it removes a problem the team really has.

A lightweight Agile rhythm, with a clear goal and short planning, helps. A standup that is a status report to a manager does not; an asynchronous update in a channel gives the same information without stopping everyone at the same time each day, and saves the live conversation for when someone is blocked. A Kanban board with a WIP limit helps when priorities move. Small pull requests reviewed within a day help everyone. Continuous delivery helps most of all, because when shipping is routine, finishing becomes the natural end of every piece of work instead of a separate event that gets postponed. And if a ceremony has outlived the problem it solved, I would rather drop it than defend it.

The test I use is simple: if the team stopped doing this tomorrow, what would go wrong? If the answer is nothing, it is overhead.

What I have learned

I have been on both sides of this. As a founder, I was sometimes the person changing the priorities, because a customer called or an opportunity appeared, and I learned the hard way what it did to the people building things. As a CTO and engineering leader, I have been the person explaining to the business why a team that was working hard was not delivering, and more often than not the answer was that it had been asked to start too many things.

The balance I aim for has three parts. The business needs flexibility, because markets and customers do change, and a team that cannot respond is a liability. Engineering needs discipline, because finishing is what turns effort into value. And the team needs to see that the two are being balanced honestly, by a leader who will say what something costs and then support whatever the business decides. A fast-paced company still needs clear direction. That direction is the thing that lets a team go fast.

Short answers