What was your path to Gearset?
“I studied Computer Science at the University of Cambridge followed by a PhD specialising in the theory of secure programming languages. After this, I moved away from academia and started a career as a software engineer. I spent a little over 7 years at another engineering firm in Cambridge before making the move to Gearset, where I’ve been for just over 4 years.”
What made you decide to join Gearset?
“I started struggling to progress with my previous employer in terms of my personal development, and I wanted to focus on my desire to work with newer technologies. When I started to look for other opportunities, I was put in touch with Gearset via a third-party recruiter.
After going through the interview process, I felt like they’d be a great company to work for — the fast rate of growth Gearset was (and is) going through yields so many opportunities to progress.
Everyone I met during the interview process was very friendly, it made me feel like it was a very collaborative company and after working here this long, I can definitely say that it is!”
Can you tell us about your journey as an engineer at Gearset?
“I started at Gearset as a Software Engineer in one of the product teams. Initially I had a range of tasks to introduce me to various bits of the Gearset infrastructure and codebase, before I moved on to a larger project to improve how we handle scheduled jobs. Around 9 months into the role I started line managing a new starter, and shortly after I split out to lead a separate engineering team.
From there, I had to learn to balance time spent on “my” projects, and time spent helping or providing support to members of my team or ensuring they have enough work in the pipeline to keep us busy without feeling overworked.
My interests lie more on the infrastructure/architecture side of software development, so over time I started to align my team more with that sort of work. We’ve now moved away from product work in order to dedicate engineering time to improving the infrastructure and other non-product-facing features, without having product requirements competing for time.”
What has been the biggest challenge you’ve faced moving into your current role?
“Prior to joining Gearset, I hadn’t had any experience managing another person. Although I feel that’s the greatest challenge I’ve had, there was a lot of support here in different forms to build those skills to be a great manager.
I had an internal mentor who already had line management experience, so they could really help with specific situations that cropped up. Also, all new managers at Gearset are put through an external training course to give us many tools that we can use for things like running effective 1-1s, helping our team members grow into their role, and tackling any trickier problems that might occur.
The constant feedback culture that Gearset has was really beneficial here, too — my team members gave me direct feedback about how things are going — both positive and constructive — to help me grow and support them even more.”
How have you grown as an engineer at Gearset?
“One of the hardest things as an engineer is the ability to decide what’s the most important thing to be working on at any given time. From day one at Gearset, there are times when you have to make a decision between, say, continuing with product work, or picking up an issue that’s just been reported to us and working to fix that for the customer. Making that sort of decision isn’t always easy, and after moving into a Team Lead role, this became even harder as you now have to balance work for the whole team rather than just yourself. Having clear company, department, and team goals really helps to combat this, which Gearset does very well. It helps us prioritise what’s the most important job to be done (JTBD) — this is one of our Gearset values and is part of everything we do.
It’s natural as you become a more senior developer that you become the “expert” in one or more areas of the codebase. The risk here is then you’re the “go-to” person for changes in that area, you then end up making those changes, and the cycle continues. It’s important to recognise these situations and ensure that you collaborate with other developers to help spread the knowledge. Even if this would take more time in the short-term, in the long-term this leaves the team in a better position.
Encouraging collaboration between team members is another important skill that I’ve learnt at Gearset. It’s all too easy to say “this is a one-person task” when working in the codebase. But by pairing or group-coding you get several benefits, such as: having more eyes on a single problem so more edge-cases can be spotted, and helping to teach more junior developers how to approach larger problems and break them down into manageable chunks. It also helps to foster a closer team if everyone can feel like they’re contributing to the main task at hand.”
How do you engage your team?
“One of the most important things to be aware of as an engineer is knowing when to stop working on a given feature or change. No piece of code is ever perfect, but if the solution that covers 90% of useful cases is good enough, then we don’t need to worry about working harder to finish the remaining 10%. Instead, we can use that time to make another, more impactful change to the codebase. From day one, I encourage my whole team to speak up if they feel like we’re doing something “for the sake of it”, or if they can think of an easier way to achieve the outcome we’re going for.
In addition, when we look at longer-term (quarterly) plans, I always put together a draft and then ask for feedback or suggestions, as there might be other important things that I’m not aware of that we should do instead. It’s very much a team effort to work out what to do next and how far we need to go with each piece of work.”
What skills do you think make a great Senior Engineer?
“There are a few key skills that I think are really important for someone looking to be a great Senior Engineer:
- Knowing when something is “done” — as mentioned above, it’s all too easy to get bogged down in unnecessarily complex edge cases, and quite often a solution that tackles the main points is all that’s required to provide value to the user.
- Become a “go-to person” in one or many key areas — you should gain an in-depth knowledge about parts of the codebase, and as a Senior Engineer you should be approachable and provide time to help people with any questions they may have.
- Be happy to help mentor and/or coach more junior engineers — whether this is helping to onboard new hires, or pairing with engineers on certain problems to show them how to tackle something or use a particular technology, rather than just doing it yourself.
- Know who you’re communicating with and tailor conversations appropriately — when you have a significant amount of knowledge about a subject, it can be easy to assume people you’re talking to have similar levels of understanding. However, if you’re discussing how best to fix a problem, you may not want to go into really technical details if dealing with a customer who lacks knowledge about software architecture, for example — they just want to see the end product. Conversely, when talking to another engineer you may wish to dig a lot deeper into what would be “best” from a technical perspective.”
What’s the best and worst part of your job?
“I think the best part about being an Engineering Team Lead at Gearset is being able to shape the role and your team into what best suits you and them. Each team, and each Team Lead, has different strengths and weaknesses, and by not having a set formula for each team, Gearset lets us figure out the most effective way to work.
For me in particular, I’ve been able to alter the things my team works on to be more infrastructure-based (ensuring that each team member is happy with this along the way, too). In addition, I have a keen interest in product management, so I’m starting to pick some of that up in relation to the technical/architectural backlog of work we have planned.
The most challenging/worst part of the job is ensuring time is balanced sensibly. It’s important to ensure each individual person has enough support with their work and learning/development without feeling micromanaged, and also ensuring that I have enough time left to work on technical problems myself.”
What is one thing you’d like to learn, develop, or work on this year?
“I’d like to get even more exposure to some of our infrastructure, especially around the Kubernetes setup we have and how everything integrates together. That knowledge has to be gained by “doing”, though — by being in an infrastructure team, there’s plenty of opportunity to work with the nitty gritty details about Gearset, and learn at the same time.”
What’s the best piece of advice you’ve received?
“Take time to bring others on board with what you’re doing rather than forcing ideas upon them. It’s much easier to work towards a common goal if everyone is on board with it, rather than just saying “this is what we’re doing”, even if the outcome is the same either way. The little bit of extra time to bring people around to your way of thinking is invaluable, and at times they may spot holes in your plans that you hadn’t seen in the first instance.”
