Most founders realize the difficult reality of investing more in engineering, and yet their business doesn’t feel more capable. When the engineering system is getting better, the stack is more modern, more work is automated, the architecture has been cleaned up, infrastructure is more scalable, and the team has adopted better tools, the business may still feel constrained, as features may still take weeks, production problems keep interrupting the team, infrastructure costs keep rising, and customers still wait too long for changes.
What most founders fail to realize is that engineering and business improvements aren’t the same thing since a more sophisticated system can still leave the business constrained if bottlenecks that matter aren’t removed. Automating a process that was never slowing the business down, rewriting a system that was ugly but still effective, spending months improving the technology only to discover later that the real constraint was a product decision, an approval process, or a lack of customer clarity are all wrong reasons for trying to look into what the business can do that it could not do as reliably, quickly, cheaply, or safely as before. The goal is to make the business more capable through engineering, not simply make engineering better, and that’s where engineering leverage comes in.
Engineering leverage is created when engineering work increases the business's ability to deliver, respond, operate, grow, or make good decisions without a matching increase in cost, effort, delay, or risk.
Better engineering does not automatically create a better business.
Early-stage startups, unlike growth-stage startups, have different needs because they need to be optimized for learning from activities like getting something into customers’ hands, feedback, discovering what people value, and changing directions without spending a year building the wrong thing - that means accepting shortcuts, which is not automatically bad engineering. The problem comes in when those shortcuts become permanent constraints after the business has changed and the product gains customers, traffic increases, and revenue becomes more dependent on the software, resulting in the engineering team growing, customer expectations rising, and the number of integrations increasing.
At that level, the business needs a system that supports a different level of activity. The old system may still "work." Working is no longer enough because the business needs to know whether the system can support its next stage. This is why technical maturity should not be judged by how modern a system looks, but by whether the system is appropriate for the business it now has to support.
What engineering leverage actually means
Three separate ideas are often mixed.
- Engineering quality is how well the system is designed, built, tested, secured, and operated.
- Engineering productivity is how efficiently the engineering team performs its work.
- Engineering leverage is how much additional business capability engineering creates from the resources the company already has.
They are related, not identical. A team can become more productive without making the business significantly faster. For example, the product team may still take two weeks to approve a feature, testing may still happen manually, and/or production deployment may still be risky. In such situations, engineering activity increased, but business leverage may not have changed much.
The opposite can also happen when the team writes roughly the same amount of code as before, but:
- engineers can now release safely
- failed releases can be recovered quickly
- the most common production problems are automatically detected
- important changes no longer require five teams to coordinate
The business's capacity increases, and that’s leverage. It’s an important idea for founders to measure the capability the system creates, not just the technology it contains.
Not every valuable engineering investment creates leverage
It would be wrong to conclude that engineering work is valuable only when it produces an immediate business gain.
Some engineering is insurance; for example, security improvements may reduce the chance of a serious incident, disaster recovery may sit unused for years, replacing unsupported software may prevent a future failure, and backups may produce no obvious return until the day they are needed.
Some engineering is foundational; for example, observability can make future problems easier to diagnose, good system boundaries can make future changes safer, automated testing can reduce future regression risk, and capacity planning can help a company prepare before demand arrives.
Some engineering is option creation; for example, an architectural change making several future product directions possible.
Repeatable deployment procedures, appropriate access controls, automated checks, documented recovery procedures, rollback mechanisms, operational training, and monitoring that reduces dependence on tribal knowledge create engineering leverage. The business results are less waiting, more operational independence, and lower key-person risk.
A better model is that engineering should have a clear relationship to business capability, economics, risk, or future constraints. A useful way to think about engineering value is through the five forms of business capability.
- Capacity: More output from the same resources, and more engineers releasing safely.
- Speed: Faster movement from decision to customer, and features reaching users sooner.
- Reliability: More consistent operation, and faster failure detection and recovery.
- Economics: Better cost relative to business output, and cost per transaction falls.
- Options: Safer choices in the future, and new product changes become easier to support.
Engineering leverage is when these capabilities allow the business to achieve more without a proportional increase in people, money, delay, or risk. This distinction makes the idea much stronger. It also prevents a dangerous mistake of optimizing engineering only for what can be measured this quarter.
The first mistake
Not every business constraint is an engineering constraint, and assuming so is the first mistake.
When your engineering/development team is too slow, it could mean that priorities change every week, requirements are unclear, product decisions take too long, customer requests are poorly defined, every change needs multiple approvals, sales promises custom work, teams depend on one another, testing happens late, deployment is risky, or engineers spend too much time on incidents. The symptom appears in engineering, while the cause may exist elsewhere. This matters because an engineering solution to a non-engineering problem can make the situation worse.
When the product roadmap is still unclear, more code is produced, and more work enters review, but nothing fundamental changes, the founder should focus on where the work is getting stuck, not which technology is old.
The constraint is often hidden in the queue.
One of the best ways to understand a growing engineering organization is to look at waiting. A feature may take three weeks, but perhaps the developers spend only four days actively building it. The other eleven days involve waiting for decisions, code review, testing, another team, deployment, a person with production access, or recovering from an earlier failure. The engineering team may be described as "slow," but the bigger issue may be that the system has lots of queues. It’s therefore important to always find the part of the system that is limiting capacity.
Four constraints that quietly limit growing software businesses
1. Recurring failures
A ten-person engineering team does not have ten people's worth of capacity if three of them spend large amounts of time dealing with recurring production problems. The pattern usually looks like this:
Failure → emergency fix → planned work interrupted → underlying weakness remains → similar failure happens again
Google's Site Reliability Engineering guidance describes repetitive, predictable operational work as "toil" and recommends reducing it at the source because it can consume engineering capacity that would otherwise go toward longer-term improvements. This creates a subtle business problem.
Busy engineers are not necessarily increasing business capacity, because if the same failure keeps returning, the business may be paying for the same problem multiple times. It’s therefore important to track repeated incidents, recurring customer-facing bugs, emergency deployments, repeated rollbacks, time spent on unplanned work, alerts that produce the same investigation, and systems involved in a large number of failures. The goal is to reduce tomorrow’s work, not only to resolve today’s incident. That creates leverage.
2. Slow-to-change systems
Some systems have no obvious outage, major failure, or an alarming dashboard. Everything works, yet every meaningful change is painful. For example, a pricing rule takes two weeks, a small integration requires changes in several unrelated places, a customer-specific requirement requires huge testing, and/or a product experiment takes too long to release. This is a different type of engineering constraint: changeability.
A business that cannot change its software efficiently cannot respond efficiently to its market. That does not mean every system needs a new architecture. In fact, that can create another problem.
A system may be technologically old but easy to change. Another system may use modern patterns but be tightly connected and difficult to modify. It’s about how difficult it is to make the changes that matter to the business, not how modern the architecture is.
Take several recent features, and measure:
Decision → Development → Review → Testing → Deployment → Customer
Then separate active work from waiting. You may discover that the system around coding is the bottleneck, and coding isn’t. DORA's guidance similarly treats delivery performance as a combination of throughput and instability rather than simply "developer speed." The business cares about the entire journey, not lines of code written.
3. Infrastructure costs that grow faster than the business
A bigger cloud bill is not automatically a problem, as a growing business uses more resources. Therefore, it’s important to check how technology cost is changing relative to business output. Suppose revenue grows 2x, transactions grow 3x, and infrastructure cost grows 8x; then that’s worth investigating. The cause could be inefficient queries, unnecessary computation, poor resource sizing, duplicated processing, excessive data transfer, resources running when they are not needed, or architecture that becomes increasingly expensive as usage grows.
Linking workload costs to workload metrics or business outcomes, so that cost efficiency can be understood, is better than looking at spend in isolation. The useful measure may therefore be: cost per transaction, or cost per active customer, or infrastructure cost per unit of revenue. That converts an infrastructure problem into a business metric. Always look for the engineering change that could improve the economics of growth.
Engineering constraints do not stay still.
There is another important idea that growing companies often miss: constraints move.
- Stage 1: Engineers do releases.
- Stage 2: Now database performance limits the system. You fix that.
- Stage 3: Now customer support cannot keep up with the operational complexity. It becomes the constraint, and you fix that.
- Stage 4: Now infrastructure costs grow quickly, and the constraints move again. This means removing one bottleneck does not make the business permanently unconstrained. It exposes the next bottleneck.
The worst engineering problem is not necessarily the most important one
Suppose your team discovers outdated libraries, inconsistent naming, slow tests, a large monolithic codebase, an expensive database query, and/or recurring payment failures. All of them can be real problems, but do not deserve equal priority. A technical team may naturally focus on the most visible technical defect.
Founders should be aware of what happens to their business if they don’t make changes. An old library may be inconvenient, a recurring payment failure may directly affect revenue, and a messy codebase may frustrate developers.
On the other hand, a slightly slow query may have little effect at today's traffic. This gives you an important principle: Technical severity and business importance are not the same thing. The right priority is the problem whose consequences matter most to the business, not the ugliest problem.
This is where engineering judgment becomes valuable.
What about technical debt?
Technical debt is another area where founders can be misled because it can mean different things, including slow change, an increment in incident risk and operating costs, and ugly but harmless code. It’s therefore useful to always consider the technical decisions that create measurable constraints or risks.
A small amount of ugly code in a rarely changed feature may not matter. A tightly coupled component used by every major workflow may matter enormously. The difference is consequence.
Do not fix everything.
This deserves to be said directly: Some engineering problems should remain unfixed. It can be good prioritization, not negligence.
You may have a piece of ugly code that nobody needs to change, a manual process that happens ten times a year, an old technology that is stable, supported, and not causing trouble, a monolith that has clear boundaries and remains easy enough to change, or a performance issue that costs the business almost nothing at current scale. Fixing these problems may still be worthwhile someday. "We could improve this" isn’t a sufficient reason to spend scarce engineering capacity on it. Consider what the problem costs today, the risk it creates, the likelihood of increased risk, the future fixing capabilities, and what will not be built while working on it. Note that engineering capacity is finite, and every engineering investment has an opportunity cost.
Modernization needs a value hypothesis.
The argument about modern technology needs more nuance, because modern architecture, automation, AI coding, microservices, and cloud platforms can all be valuable. However, none of them are automatically valuable because they are modern. What the change improves is what matters: for example, new deployment processes that allow more engineers to release safely, independent deployment and scaling because parts of the product have different growth and reliability requirements, and tools that reduce time spent on selected development tasks while maintaining quality and keeping delivery stable.
AI is an amplifier of the business around it rather than a substitute for sound engineering and delivery practices, even if there are always tensions between increased development throughput and the additional verification and instability that can accompany greater AI adoption. That leads to a useful principle: A technology decision should begin with a capability hypothesis, not a technology preference.
Engineering productivity is not the same as business speed
Suppose developers become 25% more productive, but product decisions remain slow, approvals remain manual, deployment remains risky, incidents remain frequent, and/or customer feedback arrives slowly. The developers may be producing more, but the business may still be moving at roughly the same speed. That means: Engineering productivity increased, but business throughput did not increase proportionally. This is why measuring only developer activity can be misleading.
Businesses ultimately care about how quickly and safely business and engineering decisions can turn into customer value. That distinction is explicit.
Business constraints can exist outside engineering.
Suppose the engineering team can ship every day; however, marketing cannot generate qualified demand, sales cannot close customers, operations cannot fulfill orders, customer support cannot handle growth, and/or the founder takes too long to approve decisions. The business may still be constrained, and engineering leverage cannot fix all of these. Sometimes the right conclusion is: Engineering is not the bottleneck. That may be one of the most valuable conclusions, because it prevents the company from spending money fixing the wrong system.
The time horizon matters
Not every engineering decision should be judged on the same timeline. Some investments solve a constraint today, others prevent a constraint six months from now, and others create options the company may need much later. A useful way to classify engineering work is:
- Now: What is actively constraining the business today?
- Next: What is likely to become a constraint as current growth continues?
- Later: What capability may eventually be needed but does not yet justify investment?
This helps prevent two opposite mistakes.
- Under-investment: "We will fix it when it breaks."
- Over-investment: "We should build for a scale we do not yet have."
Good engineering judgment lives between these extremes. Businesses should therefore know today about the constraints it’s likely to face next.
A stronger way to evaluate engineering investment
Before approving a major engineering initiative, use this test.
- Be specific about the business constraint you’re trying to remove. For example, important customer changes taking too long.
- Use evidence such as delivery time, incidents, release data, infrastructure costs, customer complaints, repeated work, and support volume to tell which constraints are real. Measure software delivery performance to understand current performance, prioritize improvements, and validate whether changes are actually working.
- Investigate the cause of the constraint, not the symptom. Possible causes include unclear requirements, excessive waiting, tight system coupling, poor testing, deployment risk, database limitations, external dependencies, and coordination overhead. Note that "features taking too long" is not a cause.
- Choose the intervention after understanding the cause, not before.
- Every engineering solution introduces trade-offs, and it may add complexity, migration work, new infrastructure, operational burden, training, vendor dependency, maintenance, and transition risk. A solution that removes one constraint but creates a larger one is not a successful intervention.
- What the business can do better afterwards is where technical work becomes business language. For example, more engineers can release more safely, customer changes reach production faster, failures are recovered with fewer disruptions, and each transaction costs less to operate.
- Use evidence to show that the intervention worked. Without this step, it becomes very easy to confuse engineering activity with engineering progress.
- Solving today’s or preparing for tomorrow’s problems can both be valid, but they’re different investment decisions.
The cost of engineering constraints is much higher than the engineering bill.
When founders think about engineering costs, often, it’s salaries and cloud bills. Those are only parts of the picture. Consider the cost of delay. A feature released two weeks late may mean delayed revenue and learning, slower customer adoption, and a missed market window. Then there is the cost of rework. The same work gets done twice because the first version failed. Then the costs of incidents, where one production problem can consume engineering and support time, refunds/credits, customer trust, and management attention. Then there is coordination cost, where a small change requires six people to discuss, approve, test, and release. These costs are rarely visible in a cloud invoice, but they’re still business costs.
The strongest engineering work may look boring.
Real engineering leverage is often surprisingly unglamorous. It may be a rollback procedure that reduces recovery uncertainty, a database query that stops wasting resources, monitoring that exposes problems before customers report them, a clearer system boundary that allows teams to work independently, documentation that lets engineers operate a service without interrupting the same person every time, an automated test that prevents a recurring class of customer-facing failures, or a cost dashboard that tells the business which workload is getting expensive. None of these necessarily produces a flashy architecture diagram, but each can increase the company’s operating capacity. That is the point.
Engineering leverage compounds when the system gets better at improving itself
The best engineering improvements do not only solve today's problems; they make future problems easier to solve. For example, better monitoring helps the team understand future failures, better deployment automation makes future releases safer, better testing reduces the cost of future changes, clearer system boundaries make future architectural decisions easier, and better measurement makes future investment decisions more informed. This creates a compounding effect, and the system becomes not only more capable, but easier to improve. That is a stronger form of leverage.
What happens when you leave constraints alone?
Most engineering constraints do not suddenly destroy a company; they usually accumulate when one slow release is not a crisis, one production incident is not a crisis, and a cloud bill increase faster than expected is not a crisis. The problem is the pattern of a delay becoming normal, a workaround becoming permanent, a temporary shortcut becoming architecture, and a manual process becoming "how we do things." The organization adapts around the constraint, and eventually the constraint becomes invisible because everyone has learned how to work around it. That is often when it becomes expensive.
The business may then need to spend significantly more to recover the capacity it could have preserved earlier. The legitimate urgency is that the longer a business adapts around a constraint, the more that constraint becomes part of how the company operates.
Engineering should expand what the business can do
The goal is more business capability, not more technology. Engineering should help the company create more capacity, move faster, operate more reliably, improve economics, and preserve useful options for the future.
Sometimes that means modernization, automation, refactoring, better infrastructure, or doing nothing. Sometimes the most valuable engineering conclusion is: “Engineering is not the constraint you should fix right now." That is good engineering judgment, not a failure because the business does not need the most sophisticated system it can afford. It needs the system that helps it move. It is about connecting sophistication to purpose, not rejecting it.
Share this article
Send it to someone who would find it useful.