The Architect Who Asked Me What a REST API Is

There's a guy on my project with "architect" in his title who asked me to explain what a REST API is during a call last month. Not which pattern to use. Not whether we should consider an alternative approach for the integration layer. He wanted me to explain the concept. From scratch. This person is making architectural decisions on a banking platform that processes real financial transactions every single day.

He was an intern two years ago.

I've been building banking systems for 25 years. Core integrations, real-time payments, infrastructure that moves actual money for actual people who trust their bank to not lose it. I've worked with plenty of people who were still learning and that's fine, everyone starts somewhere. But this isn't someone learning. This is someone who already has the title, already has the authority, already sits in meetings where decisions get made about how millions of dollars worth of technology gets built. And he can't explain REST to another engineer on a call.

The REST API thing isn't even the worst one. A few weeks later we were in a discussion about our Kubernetes environment in the cloud and someone asked him a straightforward question about workload types. Not some obscure edge case. The kind of question you'd expect someone working with Kubernetes for even six months to be able to answer without thinking. He couldn't. He fumbled through a non-answer while everyone else on the call sat in that painful silence where you can tell people are looking at each other's faces on the screen trying to figure out if anyone else noticed what just happened. Everyone noticed. Nobody said anything.

The boxes are empty

His architecture diagrams are beautiful though. I'll give him that. Clean boxes, nice arrows, everything labeled in a way that makes non-technical people nod along in meetings. Leadership eats it up. He presents with confidence and uses words like "orchestration" and "decoupled services" and "enterprise alignment" and everyone in the room who doesn't write code for a living feels like technology is under control.

But every single time you ask him to zoom in one level, to show what actually lives inside those pretty boxes, to explain what happens when service A calls service B and service B is down, he dodges. He'll say he needs to follow up. He'll pivot to a different topic. He'll throw a question back at you to buy himself time. Because there's nothing inside the boxes. They're a movie set. Impressive from the front and completely hollow the moment you walk around the back and look.

I used to question his diagrams in reviews. I'd ask about failure scenarios, about data consistency between services, about what happens under load. He'd stutter through half an answer and then trail off. The room would go quiet. Not the good kind of quiet where people are thinking. The uncomfortable kind where everyone is watching someone drown and pretending they don't see it. After a few of these sessions he stopped presenting altogether. Didn't announce it, didn't explain it, just quietly started letting another architect on the team present instead. Now he sits in the back of architecture reviews and doesn't say much. He found someone to hide behind and nobody called it out because calling it out means acknowledging that the person leadership promoted to architect can't survive a basic technical question from a peer.

We rebuilt everything he designed

The moment it went from frustrating to genuinely dangerous was on a recent project. A developer on my team was trying to implement one of his architectural designs and nothing worked. The integrations didn't connect the way the diagram said they would. The data flows didn't make sense. Components that were supposed to talk to each other had no actual interface defined between them.

I sat down with the developer and we traced through the whole thing together and that's when it hit me. What he'd drawn wasn't technical architecture at all. It was a business process flowchart with technology vocabulary pasted on top. Someone had diagrammed how the business thinks the process works and labeled it as a system design. The developer was trying to implement something that was never designed to be implemented because the person who drew it doesn't understand the difference between "this is how the business wants it to work" and "this is how the systems need to be built to make it work." Those are completely different things and the gap between them is where architecture actually happens. He doesn't know the gap exists.

My team and I threw out his design and rebuilt the entire architecture from scratch. He sat in the redesign sessions but barely said a word. Didn't challenge anything, didn't contribute alternatives, didn't ask why we were changing his work. Just sat there. I think by that point he knew. And I think he also knew that it didn't matter because his position was secure regardless of whether his architecture actually worked.

After we shipped the redesigned system, after it was running in production doing what it was supposed to do, nobody had a conversation with him about what happened. No review. No feedback. No "hey let's talk about why the original design didn't work." Nothing. His name is still on the architecture documents. His title hasn't changed. Leadership still thinks he's great.

The two versions of him

What drives me genuinely crazy is that there are two completely different versions of this person depending on who's in the room.

