Manage Knowledge, Not Code

After 20 years deep in the trenches of the software industry, working with everyone from early-stage startups to Fortune 100 companies, I’ve seen every kind of problem you can imagine except one: I’ve never seen a company that truly lacked the resources to write the code it needed.

The problem isn’t resources. It’s how we think about software itself.

Software Is Never Done

Software development doesn’t end; it just reaches good enough. That’s because software is inherently iterative. People write the code they think they need, discover gaps, rewrite, extend, and repeat.

There’s an easy way to visualize this: for every hour of development, you generate X additional hours of future work.

If the final program is 5,000 lines of code and a programmer can write 1,000 lines a day, the project should take 40 hours. But if X = 0.5, those 40 hours actually create 20 more hours of new work. If X ever rises above 1, the project will never finish.

For any business, keeping X below 1 is essential.

What Companies Get Wrong

Most companies invest huge amounts of time and money trying to write code faster. They adopt Agile, Lean, FDD, and other frameworks, all attempts, whether they realize it or not, to control X. But the industry does not understand that’s what they’re optimizing for. They are trying to bowl strikes by putting inflatable bumpers in the gutters, when instead they really need to learn how to send that ball down the center of the lane. 

They don’t need more code; they need to reduce X, and the way to reduce X is not by managing software. It is the skill of managing what’s inside engineers’ heads. When you make that mental shift, it becomes possible to successfully create good software.

Managing Knowledge

The real key to software success is not information management and not data in systems; it’s knowledge in people.

Each engineer brings a unique combination of experience and expertise. Managing software means managing both the knowledge and information they have, and along with the knowledge and information they need to have. The job of leadership requires validating that the knowledge and skills are diverse enough to be up to the task, as well as finding areas of excess overlap or areas that are fundamentally lacking. 

Let’s start with hiring.

Build software so an average entry-level engineer can become productive in a week or two. Track time to productivity as a real metric. In 20 years, I’ve never seen a company do this, and yet it’s the truest measure of how efficient your architecture and processes are. Programmers do not have an incentive to create simple, clean software, but it is very valuable for the business to have the widest possible labor pool to choose from. 

Make learning curves gentle slopes, not vertical climbs. Even senior engineers need time to understand a new codebase or stack. And before you start a project, make sure the necessary skills even exist in the labor market. Many projects fail simply because no one on earth has the mix of knowledge required to complete them.

The Cost of Consensus

This is not limited to skills, knowledge, and background. Consensus is also a state contained in the engineer’s head. Consensus is the shared understanding that lets a team move in the same direction. However, consensus can only be achieved through communication, and communication is expensive. It scales roughly with the square of the number of people involved. This is called the Network Effect. It’s what makes social networks valuable, but it also makes consensus expensive. Fred Brooks noted this while trying to create OS360 at IBM decades ago; he captured his understanding in The Mythical Man-Month.

The ideal project team is the smallest possible group that collectively holds all the information needed to get the job done. Adding people adds communication overhead exponentially, not linearly.

Coding Standards

Even coding standards are fundamentally about lowering the barrier for engineers to understand a codebase. They exist to make it easier for engineers, both new and experienced, to read, learn, and contribute quickly. Their true purpose is to shorten the learning curve, not to enforce style purity.

Why AI Misses the Point

AI can churn out code, but it is not solving the real problem: getting knowledge into engineers' heads (not just regarding how the code works, but also why the code is the right code to solve users' problems). Having employees who can understand what the users need, understand the dependencies, and implement effective solutions without creating disastrous side effects in the context of the entire system is what’s truly valuable. Not only is AI not up to this task, but it is also not even close. 

It used to be that companies had at least one employee who understood the code because someone wrote it. AI is just generating code that no engineers at the company know. Some companies are enforcing that their engineers understand the code that AI writes. By that point, you have not saved anything because that understanding is the hard part. 

A Shift in Perspective

The key isn’t adopting new frameworks or chasing new tools. It’s changing how we see the problem.

Software engineering isn’t a race to write more code. It’s a process of managing complexity, aligning human understanding, and keeping X below 1.

When you start thinking about development as a knowledge optimization challenge instead of a coding challenge, everything else, from team structure to architecture, starts to make sense.

We’ve been doing this intuitively for decades. It’s time to start doing it deliberately.