Software projects are most efficient when, at any given time, each contributor is focused on a different concern. Like objects in 3D space, projects can be said to have surface area and volume:

• Surface area represents the number of opportunities to contribute—that is, how many people could efficiently work on the project at the same time.
• Volume represents the knowledge space of the project (measured, perhaps, in the total number of productive person-hours spent on it). Divided by the number of contributors, it also measures the theoretical limit (relative to the project as a whole) on any single contributor's ability to make an extraordinary impact.

As projects grow, they inevitably increase across both measures—but not evenly. A perfect sphere has the smallest possible surface-area-to-volume ratio: that's a project where a few well-tenured contributors will outperform any other team configuration, meaning that hiring wouldn't increase productivity or efficiency. A flattened cuboid, on the other hand, has a large surface-area-to-volume ratio: there are many different opportunities to contribute, and hiring will usually increase speed of delivery, but increasing headcount will eventually yield diminishing returns as the space becomes too limited for each contributor to spread their wings. Thus, projects with the same scope may have very different shapes.

^{For teams that practice pair programming, two developers can be counted as a single, highly efficient contributor.}

Following are four theories about software development that proceed from this analogy.

1. Starting a project

Theory: Every starting-from-zero project should have exactly two people assigned to it for the first eight weeks. Those two people are an engineer and a product manager.

A brand new software project, like a marble, is very small and has a minimal surface-area-to-volume ratio. One motivated developer can make incredible progress in a very short time; another developer would only slow the project down or end up waiting around while the first developer works on initial project setup, architecture, and creation of patterns.

What one programmer can do in one month, two programmers can do in two months.

— Fred Brooks

To mitigate the risk of the developer making progress in the wrong direction, the product manager's role is to map out the scope of the project and continuously negotiate the feature set. They also lead out on collaborating with pilot clients, testing and validating early iterations, and building a prioritized backlog.

Only when a project actually does something is it reasonable to assign more people. Ideally, it should do several things. It should also have had a chance to fail if any of its core assumptions were faulty. Every project is an experiment until proven otherwise. Part of the logic of assigning minimal staff to it for a while is to avoid overspending on something that won't yield fruit.

2. Growing the team

Theory: Individual contributors have the clearest picture of what roles should be added to a project.

It's important to be thoughtful about adding more people to a project as it grows. Headcount is often assigned to projects based on extraneous criteria such as profitability, corporate strategy, or contract deadlines. This approach to staffing is based on wishful thinking, not sound methodology.

Adding [human resources] to a late software project makes it later.

— Brooks's Law

The 3D object model of software development insists that we assign headcount for one reason only: efficiency. This can mean different things in context, but at the very least, adding a role of type X when there's an existing bottleneck of type Y won't do much for productivity.

Every development cycle has bottlenecks, but many are only visible from the ground.

• If a product manager is working frequent overtime, it may appear that another product manager is needed to partner with them. But maybe they're spending all their time fielding support tickets because the software has a high rate of defects. In this case, another product manager would be less helpful than a QA engineer.
• If features are spending too long in development, it may seem like the solution is to hire more developers. But the problem could be that developers are having to wait several days for UI prototypes to be finished, or that the features are underspecified and they have to jockey for time with an overscheduled product manager to nail down the details. In these cases, more designers or product managers, respectively, are needed.

To discover these bottlenecks, it's essential to talk to the people closest to them: individual contributors. Any hiring decision made without this information is no better than a guess.

3. Building connected projects

Theory: The size, composition, and hierarchy of a software team is a software-architectural decision, not a human resource decision.

Choices about the structure of a software team invariably affect the projects they ship.

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.

— Conway's Law

When you split a product team in two, you're incentivizing them to create two different products. Whether those products appear unified to the end user is a consequence of how well the teams communicate with each other. When you combine two teams into one, you're incentivizing them (albeit in competition with other constraints) to combine their products. When you form a centralized "core UI" or "platform" team, you're incentivizing those teams to ship discrete products to other teams, which become end users—for better and for worse. These incentives can be overcome, but only by well-defined rules and continuous incentives.

Teams, by nature, create and defend their own opportunities to contribute (surface area) and their own tight-knit knowledge space (volume). When their projects must interact, the quality and reliability of the interaction largely depends on how difficult it is for contributors on different projects to ask each other for favors.

Teams working on interdependent projects can only be effectively organized by someone who has a mental model of each project's structure, shape, and interaction points. Trying to force teams of one's preferred shape onto projects with completely different shapes is, in a real sense, no different than trying to put a round peg in a square hole.

4. Building long-term value

Theory: Growth is never value-neutral; it either adds consumer value or subtracts from it.

A project with a simple shape is easy for a customer to understand and use, but that doesn't mean it provides ideal value, or even any value at all.

Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can.

— Zawinski's Law

Some customers prefer software that does one thing well, but most will gravitate to a one-stop shop. Nearly all software products are pathologically incapable of communicating with each other, so one mediocre product that manages an entire process typically requires less effort to use than five spectacular products that each manage a single step.

In the 3D object model of software, consumer value can be thought of in terms of congruence between a customer's process (also a 3D object of sorts) and a project's knowledge space. Each customer may have a different process, but if they're rational, they'll prefer whatever software has the most similar shape and the same or larger size. Processes appear continuous when you're in them; you can't easily persuade a customer to slice their process into multiple pieces for the sake of adopting your software. Therefore, every process should be considered holistically.

Planning new features for a project is a matter of two driving goals: matching the average customer process more closely (shape), and increasing the knowledge space of the project so it can accommodate a greater number of differences between processes (volume). An increase in volume without a change in shape creates value for all customers, since processes tend to evolve over time, but every change in shape either makes the project more congruent with the average customer process or less so. This is one reason why customer collaboration and functional empathy are so important.

Changes in shape and volume can come in many forms. Running ads in a product, for example, is a risky proposition because "viewing ads" isn't part of anyone's process. The presence of ads always decreases customer value, which isn't to say it's always self-defeating; the revenue opportunity may justify the addition of unsightly vertices to the project's shape. But if a project's entire revenue comes from advertising, it's destined to take on the shape of its advertisers' process rather than its users', which will make it less competitive. Collecting and selling user data is risky for the same reasons.

The Platonic ideal of any project is something that perfectly matches its users' needs without any unnecessary volume. This has never been achieved. But it can only be approximated when the user and the payer are the same person.

A project that completely covers its target market's processes, variations included, will nonetheless face pressure to grow. There may be opportunities to do so by addressing new customers with very similar needs. However, there are more and easier opportunities to grow in the short term by sacrificing customer value for profit. When a project's only remaining options are to stop growing or sell off its own competitiveness for parts, it becomes a sinking ship. Vendor lock-in and lack of competition are the only forces that can keep its customers on board after that.

Modeling success

Like any model, the 3D object model is imperfect and reductive. There are many factors outside of it that contribute to project success or failure: sales and marketing, willingness to pay, market power, pricing, organizational competence, turnover, and so on. But it's a useful tool for thinking about software in terms of the internal (what it does, how it's used, and who builds it) rather than the external (what we believe about it and how it sells). This is important because the internal factors are more often ignored, yet more easily controlled.