Skip to main content

The Cohesion Crisis: A Prediction on Feature Sprawl

Ever since becoming a leader my North Star has been velocity. Each day I’ve tried to optimize sprints, CI/CD pipelines, and stand-ups to solve one problem: how do we ship faster? Now, I’m staring at a world where AI might actually give us what we asked for. But as I watch our teams start to lean into these tools, I’m beginning to suspect we’re heading toward a different kind of disaster.

My prediction: We are about to enter the era of products plagued by feature sprawl.



The "Cost of Yes" is Bottoming Out

Historically, engineering friction was a natural filter for product quality. Because code was expensive and slow to write, we had to be ruthless about what made the cut. We debated every setting, UI button, and every API endpoint because we only had so many hours in a sprint.

But I’m seeing that friction start to evaporate. When AI makes it trivial to spin up a new module or a "quick" feature add-on, the organizational impulse won't be to simplify - it will be to expand.

I think we’re going to see products go wide instead of deep. We’ll see a massive acceleration in feature creation, but I fear it will come at the expense of a cohesive user experience. We’re going to build a lot of "stuff" simply because we finally can, without realizing we’re burying our core value proposition under a mountain of AI-generated noise.

The Orchestration Gap

Here’s what I’m watching for: a growing gap between Feature Velocity and Product Cohesion.

If we can suddenly generate features 5x faster, but our ability to orchestrate them into a unified, user-friendly experience stays at the same 1x pace, the math just doesn't work. We’ll end up with "Frankenstein" products - collections of features that work individually but feel disjointed and bloated as a whole.

For those of us in leadership, I suspect our roles are about to shift fundamentally. We won't be judged on how much our teams produce - AI has turned that into a commodity. Instead, I think we’ll be judged on our ability to curate a cohesive product.

What I’m keeping an eye on:

  • The "No" Muscle: Will we have the discipline to say "no" to features that are "free" to build but "expensive" for the user to understand?

  • The New Technical Debt: I suspect we’re going to see a new flavor of debt - not just messy code, but "Cohesion Debt." It’s the cost of having 50 features that don't talk to each other or multiple ways to do the same thing.

  • The Role of the Engineering Manager: I’m betting the most successful Managers of the next two years won't be the ones with the highest velocity metrics. They’ll be the ones who act as "Product Orchestrators," ensuring that every line of AI-assisted code actually belongs in the same universe.

Let’s see how it shakes out

I don't have the data to prove this yet - none of us do I suspect. But the trajectory feels clear. We are solving the "delivery" problem only to create an "integration" nightmare. It’s also not clear to me if it’s Engineering Managers who plug the gap, Product Managers, User Experience, or a mix of everyone. My gut tells me the lines between these roles could blur further - let’s see!

Are you seeing the early signs of this "feature sprawl" in your own orgs? How are you planning to keep your product from becoming a junk drawer?
Labels:

Comments

Post a Comment

Popular posts from this blog

The "Just-in-Time" Manager and the 1:1 Gemini Gem

  We’ve all been there. The calendar notification pings. You finish your previous meeting (which ran over by three minutes), and as the Zoom window for your next 1:1 pops up, you’re frantically tabbing through Google Docs and Slack. You’re trying to remember: What did we talk about last time? Did that project go okay? Wait, did they mention a vacation or a baby? You’re "prepping" while the meeting is already happening. You’re physically present, but mentally, you’re a detective trying to solve the mystery of your own calendar and trying to switch off the last meeting.  It’s a common trap for managers, especially as their direct reports grow and they now have skip level 1-1s, or skip-skip level 1-1s. Our schedules are a mosaic of context-switching, and unfortunately, the deep, reflective prep our direct reports deserve is often the first thing to get squeezed out as we are dealing with incidents or other emergencies.  From "Zero Prep" to "Instant Context" R...
Post a Comment
Read more

Prompting AI Adoption for Skeptical Engineers

We’ve all seen the headlines. "AI will replace the junior engineer”.  "The 10x engineer is now a 100x engineer." In leadership meetings almost every conversation comes back to velocity and how we could unlock efficiency with AI.  But when you talk with the team the reality can be different. Your most senior engineers - the ones who built the core of your system - are looking at Copilot or Cursor with a squint. Some see it as a toy; others see it as a threat to the craft; a few see it as a glorified Clippy that hallucinates half-baked solutions into their carefully maintained repos. As Engineering Managers and Directors, we are currently in a delicate spot. We are being asked by the business to "leverage AI," but we are being told by some of our best people that it’s "not quite there yet". How do we advocate for AI without sounding like a marketing brochure? How do we move the skeptics without losing their trust? 1. Validate the Skepticism (Because it...
Post a Comment
Read more

The New Unit of Planning: Headcount vs Tokens

  As I work through another planning cycle, the ritual remains the same: the spreadsheet opens, the roadmap is prioritized, and we start the negotiation for more "heads." In my world, and likely yours, the engineer has always been the fundamental unit of progress. If we want to move faster, we hire more of them. But this year, the math feels... off. I’m asking myself - do I really need a new hire for this or do I just need a larger token budget? We are moving away from a world of Fixed Labor and into a world of Variable Compute. When you hire a Senior Engineer, you’re buying a long-term asset. You’re also buying a 6-month onboarding lag, a management overhead, and a permanent line item on the P&L.  When you "hire" tokens you’re buying instant, fractional capacity. If your engineers are telling you they can automate 30% of the "toil" using a custom-tuned model, the traditional argument for that extra engineer disappears. We are moving from mere manageme...
Post a Comment
Read more