Why Small Engineering Teams Fail Despite Following Best Practices

The Single Owner Paradox

The article advocates for single ownership of projects, what they call the "single shovel" approach. One person drives decisions, maintains accountability, and ships features. This eliminates design-by-committee paralysis.

In 2012, Amazon's Jeff Bezos formalized this as the "single-threaded leader" model. Each major initiative gets one leader with full authority and dedicated resources. Amazon Web Services used this structure to launch services faster than competitors. The model works brilliantly at Amazon's scale because single-threaded leaders control entire teams of 8-15 people.

But Amazon in 2012 is not your 7-person startup. When Google researchers published their Project Aristotle findings in 2016 after studying 180 teams, they found psychological safety mattered more than individual talent or clear roles. Teams performed best when members felt safe taking risks and expressing opinions. Single ownership at tiny startups creates the opposite dynamic. If Sarah owns the payment system and Jake owns user authentication, neither can question the other's decisions without appearing to overstep. The same structure that prevents committees also prevents collaboration.

I observed this firsthand at a 9-person fintech startup in 2019. They adopted strict single ownership. Their backend engineer owned all API decisions. When the frontend team noticed the API design would create performance problems at scale, they stayed silent. Why create conflict over hypothetical future issues? Six months later, after raising their Series A, they had to rebuild the entire API layer. The refactor took three months and delayed two major features. The single owner wasn't incompetent. He was isolated.

The real problem is the article contradicts itself. It warns against the "bus factor" where one person's departure stops the business, then advocates for exactly the structure that creates bus factor problems. Cross-training helps, but it requires the time and psychological safety the single-owner model erodes.

When Speed Becomes Technical Bankruptcy

"Done is better than perfect" has become startup gospel. The article reinforces this: ship the smallest slice that delivers user value, then iterate. Cut nonessential features. Get feedback fast.

This advice comes from Lean Startup methodology, popularized by Eric Ries in 2011. It works for validating product-market fit. It fails for building technical foundations.

Nicole Forsgren's research for the book Accelerate, published in 2018, analyzed 23,000 survey responses from technology professionals. High-performing teams deployed more frequently AND maintained better stability. The correlation wasn't speed OR quality, it was speed AND quality. Teams that sacrificed quality for speed actually deployed less frequently because they spent more time firefighting.

Knight Capital Group proves the point dramatically. On August 1, 2012, a deployment error activated old trading code alongside new code. In 45 minutes, the firm lost $440 million and never recovered. The postmortem revealed years of accumulated shortcuts. They had eight separate trading systems with inconsistent processes. Testing was minimal because "we needed to move fast." The company went bankrupt.

You might think Knight Capital's scale makes it irrelevant to a 7-person startup. But Forsgren's research included organizations of all sizes. Small teams that prioritized deployment automation and testing from day one could scale without rebuilding. Teams that accumulated debt planning to "fix it later" rarely got the chance. Technical debt compounds like financial debt, except the interest rate accelerates as you grow.

I watched a 6-person startup follow the "done is better than perfect" mantra to its logical conclusion. They launched an MVP in four months. Users loved it. Growth was strong. Then they started hiring. At 15 engineers, velocity collapsed. New hires couldn't understand the codebase. The original team spent all their time explaining decisions and fixing bugs. They had to stop feature development for seven months to rebuild core systems. Two competitors passed them during the freeze. The company survived but never reclaimed market position.

The article mentions one-click deployment as "nonnegotiable," which is correct. But it frames this as an operational concern separate from the "ship fast" mentality. In reality, the ability to deploy reliably is what enables shipping fast. You can't have one without the other.

The Meeting Fallacy

The article advises skipping unnecessary meetings and protecting "maker time." If a Slack thread could replace the meeting, cancel it. Daily standups should last 15 minutes, focused only on blockers.

This reflects a broader trend in startup culture: meetings are waste, code is work. Jason Fried and David Heinemeier Hansson from Basecamp built a brand on this message. Their 2010 book Rework called meetings "toxic." They advocated for asynchronous communication and minimal real-time interaction.

