Meet the Appvians: Mark Hughes, Product Engineering Lead

Table of Contents

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?

screenshot 2021 06 27 at 10.14.41 pm

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! 

COULD YOU BE THE NEXT APPVIAN? 

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.

About Appvia

Appvia enables businesses to solve complex cloud challenges with products and services that make Kubernetes secure, cost-effective and scalable.

Our founders have worked with Kubernetes in highly regulated, highly secure environments since 2016, contributing heavily to innovative projects such as Kops and fully utilizing Kubernetes ahead of the curve. We’ve mastered Kubernetes, and experienced its complexities, so our customers don’t have to. 

Share this article
Twitter
LinkedIn
Facebook
profile-112x112-crop-1
Katy Ryder
Demand generation manager
I originally hail from Austin, Texas but now call London home. When I’m not crafting content, you might run into me at a coffeeshop (there’s always room for one more latte), hiking through Hampstead Heath or snapping street style photographs.

The podcast that takes a lighthearted look at the who, what, when, where, why, how and OMGs of cloud computing

Related insights

Managing Kubernetes Secrets with HashiCorp Vault vs. Azure Key Vault Keeping secrets secure...
Namespaces are a vital feature of Kubernetes. They allow you to separate uniquely named...
DevOps teams have rapidly adopted Kubernetes as the standard way to deploy and...
Once you start working with Kubernetes, it’s natural to think about how you...
Self-service of cloud resources Kubernetes has been brilliant at delivering an ecosystem for...
Pods, deployments, and services are just some of the concepts that you need to understand in...
Last week I published a blog, “How to spot gaps in your Public Cloud...
Breaking down the core areas that you should be aware of when considering...
5 tips to help you manage more with less Not every manager of...
Public cloud has provided huge benefits in getting infrastructure and services to people...
This is the story of how three Appvia Engineers contributed so much to...
Overview The UK Home Office is a large government organisation, whose projects and...