In technical calls with engineers he's quiet now. He used to try to assert authority early on but after getting questioned a few too many times he pulled back. He answers direct questions with the minimum possible words and redirects anything deep to someone else. He's learned to survive technical conversations by not participating in them.

But put him in an executive call and he transforms. The hesitation vanishes. The vocabulary gets sharper. He leans forward and says things like "we're aligning the integration strategy with the enterprise roadmap" and "the architecture is designed for scalability and resilience" and every non-technical person in the room thinks they just heard something important. They didn't. Those sentences mean nothing. They're the architectural equivalent of a horoscope, vague enough to apply to anything and specific enough to sound like a real statement. But it works. Leadership walks out of those meetings feeling like technology is under control. And that feeling is his entire product.

Everyone knows and nobody talks

Here's the part that made me want to write this. It's not just me who sees it. The entire team knows. Every developer, every engineer who's had to work with his designs or sit through one of his reviews knows that this person does not have the technical depth for the role he's in. I've had private conversations with multiple people on the team and they all say the same thing in slightly different words: "yeah we know but what are we supposed to do about it."

They think he's protected. Whether he actually is or whether leadership is just oblivious I honestly don't know. But the effect is the same. Nobody says anything upward because they're afraid of the political consequences. So the team quietly works around him. They take his diagrams and build what actually needs to be built instead. They nod in his architecture reviews and then go design the real solution in a separate call without him. They've created an entire shadow architecture process that exists specifically because the official one is run by someone who can't do the job.

And the organization will never know this is happening because from above everything looks perfect. There's an architect. There are reviews. There are diagrams. There are meetings. All the boxes are checked. The process exists. The governance is in place.

This is Risk Management Theater

I've been writing about a pattern I call Risk Management Theater for a while now and this situation is one of the clearest examples I've ever encountered. The organization believes technical risk is being managed because there's an architect managing it. The role exists, the person is in the role, the ceremonies are happening. It feels managed. It looks managed. On a slide deck it is managed.

But underneath that surface nobody qualified is actually evaluating real technical risk. The person in the architect role can't identify what he can't understand. He can't flag a design flaw he doesn't recognize as a flaw. He can't anticipate a production failure scenario he's never experienced. He can't push back on a bad technical decision because he doesn't know it's bad. He just draws another box and labels it and moves on and the organization counts that as architecture.

The risk isn't gone. It's invisible. And it will stay invisible until production goes down at 3am and someone in leadership calls an emergency meeting and asks "how did this happen, don't we have an architect reviewing these systems?" Yes you do. He just doesn't know what a REST API is. But his diagrams looked great in the last steering committee so everybody felt safe.

If any of this sounds familiar, if you work in a place where the titles look right and the ceremonies happen on schedule and the slides are beautiful but something underneath feels fundamentally broken, try the RMT Diagnostic. Five minutes, ten questions. Most people score between 12 and 18. The ones who score that high aren't failing. Their organization is.

The uncomfortable question

I've spent 25 years building systems that actually work. That handle real money. That don't break at 3am because someone drew pretty boxes and called it architecture. And after all this time I've started asking myself a question I don't like the answer to: do organizations actually want real architects? Or do they want exactly what this guy provides, a comfortable feeling in a meeting, a professional looking slide, a confident voice that makes complexity feel managed without anyone having to actually understand it?

He fills a role that leadership needs filled. I fill a role that the codebase needs filled. Leadership decides who gets promoted. The codebase doesn't promote anybody.

I used to think that was unfair. Now I think it's just the system working exactly as designed. The architect who can't explain REST isn't a bug. He's a feature. He's exactly what the organization optimized for. And people like me who actually build the systems that work? We're the infrastructure. Necessary, invisible, and easy to replace on paper because nobody above us can tell the difference between someone who understands architecture and someone who learned to perform it.

---

I'm Benjamim Castell, not my real name. I'm a software architect at a US bank writing under a pseudonym because I'm still inside the system. If you've ever had to quietly rebuild someone else's architecture while they got credit for it, Chapter 2 of my book is about that feeling. You can read it for free.