The hidden execution killer: treating aspirations like plans
While this might seem very common sense, I have indeed experiences in many large systems that folks do not distinguish between both and results in one of the most expensive mistakes.
We talk about aspirations as if they’re plans.
It happens in good faith. A team wants the right thing:
- improve reliability
- reduce latency
- simplify operations
- close security gaps
- pay down tech debt
- left shift quality issues
And in conversation, it’s easy to use plan-shaped language:
“Yeah, we’re planning to do that.”
“We have it in our plans.”
“It’s on the roadmap.”
The problem is that partner teams hear that and make downstream decisions. They assume dependencies will be met. They set expectations with their stakeholders. They schedule their own work around it.
Then nothing ships.
And the failure isn’t usually competence or effort. The failure is that what existed was an aspiration, not a plan.
Why this happens more in complex systems
If you’re building and operating complex systems (distributed services, production workloads, multi-team platforms), there is always more work than time:
- incidents pull attention
- customer asks arrive mid-flight
- urgent operational gaps appear
- priorities shift because risk shifts
In that environment, any work that isn’t made concrete tends to lose the fight for attention.
That’s why aspirations often “feel real” in a meeting, and then evaporate in the day-to-day.
How to tell if something is a plan
A plan isn’t a slide. It isn’t a statement of intent. It’s something you can execute.
At minimum, the idea has been expanded into workitems/tasks and each one of them has the W’s:
- What exactly will be delivered (not a theme, a measurable outcome)
- Who owns it (one accountable owner)
- When it will land (a date, sprint, or milestone)
And just as importantly: it’s written down, assigned, and tracked in whatever system the team actually uses to run its work. Doesn't matter if that is ADO/Jira or an excel sheet.
If those pieces don’t exist, then even if everyone agrees it’s important, it will struggle to land in a large team. Not because people don’t care, but because the system of work will always prioritize what is explicit over what is implied.
The “phantom plan” problem
A common pattern in cross-team work goes like this:
- Team A says: “We’re planning to do X.”
- Team B walks away believing X is coming, and plans accordingly.
- Later, Team B asks for an update.
- Team A replies: “We haven’t started yet, but we still want to.”
- Team B realizes X was never actually planned work.
This is the worst kind of misalignment: everyone thinks progress is happening, until reality catches up.
The simple habit that helps
So when someone asks, “Do you have a plan for X?”, the most helpful thing isn’t more confidence. It’s more precision.
Either:
- “Yes: who owns it, what is the next deliverable, when is the milestone,” or
- “Not yet: we agree on the aspiration, but it’s not planned work until we assign and track it.”
It’s a small distinction, but in large complex engineering environments, it’s the difference between:
- “we all agree this is important” and
- “this will actually land.”
