Katy Ryder, June 25, 2021
From engineering to operations, Meet the Appvians is a series that shines a spotlight on the people behind our products: What they do, what they enjoy outside of work, and how they’ve experienced life at Appvia.
This time, we caught up with Mark Hughes, Appvia’s Product Engineering Lead on how Appvia Wayfinder, as well as product engineering principles, have evolved during his time with the company.
Mark, can you first give a brief overview of what it is that you do at Appvia?
So my title now is ‘Product Engineering Lead’. Myself and Rohith, who is also an Engineering Lead at Appvia, head up the engineering of Wayfinder, working to align the dev team and drive the product forward.
Yes, congratulations on your recent promotion! Can you give some background on what you were doing before?
Just over a year ago, in early 2020, I started as a Senior Engineer on the product team. Originally, my role was very much developing and shaping the product. As time has progressed, I moved into more of getting the process right and lining stories up in the backlog — things that act as glue between product and development.
I came in from a development background, leading on big corporate IT projects. It’s very different from coming into a startup and building a brand new product, and Appvia is my first-ever startup!
Before landing here, I spent thirteen years at the London Stock Exchange Group (LSEG), which is also where I met Lewis (Marshall – Appvia Tech Evangelist). He was my original link to Appvia and persuaded me to get on board and try start-up life.
Other than Lewis, what drew you to Appvia?
For me, it was the attractiveness of the problem we’re trying to solve.
Having seen it from the big corporate IT perspective, at the other end of the scale on how you consume these things; it’s really complicated and everyone ends up engineering solutions themselves. In a big company, you shouldn’t all be engineering your own solutions to these things.
There’s a lot of repetition. Every company is doing the same thing. Sometimes every team does the same thing. And engineering solutions to these problems doesn’t make their businesses any money. It’s not their business to engineer cloud services and work out how to get Kubernetes.
So it felt like we were solving the right problem here at Appvia, in a way that lots of companies can use one set of engineering practices to solve it well — let us concentrate on making the product that does that. And then the businesses that we’re serving can concentrate on solving their business problems rather than their infrastructure problems.
That and getting involved in new, interesting technologies like containers and Kubernetes were what drew me in.
The interesting problem and interesting technology are coming together for the solution that we’re engineering right now with Wayfinder.
Were you living out some of those ‘problems’ in your previous roles outside of Appvia?
Yeah, absolutely. I’m a testament to these problems existing, for sure. As part of being a lead engineer, leading software solutions, I always ended up having to get involved in the infrastructure side, always having to get involved in the security side, always having to get involved in the network side, storage side etc…
I found that you had to wear all these different hats to make a solution work. Other development teams around me had projects that weren’t succeeding because people weren’t getting involved in all those things. So you could clearly see how, if you don’t have someone who’s prepared to get involved in all of those things, you can end up boxed into a hole and not actually be able to deliver your project.
So that’s how I lived it, I’d see projects I was on succeeding because we were having to do a lot of work across all these different things to bring those threads together. And other ones failing around me because they weren’t able to do those things for whatever reason. It was challenging. You shouldn’t be a ‘unicorn’ if you manage to get a project to production.
These problems are the same at all big companies. And if we can solve those, we’ll be good.
It sounds like this really primed you to come in here and work on a solution to these problems?
My approach to software development is to empathise with the user. What do they know? What’s the problem they’re trying to solve?
The product [Wayfinder] first started off quite complex. The user had to know quite a lot to use it, and that experience doesn’t really meet that requirement for me. I want to make things uniform and understandable and allow the user to help themselves. They understand what they’re doing and they understand why, and they can always find out more details if they need to.
So a lot of work we’ve done in the last year was to add new features, of course, but also making those features clear and understandable for the users. There’s always more you can do, but we’ve made some concrete improvements to that.
For example, you learn a way of working that applies to all of the clouds, rather than having to learn three different ways of setting up each of the three clouds that we support. And that’s just one example.
Just to take a little step back, can you give some insight into how the Engineering team works?
Over the last few months, we’ve formalised our process. Before, the team was very small so we just picked up stuff and did it. We started to realise we needed a bit more process as we grew, but we’re still trying to keep it light.
It certainly takes some time as you try different things, but when you get that process right you’ll end up with a really effective workflow. And it’s not the same for every team. My experience with previous teams is that when you get the right mix of people and processes, and all of a sudden the team can start delivering really rapidly. That’s what we’re zeroing in on.
And what else do you think makes a solid engineering team?
For me, one of the most important things in engineering teams is having a diverse set of people, with diverse experiences. Because if you get a bunch of engineers who have all used the same technologies in the same way and went to the same sort of universities, they all tend to think the same way.
They don’t think out of the box, they don’t approach problems in different ways or have discussions. A good team has discussions of differences, rather than someone just saying, ‘this is how we do it.’ Different angles that people take informs the product and makes it better.
Our team is full of opinionated people but also we all listen to each other, which is rare in my experience. A team that can cover that breadth of experience and also can accept other people’s viewpoints and actually factor those in ends up with better solutions.
Do you have an example of how that’s worked really well?
A good example is, we’ve recently changed the way we deal with accessing cloud accounts within the system. It used to be that each one had an independent set of code for how we talked to that cloud. And then we built a general structure for how we talk to all clouds. So it’s generalisable and shared. And with that process, there was a lot of input from the different people in the team. There was the initial idea that we needed to generalise this. And then someone else was like, “hang on, you haven’t considered that we need to do it like this, we need to have this angle on it.” We had a lot of conversations to evolve the solution, with input from a host of really good quality engineers. In having those types of open discussions, you evolve the solution into something much better.
This solution met not only the need to generalise the cloud account thing but also started the conversation about how we do Least Privilege in the product, which is a different problem. But because we had that open conversation, we’re now able to solve both problems using the same set of code. So the same structure of openness and combining expertise springboarded the next piece of work we’re working on.
You’ve given us such a good insight into how the team works and what’s next! Before we wrap up, I have a few questions that I like to throw into each ‘Meet the Appvian’.
First up, which Appvia company value do you resonate with the most?
If I had to pick one, I would, I would say empathy. Empathy with the problem, and the users that we’re doing this for. You don’t develop software in a vacuum, the whole point is to solve a real problem a real user has while being empathetic to their needs. I think that’s key to delivering good software.
I think also the candour within the team is a key one that also plays into what I previously mentioned about a good engineering team. We’re prepared to have candid, frank discussions in order to further develop the product.
It’s hard to pick one, isn’t it! I totally agree. Okay so onto another fan favourite question: What does your desk look like?
It’s clean and tidy about once every three months, and then slowly gets covered in stuff. I have some pottery that we made as well as the terrarium (also from an Appvia event). I will say I can’t live without two monitors. So I do have a nice second monitor setup because I feel like my arms are cut off if there is only one screen.
And you have your bikes behind you, can’t forget that! Last question here: Do you have a favourite work song? Something that hypes you up?
Whatever Spotify Daily Mix recommends for me, which is usually a sad indication of whatever I’m listening to at the moment. A combination of French Pop and Les Mis … not sure I want to admit to that!
We’re looking for talented and passionate people to join our growing team in London and beyond —. check out all of the current open roles. To learn more about Mark or find out more about the growing Engineering Team, connect with him on LinkedIn.
