What is a Technical Architect anyway?

I spent a fair chunk of my career being a technical architect, most of which I also spent dreading the inevitable, "so what do you do for a living?" question at parties. Mostly I settled on answering, "I don't know" and quietly sobbing in a corner, because at least that has a reasonable chance someone will buy you a drink in sympathy.

Not only do you have very little idea what you're supposed to be doing on a day to day basis as a technical architect, but neither does your employer. This may seem like a fundamental omission but I saw it regularly across the industry - organisations will decide with great fervour that they really, really need a technical architect even though they aren't quite sure exactly what they need one for. And so up will go a job description with nebulous phrases like, "direct the application architecture strategy" or "engage with senior stakeholders to drive positive business outcomes", and lo! A technical architect will be summoned from the recruitment ether.

They will then spend quite a lot of time figuring out what it is they're supposed to be doing. And while your job description may be woolly, your boss is usually clued up enough to understand that, "have a minor existential crisis" isn't on there as a bullet point.

Here's what takes a long time to realise: you have something as a technical architect which few other people get to experience. That thing is agency.

If a technical architect says, "I think there's value in containerisation" and spends a few days downloading Docker, working out how to put together a Dockerfile, making a few false starts, reading some best practice and then making a working prototype, nobody complains. They go, "I don't really know what a technical architect does, but if I did know I'd say that prototype looks like a technical architect sort of thing".

This is actually a rare thing in software development. If you spend a few days doing that as a developer without agreeing a spike in planning, your product owner or project manager comes and yells at you and asks why you weren't concentrating on your assigned tasks. If you do it as a manager, your team yells at you and says things like, "what even is this, who writes code like this in 2018?" and "what the hell dude, you did this in a subdirectory and then committed to master, don't you realise this isn't Visual SourceSafe any more?" Then your boss yells at you for not having turned up to any meetings for the past week.

But as an architect, you do get this agency. Nobody yells at you when you spend your time doing interesting technical stuff. And this helps you unlock the real value of being an architect.

See the thing an effective technical architect does, more than anything else, is have the answers.

This is why nobody can properly explain the job role. They put, "develop an architectural strategy" or "be a reference of authority for the team" in your job description, but what they actually mean is, "be the person who stops an argument by saying, 'if we build this as a series of AWS Lambda functions this will be decoupled by default, and we can avoid having to make that decision right now'". Make decisions and own them. There's your value.

This also gives you the template for successful growth as an architect. At the start, when you've just been promoted from senior dev or team lead or whatever, you'll spend most of your time just trying to keep up with the team's need for decisions. Terraform vs. CloudFormation, Puppet vs. Ansible, whether we should spend time rewriting this to use the decorator pattern: you seem to spend your entire day typing "x vs y" into Google, comparing feature lists and eventually just picking whatever the first thing to install or compile successfully was.

The next stage is where you've worked with a few teams, you have something you've used in the past to solve most classes of problem (probably because it was the easiest to install), and you know from experience what looks like it ought to work but doesn't. This is the stage where you can give very immediate and definite answers based on that experience. Use Terraform, I used it in the past. Use Puppet, it worked for us on this project. Avoid rewriting that, these decorator pattern rewrites never end well.

A lot of technical architects (myself included, at one point!) get to this stage and progress no further. They build up a set of preferred technology and approaches, and where this doesn't match what's going on elsewhere in the organisation or the industry their team becomes a little enclave of, "over here, we do it this way." At worst this can even lead to a team who actively shun new approaches and start slipping horribly out of date, into the near-inescapable hole that is legacy technology.

What the effective people do is not this. They take the time they're saving on the mechanics of understanding what something is and how it works, and apply it to becoming more outward-looking. Some of that is the expected stereotype of going to conferences and events, playing with lots of new tech and building up a stash of stickers, but a more important part is being outward-looking within your own organisation. This means building up a network of who's doing what, common problems everybody faces, and where interesting technology is being used to solve them.

At that level, your answers to your teams start taking on a more holistic view. "We should use Ansible, because while my experience is in Puppet there's a lot of Ansible in use around the company and we can tap into that community." Or, "a lot of people have problems that would be solved by serverless approaches, if we use AWS Lambda for this and document it well then we can help lead and shape that approach." This is not only better for the company, but it's better for you: it gets you recognised as a thinker and leader, and serves as a good platform for the next career step up. The enclave architect might have the answers for their own team, but they don't have answers for anyone outside of it, and they won't get the respect as a result.

It's hard do this at first, because you're going from a very technical role to a very social one. A lot of the value of a really good technical architect is their ability to create communities and get multiple teams sharing approaches and ideas. Instead of coding you're spending your time communicating, persuading and (at times) challenging. You need to think about how you speak, how you present ideas, and how you engage with people to consistently provide those outward-looking answers. However, it's very rewarding when you get it right - and I say that as a former back end engineer who many years ago just wanted to sit in a dimly-lit corner with headphones on and write code without speaking to anyone.

That's my view. What is a technical architect? The person who looks outward and answers questions. Except the ones about what you do at work when asked at a party.