Becoming the Architect I wanted to be

I really have to get better at writing more. The benefit of learning through experience is diminished if I don't share it, so here goes hopefully something will be helpful or relatable for someone somewhere. I was recently invested with the title of Technical Architect in Kainos, and I want to tell you a little bit about how I got there, if it's where I expected my career to go, and what it's like to do this job in Kainos. All things to all people 'I'm a Software Architect'. I have come to learn that no other job title in our industry presents as many different variations when it comes to describing what it is or what one does both in terms of duties and responsibilities. Depending on the company you work for, it can mean anything from 'people manager of a technical team' to 'I spend my days in enterprise software producing UML diagrams'. So what does it mean for me? Let's start at the beginning. Dealing with perceptions I like building things. I like writing code and that's what I wanted to do when I joined the company as a graduate, having worked on developing internal tools for Microsoft on my placement, I was excited to be part of a team building user-facing services that were going to make a difference to someone. As a graduate I hadn't really given much thought to where I wanted my career to go, or what I wanted to be when I grew up, until I was forced to think about it when our CTO asked me, on my first day out of our company training, just before joining my first project, 'Where do you see yourself in five years?', (he gets straight to the point, I like that about him) I responded with 'I don't know, I like the idea of deciding how we build things, but I don't want to give up building them'. That was my perception, all I could see is that it seemed that the more senior you get in a technical role, the more you transitioned from building things to talking about building things. The idea wasn't particularly appealing to me, I'm a Software Engineer, I thought, my place is in the code, someone else can deal with customers and all those meetings! The influence problem There was a flaw in my plan. I'm far too passionate about building the right thing in the right way to not aspire to have more influence in the decisions that go into building software. What technology will we use? How will the service architecture look like? Where is it going to be hosted? I found I almost always had an opinion about these things, (sometimes it was even half thought out!) but more importantly I started feeling like I had something to contribute beyond writing, testing and reviewing code. Now what though? The dilemma around not wanting to stop building things is still there right? Maybe. Kind of. Not really. Turns out I was at least in part wrong in my perception. As I moved around different projects and had a chance to observe different people interpret the various senior architect roles in Kainos, and most importantly when I had a chance to get involved 'unofficially' in some of the things an architect in Kainos does, my perception changed. An architect I can get on board with I realised my definition for 'building things' was far too narrow. IDEs and terminal windows are cool, but they're not the whole story. Working with the customer to understand the whole problem, being the person to come up with possible solutions, working with the team to come up with designs and to pick the right technology, asking 'why' a lot, thinking about scale, infrastructure, performance, resiliency and security, as well as getting stuck into the code, became my new definition of 'building things'. And this is the thing I love about what Kainos mean by an architect; it's a hands-on role, building things is front and centre of what you do, forget about being removed from the code or the team. You can't influence the customer in identifying constraints and challenges if you can't remember the last time you were forced to write sub-optimal code because those things weren't thought through properly at the start. You can't be the gate-keeper for technical quality for a team if you're not both passionate about and have a lot of experience in writing quality code. You can't pick the right technology if you haven't been bitten by someone having picked something shiny over something useful. In short, you can't be an architect here, if you're not an Engineer first. You need to be a rounded engineer who has an understanding of what it takes to build and deliver quality software that meets user needs, someone who is at peace with the reality that they don't know everything and never will, but can use the experience of others in the team, either more senior or indeed junior, to make the right decision. Helping people grow As an architect, you're not a one-man team. Your success rate is going to be determined by how open you are to learning from your team and leveraging their experience. Here are my final thoughts on how you can develop your team members if you think they're ready to do so it's certainly something that helped me.

• Value your team's opinions give them the opportunity to try new, difficult things in a safe environment with plenty of support.
• Look out for people in your team who are ready to take on something extra, make it clear it's ok to fail and give them all the help they need.

If the type of architect I described isn't what you think a software architect should do, then Kainos is probably not the right place for you, however if my story resonates with you either in terms of what you're already doing or your future aspirations, then you should check out our open positions, we can always do with more like-minded techies!