The tech industry in 2025 is different. We all feel it. The days of unlimited budgets and "move fast and break things" have shifted to "deliver value efficiently." Companies are asking harder questions about ROI. Teams are being asked to do more with existing resources.
Is that bad? I'm not sure it is.
The pressure is real, but it's also pushing us to work smarter. Teams can respond to this pressure in two ways. Some will grind harder with longer hours, more meetings, and more process. They'll burn the midnight oil trying to meet impossible demands with the same playbooks. Others will question everything about how to build software. Removing friction instead of adding effort. Shipping faster than ever, with better quality, without destroying their teams.
Those teams discovered something important: the processes we built during the boom years are holding us back.
The fastest shipping teams aren't grinding through 80-hour weeks or following complex processes. They just removed the friction. Linear runs with 25 engineers serving 10,000+ companies through radical simplification. Figma hit a $20B valuation with minimal process. Stripe maintains legendary developer experience using small, autonomous teams.
These companies found a playbook that works while keeping people sane.
When I say "removed friction," I mean they deleted most of their processes. Not refined them. Not optimized them. Removed them. And somehow shipped faster with better quality.
We've been taught that moving fast means breaking things. Quality requires slowness. Careful planning prevents problems.
I used to believe this, but not anymore.
Remember fixing a bug from three months ago? You stare at code and think "Who wrote this garbage?" Then git blame reveals it was you. You wasted an hour just to remember what this service does. Another hour figuring out that weird decision. There was probably a reason but who knows what it was. Half your day gone before you even start the fix.
The fastest teams maintain high quality because they ship continuously. No time for bugs to accumulate. No distance between code and customers. They ship excellence because perfection takes too long.
A bug fixed immediately takes maybe half an hour? An hour? Give or take. The same bug fixed months later? Well, there goes most of your morning. Finding it, remembering context, understanding implications, testing the fix. When you remove the time gap, speed and quality aren't opposites anymore. They're the same thing.
Amazon's "two-pizza team" rule isn't about pizza.
It's about communication overhead. With 3 people, you have 3 communication paths. With 6 people, you have 15 paths. With 10 people, you have 45 paths. Every communication path slows you down. Research from Stripe, Uber, and Digg's engineering lead confirms that teams smaller than 4 people aren't really teams. They're individuals requiring excessive coordination. The sweet spot is somewhere around 5-8 engineers with clear ownership.
But the exact number matters less than the principle. Keep it small enough that you can make a decision without scheduling a meeting about scheduling a meeting. A lot of companies get this wrong. They create small teams but those teams still need six approvals to ship anything. The complexity just moved to coordination overhead.
Real autonomy means full stack ownership from database to user interface. Direct customer access to customers. Deployment independence without waiting for other teams. Outcome accountability where you own the metric, not the task. If you have to ask permission, you don't have autonomy.
When you have a solid design system like shadcn/ui or MUI, engineers don't need pixel perfect mockups anymore. They need clarity on user intent.
One solid approach is to sketch the user journey on a whiteboard with fat markers. You literally can't obsess over pixels when your pen is an inch wide. Identify what users can do. Define how you know it worked. Let engineers and designers build together.
It's been a while since I've been a hands on IC, but in the past what's worked best was having my designer code alongside me, making adjustments as we went. No handoffs. No "that's not what I meant." Just building. We worked off a napkin sketch and leaned into the framework, and most of all we had something working fast.
JIRA is just a tool and tools aren't evil. The problem is how we use it.
User stories are theater. The "As a user, I want..." format is just verbose packaging around what engineers actually need. Linear gets this. Write issues, not stories. What's broken? Why does it matter? What are the constraints? How do we know we're done?
Once we have these tickets, we spend hours estimating them with story points that rarely reflect reality. Jason Krohn writes about this in "The Futile Chase for Predictability in Software Development" where he says story points give us the illusion of predictability while missing what matters: throughput. We spend hours estimating complexity instead of measuring how fast we deliver value.
I know a team that replaced story points with a simple question: "Can we ship this in 2 weeks?" If not, break it down. If yes, start building. Their velocity doubled in six weeks because they stopped playing estimation theater and started shipping.
The irony is we're living in an era where AI tools could accelerate everything, but we're not giving them the context they need. Product managers can generate comprehensive PRDs in hours using Claude or GPT. Engineers have Cursor and Copilot ready to consume rich context. But instead of clear problem definitions with success metrics and constraints, we provide these tools with user stories that lack substance.
When product provides actual JIRA context that matters, engineers feed that directly into their AI tools. Suddenly your development assistant understands the problem space. It becomes an architecture partner, not just a code completer. Good tickets enable good AI assistance, while bad tickets waste time.
Traditional Scrum assumes everyone works on everything.
This can create problems. Context switching destroys focus and coordination overhead consumes energy. Run parallel work streams instead where Team Alpha does customer onboarding improvements and API performance optimization while Team Beta handles search functionality overhaul and web app sync issues. Each stream has a couple engineers plus shared design/product support. They ship independently. They own outcomes completely. They never wait for another stream.
When you eliminate dependencies, you eliminate delays.
Requirements documents are lies about the future. By the time you build what was specified, the world changed. You know how this goes. Product creates a detailed PRD. Engineering pokes holes in it. Design creates mocks. You build exactly to spec. You ship it. You watch session recordings and realize customers use it completely differently. That feature you debated for hours? They never noticed. That edge case you spent a week handling? Never happens. Never. Not once. But we built it anyway because it was in the requirements.
Smart teams flip this model. They work with design partners from day one. Give 10 real customers access to half-finished features. Let them complain about the save button that doesn't work yet. Ship them updates every week and watch what changes they actually care about. Gong built their entire platform this way, converting 11 of their first 12 design partners into paying customers. Not because the product was perfect. Because it solved real problems they helped identify.
This isn't rocket science. It's just good product development. Marty Cagan has been preaching this empowered product team model for years. Build with customers, not for them. Ship to learn, not to launch. Yet most teams still hide behind requirements documents and sprint planning instead of getting real feedback from real users.
The magic happens when you ship daily to people who care enough to complain. Not quarterly releases with 100 features nobody asked for. Daily improvements based on actual usage. Small changes validated by real customers. That compound effect of shipping to design partners beats any amount of internal planning.
When your team feels customer pain directly through constant feedback loops, quality becomes personal. Design partners become your co-creators, not just your validators.
Your best customer insights might be sitting ten feet away. Sales teams hear objections every day. Customer Success knows exactly why people churn. Support sees every frustration point. Yet all too often teams treat them like ticket creation machines instead of goldmines of user feedback. Get your engineers listening to customer calls. Let Customer Success show them how customers actually use the product versus how engineering thinks they use it. These teams live in customer reality while engineering often lives in abstraction.
Shipping isn't the end. It's the beginning of understanding what you're building.
Every deploy teaches you something. That feature that took three weeks to perfect? Nobody uses it. That hack thrown together Friday afternoon becomes the most loved part of the product. You can't predict this stuff, you discover it by shipping.
Teams spend months building elaborate filtering systems with beautiful code and clever algorithms, then watch users ignore them completely. Turns out they just wanted basic search that worked. Two days with a simple prototype would have revealed this, but instead two months went to building the wrong thing perfectly.
Daily shipping creates rapid learning cycles. Each deployment asks a question and the answer comes back in hours, not months or quarters. When something's wrong, you adjust tomorrow. When something works, you double down immediately.
The teams that win don't ship perfect software. They figure out what perfect means while competitors are still debating requirements. By the time everyone else catches up, these teams have tried three approaches and know which one works.
Iteration beats planning because reality beats theory. Every single time.
Teams with zero bugs ship faster than teams with bug backlogs. Sounds backwards, but it's true.
Think about your bug backlog. How many tickets from six months ago just sit there? "Investigate occasional logout issue" or "Button sometimes doesn't work (unable to reproduce)." They'll never get fixed.
Linear's engineering team pioneered this approach at scale. As Sabin Roman, Linear's Engineering Manager, explained, he was initially skeptical. Now he sees it works without overloading engineers. The policy is simple. Bug discovered? Fix it today or close it forever. No bug priorities or backlogs. No P1, P2, P3. Just bug or not bug. Engineers decide what's really a bug.
I'm willing to bet you'll find a bunch of "bugs" that were really feature requests. So, fix the actual bugs ruining customer experiences. Stop spending Tuesday mornings in "bug triage meetings" discussing issues nobody remembered. A fresh bug takes minutes to fix. An old bug takes hours just to understand what the ticket means. Multiple companies report massive velocity improvements after implementing zero-bug policies. Not because they stopped fixing bugs. They stopped managing them.
Elite teams deploy constantly. Multiple times per day, including Friday afternoons. Feature flags mean shipping code whenever you want without releasing features. With canary deployments, you roll out to a tiny percentage of users first, then expand. Rollback takes one button with no meetings needed and nobody gets blamed.
The 2024 DORA State of DevOps Report shows elite performers deploy multiple times per day with change failure rates under 15%. That's an excellent number.
You should deploy so often that people forget what they shipped yesterday. When a new engineer asks you, "When do you deploy?" wouldn't it be great if your answer was, "When the code is ready."
Every day is deployment day. Every hour can be deployment hour. Make deployment so boring nobody notices. When deployment becomes routine, fear disappears. When fear disappears, speed emerges.
You can't fix a team that doesn't ship by giving them a fancy new process. I've watched teams implement Shape Up, adopt OKRs, try betting tables. All while taking three weeks to deploy a button change.
If your team can't ship something today and see it in production tomorrow, fix that first. Get good at shipping. Then worry about whether you're using sprints or bets or whatever methodology is trending on Hacker News this week.
Process won't save you if you can't ship. It never has and it never will.
You're probably thinking this sounds great but your company would never go for it.
You don't need permission to make your team better though. Start small. Pick your hungriest team for transformation. The ones ready for change, not the ones playing it safe. Delete their bug backlog. Export it to a spreadsheet if you're scared. Archive every ticket over 30 days old. Watch how much lighter everyone feels.
Cancel their planning meetings. Replace that three hour "grooming session" with a 30 minute problem discussion. What problem are we solving? Why does it matter? How will we know we succeeded?
Give them a customer outcome. Something like "help customers find products in under 10 seconds" instead of "implement search." Let them figure out the how.
Measure cycle time from idea to customer value. Forget story points and velocity charts. Track the time from "we should fix this" to "customers are using it."
Be their shield. When someone asks for a status report, you give it. When someone wants an estimate, you handle it. Let them build.
You'll face resistance. Your PM asks about roadmaps. Your manager wants reports. Tell them you're running an experiment to improve delivery speed for a few weeks and see what happens. Usually buys you enough time to show results.
Teams using these practices see improvements in cycle time. Big ones. Deployment frequency goes way up and team satisfaction improves. Y Combinator's analysis of high growth startups found these patterns hold even while scaling from 10 to 100+ engineers.
When teams ship fast with high quality, customers notice. They feel momentum. They see their feedback implemented in days, not months. They stop complaining about bugs and start asking for features.
Teams that go from monthly releases to daily deployments often see significant NPS improvements. Not because they built more features. They built the right features, validated quickly, and killed the wrong ones fast. Ship, learn, iterate, repeat, every single day.
This approach needs certain things from your organization. Leaders who trust their teams, not just say they do while demanding daily updates. Engineers who see problems and fix them without waiting for tickets. Designers who open pull requests alongside their Figma files. Product managers bringing problems to solve rather than solutions to implement. Organizations measuring customer outcomes instead of counting story points.
Your customers are waiting. They don't care about your velocity charts or your "agile" process.
One thing matters: are you solving their problems or not?
The best teams already made this shift. Linear's Method, GitLab's async culture, Vercel's deployment philosophy. They didn't find some secret hack. They removed barriers between idea and impact.
Ready to try something different? Start with one team, one bet, one outcome. Protect them from process and see what happens. The results might surprise you.
The choice is simple. Ship daily and learn constantly, or keep planning while others ship.
I know which one I'm choosing.
- Shape Up: Stop Running in Circles and Ship Work that Matters - Ryan Singer & 37signals
- Linear Method: Principles for Building
- The Futile Chase for Predictability in Software Development - Jason Krohn
- Move Fast with Little Process: Linear's Engineering Approach
- How to Size and Assess Teams
- DORA Metrics and the 2024 State of DevOps
- Google's Postmortem Culture
- GitLab's Guide to Asynchronous Work
- Y Combinator: How to Maintain Engineering Velocity as You Scale