Hello. This is the second instalment in README, a series dedicated to our illustrious engineering team. They're busy people, but I was lucky to grab some time with two of our Solutions Architects to ask them "Hey, so what do you actually do? Architect stuff?"
We have three Solutions Architects at Kyan; Andy Pike, Andy West and Andy Tom Marshall. I sat down with Andy West and Tom, who were kind enough to walk me through the what's what of the role and their journey into it.
What is a solutions architect?
Andy West: A Solutions Architect is someone expected to take a leading role on a project and be responsible for forming the technical approach to solving the given brief. That includes choice of technology, design-related choices and the pragmatic decisions that we need to take regarding the direction of the project in order to make it deliverable.
There are also tasks relating to the team who are going to be working on the project, such as asking who might be a good resource or appropriate person to work on the project. And I guess we also take on the role of a kind of 'intermediary' between the development team, our client services team and the clients themselves.
Tom Marshall: I think that pretty much covers it. It's definitely the overarching technical strategy or roadmap for a project as Andy said, and identifying the technology solutions within that. I think a big part of it is identifying opportunities within what the client is trying to do – pinpointing where good technologies could be applied to improve the solution we're offering. And also where there's opportunities to simplify what we're trying to do as an initial piece of work.
A lot of what we’re trying to do here is user-centred and led by user feedback. It’s easy to jump to complicated solutions and I think part of our role is trying to identify over complexity and steer the solution towards validating the assumptions in the product as early as possible. With the client-facing aspect of that, there’s a responsibility to manage the communication in both directions in terms of what we want to do and what the client wants to do, and communicating that back to the team. That requires taking complicated technical ideas and communicating those in a way that’s understandable. You’re being kind of a translation layer between them and the technical levels of detail.
Andy: I think the point about opportunities is an important one. Internally, we will have an idea of technologies that we're strong with, technologies that we want to get stronger with, and those that we are interested in using. So identifying areas in which you might be able to work with the client to both solve that problem and also branch out into areas that we wanted to be branching out into is important and there's an element of risk assessment that goes along with that. This is because we obviously want to make sure that we're doing things which are going to be deliverable and there's going to be a quality product at the end of it. So I think there's that level of risk assessment in terms of how out of the comfort zone do we want to go in service of a good product.
Both of you were in senior development roles before this. How did you find the transition from that to what you are doing now? And what made you want to make that change?
Andy: Not too much changed really, because I think we were both gravitating towards that sort of position on projects anyway. So stepping into this role was more of a formalisation, really. There was a definite increased sense of responsibility, but not too much change from my perspective.
Tom: I definitely agree with that. As Andy said, we were naturally gravitating towards those roles on projects anyway, but it wasn't something that was immediately broken out into a new role. It's helped to some extent in trying to make sure that we're sticking to those primary responsibilities of an SA ahead of development, whereas previously you got to do the development and it felt like we were picking up this stuff as well alongside of it. There's certainly a better conversation now internally with the Client Partners and PMs in terms of being more aligned and focusing on those primary objectives – technical, strategy and roadmap-type objectives. That's the primary work piece and then occasionally picking up bits of dev as necessary, rather than more of a 50/50 split.
So becoming an SA isn't necessarily a natural progression for a developer – you need a separate set of skills to development, and because of that, the SA role may not be for everyone.
Tom: Yes, I don't see it as a step up from Senior Dev or anything like that. It's a different role and a different set of responsibilities. I don't consider myself to be one of the best engineers that we have here. We have a lot of very talented engineers who like to focus on pure engineering work.
Andy: Yeah I totally agree with that. I don't think it should be seen as linear career progression. Looking at some of our most experienced engineers here, they're not in the Solutions Architect role because sometimes it's not the best utilisation of their skill sets. I think me and Tom are both the sort of people that really like that kind of ‘comprehensive domain overview’. There's a little bit of a controlling aspect to it as well, maybe. I enjoy talking clients though the tech, demystifying the engineering and architecture side of things. So I don't think it's something that every dev would naturally gravitate towards, because you do sacrifice the ability to say “I'm going to pick a certain area of development and become the best there is at it.” You lose that because you have to spread yourself across more things and you have to keep up to speed with more things. I don't want to say the whole 'jack of all trades' thing because I'd like to think you specialise in ‘specialising in everything’ if that makes sense. But you definitely have to make some sacrifices in order to do it, and there's certainly a valid career path outside of that.
Tom: Think of it kind of like a skills pyramid where the height denotes level of expertise and the width denotes breath of skill set. The SA role requires a broad pyramid, and we each have our peaks within that in terms of areas of expertise. A dedicated engineering role doesn’t require the same breadth, but a senior Ruby or React dev with multiple years of experience, for instance, would likely have a higher peak(s) in those areas. There's definitely a requirement for a genuine interest in business and talking to people, and that’s not necessarily required to be a ‘rockstar engineer’.
Do you get to do much hands on and if not do you miss that?
Andy: I still do quite a lot. It's a little bit different for me because I spend my day-to-day working on Sage. Within Sage I don't necessarily perform that same role. So I do still do quite a lot of hands on, and I think I'd always want to anyway. I'd be unsatisfied if I wasn't doing a lot of engineering work.
Tom: In comparison, I cover many smaller projects, and invariably it varies depending on the project and the team. Recently we've had an additional engineer added to Electro Rent, which has freed me up to do less development and get back to the strategy piece, and that’s been great. But projects aren't always resourced like that, and it does vary for me from project to project in terms of that split. Like Andy, I'd never want to lose it entirely but I'm probably more comfortable dropping more of it than Andy. I'm already doing less of it per day than Andy just because the nature of the product side of the business; there are many more meetings for me compared to Sage.
Andy: Ultimately, I think the changes we are making to the engineering team are really positive. We have the two of us, plus Nick and Andy now being a part of that team. I think it's a really positive thing that within our SA team you have people who share a common skill set but we also have specialists in certain areas (variety is always good). On top of that you have SAs who have different preferences for development/business split that Tom spoke about earlier. I think that's better for everyone.
Where do you find your satisfaction in the SA role? What makes you tick and what's a good day as an SA?
Andy: One that doesn't go wrong.
Tom: I really enjoy the challenge of the new stuff. When we get somebody coming in with a big idea, whether they’re a startup or big enterprise business, the fun is in trying to take that idea and then use our technology and team to build some amazing products for them. I like the challenge of "This is the vision, use technology together with the people that we have here to turn this into something better than expected." Which I think we do often. There's really strong work coming out the team at the moment on both the engineering and the product design side in terms of what we're delivering for people. I’m really proud of the direction we’re heading in and the quality of work that we're delivering.
Andy: I'd echo that massively. I think the best thing I get out of my job is still simply the tremendous amount of satisfaction in building something cool that works. I think that's a very powerful thing. If you're not addicted to that then engineering's probably not the job for you, because you have to go over a lot of hurdles to get to that point. But when you get there it's really satisfying, you get a buzz and you want to carry on doing it.
Tom: Yeah. We were all kids that liked Lego.
Andy: Exactly, yes. It is just mucking around in your bedroom. But seriously, I think with being a Solutions Architect, what I've felt more so than before is this tremendous sense of pride in the whole team. We’re often presented with a situation where the brief could just be a whole raft of potential technical challenges, and I think in our role we can look at those challenges and analyse them and say “Okay, well here's a solution that we think will be able to deliver a quality product within those parameters and with those considerations in mind.” But we don't then build that whole thing. There's a whole team that then has to execute the work, and I think the sense of accomplishment and pride that you feel in the team galvanising and getting together to produce a product that's great at the end of it isn't something I've necessarily felt before, and I think it's been really nice.
Previous READMEs:
PHP, AngularJS and a love/hate relationship with WordPress with Damian Boni
