Found this Tweet from Jason Lemkin, an investor I follow and admire.
I found it very interesting, but I had a small derivation from it in my mind so I rewrote it. Here it is.
Let’s face it.
Eventually, all teams slow down.
Too much debt, too much to rebuild, too many workflows, too many customers, too many bugs, too much everything...But some teams are stellar and slow down only to a point that is acceptable for the continued development of a product and a business.
You’ve heard of unicorns and decacorns—we all enjoy their stories. Their journeys are rarely shorter than 10 years. That’s why I’m willing to bet they face all the issues above, yet they persist and keep pushing forward.
How do they do it?
I don’t have the complete answer. What I do know is they practice software development the right way. They do unit testing, integration testing, e2e testing.
They do it without asking management for time to do it.
They document everything and knowledge share whenever they can.
They write down stuff for the future because they are convinced there is one or they are convinced they can make it happen.
They do it because it is in their nature as software crafters.
How is your team building software? Statistics say you are doing it the wrong way.
You might say:
Dragos, most startups fail not because of technical reasons. Founders split, they don’t find product market fit or they run out of funding, etc.
NO!
****Most fail because they don’t ship fast enough.
They are too slow to talk to customers, to bug fix, to update their product, to catch-up to competitors or even newcomers to their market.
This happens even with tens or hundreds of engineers on the payroll.
They slow down to unacceptable levels, and they lose.
Heck, they lose to themselves because at that point they feel there is nothing they can do to turn it around.
It's as simple as that.
What can you do to make yours succeed?
Do the things nobody wants to do.
Automate your testing, speed up your deployment process, write down and document everything, share the knowledge every chance you get.
TURN STATIC DOCS INTO INSTANT ANSWERS
Build beautiful knowledge portals that are easy to navigate, search and share
Frequently Asked Questions
A tweet from investor Jason Lemkin set this in motion. The author follows and admires Jason, and his tweet about why startups stumble sparked a deeper reflection. This post is a riff on that idea—focusing on shipping speed, disciplined engineering practices, and knowledge sharing as the real differentiators.
Anyone responsible for building, shipping, or maintaining software:
- Founders and CTOs
- Engineering managers, tech leads, and ICs (frontend, backend, QA, DevOps)
- Product managers working closely with engineering
- Teams from scrappy pre-seed startups to high-growth companies—even unicorns and decacorns
If your success depends on how quickly you learn from customers and ship improvements, this is for you.
Momentum erodes due to compounding friction:
- Accumulating technical debt and deferred maintenance
- Costly rebuilds/refactors that keep slipping
- Process creep and too many parallel workflows
- Expanding customer commitments and a rising support load
- Mounting bugs and edge cases that sap focus
- Increased product/system complexity and toolchain sprawl
- Coordination overhead as the team and surface area grow
Great teams still slow somewhat—but only to an acceptable pace—because they invest early in testing, automation, documentation, and knowledge sharing to keep friction under control.
They don’t ship—and learn—fast enough. When releases, customer conversations, and bug fixes slow down:
- Feedback loops break, so you build the wrong things longer
- Competitors catch up or pass you while you’re stuck in rework
- Bugs linger, morale dips, and customers churn
- Runway gets burned without corresponding progress
Even with large engineering teams, if the pace drops below an acceptable level, momentum dies. Startups lose to the market—and often to themselves.
Do the unglamorous, disciplined work—without waiting for permission:
- Automate testing: unit, integration, and end-to-end
- Make deployments fast and boring: reliable CI/CD, small PRs, feature flags, frequent releases
- Document as you go: decisions (ADRs), system overviews, runbooks, onboarding guides—write for the future you expect to have
- Share knowledge relentlessly: design docs, postmortems, demos, pairing, brown-bag sessions
- Tighten feedback loops: talk to customers weekly, fix high-signal bugs quickly, measure lead time and recovery time
These habits keep the team learning fast and shipping faster—exactly what keeps startups alive.