Every engineering team has shipped features that caused more problems than they solved.
Less-than-perfect features are part of the job. But if they become the norm, they’ll drain your team’s:
Time
Budget
And patience
Over the years, I’ve wrestled with features that kept growing without end or tried to be smarter than they needed to be. Each one looked promising at first. Each one ended up clogging the flow of work like a blockage in a river – slowing everything else downstream.
The truth is, the list of feature red flags could be a hundred items long. They vary depending on your team, company, field, and resources. But four in particular show up again and again.
Here’s how to spot them early, before they derail your work.
Red Flag #1: Rabbit hole features – no clear end in sight
Rabbit hole features start small but can go on indefinitely and have no sense of completion.
For example, you decide that the app you’re working on needs a feature that allows end users real-time collaboration on projects. Something similar to Google Docs. It’s a useful feature that can put you in front of your competition. But not so fast!
What started as a nice idea turned into months of work. You need to:
Build operational transforms
Set up real-time syncing
Implement version history
Add user presence indicators
And so on
It’s a long project that can cause many compliance, security, and usability issues.
The more you build, the more you need to test. Think of it like building a wall – the larger it is, the more you’ll need to paint. That’s why the features you work on have to have a sense of completion. And because of the lack of completion, these rabbit hole features are the catalyst for other red flags.
Red Flag #2: Technical debt that outgrows its value
Technical debt can be both a red flag and a consequence of a poorly planned feature.
Features that create a lot of technical debt can be super useful for the end users. But down the road, they:
Create complexity
Cause performance issues
And hinder the development of other features
The worst part is that you might not even notice the technical debt accumulating because it starts building up over time. Maybe after a month or a year.
Imagine a team decides to add an offline mode to their product. On the surface, it sounds like a great idea – it could be really valuable for users who don’t always have reliable internet access.
But building that feature introduces hidden complexity. Suddenly, the team has to manage state within the app, sync data with the backend, and keep track of all sorts of edge cases.
As the product grows, everything starts moving slower. Every new feature has to work around the offline system, and what once felt like a win for the users now feels like a drag on the team. Over time, the team begins questioning whether the trade-offs are worth it.
The real red flag isn’t just the debt itself, it’s when a feature keeps slowing you down long after its value has peaked.
Red Flag #3: Polarizing features – when consensus turns into gridlock
There’s a concept called “Designed by Committee.” It’s what happens when too many people weigh in on a feature, but no one can agree on the direction.
When this happens, you hit roadblocks:
The team argues
The feature drags
And sometimes it isn’t even viable anymore
Teams can spend weeks debating whether to use GraphQL or REST while the actual user-facing feature sits untouched. By the time a decision is made, momentum is lost.
Polarizing features create endless loops of debate. At some point, you need to stop circling. Make a call, accept it won’t be perfect, and move forward. If the team can’t rally behind it, that’s usually a sign it’s the wrong feature in the first place.
Red Flag #4: Overengineered features – solving simple problems the hard way
Of course, engineers love new tools and methods. That curiosity is valuable, but it can also lead to reinventing the wheel.
I’m talking about the “Not Invented Here” (NIH) phenomenon. It’s when engineers dismiss existing solutions in favor of building everything from scratch. The result: a simple problem ends up with a needlessly complex solution.
Don’t get me wrong, there are legitimate reasons to build in-house – but often, it’s curiosity disguised as necessity.
It’s like going to the gym, basic push-ups and squats work, but boredom tempts you into exotic variations that take more time, add risk, and don’t actually deliver better results. Overengineering works the same way: you spend more, you move slower, and you create more points of failure – without delivering more value.
Trying new technologies and introducing new approaches can be a red flag because every:
New tech
Moving piece
Third-party service
And new library
becomes a liability. The balance is knowing when a tried-and-true approach is good enough, and when innovation is actually worth the added risk.
When red flags go unchecked
Rabbit holes, overengineered solutions, high technical debt, and polarizing features put a lot of pressure on your team and the company’s resources.
If left unchecked, they don’t just slow you down – they create ripple effects across the whole product.
Here’s what tends to happen:
Wasted time: Even if a feature sounds great for end users, it might eat months of development. That’s time you could have spent improving speed, security, or other critical areas.
Wasted money: Engineering hours are expensive. The longer you chase a red-flag feature, the more you’re paying not just for development but also for bug fixes, testing, and maintenance.
Security issues: Every new feature and third-party integration creates a potential security risk. A collaboration tool, for example, requires access rules, data privacy controls, and compliance checks. The risks multiply if you’re in sensitive industries, such as government, finance, or healthcare.
Overwhelmed team: Even though they love playing with new toys, engineers can’t work indefinitely. As red-flag features drag on, other work stacks up. Bugs slip through, end-user complaints rise, and morale dips.
Unchecked red flags don’t just stall a feature – they weaken the whole system around it.
How to spot red flags in features
You can’t avoid red-flag features entirely, and sometimes you just have to go through with it because:
Your end users demand them
Or your security and compliance leave you no choice
But if you can spot the warning signs early, you can prepare your team – or decide not to build the feature at all.
Here are four practices I’ve found worked:
Practice #1: Set time constraints
In our team, we have two-week sprints. They give engineers a rhythm and, more importantly, a sense of completion. If a feature doesn’t fit into a sprint, we split it into smaller parts that do. If nothing gets done within the sprint, that’s a signal to reevaluate.
Boundaries force you to focus. Engineering works the same way – without a constraint, you risk spinning in circles, never declaring anything done.
It’s the same logic that makes weeks and months useful in our personal lives. They’re artificial boundaries, but they help us move forward. Without them, it’s easy to drift.
Practice #2: Have an evaluation system
When completing tasks, most engineering teams use story points to measure:
Effort
Complexity
And risk
They’re not perfect, but they do help. For example, say your team has five features, each estimated at the same number of points. Based on their previous velocity, they likely won’t finish all five. So you’ll have them focus on delivering three. Here, estimation helps you forecast capacity and prioritize realistically, rather than overcommitting.
You can use any other variation of story points or evaluation systems as long as it helps you predict the complexity of a feature or project.
The key is remembering that story points aren’t the full picture. They tell you whether something is easy or hard, but they don’t always flag when complexity is hiding underneath. That’s why you need to pair your estimation system with awareness of other signals – like when requirements keep shifting, or when integration touches too many moving parts.
Practice #3: Check in with your engineers
Left unchecked, engineers can work on a feature indefinitely. Usually, they just need “one more day” or “a few more hours.” That optimism is admirable – but it’s also dangerous.
That’s where managers step in. Ask simple questions:
“Hey, you’re working on Feature A and Feature B, tell me about your progress.”
“How are things going?”
“What is your completion percentage?”
This way, you expose when work is stalling, even if the engineer is doing everything right. Sometimes it’s not the engineer who’s stuck, it’s the feature itself. It helps you see the bigger picture and evaluate whether to continue. Without check-ins, you can miss those warning signs until it’s too late.
Practice #4: Promote systems thinking
One mark of a strong team is that engineers don’t just focus on their own code – they think about how their work affects QA, design, operations, and support. An overengineered feature might be fun to build, but QA inherits the complexity, front-end engineers have to work around it, and support deals with the fallout.
As a manager, foster this awareness deliberately. Bring it up in one-on-ones, reinforce it in retros, and make it part of your team’s language. Ask questions like:
“What will QA need to test here?”
“What’s the support cost if this goes wrong?”
“How will this affect the release timeline?”
“What about the user?”
“And the next person who inherits this code?”
The more your team gets used to asking these questions, the less likely they are to build features in isolation. You’re not just delivering code – you’re building a product that other people have to maintain, support, and improve.
The short version: red flags happen, the difference is whether you’re ready for them
One bad feature doesn’t just sit quietly in the backlog. It clogs the system, forcing workarounds, slowing delivery, and creating knock-on effects for every other feature downstream.
When red flags go unchecked, they ripple outward until the whole product feels the strain. The most common ones I see are:
Rabbit hole features with no clear end in sight
Features your team can’t agree on
And overengineered features
The best way to stay ahead isn’t a magic framework – it’s discipline:
Work within time limits
Question complexity before it snowballs
And build a culture where the whole team thinks about the bigger system
Features will always carry risk. What defines your team isn’t avoiding every red flag – it’s spotting them early and steering before they sink you.
Feedback?
Have thoughts on today’s newsletter? Just hit reply — I read every message. Your responses don’t just make this newsletter better — they often spark the next guide or resource I create.
Upgrade Your Leadership
Paid subscribers don’t just get more content — they get better results, faster.
Here’s what you unlock:
The Thriving In Engineering Digest: Your Friday briefing of the most valuable leadership ideas from across Substack, Medium, and X. Curated so you get the best in 10 minutes, not hours.
Live Q&As: Handle high-stakes moments with confidence through real-time coaching and feedback.
Proven resources: Save time with ready-to-use eBooks, scripts, and PDF playbooks.
In-depth guides: Apply actionable strategies the same day to level up faster.
I have seen all the red flags come up in my work around SaaS deployments. Often, the technique I have used (along with the time constraint you mention) is digging to the root of what the real issue is that they are trying to solve. Often, the solution they are proposing does not resolve their problem, but we can, with a different, more efficient approach.