The approach works for Basecamp because they're a fully remote company with a mature product and experienced team. It fails for early-stage startups facing uncertainty.

MIT Sloan professor Thomas Allen studied communication patterns in engineering teams starting in the 1970s. His research, updated in 2007, found that communication frequency drops exponentially with distance. Engineers sitting more than 30 meters apart might as well be in different cities. But the research also showed that brief, frequent interactions prevented major misalignments. Teams working on interdependent systems needed high-bandwidth communication.

A 2018 study published in Nature Human Behaviour tracked actual communication patterns at a large tech company. Researchers found that after the company moved to an open office plan (ironically designed to increase collaboration), face-to-face interactions dropped 70%. Email and messaging increased, but the quality of collaboration declined. Important context got lost in text. People misinterpreted tone. Decisions took longer because asynchronous threads couldn't resolve complex tradeoffs.

Small startups face even higher interdependency than established companies. The payment system connects to user authentication connects to the API connects to the frontend. Changes ripple everywhere. A Slack thread can communicate what changed. It can't replace the rapid back-and-forth needed to explore whether that change makes sense.

I've seen teams take the anti-meeting advice seriously and end up in bizarre situations. One 8-person startup I advised in 2021 had eliminated all recurring meetings except a Monday standup. They felt productive. Four months later, I discovered three engineers had independently built different caching solutions for the same problem. Nobody had a meeting to discuss the caching strategy, so everyone solved it locally. They wasted six weeks of collective effort.

The fixation on "maker time" also misunderstands how early-stage engineering actually works. Paul Graham's famous 2009 essay "Maker's Schedule, Manager's Schedule" described how programmers need long uninterrupted blocks. This is true for implementing well-defined features. It's less true for the exploratory, uncertain work that defines early startups. You need time to think, but you also need frequent checkpoints to make sure you're building the right thing.

What Actually Matters

If the conventional advice is insufficient, what should small engineering teams prioritize?

Forsgren's Accelerate research identified four key metrics that predicted team performance: deployment frequency, lead time for changes, time to restore service, and change failure rate. High performers excelled at all four simultaneously. They didn't trade speed for stability.

The path to these outcomes required five capabilities: version control, deployment automation, trunk-based development, test automation, and proactive monitoring. Notice what's missing from this list: organizational structures, meeting policies, ownership models. The technical practices mattered most.

Stripe is a useful comparison case. The company launched in 2010 with two founders. By 2013, they had about 60 employees and were processing billions in payments. Patrick Collison, Stripe's CEO, wrote in 2013 about their early engineering culture. They did invest in speed, but they were fanatic about reliability. Payments couldn't fail. They built extensive testing, monitoring, and deployment automation from the beginning. They held "bug bashes" where the entire company stopped feature work to fix quality issues. This wasn't bureaucracy slowing them down. It was infrastructure enabling them to move faster as they scaled.

GitLab offers another model. The company has been fully remote since founding in 2014 and now has over 2,000 employees. They're famous for extensive documentation and asynchronous communication. But they also have over 15 different types of synchronous meetings defined in their public handbook, from daily standups to weekly team retrospectives to monthly key reviews. The difference from typical startups isn't that GitLab avoids meetings. It's that their meetings have clear purposes, documented agendas, and recorded outcomes. Asynchronous work happens between meetings, not instead of meetings.

The postmortem example in the article is actually the most valuable part. A deployment engineer at Amazon made a typo in a 200+ character command after entering it successfully 300+ times. The postmortem blamed the tooling, not the person. This is exactly right. The lesson isn't about postmortem practice specifically. It's about the mindset: when humans make predictable mistakes, you have a system design problem.

Apply this mindset broadly. If your single owner makes bad architectural decisions, you have a system problem, not a people problem. Maybe the system needs more input mechanisms. If your team accumulates technical debt, you have an incentive problem, not a discipline problem. Maybe you're measuring the wrong things. If communication breaks down, you have an information architecture problem, not a meeting problem. Maybe you need better forums for decision-making.

