Software Engineering ≠ New Features
Modern software engineering is not about producing new features. If you don't understand this, you're setting up your engineering org to fail.
Most people imagine engineering as a sophisticated factory, designed to produce new features. They picture engineers as hyper-intellectual workers in hoodies, solving a series of complex math problems on dark screens that magically materialize into buttons and drop-down menus.
Virtually every methodology, tool, and dashboard today reinforces this idea: that delivering features is work and point of engineering. Continuous feature delivery has become synonymous with engineering success.
This couldn’t be more wrong. And this misconception can literally kill your company.
Modern software engineering is not the work of producing new features. Engineering is the work of creating, maintaining, and changing a system—a system that inevitably evolves in ways you can’t control.
Features are simply goals and byproducts of that system.
Modern Software Engineering
Today, even a small engineering project can have dozens of dependencies - different frameworks, languages, libraries, and tools that keep that project running. These dependencies are like off-the-shelf, highly specialized and modular parts.
They can be powerful accelerants to your development process. With Stripe, for example, you can implement enterprise-grade, secure, feature-rich billing for your systems with minimal effort. If you were to attempt to build one from scratch, it would almost certainly take both more time and yield less functionality. Companies like Stripe charge for their services, but others are completely open-source and free.
These dependencies will also have their own dependencies. It’s not uncommon for popular software tools and services to depend on one another and co-evolve. For example, Remix is a framework for React, a popular programming Javascript library. Remix removes many of React's pain points. In turn, it makes React more popular. Their symbiotic success means that these tools will likely evolve together despite coming from two different companies.
This interconnected ecosystem is inarguably a net good. It’s removed barriers of entry and made software more accessible to everyone; you don’t need to build your own billing system to have a storefront on the internet.
But there are drawbacks. These component parts are maintained and updated independently outside of your org, you can’t control them. You don’t get to dictate when Google changes its SEO algorithm or when Facebook’s SSO inadvertently introduces a security vulnerability. These changes can happen at any time, for any reason, across dozens of dependencies.
When these changes happen, your platform changes. The impact can range from completely imperceptible to irrevocably crashing your business. There’s just no way to tell in advance.
That’s why trust is such an important currency in the developer ecosystem. A company with a reputation for poorly maintaining its API, shutting down tooling without warning, or just being buggy and difficult will quickly find that developers no longer want to work with them.
It also means that each feature you add to your platform inherently adds some amount of risk. They’re not widgets that have a one-time cost of “story points”; there is an ongoing carrying cost to everything. Simply staying alive requires constant, vigilant maintenance.
More features = more stuff to maintain = more stuff that can potentially break.
Hence why the feature factory model is so dangerous. Imagine a $20M ARR company with ~20 engineers. Building features endlessly leads to literal death; the company can’t support the weight of its ever-growing maintenance cost. Eventually, both quality and velocity go to zero. Once you get into this vicious cycle, it’s very hard to break out - especially if you are a small company with limited resourcing.
There are many points in a company’s lifecycle where it may make sense to slow or even pause feature development. If your only way of understanding engineering performance is feature velocity, you’ll ignore those to your own detriment.
You’re also completely blind to the real work of engineering - keeping the system alive, evolving it, and reactively adapting as these networks of dependencies evolve in ways that are out of your control.
The best CTOs today handle all of this behind the scenes. They refactor, upskill, and improve ergonomics so their teams can do more with less. The best CPOs act as a defensive wall for these CTOs, ruthlessly prioritizing to protect the precious time of their product teams.
This is hard, thankless work because it’s invisible and untracked. It also doesn’t make you very popular in a world that only celebrates new features. How do you track accumulated institutional knowledge? How do you credit a refactor that happens just in time—before productivity is impacted?
That’s partly why we built Godfrey—it’s designed to measure the very heartbeat of modern software engineering orgs. It doesn’t lean into vanity metrics like “developer ROI” or “deployment velocity”. Nor does it want to return to a world where bloated engineering budgets get a blank check.
Instead, it embraces the nature of engineering and faithfully and intuitively represents it. In doing so, it brings real accountability—which includes an equal dose of kudos. Amazing technical leaders deserve to have the full breadth and complexity of their work recognized - not just the byproducts.
Godfrey helps communicate the true nature of engineering, beyond story points and roadmaps, and vanity “developer productivity” metrics.
By mapping maintenance, resourcing, and architecture in a way that anyone can understand, it surfaces the invisible work that the very best engineering leaders do thanklessly.