A boundary nobody can enforce is just a suggestion.

In HBS's Strategy Execution, Robert Simons makes a point that stuck with me: the clearest strategy is often stated in the negative. Not a vision of everything you could do, but a short list of what you must never do. He calls it the power of negative thinking. Most companies bury people in procedure. The disciplined ones draw a few bright lines instead, and trust their teams inside those lines.

I took that to heart when I became Head of Engineering. One of the first things I did was sit down and write what I call our responsibility matrix. For every kind of work, sprint delivery, architecture decisions, deployments, security, hiring, it spelled out what each level of engineer owns, what they can only recommend, where they merely participate, and what they must never do. Then I called a general assembly and walked everyone through it. Who creates work items. Who reviews and approves a pull request. Who, and only who, can approve a release to production.

But here's the part I'd push any leader to sit with, because it's where I learned the real lesson.

A boundary you announce is not a boundary. It's a hope.

I'd seen enough to know that a rule living only in a slide deck or a town hall gets forgotten the first time someone's in a hurry. So I didn't stop at explaining the matrix. I wired it into the tools. We run on Azure DevOps, so I used its access controls to make the boundaries real. Executives can pick up a task and assign it to themselves, but they can't create or assign work to others, that sits with supervisors. The same logic ran through pull request approvals, pipeline access, production releases. The "never" wasn't a request anymore. The system simply wouldn't let you.

I thought we'd covered it. Then someone found a crack.

An engineer got excited about a feature and wanted it live....right now. He didn't have the authority to approve a production release, that line was drawn at the manager level. So instead of waiting for his line manager, he reached outside his own team, pulled in someone with the right access from another part of the company and got the feature pushed to production without the approval the boundary required. It went badly. It cost us.

What I want to be honest about is my reaction, because the instinct in that moment is to find the person and make an example of them. That's the wrong move, and it misreads the problem. The engineer didn't really break the rule. He revealed that the rule wasn't yet a control. We had locked the front door and left a side window open. The boundary was sound; the enforcement had a gap.

So that's what we fixed. We ran an incident review, and the outcome wasn't a punishment, it was closing the bypass, so that the path he'd found simply wasn't available to anyone again. The cross-team access that made the workaround possible got tightened. We made the "never" structurally true, not just officially true.

That episode changed how I think about leadership boundaries altogether. We talk about culture and standards and values as if saying them clearly is the job. It isn't. Anyone can write a good rule. The work is making the wrong thing genuinely hard to do and the right thing the path of least resistance. In a regulated business especially, where the cost of the wrong action isn't just embarrassment but real money and real trust, a boundary that depends on everyone choosing to honour it will eventually be tested by someone who doesn't.

Simons gave me the idea: lead with what you must never do. My teams gave me the correction: a "never" is only as strong as the control that backs it.