Technical Leadership: Stop Acting as the Proxy

Ammar Najjar · Posted on September 24, 2026 · 4 min readleadership

AI-generated image

A situation I have encountered is this: someone brings me a request that needs an exception, and that exception can only be granted by whoever owns the decision. My first impulse used to be to carry it forward myself: explain the context, bring the answer back, and handle the follow-up questions in between. What has worked better is helping sharpen the request and then connecting the person directly with them, so the reasoning behind the answer arrives firsthand instead of through my retelling.

I used to stay involved for too long in that middle position. I would carry the arguments upward, bring the response back, explain the reasoning, collect another objection, and repeat the cycle. It felt helpful because I was keeping the communication moving. Over time, I noticed that this blurs where the decision actually sits: the person affected by it no longer speaks directly with the person accountable for it, while I gradually end up defending a decision I did not make.

The same dynamic appears in engineering work. An architect can become the messenger between teams. A technical lead can become the interpreter between a delivery team and a platform owner. A lead can find themselves repeatedly negotiating a constraint that belongs to another organizational boundary. The original problem then gets mixed with a second one: it is no longer clear who is accountable for the decision.

From Facilitation to Connection

What changed for me was paying more attention to the point where facilitation should turn into connection. I can still help make the issue precise, separate facts from interpretations, clarify which constraints are fixed, and make sure the relevant context is available. What has worked for me at that point: write down the facts, the fixed constraints, and the one open question, share that note with both sides, and then bring the relevant people together so the decision and its reasoning are heard directly. I stay available for context, but the decision itself is voiced by the person accountable for it.

AI-generated image

That distinction matters to me: helping clarify the problem is my contribution, carrying someone else’s decision is not. Once the remaining disagreement is about a decision outside my authority, the cleaner move is to make the direct conversation possible rather than to keep relaying messages.

Stepping Out Is Part of the Contribution

There is also a personal discipline involved. Acting as a proxy can feel productive because you remain central to the problem. Stepping out requires trusting that your contribution may be complete once the right conversation is possible. Lencioni puts that kind of vulnerability-based trust at the foundation of The Five Dysfunctions of a Team. I have come to see that step as part of the leadership contribution itself, not as withdrawal or lack of support.

In my companion piece on giving a team a time boundary, the move was the same in shape: make what needs to be true explicit, then step back. But that boundary sat inside my own authority, because the team I led still owned the approach while I kept the outcome. Here the line is where my authority ends, so the useful thing to make explicit is not the outcome but the direct conversation between the people who do own it. This is also the flip side of ownership building: there I was keeping context from concentrating in myself, and here the point is to stop relaying decisions across a boundary that is not mine.

My signal for proxy mode is simple: I am explaining someone else’s decision in a conversation they are not part of. That signal helps me check whether my involvement is still needed.

The Question I Now Ask

A useful diagnostic question for your next difficult discussion is:

Am I still helping to clarify the problem, or am I now carrying a decision that belongs to someone else?

If you have found yourself in that middle position, share how you handled it in the comments.