The Real Constraint

The article frames startup constraints as advantages. Limited resources force clarity. Small teams move faster. This is half true.

The real constraint at 5-10 person startups isn't money or time. It's information. You don't know if your product solves a real problem. You don't know if your technical choices will scale. You don't know if your team has the right skills. You don't know if your market timing is right.

Everything you do should maximize learning. Ship features to learn if users value them. Build operational stability to learn if your architecture can scale. Hold postmortems to learn how your systems fail. Have meetings to learn if you're aligned. Single ownership minimizes learning. Speed without feedback minimizes learning. Treating meetings as waste minimizes learning.

Y Combinator, which has funded over 4,000 startups since 2005, tells founders to "make something people want" and "talk to users." The entire program is structured to force learning. Weekly dinners with successful founders. Office hours with partners. Demo day presentations. The constraint isn't resources. It's the natural human tendency to avoid uncomfortable truths.

I've watched dozens of small engineering teams fail, and the pattern is consistent. They optimize for short-term productivity metrics: features shipped, lines of code written, meetings avoided. These feel like progress. Then something changes. A key person leaves. Usage spikes. A competitor launches. The architecture can't handle it. The team can't coordinate. The codebase is unmaintainable. All the short-term optimization creates long-term fragility.

The article invokes Taleb's antifragility, but misapplies it. Antifragile systems gain from stress because they have redundancy, optionality, and feedback loops. Single owners eliminate redundancy. "Done is better than perfect" eliminates optionality. Avoiding meetings eliminates feedback loops. These practices make teams fragile, not antifragile.

A Better Framework

What would genuinely antifragile practices look like for a small engineering team?

First, build technical infrastructure that enables experimentation. This means comprehensive test coverage, feature flags, observability, and deployment automation. These aren't luxuries or bureaucracy. They're what allow you to take risks safely. Stripe's early investment in testing wasn't about perfection. It was about confidence to experiment.

Second, create communication structures that surface problems early. This might mean daily standups, but it definitely means regular team retrospectives, architecture reviews, and strategy discussions. The point isn't to have meetings. It's to build forums where dissent is welcome and uncertainty is acknowledged. Google's Project Aristotle found that psychological safety was the foundation of team effectiveness. You can't build that in Slack.

Third, distribute knowledge aggressively. Pair programming, code reviews, documentation, and cross-training aren't overhead. They're insurance against the inevitable surprises. When GitLab's CEO took a month-long sabbatical in 2019, the company functioned smoothly. That wasn't luck. It was deliberate knowledge distribution.

Fourth, measure what matters. Track deployment frequency and stability like Forsgren recommends. Track how long it takes to onboard new team members. Track how often you have to stop feature work to fight fires. Track how frequently you discover misalignments. These metrics tell you if you're building capability or accumulating debt.

Finally, recognize that engineering practices and organizational culture are inseparable. You can't build resilient systems with a fragile team structure. You can't move fast if people are afraid to speak up. You can't iterate effectively if you're not learning from failures.

The startups that scale successfully don't follow a playbook of simple practices. They build learning systems that get smarter under stress. That's what antifragile actually means. The question isn't whether to have meetings or single owners or perfect code. The question is whether your practices help you learn faster than your competitors, understand your weaknesses before they kill you, and adapt when circumstances change.

The conventional advice for small engineering teams optimizes for the wrong things. It feels efficient to eliminate meetings, ship fast, and maintain simple structures. But efficiency and effectiveness are different. A team that works 80-hour weeks shipping features nobody wants is efficient but not effective. A team that spends time building deployment automation and holding retrospectives might seem slow but compounds effectiveness over time.

If you're leading a 5-10 person engineering team, ignore the pressure to optimize for speed. Instead, optimize for learning. Build the technical and organizational infrastructure that helps you learn faster. That's the only sustainable competitive advantage you have.

For deeper insights into building engineering teams on a budget, visit this guide on Enjoy The Work.