Feature Complexity

There are three things that happen when you put a complex, risky feature at the front of your development pipeline.

(A) You kill your team. (2) You block everything behind it. (D) You spike an external team to do it.

I’ve numbered these deliberately. If your pipeline feels like it’s going in multiple directions at once — outcomes labelled in different formats, running out of sequence — that’s what scheduling your hardest feature first actually feels like from the inside.

What you’re actually doing

Feature complexity isn’t the problem. Hard things need building. The problem is where you put them.

When a complex feature goes in early, it consumes the oxygen. Estimates are wrong — they’re always wrong on novel work. The team gets stuck, extends the sprint, and carries compromise forward. Every feature behind it is waiting. The roadmap is hostage to a decision that felt strategic at the time.

What’s actually strategic is understanding what creates value, and building that first.

The three outcomes, in order of how often I’ve seen them

Kill the team. The feature ships, eventually, but the team is broken by the effort. Shortcuts accumulate. The codebase is harder to work in than it was before. The next feature takes longer because the foundation is compromised.

Block the pipeline. The feature doesn’t ship. It parks in the middle of the roadmap and everything downstream stacks up behind it. The backlog grows, stakeholders get restless, and at some point someone decides to split the team to work around the blockage — which creates different problems.

Spike via outsourcing. An external team gets brought in to unblock it. They build it. They leave. Your team inherits code they don’t fully understand, written to a spec that shifted three times during the engagement.

What to do instead

Build value first. The features that establish the core product loop — the ones users actually need — go at the front. By the time you reach the complex, risky work, you’ll have a cleaner codebase, a more experienced team, and a much clearer picture of what the hard feature actually needs to do.

Hard features scheduled late are often also smaller when you get to them. The product has evolved. Requirements have clarified. What looked like a six-week piece of work might turn out to be two.

Put the difficult things at the back. They’ll be there when you’re ready for them.

Things to verify before publishing: this is based on general professional experience — no specific client or engagement is named, so no verification needed beyond Robin’s own accuracy check.