Your Best Work Can Still Get Shot Down
You’ve spent weeks on a side project to help the team work faster. You know it’s good. You walk into the room, present it, and watch as confused faces stare back at you.
Questions start coming that feel like they’re from a different conversation. Someone raises a concern that would have taken ten minutes to address two weeks ago. The meeting ends without a decision.
The work wasn’t the problem. The problem was that nobody saw it coming.
The Surprise Problem
When people encounter finished work for the first time in a final presentation, they don’t have the context to evaluate it fairly.
They don’t know what problem you were solving, what alternatives you considered, or what tradeoffs you made. They’re reacting coldly to something you’ve been living with for weeks.
That puts them in a difficult position. They can approve something they don’t fully understand, or they can push back. Most push back, not because the work is bad, but because they have no other foothold.
This is what the High-Dive Problem describes: proposals fail not because the idea is wrong, but because the audience can’t orient to it before you’re asking for a decision.
The reveal format almost guarantees this outcome. By the time people see the work, incorporating their input means rework.
The Consortium for IT Software Quality found that rework accounts for up to 45% of total project costs in software development, with late-arriving feedback as one of the primary drivers.
The Moonshot
Last week I wrapped up a moonshot project at work. A moonshot is a short, focused sprint where teams build something new, similar to a hackathon.
Mine was ambitious: I built a game to teach others how enterprise AI systems are structured and how AI fits into the software development lifecycle.
Building a game in a compressed timeframe is one challenge. Building something that survives contact with the organization afterward is another. That second part was what I was really trying to solve.
So instead of putting my head down and presenting a finished product at the end, I shared progress throughout the week. Screenshots as the game took shape. Short notes on where I was headed and what I was uncertain about. Nothing polished. Just enough to show what was happening and invite input.
Midway through the week, a colleague reached out after seeing one of my updates. He had some experience with game design and wanted to help. He ended up reworking parts of the game’s world structure, adding sound, and fixing text that wasn’t landing right. Small changes that made the game feel more accurate and more engaging.
Without those updates, he would have sat in the final session, seen a finished product, and maybe offered thoughts afterward. Instead, he had enough context to jump in while the work could still absorb it.
Someone else followed along across the week and showed up to the final presentation already invested. Not because I asked them to care, but because they’d watched it come together.
By the time I presented, the room wasn’t evaluating my work from scratch. They’d been alongside it.
|
|
Where can AI save you time?
My friends at Big Creek Growth put together a quick survey to spot the repetitive work you can hand off to automation.
|
|
What and When to Share
The goal isn’t to post constant updates. It’s to give people enough visibility at the right moments so they can orient to the work, contribute if they have something useful to offer, and feel like part of the process rather than an audience at the end.
In practice, that means at least two or three meaningful touch points across a project. Larger projects need more touch points. What those touch points look like should shift depending on where you are in the work.
Early: share the problem and how you intend to solve it.
Not the implementation details, but the framing. What isn’t working, why it matters, and the direction you’re heading.
This is the most underused update. Most people wait until they have something to show visually, but the problem framing stage is where buy-in either starts or doesn’t.
If the people who need to support the work don’t understand what you’re solving and why, no amount of polished execution will win them over later.
As the work develops: share visual progress at natural milestones.
A screenshot of a working prototype. A diagram that shows how the pieces fit together. Something that makes the work tangible without requiring a formal presentation.
These moments give people a concrete sense of where things are headed and create natural openings for input.
At every stage: be specific about what you’re asking for.
This is the part most people get wrong. There’s a meaningful difference between these two updates:
- “Here’s where I’m at” — easy to read and move on from
- “I wrapped up this piece and could use some feedback on how this specific component is designed” — gives someone a clear entry point and a reason to engage.
Vague updates generate passive acknowledgment. Specific questions generate actual conversations and build buy-in from others.
The more precisely you name what you need, the more likely you are to get a useful response.
This is also the underlying argument in the Write It Once issue: written updates create alignment and visibility without requiring meetings or repeated explanation.
A well-framed progress note does the same work as a 30-minute sync and gives people the chance to engage on their own time.
Working in isolation is efficient in the short term. You move fast, you don’t have to explain half-formed thinking, and no one slows you down.
But when the final result lands, you own it entirely. If something is off, no one saw it coming. If the work needs organizational support to go anywhere, no one’s already invested in it. You’re asking people to get on board with something they’re seeing for the first time.
The game I shipped was better than what I would have built alone, and it had people ready to use it before I even presented. That happened because a colleague had enough context to contribute while the work could still absorb it, and because others had followed along long enough to feel some ownership over the outcome.
Good work still needs people to be ready for it. Sharing progress is how you get them there.