This conversation has gone in a completely different direction from the article. We're now all complaining about architects instead of the point it's trying to make.

But you can't fix that, so I'll chime in.

In my opinion, an Architect is just a role that gives advancement opportunities to individual contributors that doesn't go down a management path. You're still a part of the dev team, and you still do work.

When I've been in that role, that's how I treat it, and it's worked out pretty well. Generally speaking, when the position gets treated that way, I'd get involved in new products or major changes. For major changes, there's a specific thing we're targeting that needs something different. An extra complexity or just a different approach. That's all I focus on while writing the design document in response to the requirements document. Everything else is fine, but we need to do this one specific thing differently to make it work better. And this will have trickle-down effects on the rest of the system that's going to have to accommodate it. If I've done my job well, those are reasonably doable without that much explanation. I'll write the prototype that gets at the core of what needs to change, do code review with the team I'm eventually going to hand it off to, and explain my decisions in person. Once everyone is on the same page and gets what we're trying to do, I can hand it off and move on to something else.

For new products it's a little different. We want to make sure that we learn from our past wherever we can. Companies often have themes to their products and even a completely greenfield project isn't totally different from other stuff you've done. There's lots of stuff floating around that isn't great, but it's not so bad that you're ready to invest in a "major change." But if you had to do it all over again, you would do it differently.

That's what you want to make sure you capture when you start a new project. So again, there's requirements. And again, I write a tech document that represents my interpretation of the specs as it applies to the systems in play. The vast majority of these don't really matter, and any competent developers on the team can handle them. So my input is to focus on the things that are non-obvious and caused problems for us in the past. But the end result is the same: I write the prototype, workshop it with the team that's going to be taking it over, and hand it off and move on when everyone is confident that we all know what needs to be done.

Sometimes, it's not either of those things. Sometimes there's just a really annoying bug that needs tracking down and is really hard. It might not even be caused by the system your team is working on. You might need some cross-team investigation to figure it out. Sometimes you need a wider knowledge than a specialized team has. And sometimes it's just because some shit is broken that you wrote 6 years ago, and no one noticed until now because no one used it quite this way back then, but now everyone uses it that way, and it's awful, and half the reason you got promoted to architect is because that solution was mindblowing and novel, but now it sucks because no one knows how it works. Not even you. So it's your problem, genius, so go fix it. And you go crawl in a hole of shame.

Architect as anything other than really super double senior engineer doesn't make sense to me. Architect as an outside hire doesn't make a ton of sense to me. Architect as a layer of management that's not engaged in building software doesn't make any sense to me at all.

Architect makes sense as a retention strategy. It makes sense as an upward path for ICs. Architects should mentor.
Architect shouldn't be a special title. It should be a normal result of doing solid work over time by a person who wants to keep doing solid work instead of switching to management track just to justify a raise/promotion.

Just my thoughts.