What is a technical architect?
I have wanted to be a technical architect since I started out in IT, and last September I was delighted to achieve this long-held goal. But very quickly I realised that, while it was clear to me that the role of a technical architect is overseeing the technical aspects of large software projects, I really wasn’t sure what that meant I should be focusing on day-to-day. So I turned to some of the brilliant technical architects I know, both colleagues and elsewhere in the industry, for their advice.
Being a technical architect
In my first job as a developer, several years ago, I sat down with an architect I really respected, and asked his advice on how to get there. The diagram he drew for me in that conversation is the career plan I’ve been working off since then:
But now I am here it turns out there is a lot of variance. Different technical architects do completely different things. Some are hands-on with a project or small number of projects, writing code. Some have a consulting role. Some are inward-facing to the organisation, some outward-facing.
I know that I definitely want to stay technical, so I asked specifically about that and also for more detail of what the role involves. I focused on skills over and above my previous role as senior developer; for example, problem-solving, analytical skills and being a technical authority are all part of the developer role as well. I haven’t included people’s names as these conversations all took place in a series of private chats and emails.
A tech arch does what needs to be done
One thing that came up from almost all of the people I spoke to was that the technical architect does what needs to be done to move things forward. The role was variously described as “being a grown-up”, “the project shaman”, and “the rare responsible person”.
Of course, that could also be the description of the role of delivery manager and product owner and also, in some ways, any other member of the team. So one important thing I’ll have to think about is how to do what needs to be done to get the thing to work, without taking on too much of the non-technical aspects of that.
You need to stay technical
I definitely want to stay technical, and in any case some of the people I spoke to felt this wasn’t optional – you have to stay technical to do a good job. “You need to be coding as an architect. Try and spend as much time as you can on writing code.” This person also said “when things are going right, a tech lead and a tech arch are the same thing” and recommended Pat Kua’s series on technical leadership.
Staying technical while also doing whatever needs to be done to get the thing delivered is going to be tricky. One person advised me “the management stuff can eat up all the time if you let it, so make the time to step back and plan or engineer situations that will force you to do some ‘maker’ stuff.” One suggestion was that in a situation where I am overseeing a number of projects, I could go and visit one of them and then spend the rest of the day coding in one of their meeting rooms.
Someone also suggested that it’s good, if you can, to avoid regular, fixed commitments: “if you have a lot of steady state commitments, your ability to spend time on the most pressing issues tends to be squeezed.”
More specific than staying technical is actually trying to make sure you take the time to work alongside the people actually doing the work. One person who had done some job-hopping from technical architect to developer and back said that one thing the job changes had reminded them of is “how frustrating it can be working at the developer level with decisions being made ‘elsewhere’ in ‘smoke-filled rooms’. Working at that level a little may help you to keep in touch with these sort of issues”. Though you have to take care that people don’t treat you with kid gloves.
Responsible for communicating and enabling the technical vision
There were a lot of useful general comments on what the core skills of a technical architect are. It’s about owning the overall vision, establishing a common understanding of what the team is aiming for, and communicating it.
The technical architect should be paying attention to whether we are building the right thing, the right way, and the long-term vision. This might involve requirements, and it might involve a roadmap, but ultimately, the architect – as one person put it – should be “fundamentally lazy”; an enabler. Not command and control; rather communicate the long-term vision and let the team figure it out.
And the most important skill of a technical architect is the ability to find simplicity in complexity.
Influencing people
Many people point out that a technical architect’s role includes influencing people. As in a tech lead role this may well include stakeholder management, persuasion, and and maybe even convincing people to make big changes in the way they work.
One person had some very practical advice on this: “A conclusion from my initial architect days was that influencing people and coaching them is a major part of the job so I needed to work on it. The former doesn’t come naturally so I still have to make a conscious effort to take opportunities to talk to people without a specific purpose in order to form a relationship that will help us work together better later. People are far more of a challenge than computers! As someone said recently, if you’re looking for a complex adaptive system to work with, try people!”
Say no to things you really want to do
One skill that I’ve had to work hard to develop is learning to say no. Initially, you progress in your career by volunteering for a lot of things. You gain a breadth of experience, leadership skills and get to work on a lot of varied, interesting stuff. However, as people start to recognise you as someone who can get things done, you will be asked to take on more, and you need to learn to be selective in what you agree to take on so that you can properly focus your attention on the things you have taken on.
I thought I was quite good at that, but in my new role, I am going to have to take it to another level. I am going to have to start saying no to things that I really want to do. One person put it like this: “You will get lots of opportunities to do things that you would be really good at, that you would enjoy and you know that you would knock it out of the park; and you need to be able to say no to those things that don’t meet your goals.”
As a technical architect you are more in charge of your own time
Someone said “as a tech arch, you are largely in charge of your own time, so decide what you want to do and do it”. As noted above, a good thing to do is to carve out time for coding, design, or just thinking about a problem.
That doesn’t seem to reflect my current situation though. While it’s true I’m in charge of my time to the extent of how I help the team reach our goals, there seem to be a number of non-optional things I have to do in order to get there. A lot of that involves making sure to talk to people, and my days at the moment tend to be back-to-back meetings. Here is tomorrow:
And most of last week was the same.
In part, this is a function of the stage of my project is at; we’re just starting out so still need to communicate our initial goals and build the team. But I think it also indicates that there are some skills that I need to develop as a technical architect.
Luckily I have a great team and I’m confident that we can work out how to give everyone the room to do what they need to do, so my immediate next step will be working with the team on carving out the time for me to stay involved in the technical aspects of the project. I shall report back.
If you’d like to be notified when I publish a new post, and possibly receive occasional announcements, sign up to my mailing list: