Everything New Has Bugs

Increasing velocity and quality

Back in the early 2000s, when I first learned that eBay was running at least one full version behind on their Oracle database, I assumed it was because upgrades were a logistical nightmare. The real reason was more interesting. The DBAs told me they avoided upgrading because every new version had bugs, and they preferred the bugs they already knew over the ones they didn’t.

At the time, I thought that was overly cautious. But the more I worked in fast-moving product organizations, the more I realized the underlying truth: whenever you change systems, whether that’s an upgrade, a new framework, or just accelerating your release cadence, you’re effectively trading stability for learning. You’re increasing velocity, and velocity always creates turbulence until your processes and people can handle the new speed.

Every engineering leader eventually learns this lesson the hard way. The first time your team moves from quarterly releases to continuous deployment, there’s a short-lived honeymoon period, until the pager starts lighting up. Incidents spike, defect rates rise, and engineers who were once confident start second-guessing themselves. The problem isn’t that anyone got worse at their job. It’s that the system is being asked to move faster than its safety mechanisms were designed to handle.

Take as an example Amazon’s move from its C++ monolith to a service-oriented architecture in the early 2000s. The transition enabled much faster development, but internally it was described as “going from controlled chaos to uncontrolled chaos.” Deployments broke, dependencies multiplied, and monitoring lagged behind. For years, they were effectively paying a “speed tax” in the form of bugs and outages until the supporting systems, CI/CD pipelines, automated rollback mechanisms, and observability, caught up to the new level of velocity.

That’s the paradox of scaling engineering teams: success often requires moving faster, but moving faster almost guarantees a temporary dip in quality. You can’t avoid it; you can only plan for it. It’s like turbulence on takeoff, if you want altitude, you accept the bumps.

The lesson isn’t to move slowly. It’s to acknowledge the natural lag between increased speed and recovered stability. Great teams don’t mistake early chaos for failure; they treat it as part of the process of getting better. They anticipate the bugs, build better feedback loops, and iterate their way back to equilibrium.

So yes, everything new has bugs, but especially when what’s “new” is speed itself.

When teams start to accelerate, they often mistake movement for progress. They ship more code, more experiments, more releases, and for a moment, it feels exhilarating. The graphs go up. The stand-ups buzz with energy. But underneath, the system begins to creak. Tests start flaking. Deployments get riskier. Customer support sees a slow rise in bug tickets. No one notices at first, because velocity hides fragility. It’s only after a few cycles that the cracks begin to show.

Facebook’s evolution is one of the best-known case studies here. In its early days, the company’s internal motto was “Move fast and break things.” It perfectly captured the spirit of a startup trying to outpace everyone else in Silicon Valley. And it worked, until it didn’t. As the platform scaled to billions of users, the collateral damage from “breaking things” became untenable. In 2014, Mark Zuckerberg publicly changed the motto to “Move fast with stable infrastructure.” That tiny shift in language acknowledged a truth every engineering organization eventually faces: velocity without maturity eventually consumes itself.

The deeper issue isn’t speed itself, it’s the lag time between faster motion and the adaptation of supporting systems. When you double your release cadence, you also double the pressure on QA, incident response, deployment tooling, and observability. Unless those systems scale proportionally, quality drops. And that drop isn’t a moral failure; it’s physics.

Consider Knight Capital, a trading firm that, in 2012, deployed a new high-frequency trading algorithm to production without fully cleaning up remnants of an old one. Within 45 minutes, the system had executed billions of dollars’ worth of erroneous trades, costing the company $440 million and effectively ending its existence. It wasn’t a coding mistake, it was a process mistake. Their release velocity had increased, but their deployment governance hadn’t caught up. The speed of change outpaced their ability to absorb it.

A less catastrophic but equally instructive example comes from Spotify. In 2016, their engineering teams began aggressively adopting feature toggles and continuous delivery to increase experimentation. Predictably, they saw an initial surge in production bugs and performance regressions. But they had planned for it. Their quality metrics, error budgets, incident postmortems, and test automation, were designed to absorb and learn from the turbulence. Within months, they were not only releasing faster than before but with fewer incidents overall. The process had caught up to the pace.

The pattern repeats everywhere: speed increases → quality drops → systems adapt → new equilibrium. Mature organizations know this cycle is unavoidable, so they design for it. They expect the turbulence, monitor the metrics, and focus on shortening the adaptation curve. Immature teams, by contrast, panic when quality slips. They either slam the brakes or double down recklessly, both of which make the cycle worse.

This is why “go faster” isn’t a strategy; it’s a stress test. It reveals every weakness in your tooling, your communication, and your culture. How your organization responds when things start breaking says far more about your long-term quality than the bugs themselves. Great teams use velocity as feedback. Poor teams mistake it for success.

