Most projects die. Not because the code's bad. Because the org never agreed it was done.
I used to think shipping meant deploying. Tickets closed, PRs merged, CI green. That's the easy part. The hard part is convincing everyone - product, leadership, the team two levels up - that you actually solved the thing you said you'd solve.
Shipping Is Whatever the Org Says It Is
Sean Goedecke nailed this. A project isn't shipped until your management chain recognises it as shipped and believes it hit the business goal.
That feels weird at first. We want to believe clean code and green tests are enough. But customer value has to travel through your company first. Some projects delight users. Others check a compliance box. Others make an exec look good. Same code, different game.
| Lens | What I Used to Think | What Actually Matters |
|---|---|---|
| Definition of shipped | Code deployed, tickets closed | Leadership says "yeah, that's done" |
| Success metric | Technical completeness | Business purpose achieved |
| Common mistake | Over-engineering the polish | Missing what the company actually wants |
| Practical move | Keep refining forever | Declare victory when decision-makers are satisfied |
Before you lead anything, figure out what "done" looks like in business terms. Ask the awkward questions early. Frame trade-offs in dollars and deadlines, not engineering purity.
Projects Fail by Default
Left alone, every project drifts, gets blocked, or hits an invisible dependency you didn't know existed.
This pattern repeats everywhere. A project looks simple on paper. Three sprints. One engineer. Straightforward. Then you discover the security review wasn't scheduled, the dependency team has a six-week backlog, and the RFC never reached the people who needed to see it. Assumptions live in different Slack channels until someone asks the obvious question three weeks in.
Someone has to drag it across the line. Usually one engineer who holds the whole picture in their head - not doing all the work, but noticing the missing review, the unowned dependency, the team that assumed someone else was handling it.
Rules that look rigid bend when the business actually needs movement. The trick is knowing when the business actually needs movement.
Technical Skill Is the Multiplier
Strong engineers can jump into unfamiliar code, build a demo that kills three weeks of debate, or spot a requirement that can be safely simplified.
I've seen teams spend months debating infrastructure choices with slide decks and benchmark data, neither side budging. The breakthrough usually comes from someone who stops talking and starts showing - a working prototype with real load tests, a demo that makes the trade-offs visible, a spike that answers the question in days instead of weeks.
The engineer who builds the prototype rarely gets credit in the project update. But people remember who moved things forward. The next time a hard project needs leadership, that's who gets asked.
Burning down Jira tickets is less impactful than de-risking a project that matters. Find the bottleneck that's blocking everyone, then prototype the smallest thing that moves the conversation forward.
Talk to product. Talk to design. Find where the project is actually stuck and apply your skill there.
The pattern applies beyond software. Any complex project with multiple stakeholders, invisible dependencies, and unclear ownership follows the same dynamics. The code - or the document, or the campaign, or the product spec - is the easy part. The hard part is the organisational agreement that the problem is solved.
AI Helps Most With Speed and Unfamiliar Code
Generative AI is great when you need to get from zero to something workable fast. New repo, new language, new tooling - it gets you oriented quickly.
But faster code just moves the bottleneck downstream. Review, testing, operational confidence - that's still on you.
| Area | AI Makes Easier | Still Your Problem |
|---|---|---|
| Unfamiliar repos | First-pass code and orientation | Correct local trade-offs |
| Glue work | Internal tools and admin pages | Production robustness |
| Prototyping | Demos and spikes | Product fit and polish |
| AI product work | Faster experimentation | Evals, hallucinations, moving abstractions |
Keep humans focused on the final 20 percent where verification and judgement matter most.
Internal Platforms Need Shipping Discipline Too
Shipping discipline applies to internal tools, not just customer-facing products. I learned this building a developer experience platform - essentially an internal portal for engineering teams.
The first version had a service catalog, some onboarding docs, and a few software templates. Technically deployed. But engineers didn't use it. It wasn't "shipped" because the org hadn't agreed it solved a real problem.
The shift came when we stopped adding features and started measuring outcomes. Time-to-first-commit for new engineers. Number of teams self-servicing provisioning instead of opening tickets. Scorecard adoption rates. Once we had metrics tied to real engineering pain, leadership recognised it as shipped. Same codebase, different framing.
Internal platforms die from feature bloat and unclear ownership. The ones that survive ship incrementally and measure obsessively. Each small release proves value. Each metric tells a story the org can understand.
Another lesson from platform work: keeping scope bounded is harder than it sounds. A platform migration I was involved with kept growing - new requirements, new stakeholders, new edge cases. The breakthrough came when we explicitly defined what was out of scope and stuck to it. A green-field module with solid tests shipped faster than the grand rewrite that was still being designed six months later.
For platform teams: ship a thin slice that solves one real problem, then measure. The org will believe in the platform when they see a team save hours, not when they see an architecture diagram.
Remote Teams Work When Handoffs Are Clean
Distributed teams can outperform co-located teams if they work async and hand off work cleanly across time zones.
Teams that hand off cleanly write context down. The engineer in one timezone leaves a detailed post: found the root cause, branch name, test status, next step. The engineer in another timezone picks it up hours later, runs the integration test, deploys to staging, monitors. By the time the first engineer is back, the fix is validated. One day of work, zero meetings, two detailed handoff notes.
Compare that to the team with one remote engineer alone in a timezone. No handoff notes. No async context. Mornings spent waiting for answers. Afternoons trying to reconstruct what was learned. Productive for three hours a day. The rest is waiting and context-switching.
Don't leave one remote engineer alone in a timezone. Build clusters, not isolated individuals. Write down context. Record demos. Make the next steps explicit so work keeps moving while someone sleeps.
Summary
- Shipping ≠ deploying. It's the org believing the problem is solved.
- Projects fail by default. Someone needs to hold the full picture and push.
- Apply skill to bottlenecks. Not just backlog tickets.
- AI accelerates breadth, not depth. Use it for unfamiliar terrain, keep humans on verification.
- Remote teams need clean handoffs. Written context beats overlap hours.
What's Next
Next time you're leading a project, ask: does leadership actually believe this is shipped? If you're not sure, it's not done. Fix that first.