Making decisions - When should you trade off between speed vs. quality?
Startups develop rapidly by applying different kinds of shortcuts — learn what they are and know when to take them yourself.
Startups survive because of their agility and speed — their ability to pivot and move quickly. They measure their execution tempo in hours, days, and weeks. This allows them to maneuver around larger lumbering organizations that operate in tempos of months, quarters, and even years.
In environments like this, speed is king. Rapid time-to-market is the startup’s competitive advantage. Without it, you can’t get the tight feedback cycles that make iteration possible.
Achieving these speeds isn’t easy — it requires startup engineers to make a lot of sacrifices (both personal and technical) and take plenty of shortcuts. These actions have pros and cons that impact the organization’s ability to sustain and maximize its speeds over the short and long-term.
Two kinds of shortcuts
There are two kinds of shortcuts engineers at startups make in the pursuit of speed:
They reduce Quality
They reduce Scope
Reducing quality
Reducing quality means writing code quickly, without regard to the general hallmarks of maintainability including:
Correctness
Cleanliness
Understandability
Engineers taking this shortcut choose not to do things that would otherwise ensure these attributes, such as:
Writing automated tests
Refactoring
Creating abstractions and thoughtful system designs
Generalizing repeated functionality into reusable libraries and frameworks
Not doing these things saves engineers time in the short-term. They prioritize the speed-to-create, which allows for faster short-term releases at the expense of speed-to-change, which slows down future changes such as integration, debugging, and iteration.
Reducing scope
Reducing scope is a shortcut engineers can take regarding completeness and comprehensiveness. Activities that fall into this are often product-related, which requires negotiation with product owners or thoughtful execution management on the part of engineers.
They include:
Not building all of the capabilities that are envisioned
Not building everything at once
Not integrating with existing process or technology
Not addresses all of the concerns (eg. scalability, measurability, security)
Not involving engineering at all (eg. doing things manually)
Not automating or operationalizing (aka. doing things that don’t scale)
Not handling less common use-cases
While many of these aren’t entirely up to the engineer to decide, engineers can influence these decisions. At early-stage startups, the order in which to actually execute is often up to the engineer to figure out, as they have to lay the track needed to get to the eventual goal. It is here they can influence the build by developing smaller, complete, fully-functional verticals instead of building the entire feature all at once.
Which one to pursue
While both of these practices can result in speed, only one results in speed over the long-term.
Sacrificing quality can be a massive initial speed gain during the first creation of the product, but these speeds rarely sustain themselves once iteration starts to occur — and iteration will occur.
Maintaining is harder than creating
Teams that sacrifice quality slow down over time, becoming overburdened by bugs, untraceable issues, and difficult-to-change systems. Because they optimized for creation instead of maintenance, which makes up the bulk of software development activities, the team’s output slows down to a crawl after the initial build-out.
The only solution for teams following this strategy is to approach everything as net-new — building things separate so they don’t have to deal with the debt they’ve created.
This means that products end up as shallow and unintegrated silos, regardless of whether they’ve been built before. Teams that operate in this model can’t take advantage of development momentum because they’re creating net-new on everything each time.
This works in contexts where exploration and experimentation is still the name of the game, but not in situations where product-market fit has been discovered and needs to be capitalized on.
Fixing quality shortcuts costs money
Resolving issues caused by quality shortcuts costs the startup a lot of money. More engineering headcount is required to push through the issues, or higher engineering salaries are required to get the skill needed to resolve the issues. An engineering team of 4 can perform incredibly well in a high-quality environment, but you’d need a team of 12 to reach the same amount of effectiveness in a low-quality one.
The alternative to throwing money at the problem is not something many startups can bear: pausing feature development to spend time fixing issues or paying down technical debt is the last thing founders want to do.
Either way, there’s a significant cost to quality shortcuts and they have to be meticulously measured and applied.
This strategy can be appropriate if your organization is aiming to receive a massive investment round to push through the problems, but if that’s not in the cards you’re better served to take the other kinds of shortcut.
Where possible, reduce scope instead of quality
Prefer reducing scope instead of quality. This will help ensure speed across a longer time-frame. Yes, it does mean that you’ll need more skilled engineers initially, but the payoff is massive.
One secret benefit to prioritizing quality — if you sustain a certain level of quality over a long enough period, you’ll eventually reach a point where development starts to speed up, not slow down. This is because higher quality code leads to higher confidence in development and maintenance, which results in faster changes.
Change = Risk
Lack of confidence is the number one speed killer. If a developer is not confident that their code will work, that they covered all the edge cases, that they fully understand what is happening, or that they won’t break anything, they will move slower to compensate.
This is because risk increases as change increases. While a static system only has to deal with environmental risk (risks that occur from not changing), a system under active development has to deal with much more risk — risk of bugs, risk of failure, risk of edge cases, risk of losing customers, etc.
You combat risk by minimizing the negative impact of failures and improving quality so that developers have increased confidence that the changes they are making are correct and have no unintended consequences.
The more confident a developer is in the change they are making, the faster they move. By keeping quality higher, you improve developer confidence and thus improve speed.
Advice for the real world
Of course, we live in the real world where things get messy and the lines are easily blurred. Sometimes the barometer of when to sacrifice quality and when to sacrifice scope is hard to read. You need to know how to best deal with both strategies instead of being told that you should avoid one entirely.
To benefit the most from reducing Quality…
Track it
Know when, where, and why shortcuts were taken, and track the speed of your team to ensure that these issues aren’t leading to a team-wide slowdown.
Tracking is an incredibly important aspect of quality reduction, because of two insidious aspects of technical debt
Technical debt builds one line at a time
Technical debt can be both incredibly easy and impossible to payback
Technical debt builds one line at a time.
That means it’s difficult to realize when you’ve accrued too much of it because every small change, taken in isolation, is often acceptable. It’s only by looking at the total amount that you realize the magnitude of debt you’ve taken on in the technology.
Technical debt can be both incredibly easy and impossible to pay back.
Once you’ve amassed a certain amount of technical debt, it becomes nearly impossible to pay back and maintain speed without exponential cost increases (often in the form of salaries, unhappy customers, and lost opportunities).
Keep reading with a 7-day free trial
Subscribe to Joseph Gefroh to keep reading this post and get 7 days of free access to the full post archives.