Building Alongside, Not in a Black Box

Imagine two engagements that end identically — the same system, running, delivering real value. In the first, the consultant built it heads-down and presented it finished. In the second, the consultant built it in the open, alongside the client’s engineers, sharing the reasoning at every turn. On the final day they look the same. Six months later they are worlds apart: the first system is slowly decaying because no one fully understands it, and the second is being extended by a team that learned how it was made.

This essay is about choosing the second way on purpose, even though the first is often faster in the moment.

Why the black box is tempting, and costly

Building in a black box is genuinely more efficient in the short run. You move faster alone than while explaining. You don’t wait for anyone, don’t adapt to a teammate’s pace, don’t slow down to make a decision legible. For a consultant measured on delivering the artifact, the black box can look like the professional choice.

The cost is hidden until you leave, and then it’s enormous. A system only you understand is a system the team can’t safely change, debug, or extend. The day you walk away, its evolution stops and its decay begins. You will have delivered software and failed to deliver capability — and capability was the point. A deployment that only works while you’re standing next to it hasn’t really been delivered at all.

What building alongside actually looks like

Building with a team rather than for them is a set of concrete, daily habits more than a philosophy:

• Share the reasoning, not just the result. When you make a decision, make the why visible — in the pull request, in the standup, in a quick whiteboard. The team should come away understanding not only what you chose but how you chose, so they can make the next such decision themselves.
• Pair on the hard parts. The thorniest, most judgment-laden pieces are exactly the ones worth building side by side with one of their engineers. It’s slower that hour and far faster over the year, because now two people understand the crux instead of one.
• Let them build the parts they’ll own. It’s tempting to take the interesting work yourself. Resist it enough to leave real, meaningful pieces to the team — with your support — so that by the end they’ve actually built part of the thing they’re inheriting. Ownership comes from having made something, not from having watched.
• Narrate the tradeoffs as you go. “We could do it this way or that way; here’s what each costs; here’s why I’m leaning this way.” Teaching the discipline of the decision is worth more than any single decision’s outcome.

It changes what you’re delivering

Building alongside quietly redefines the deliverable. You’re no longer handing over a system; you’re handing over a system and a team that understands it. That second half is the durable one. Software ages and gets replaced; the judgment and understanding a team gains compounds and carries into every problem they face next.

This is the multiplier mindset made concrete in the daily work. The diminisher builds in a black box, consciously or not, because a system only they understand guarantees they’ll be needed again. The multiplier builds in the open because the goal was always to leave the team able to do what they couldn’t before. The method you choose reveals which you are more honestly than any mission statement.

The tension worth holding

I won’t pretend there’s no tension. Building alongside is slower in the moment, and clients paying for a result can get impatient watching you teach rather than ship. The resolution isn’t to abandon the collaboration; it’s to make its value explicit up front — this is how your team keeps the capability — and to keep delivering visible progress so the client sees that teaching and shipping aren’t in opposition. Done well, the pace cost is modest and the return is a team that no longer needs you, which is the best outcome there is.

Which leads naturally to the moment the whole method is pointing toward: the handoff, when you find out whether the capability really stayed. That’s the next essay.