The priority inversion trap

I’ve watched several companies try the same clever approach: build a product while running a consultancy. Use downtime to work on the product. Makes sense, right?

The logic is simple. When developers aren’t busy with client work, they focus on building something that could eventually become the main business. Sounds like smart resource utilization.

But here’s where it gets interesting.

The challenge always became prioritization. How do you decide what these “spare time” developers should work on? You can’t give them the most critical features because what if a client project comes up and pulls them away?

So you end up giving them the less important stuff. The nice to have features. The experimental work. Tasks without real deadlines or with artificial ones just to create some focus.

That sounds reasonable. Low risk, low commitment work for uncertain availability.

But then you hit the handoff problem.

Eventually, this side work needs to integrate with the main product. The core team (the one working on actual priorities) has to stop what they’re doing to review, understand and approve the work from the “spare time” team.

That’s when things get messy.

You end up with a priority inversion. Your high-priority work gets deprioritized so you can process the low-priority work you assigned to fill downtime.

The thing you said was most important gets pushed aside to handle the thing you said was least important.

I’ve seen this pattern multiple times now. It always looks smart on paper. Use every available hour. Keep people productive. Build toward the future.

But coordination isn’t free. Context switching isn’t free. Code review isn’t free.

The overhead of managing “spare time” work often costs more than the value it creates. You’re not just losing the output, you’re actively making your core work less efficient.

It’s one of those management ideas that optimizes for the wrong thing. Instead of optimizing for maximum utilization, you should optimize for maximum progress on what actually matters.

There are plenty of valuable things to do with spare time. Code reviews, documentation, experimenting with existing features, learning new skills, hanging out with the support team. The list goes on.

Just don’t pretend you can build your core product features in the margins.