The Problem with Saying Something Will Be Done Soon
I've spent more years than I'd like to admit fielding status emails that say "it'll be soon enough." The phrase sounds optimistic in a standup meeting. It reads very differently in a postmortem. Here's what actually happens when you treat that phrase as a planning commitment rather than a placeholder for uncertainty. Soon enough is a hedge. It signals that something is roughly prioritized but hasn't been broken into discrete work items with deadlines attached. People use it because they want to avoid committing to a hard date while also avoiding the appearance of doing nothing. In practice, it collapses under its own vagueness within about two weeks. The first thing I learned the hard way was that soon enough doesn't disappear when ignored. It accumulates interest. Every day without a defined scope or a real target date, the perceived progress drops. Not because the work is harder, but because stakeholder trust erodes at a measurable rate. After three missed soft deadlines expressed as soon enough statements, people stop reading status updates altogether.
How I Deal with It Now
When someone tells me a feature will be ready soon enough, I ask three questions before agreeing to move forward. First, what does done look like in observable terms? Second, what's the single biggest risk that could push the timeline? Third, what am I deprioritizing to make room for this? This forces a conversation instead of a reassurance. Usually, the person offering the soon enough estimate realizes they don't have the answers yet. That's useful information. It means the right next step isn't a deadline but a discovery sprint or a spike. I recommend converting soon enough commitments into timeboxed research tasks. Two days max. The output is either a concrete plan with estimates or a documented reason why it can't be planned yet. Either outcome is better than a vague promise hanging over a team's head.
What Goes Wrong in Practice
I once inherited a project where the roadmap claimed several modules would ship soon enough across a six-month window. The team had no acceptance criteria. No one had touched the database schema for the core feature. When I dug into it, I found that the soon enough language had masked a dependency on a third-party API that had changed its authentication model six months prior without notifying anyone. The fix wasn't heroic. It involved pulling the integration into an isolated prototype environment and building a wrapper that handled the new auth flow. That took eleven working days. Without the prototype-first approach, we would have discovered the breakage only after integrating, which would have cost roughly three weeks of rework. The lesson was simple. Treat soon enough as a flag that signals incomplete understanding, not as a commitment. When I see that phrase in a spec document, I annotate it with a research tag and schedule a spike. The team benefits because nobody starts coding blind.
Get the Full Details
Counter-Intuitive Things I've Discovered
Here's something most managers miss. Soon enough is actually more dangerous when attached to experienced teams than to newcomers. Newcomers ask questions. They surface blockers early because they don't know better. Experienced people absorb vague promises and deliver quietly, then complain about context switching afterward. The metric that matters isn't what was said in the planning meeting. It's whether the person assigned to the work can articulate the acceptance criteria without looking at the project manager. Another thing worth noting. Soon enough estimates correlate poorly with actual delivery dates, but they correlate surprisingly well with burnout metrics. Teams operating under persistent soon enough pressure show a measurable uptick in unplanned absence and turnover. The correlation isn't perfect. Leadership tends to blame hiring problems instead. But the pattern is consistent enough that I track it now when reviewing a roadmap. There's a boundary condition where soon enough actually works fine. That's when it's explicitly labeled as such. If a product owner writes "targeting Q3" and backs it with a clear priority ranking and a defined set of must-have criteria, the team can plan around it. The problem arises when soon enough is presented as a timeline rather than an aspiration.
When the Approach Fails Completely
This method doesn't help when the organization treats any form of soft commitment as a binding promise. If leadership rewards people for saying soon enough without ever requiring them to follow up with concrete plans, then translating that phrase into a research task is just theater. You're optimizing around a symptom instead of the disease. In those cases, the alternative is to make the cost of vagueness visible. Track how many soon enough items never convert into properly scoped tickets. Show that metric in quarterly reviews. It's uncomfortable for everyone. It's also the only thing that changes behavior in environments where vague optimism is incentivized. I've also seen teams adopt a hard rule that no item enters active development without a written acceptance test. That eliminates the soon enough ambiguity by force. It slows down initial triage. It speeds up everything else. The net gain is usually about twenty percent reduction in (rework) cycles, which translates to roughly a week per month reclaimed across a small team.
At the end of the day, soon enough is a language problem, not a planning problem. The words are fine. The discipline around what follows them is what's missing.
