If You Can't Explain It Simply, You Don't Understand It Well Enough

When I think about what’s served me best across nearly 30 years of building software — the technical skills, the architecture knowledge, the years of shipping products — none of it comes close to this: I learned how to explain things to people.

That probably sounds underwhelming. It’s not.

The Superpower Nobody Teaches You

Earlier in my career, working at a larger company, I figured out something that changed my trajectory. I wasn’t the smartest engineer on the team. I knew it then and I know it now. I’m smart enough to know who the truly talented people are.

But I was easy to talk to. People came to me with questions — not because I had all the answers, but because I’d actually listen and try to help. And here’s the thing I discovered: I knew who to ask. I made it my business to know which engineer understood which piece of the system best. Someone would come to me with a problem, I’d go find the person who knew that area cold, ask them, and then translate their answer into something the original questioner could use.

From their perspective, the experience was: “I ask Brant stuff, and he knows everything.” That wasn’t remotely true. But it didn’t matter — what mattered was that they got a useful answer, explained in a way they could act on.

That pattern has served me in every role since. When I’m consulting at a larger company now, one of the first things I do is figure out who knows what about which part of the codebase. Not so I can hoard that knowledge, but so I can connect the right people and translate between them when needed.

The Real Work Is Translation

The most valuable version of this skill isn’t explaining code to non-technical people, though that matters. It’s sitting between engineering and product and being willing to translate in both directions.

I do this constantly. An engineer knows something is architecturally critical — a refactor that has to happen, a risk that needs to be addressed — but the product team can’t see why it matters. They’re looking at feature timelines and customer commitments. The engineer is looking at a system that’s going to become unmaintainable if they keep bolting things on. Both are right. Someone has to bridge that gap and make the engineer’s case in terms the product team can evaluate.

I’ve gone the other direction just as often. An engineer who cares deeply about quality and correctness wants to iron out every edge case before shipping. That instinct is usually good. But sometimes the risk is small, non-critical, and manageable if it ever materializes. The product team has context about timing and market pressure that the engineer doesn’t. Someone has to communicate that honestly — not as “just ship it,” but as “here’s why this tradeoff makes sense right now, and here’s how we’ll handle it if it comes up.”

Both of those conversations require believing something that I’ve held onto for my entire career: there are no product decisions too “businessy” for an engineer to understand, and no technical details too complex for a product owner to grasp. If someone isn’t understanding, the problem is the explanation, not the audience. If you start from that assumption, you refuse to leave anyone siloed off from the group. And that changes everything about how a team communicates.

Where I Got This

I didn’t arrive at this naturally. I had mentors — Andrew, Ellen, Josh, Max, Phil — who saw potential in me and invested real time shaping the habits I needed as an engineer. They didn’t just teach me technical skills. They modeled what it looked like to take something complex and make it approachable. They showed me that clarity isn’t a dumbing-down — it’s a sign that you’ve done the work to truly understand something.

That investment made me want to pass it on. Great mentors create people who want to mentor. It’s like sports: great players make the people around them better. Not by being the most talented person on the court, but by elevating everyone’s game through how they communicate, how they share what they see, and how they make their teammates feel capable of more.

Why This Matters More Now

This is also why I care so much about Behavior Driven Development. BDD at its core is a communication practice. It’s about bridging the gap between what a business needs and what the software actually does by forcing both sides to describe the expected behavior in terms everyone can understand.

The whole premise of BDD is that the people closest to the problem — product owners, domain experts, stakeholders — have knowledge that’s essential to building the right thing. But that knowledge is trapped if the only way to express it is in technical jargon or code. Executable specifications give everyone a shared language. They expose the areas we don’t yet understand. And they make it impossible to hide behind complexity.

That’s the same principle I’ve been applying my whole career. If you assume people will understand when you explain it well enough, you stop building walls between disciplines. Engineers engage with business strategy. Product owners engage with technical constraints. The conversation gets better because everyone is actually in it.

The Skill Behind the Skill

If I could go back and tell a younger version of myself one thing, it would be this: your ability to explain complex ideas clearly will be worth more to your career than any specific technical skill you learn.

Technical skills matter enormously. But they compound when people can understand what you’re doing and why. The engineer who can make a compelling case for a refactor gets the refactor approved. The architect who can explain a system’s constraints to a non-technical executive gets the resources to fix them. The developer who can translate between product and engineering becomes the person everyone trusts.

None of that requires being the smartest person in the room. It requires caring enough to make yourself understood — and believing that the people you’re talking to are capable of understanding.

Nearly 30 years in, that’s the lesson that’s paid the most dividends. And I don’t think that’s going to change.