Agile, PRDs, sprint planning, standups, retrospectives - all of it was designed as preventative damage control.
We created this system because execution was expensive.
Building features took weeks. Shipping the wrong thing was catastrophic. So we invented processes to make damn sure we built the right thing the first time. Meetings. Specs. Sign-offs. Planning poker.
At big tech, the approval process was enormous and exhausting. You had maybe 3-4 chances a year to make a big release. It had better count. So everything got scrutinized. Everything got debated. Everything got planned to death.
The bureaucracy was “somewhat” necessary. But it held back high performers.
AI killed that constraint.
The Proof is Already Here
This isn’t theory. The biggest, fastest-moving companies are already doing this.
Anthropic shipped Claude Cowork in 10 days.
A bunch of people - myself included - saw how powerful Claude Code was becoming. Over the Christmas break, people started using it as a file manager, a digital assistant. It’s Unix-based, and if you know the sweetness of Unix pipes and filters, you can do incredibly powerful things. As long as your imagination can think of it.
Anthropic noticed. They saw the signal.
10 days later, 4 people shipped Cowork. Not 10 days of meetings. 10 days of building. They’re testing it right now on the Claude Max plan. They shipped it. Put it in front of users. Got feedback. That’s insane. But that’s the shift.
The engineers saw something others couldn’t. They had the judgment to know it was worth pursuing. They had the skills to execute it. And leadership got out of the way and let them ship.
Google shipped NotebookLM the same way. They saw market adoption, saw high need, shipped it. Then refined. The product you see today isn’t the product they launched. They got it out, saw it was sticky, then made it better.
That’s the playbook now:
- Build the prototype
- Get it in front of users
- See if it’s sticky
- Refine based on actual use
Not: plan extensively, get approval, build the approved thing, hope users want it.
The Math Changed
What took weeks now takes minutes. What took a team now takes one engineer and Claude.
You used to have 3-4 chances a year to ship something big. Most big tech companies had bureaucratic red tape for a reason - the cost of getting it wrong was thousands of man hours down the drain, with no way to recover it.
Now? You can ship new features every single week. Your velocity on execution just skyrocketed. Now you have 40-50 chances a year. That means you can afford to be wrong fast and correct even faster.
With good engineers, you can draft and prototype results in days, not weeks. Get it in front of users. Actually see if it’s what they want. Then loop back and refine.
“Good enough to test” beats “perfect on paper.” Google didn’t ship a perfect NotebookLM. Anthropic didn’t ship a perfect Cowork. They shipped something good enough to learn from, then refined. That’s the only way to move fast enough now.
The Org Problem Nobody Wants to Admit
Here’s the thing that’s going to piss some people off: technical leadership is literally the bottleneck now.
Not the engineers. Not the resources. Not the technology. The leadership.
I’ve seen it. You’ve probably seen it too. Smart engineers sitting in meetings, waiting for approval on something they could’ve built, tested, and validated in the time it took to get everyone’s calendar aligned.
When execution was expensive, leadership needed to gatekeep. Made sense. You couldn’t afford to build the wrong thing.
But now? I can prototype something in a few hours. Ship it. Get it in front of users. See if it’s actually what they want. All before the approval email thread even gets a response.
So what’s the hold up? “Will they let us build this?”
That’s the new constraint. Not “can we.” Will they let us.
Here’s how you fix it:
Get out of the way. Seriously. If something can be validated faster than it can be approved, why are we approving it? Just let them build it.
Push decisions down. The engineer closest to the problem knows more about it than the director three levels up. Let them make the call.
Let your engineering leads actually lead. Principals and Staff engineers shouldn’t be managing Jira tickets and attending planning meetings. They should be shipping prototypes that show what’s possible. Leading by doing.
And leadership? Your job isn’t to approve or reject. It’s to point the team in the right direction and get out of the way. Guide the vision. Stop being red tape.
Think of your engineering org as a lab. You’ve got a bunch of curious people who want to tackle big problems. Let them. Go fast. Break things. Apologize later.
The companies that figure this out are going to run circles around everyone still scheduling alignment meetings.
But Here’s the Catch
If you just let a bunch of engineers loose on a problem… it doesn’t always work out. Startup land shows us that every day. Even now, when the cost to build has never been lower, most startups still fail.
So what’s the missing piece?
Vision. Judgment. Taste.
If the onus of execution is on the engineer, they need to know whether the ideas they’re pursuing are actually good. They need to see the openings others can’t see. And when they see one, they need to fill that space - fix the problem, ship the solution - not wait for permission. Because if they wait, someone else will do it, or it’ll never get done.
Engineers with Taste are Rare
Here’s the uncomfortable part.
Not everyone has good judgment. Not everyone can see the openings. And you can’t just flip a switch and give someone taste.
It’s like watching Steph Curry shoot threes. Or Jordan in his prime. That’s not something you learn in a weekend workshop. It’s practiced over time. Years of reps. Building intuition for what works and what doesn’t.
This is a leadership problem. A training problem. A hiring problem.
You either hire people with good taste, or you train it over time. And honestly? Critical thinking isn’t taught well anymore. People have spent the last century learning to stifle their creativity, follow the process, wait for approval.
The barrier is self-belief. Once you see what’s possible, you can’t unsee it. But getting people to that point takes time.
And you still need excellent engineering skills. You need to either understand the problem space deeply enough to get a coding agent to solve it for you, or be able to execute it yourself and micromanage Claude into finishing the job.
The new model isn’t “anyone can ship.” It’s “people with good judgment and strong skills can ship faster than ever before.”
Product managers shouldn’t fight this execution - they should enable it. Technical leadership shouldn’t gatekeep - they should guide the vision and clear the path. But at the end of the day, you need engineers who can see the opening and have the taste to know it’s worth taking.
I’ve Seen This Work
Let me get specific about what this looks like in practice.
Last year I was closing at 5%. Garbage numbers. (granted I had about 3 tragic life events occur all at the same time, but neither here nor there).
Instead of asking for training or waiting for a sales enablement tool to get approved, I built an AI system that coached me through calls in real-time.
Day 1: Built it Day 2: Used it on real calls Day 30: Already at 25% 2 months later: 40% close rate
I went from worst closer on the team to best.
A veteran closer with 5+ years saw my numbers and got curious. Me - the non-closer engineer with no prior sales experience - started closing deals, with a utilization rate of 30% (normal is about 75-80% on high level sales teams)
Nobody asked if it was approved. They asked how it worked.
If I’d followed the old model?
- Week 1: Stakeholder alignment on AI for sales
- Week 2: Technical feasibility assessment
- Week 3: Budget approval process
- Week 4: RFP for external vendors
- Week 12: Maybe we have something
I had results before most companies would’ve had a vendor shortlist.
ContentEngine: Same Pattern
I needed a system to capture my daily context, generate content ideas, and post to LinkedIn. Old model? Evaluate existing tools. Write requirements. Get budget approval. Maybe build something in Q3.
Since it was a personal project, I could’ve just started coding by hand, which would’ve taken months, most likely.
Instead:
- Evening 1: Set up the project, built LinkedIn OAuth integration
- Evening 2: Built the posting system and CLI
- Evening 3: Added context capture from my AI session history
- Evening 4: Running in production
Now I have a system that captures what I’m working on, helps me generate content, and posts directly to LinkedIn. You’re reading output from it right now.
I verified the approach worked before most companies would’ve scheduled the requirements gathering meeting.
What This Means
If you’re able to hire and train engineers with taste, and develop a culture of transformation… you will still fight an uphill battle at most companies.
The approval process is now the bottleneck. Not execution.
When you can prototype in hours and ship in days, every meeting is time you could’ve spent validating with real users. Every approval chain is a feature that could’ve been tested and killed (or proven) by now.
High performers are unshackled. The stallions are out of the stall. If you can build fast and show results, you don’t need permission. You need results. The 40% close rate speaks louder than any PRD ever could.
The teams that got the most done? They were the ones who never had a product manager telling them what to do. They just relentlessly shipped features. Or they were stallions in the stall - high performers waiting for any opportunity to make significant change, held back by process.
The Point
Meetings and process were codified because execution was limited. That was the constraint that mattered.
AI drove that cost down. Way down.
What took weeks before can now be done in the time it took to finish the meeting about it.
The age-old wisdom of getting everyone to sign off on a design change? It’s moving progress backward now, not forward.
It’s much more important to get your ideas out into the world and see if they’re sticky. Then refine. That’s the playbook for Anthropic. That’s the playbook for Google. That’s the playbook for anyone moving fast right now.
The old model - product managers approve, engineers execute - is dying. Fast.
Innovation now belongs to the person who ships.
Agile is dead.
Go ship, my friend, and stop asking for permission.