So the next time you’re pushing to accelerate, new release cadences, new experiment frameworks, new team structures, remember the natural law at work: every increase in speed will first feel like a drop in quality. The key isn’t to avoid that dip, but to control its depth and duration. If you can do that, you’re not just moving fast, you’re learning fast, too.

If increasing speed inevitably introduces instability, then the counterbalance isn’t just process, it’s space. Every high-performing engineering team I’ve ever seen builds slack into its operating rhythm, whether they call it that or not. Slack is what lets a team breathe, reflect, and fix the hairline cracks before they become structural failures.

Slack is also what allows ownership to flourish. When engineers are given zero time beyond delivery, ownership collapses into obligation. But when teams have space to explore, refine, and improve, they begin to take pride in what they build. Quality isn’t an outcome of process; it’s an expression of pride in craft.

Toyota figured this out long before software did. On their assembly lines, any worker could pull the andon cord to stop production if they noticed a defect. To outsiders, that looked inefficient, why halt an entire line over a single issue? But Toyota understood that the few minutes lost fixing one problem were nothing compared to the hours lost later if the defect made it into the final product. That’s slack: deliberate inefficiency in service of long-term quality.

Etsy adopted a similar mindset in its early DevOps culture. Their engineers were encouraged to spend part of every cycle improving deployment safety, documentation, or test coverage. No one had to “ask permission” to fix something broken. The result was a sense of collective ownership, if a bug escaped, the response wasn’t “who wrote this?” but “what did our process miss?” That shift, from blame to curiosity, is the foundation of quality.

Contrast that with teams that chase perpetual 100% utilization. I once worked with a company that prided itself on keeping every developer “fully booked.” Projects were scheduled back-to-back, sprints jammed to capacity. On paper, it looked efficient; in practice, it was exhausting. There was no room for maintenance, learning, or reflection. Quality slipped, bugs accumulated, and burnout became the quiet default. When we finally introduced 10–15% unallocated time for proactive improvements, the irony was immediate: velocity increased. We shipped faster because we were fixing the root causes of slowness instead of constantly reacting to symptoms.

Slack isn’t waste, it’s margin. It’s what allows engineers to be creative rather than reactive. The best leaders understand that the cost of unused capacity is far less than the cost of accumulated chaos.

But slack alone isn’t enough. Without ownership, it turns into drift. Ownership is the cultural engine that turns space into quality. It’s the moment an engineer says, “This code is mine, I want it to be great.”

Ownership doesn’t mean control; it means care. It means developers writing their own tests because they take pride in the product’s reliability, not because QA will catch their mistakes. It means teams choosing to refactor a shaky subsystem before it fails in production, not waiting for permission. It means engineers who stay close to the customer experience, not because they have to, but because they want to see the impact of their work.

You can see this ethos at Netflix, where the “Freedom and Responsibility” culture is more than a slogan. Engineers are trusted to make decisions about their services, deploy on their own schedules, and fix what they break. That autonomy creates an intense sense of accountability. When something goes wrong, there’s no faceless “ops team” to clean it up, you own it. And because you own it, you care deeply about its quality.

Google’s Site Reliability Engineering (SRE) model operates on the same principle. SREs aren’t there to take on developers’ problems; they’re there to teach developers how to own production quality themselves. The goal is to build systems that can tolerate change without collapsing, because everyone involved feels responsible for that resilience.

When ownership and slack coexist, something magical happens. Teams begin to self-correct. They fix flaky tests because they want reliable feedback loops. They refactor brittle code because it offends their sense of craftsmanship. They make time for postmortems not because leadership mandates it, but because they genuinely want to understand what went wrong and how to make it better. Quality becomes intrinsic, not imposed.

And here’s the beautiful paradox: giving teams time to slow down is what ultimately allows them to go faster with confidence. It’s the engineering equivalent of sharpening the saw, maintenance of the craft itself.

When I think back to that eBay story, the DBAs who knew every bug in their Oracle version and every workaround by heart, I realize they embodied this balance. They weren’t clinging to the past; they were stewarding quality. They understood that speed without stability is unsustainable, and stability without evolution is stagnation. They moved when it made sense, not when the calendar said so. That’s ownership. That’s professionalism.

Quality software isn’t just built by good engineers, it’s built by patient engineers, led by organizations wise enough to value slack, autonomy, and accountability as much as velocity. Everything new has bugs, but great teams are the ones who expect them, design for them, and keep moving forward anyway.

Speed will always tempt us, it’s wired into the DNA of modern product development. But every increase in velocity carries a hidden tax, and leadership’s job is to make sure the organization can afford to pay it. The best leaders don’t just push for faster output; they invest in the systems, processes, and people that make sustained speed possible.

So the next time you’re asking your teams to move faster, pause and ask yourself: Have we built the slack, ownership, and feedback loops that allow us to absorb the bumps that speed creates?

Because anyone can go fast for a sprint. The real craft of leadership is building a culture that can go fast, and stay excellent, for the long haul.