Stay in Your Lane

In 2004, I joined a software company as a back-end tech lead.

Early on, I was given an explicit boundary: don’t talk to the front-end team.

Of course, we could chat socially; they sat across the floor from me. But if I needed to discuss work with them, I had to go to my manager. He would then talk to their manager, who would talk to his tech lead.

As someone who’d already been using Agile ways of working for four years (as both dev and manager), I found this to be unhelpful. I discussed it with my manager, but he didn’t see a problem with it.

Me being me, I thought, “Let me chat with the VP.” But now I had a problem: there was no explicit boundary about approaching executives (and more specifically, discussing the process with my boss’s boss).

I went ahead with it. But I can guarantee you, nobody else in development would have done that.

Why? Because they assumed they couldn’t. In the absence of explicit norms, rules, guidelines, processes, or values, people (especially at work) default to holding back. It’s not that I’m a great boundary-crasher myself, but I thought that the potential gain — to the company! — outweighed the risk. I was ready to ask for forgiveness instead of permission.

At work, we usually avoid the word “boundaries” because of its negative connotations. Instead, we use the term for what lives inside them: “empowerment.” But people still need to know how far their empowerment extends. Otherwise, they don’t act enough on it, which effectively makes them less empowered.

Contrary to what the word might connote, boundaries may be quite expansive. That’s the case in many high-functioning agile organizations.

Boundaries always exist, whether we feel comfortable articulating them or not. Make them explicit and clear.