Check out part 1

Every few years, our industry discovers a new way to become more efficient.

Sometimes it is a methodology. Sometimes it is a framework. Sometimes it is a programming language, a cloud platform, or an AI-powered development tool that promises to eliminate another category of work. The details change, but the promise remains remarkably consistent: we will build software faster, with fewer people, less effort, and lower cost. There is nothing inherently wrong with pursuing those improvements. Engineering has always been a discipline that values refinement. We automate repetitive work because people should spend their time solving problems rather than repeating them. We improve build pipelines because waiting for computers to finish unnecessary work benefits no one. We standardize deployments because predictable systems are safer than fragile ones. Every mature engineering organization should care deeply about efficiency because waste, regardless of its source, eventually becomes someone else’s burden.

The difficulty begins when efficiency quietly changes from a means into an objective. That transition rarely happens intentionally. No executive ever stands in front of a company and announces that reducing effort has become more important than creating value. Instead, it happens gradually, one optimization at a time. Teams celebrate shorter release cycles, lower infrastructure costs, and increasing levels of automation. Quarterly reviews become filled with charts demonstrating that engineering can now accomplish more work with fewer resources than it could a year earlier. Individually, each of those improvements is real and worth celebrating. Collectively, however, they create an environment where efficiency itself begins to look like success. Eventually, organizations become so focused on improving the process of building software that they spend surprisingly little time asking whether the software being built deserves the effort in the first place.

Part of the confusion comes from the fact that efficiency, productivity, and effectiveness are often treated as interchangeable ideas. They are discussed together in leadership meetings, measured together on executive dashboards, and celebrated together in company updates. In practice, however, they describe three entirely different characteristics of an organization. Efficiency measures how well resources are used. Productivity measures how much work is completed. Effectiveness measures whether the completed work actually improves the outcome that mattered. Those distinctions may seem academic until an organization becomes exceptionally good at one while quietly neglecting the others. At that point, the differences stop being definitions and begin determining whether years of engineering effort create lasting value or simply produce larger quantities of software.

Efficiency is perhaps the easiest of the three to improve because waste is usually visible. Slow builds can be measured. Manual deployments can be automated. Duplicate processes can be eliminated. Better tooling, stronger infrastructure, and thoughtful automation all contribute to an engineering organization that spends less time fighting its environment and more time solving meaningful problems. These improvements matter because engineering time is expensive, not simply in dollars but in opportunity. Every hour consumed by avoidable friction is an hour that cannot be invested in understanding customers, improving architecture, mentoring teammates, or solving the next difficult problem. Well-managed organizations should relentlessly pursue these kinds of improvements because they allow talented people to apply their abilities where they have the greatest impact.

Productivity, while closely related, answers a different question. Once unnecessary friction has been reduced, productivity reflects an organization’s ability to consistently transform ideas into working software. Healthy engineering teams finish projects, deliver features, resolve defects, and improve systems with a rhythm that inspires confidence. Productivity is evidence that an organization can execute. It demonstrates discipline, coordination, and technical capability. Without productivity, even excellent ideas remain little more than conversations and diagrams. An organization that cannot reliably build software will eventually lose the trust of both its customers and its own engineers because execution is one of the promises every engineering team implicitly makes.

Neither efficiency nor productivity, however, can answer the question that ultimately determines whether an organization succeeds. A team can automate every deployment, shorten every build, increase every velocity metric, and consistently deliver every planned feature while still failing to create meaningful value. That possibility sounds counterintuitive because we naturally assume that doing more work, more quickly, with fewer resources should produce better outcomes. Yet software history is filled with organizations that became extraordinarily good at building the wrong things. They produced impressive volumes of software, maintained sophisticated engineering practices, and invested heavily in improving their delivery capabilities. What they lacked was not execution but judgment. They had optimized their ability to move without spending enough time deciding where movement was actually required.

