I think about what it means to be a builder a lot.
Before working in tech, I associated the word ‘builder’ with the trades. People in construction making houses and bridges, or welders fixing the hull of a boat. And sometimes, I associated building with children’s toys and play. Making houses out of Lego and animals out of modeling clay. But I never saw myself as a builder. I was a creative thinker. Someone that brought ideas into the world and taught people about themselves.
But as I became more embedded in the culture and tradition of software development, I learned that building isn’t just something someone does, it’s an identity. A way of being and thinking. In this space, being a builder means wielding your craft to shape an idea into something tangible and (ideally) useful for other people. Even though software seems like a predominantly cognitive activity, the results of writing and organizing code is quite literally digital architecture, which at scale, produces interconnected systems that allow for the sophistication of modern life.
With that shift in perspective, I started to see builders everywhere, including myself. When I think of what it means to be a builder though, my mind naturally gravitates towards living systems. Human systems to be exact. There’s nothing wrong with artificial systems. I have great respect and appreciation for them.
But human systems are where I find the most important problems are worth solving.
And when I think of organizations and places of work, one type of builder stands out amongst the rest: the leader.1 Because the leader builds teams, and teams are the first living system an organization has. Get the team right, and the value scales all the way up.
Building human systems
Now that I’ve just made a statement about how problems in living, human systems are worth solving more than the ones in artificial systems, I’m going to walk it back for a minute and say that at a high level, systems are systems. Zoomed out, we can apply the same useful mental models we use for building software and products to building human systems. That’s the beauty of looking across domains. Some patterns are helpful regardless of where you apply them.
When you build a product, you follow an order. You figure out what you’re making before you start, you keep the scope tight, and you iterate quickly so that you can surface problems early. And if (or when) something breaks, you debug the system rather than blaming the user.
As a leader, you should be doing the same when building your teams. Let’s dive in.
Define what you’re building
Building products: the most expensive mistake is building the wrong thing well. So before you commit resources, you define what you’re making and who it’s for.
Building teams: define what the team is for before you size or staff it. Write its purpose in one sentence. “Talent development” sounds like a location on an org chart. “So every person at DiscoveryInc can see a clear path to excelling at what they do, and take it” is a purpose. This matters because all too often, people on the same team assume they share a purpose, but when it isn’t crystal clear and explicitly stated, or when it keeps shifting and drifting, each person ends up working towards their own version and the work inevitably starts pulling in opposite directions. Writing one sentence everyone can align on now, as you step into building this team, surfaces any mismatches while it’s cheap to fix.
You’ll know you’re done this step when your team’s purpose holds true even after a reorg or change in reporting lines.
Know your constraints
Building products: you have to accept that some things are fixed. The material has agency. The wood splits along the grain, clay cracks if you rush the drying, metal fatigues when you bend it too often. Those constraints are what make your choices real. You don’t get to wish constraints away, you build within them.
Building teams: People are material in that sense. They have real strengths and real limits, and a very real amount of time and attention to give. As a builder of human systems, your first move is to stop pretending the material is infinitely flexible and start working within the constraints you have. You need to spend time getting to know who your people are, because they are your most valuable asset and your most unpredictable constraint. People experienced enough to make their own calls need a loose structure with room to make and own decisions. People newer to the work need defined roles, clear aim, and more frequent check-ins. There’s no single right structure, but you won’t know which one to build until you understand the people that will interact and work within it.
You’ll know you’re done this step when you can name who each person on your team is, what they can own outright, and what type of scaffolding they need.
Keep the scope tight
Building products: every feature you scope in adds connections and dependencies to other parts of the system. And connections are where systems usually slow down or break. That’s why simplicity is key. Good builders are ruthless about keeping the number of interconnected parts and features as low as possible while keeping the value that their product offers high.
Building teams: the same math applies to people, but in my experience, complexity scales at a much much higher rate than in artificial systems. Because yes, you’re tired of hearing me say it (but I love some good repetition): people are unpredictable and complex. Each person you add to your team doesn’t just contribute their own work and output, they also add interpersonal relationships with everyone else on the team. Five people have ten connections to maintain. Ten people have forty-five. Coordination cost climbs faster than output, which is why large teams move slower, even when every person on the team is strong. I’m not saying small teams are better here. Some work needs more people, and forcing a team to be small in this scenario would just mean work doesn’t get done. The point is that team size is a real cost, not a free choice. As the builder, you need to add each person deliberately, knowing what each additional connection brings to the system, rather than growing the team simply because it feels like progress.
You’ll know you’re done with this step when you can say why the team is the size it is, and every person on it is there for a reason you can clearly name.
Iterate quickly to surface problems early
Building products: you don’t build something and hope it works. You build it so it fails loudly and you know when it breaks, and how to improve the system. Tests, monitoring, feedback are all part of the features you build in.
Building teams: structure your rituals, workflows, and expectations so problems surface early instead of staying hidden. This means people on your team feel permitted to say what’s actually going on without it costing them. Can someone admit they’re behind, flag a mistake, or tell you a plan won’t work, without being punished for it? The anti-pattern is a team where people stay compliant to avoid friction. That team may seem calm at first, but problems tend to pile up and cost more downstream. This is the condition that separates a high-performing team from a struggling one, more than a talent bench does. Strong and weak teams are built from similar people. The way you design the conditions around the team is the differentiating factor.
You’ll know you’re done with this step when people on your team bring you problems early and unprompted, and disagree with you in front of each other.
When it breaks, debug the system, not the people
Building products: you don’t blame users for system failures (even if you might want to). You find the flaw in what you built. The fault is almost always in the design, not people hitting the bug.
Building teams: it can be easy to pin failures on one person or one situation. That’s sometimes fair. Making sure the right people are on the team matters. But systemic failures are rarely about one person. Start somewhere else. Most of what determines a team’s performance are the conditions we talked about above: type of people, purpose, size, rituals, and flows. So scan the system for a broken condition. Is the purpose written down and clear to everyone on the team, even after a reorg? Is the team too big to coordinate or too small to achieve its purpose? Is everyone in a seat the team actually needs? Is it permitted to raise problems and create necessary friction? Etc. Fix the condition that’s off.
You’ll know you’re done when you’ve found and improved the broken condition(s) in your system, not the person to blame.
Leading from a different angle
Like all my essays, this mental model isn’t exhaustive and it might not resonate with everyone. But try it on for size. If the shoe fits, here’s what I want you to take away: the team is something you build, not something you manage into existence. It is a human system. Which means building it well compounds in ways that artificial systems can’t. A good product does its job. A well-built team makes better people, better work, and better organizations. That’s why they’re the systems most worth building.
For this particular essay, I’m talking about leaders that oversee and are accountable for groups of people, whether trough formal reporting lines or projects.
Nice sentence! : “at a high level, systems are systems. Zoomed out, we can apply the same useful mental models we use for building software and products to building human systems. That’s the beauty of looking across domains. Some patterns are helpful regardless of where you apply them.”
Well stated.😊