My Manager Leaves Every Technical Discussion And It Took Me a Year to Understand Why

For the first few months I thought it was just bad luck with scheduling. We'd be in an architecture review or a technical deep-dive about how two systems should integrate and my manager would drop off the call. Sometimes he'd make a joke on the way out like "I'll let you guys figure out the hard stuff." Sometimes he'd say he had another meeting. Sometimes he'd just disappear without saying anything and nobody would mention it.

I didn't think much of it at first because managers are busy and not every conversation requires their presence. But then I started noticing the pattern. It wasn't random. It was selective. Any meeting where the conversation stayed high level, roadmap updates, status reviews, stakeholder syncs, he was there the entire time. Engaged, asking questions, driving the agenda. But the moment the discussion shifted into how something actually works, the moment someone pulled up a diagram and started talking about API contracts or data flows or failure handling, he'd find a reason to leave.

It took me almost a year to understand what I was watching. My manager doesn't leave technical discussions because he's busy. He leaves because he doesn't understand them and he doesn't want anyone to find out.

The performance that fills the gap

Once I saw this clearly I started noticing all the behaviors that exist to compensate for it. In every one-on-one he asks me how things are going in broad terms. "Are we on track?" "Any concerns?" "How's the team feeling?" Never once has he asked me to walk him through an architectural decision or explain why we chose one approach over another. Not because he trusts my judgment, although he might, but because asking those questions would reveal that he wouldn't understand the answers.

In leadership meetings he talks about the work using the vocabulary he's picked up from listening to the first five minutes of technical conversations before leaving. He'll say things like "the team is working through some integration complexity" or "we're aligning the services architecture" and everyone above him nods because those words sound like someone who understands what's happening. They don't. They're borrowed phrases from conversations he wasn't present for long enough to actually comprehend.

And here's the part that connects everything I've been writing about for months. He thinks the architect on our project who was an intern two years ago is doing a great job. The same person who asked me what a REST API is. The same person whose architecture we had to throw out and rebuild from scratch. My manager thinks this person is excellent. And now I understand why. Because they operate in the same space. They both exist at the layer where technology is discussed in abstract terms and never examined in detail. At that layer everything sounds competent. It's only when you go one level deeper that the emptiness becomes visible and my manager never goes one level deeper because he can't.

Who evaluates the evaluator

This raised a question that's been eating at me for months. My manager writes my performance review. He determines my rating, my compensation adjustments, my career trajectory at this company. But he fundamentally does not understand what I do. He can't evaluate the quality of my architectural decisions because he doesn't understand architecture. He can't assess whether I made the right tradeoff on a system design because he doesn't know what the tradeoffs are. He can't tell the difference between me doing exceptional work and me doing mediocre work because both look identical from the altitude where he operates.

So what does he evaluate? He evaluates what he can see. Am I in the meetings he attends? Do I respond quickly on Slack? Do I sound confident when he asks me how things are going? Do I cause problems that reach his inbox or do I handle things quietly? That's the review. Not "did this person make good technical decisions that will serve the organization for years." But "did this person make my life easier this quarter."

And once I understood that I understood everything about why certain people get promoted and others don't. It has nothing to do with technical ability. It has everything to do with operating at the same altitude as the person evaluating you. If your manager lives at 30,000 feet and you live at sea level doing the actual work, they will never see your best contributions because your best contributions are invisible from where they sit. The person who gets promoted is the one who learned to operate at 30,000 feet with them, saying the right words, attending the right meetings, making leadership feel informed without requiring them to understand anything.

The sponsorship loop

Someone in a Reddit thread recently said something that rewired my brain: "Execs sponsor whoever speaks their language." That's it. That's the entire promotion system explained in one sentence.

My manager doesn't understand technology. So he can't sponsor someone based on technical excellence because he can't identify technical excellence. What he can identify is someone who communicates the way he communicates, who prioritizes the things he prioritizes, who makes him feel comfortable in the same way he makes his own leadership feel comfortable. That's who gets sponsored. Not the person who built the system. The person who can describe the system in a way that makes a non-technical manager feel like they understand it.

The architect who was an intern two years ago and doesn't know what REST is? He speaks my manager's language perfectly. Clean high-level diagrams that never go deep enough to be wrong. Confident vocabulary that sounds technical without requiring technical understanding to evaluate. A communication style optimized for making leadership feel safe. Of course my manager thinks he's great. He's the only version of "architect" my manager can evaluate.

Meanwhile I'm the architect who builds the actual systems, who catches the problems before they hit production, who redesigns the things that don't work, who mentors the developers when they're stuck. And in my performance review none of that is visible because the person writing the review wasn't in the room when any of it happened. He left. He always leaves.

This is Risk Management Theater

I keep coming back to this pattern I call Risk Management Theater. It's the appearance of governance without the substance. And it doesn't just apply to architects and processes and ceremonies. It applies to management itself.

My manager manages a technical team. On paper, technical leadership is in place. There are one-on-ones. There are reviews. There are career conversations. The governance structure exists. From two levels above everything looks correct.

But the person managing the technical team doesn't understand the technology. The one-on-ones never go below surface level. The reviews evaluate visibility not capability. The career conversations are about perception not about growth. The entire management layer is a movie set. Professional from the front. Nothing behind it.

And the cost isn't abstract. The cost is that an architect who can't do architecture gets praised while the team that carries him gets no recognition. The cost is that technical decisions get evaluated by someone who can't tell good from bad so they default to evaluating confidence instead. The cost is that every engineer on this team is being measured not by the quality of their work but by how well they perform their work for an audience that doesn't understand it.

Why I stay

People ask me why I don't just leave. The honest answer is complicated. Mortgage, visa history, the job market being what it is, the fact that I actually like the technical work and the people I work with. But there's another reason I don't usually say out loud.

I stay because I'm documenting all of this. Not in a legal paper trail sense although I'm doing that too. I mean I'm writing about it. Publicly. Under a pseudonym because I have to. Every pattern I see, every dysfunction I experience, every moment where the gap between how organizations present themselves and how they actually operate becomes visible. I write it down.

Because the thing I've learned in 25 years is that this isn't just my story. Every time I describe one of these patterns, hundreds of engineers respond saying "this is happening to me too." The manager who can't evaluate technical work. The architect who performs competence without having it. The team that carries someone who gets the credit. These aren't isolated incidents. They're the system working as designed.

And maybe writing about it doesn't change my situation. But it might change someone else's. If one engineer reads this and realizes that their mediocre review isn't because they're mediocre but because their manager can't see what they do, that's worth something.

My manager is going to leave this discussion too. He always does. But this time I'm the one who decides what gets said after he's gone.