Effectiveness exists to answer that larger question. It asks whether the software changed anything worth changing. Did customers become more successful? Did the business become healthier? Did operational complexity decrease instead of increase? Did engineers leave the system in a better condition than they found it? These questions resist simple measurement because they require interpretation rather than arithmetic. There is no universally accepted metric for good judgment, thoughtful prioritization, or architectural restraint. Those qualities reveal themselves over time through systems that remain understandable, products that continue solving meaningful problems, and engineering organizations that spend more of their energy building the future than repairing the past.

One of the reasons effectiveness is so often neglected is that its greatest successes are invisible. Organizations celebrate software that ships because everyone can see it. They celebrate infrastructure improvements because dashboards reflect the gains immediately. They celebrate automation because the reduction in effort can be quantified. They rarely celebrate the feature that was removed from the roadmap after discovering that customers did not actually need it. They seldom recognize the architect who spent an extra week simplifying a design before implementation began, thereby preventing years of unnecessary maintenance. Almost nobody notices the production outage that never occurred because an engineer challenged a risky assumption during a design review. The most valuable engineering decisions frequently prevent work rather than produce it, and prevented work leaves behind very little evidence that it ever existed.

This is why organizations that appear slower in the short term often outperform their competitors over the long term. They are willing to invest time in understanding the problem before committing themselves to a solution. They allow engineers to question assumptions instead of rewarding unquestioning execution. They remove unnecessary complexity before adding new capabilities, and they accept that thoughtful planning occasionally delays visible progress. None of those decisions maximize efficiency in the moment. In fact, they often reduce it. Meetings become longer because difficult conversations are taking place. Designs are revised because someone recognized a better alternative. Features disappear because the underlying problem was solved another way. To an organization focused exclusively on efficiency, these activities appear wasteful. To an organization focused on effectiveness, they are among the highest-return investments available.

Artificial intelligence has made these distinctions even more important because it has dramatically lowered the cost of producing software. We can now generate code, documentation, tests, and even architectural suggestions in a fraction of the time they once required. Those capabilities represent genuine progress, but they also expose a misunderstanding that has existed for decades. If building software becomes easier, then deciding what deserves to be built becomes proportionally more important. AI can make organizations more efficient, and it can undoubtedly make individual engineers more productive. It cannot determine whether a proposed feature aligns with the long-term strategy of the business, whether a customer’s request reflects the real problem, or whether an architectural shortcut will become tomorrow’s operational burden. As the cost of implementation continues to fall, the value of judgment continues to rise.

Looking back over the organizations that have impressed me most, I do not remember them because they had the fastest delivery pipelines or the highest velocity metrics. Those capabilities certainly mattered, but they were never the defining characteristic. What I remember instead is the discipline with which they chose their work. They declined projects that distracted from their purpose. They removed features that complicated the product without improving it. They invested in architecture long before technical debt demanded attention. They understood that engineering excellence is not measured by the amount of software an organization can produce but by the quality of the decisions that determine which software deserves to exist. Their efficiency supported that judgment. Their productivity reflected it. Neither was ever mistaken for the goal itself.

Our industry will continue pursuing faster tools, smarter automation, and increasingly capable development environments, and it should. Every generation of engineers inherits better instruments than the one before it, and we should embrace those advances with enthusiasm. What we cannot afford to lose, however, is the understanding that efficiency and productivity derive their value from something larger than themselves. They are capabilities that amplify decisions already made. When those decisions are thoughtful, disciplined, and grounded in genuine understanding of the problem, greater efficiency and productivity become tremendous advantages. When those decisions are careless or misdirected, they simply allow organizations to travel farther in the wrong direction.

That may be the most important distinction of all. Efficiency helps us use our resources wisely. Productivity helps us execute consistently. Effectiveness ensures that both are applied to work worth doing. Remove any one of the three and an organization becomes weaker, but remove effectiveness and the other two gradually lose their purpose. An efficient organization can still waste its effort. A productive organization can still build the wrong system. Only an effective organization consistently leaves behind software that continues creating value long after the excitement of delivering it has passed.