Can you describe your role as Chief Engineer and what it’s like being part of the Senior Leadership Team? 

My role as Chief Engineer is quite varied. A large part of my day is spent in meetings – whether that’s with clients or internal teams. I’m often reviewing plans, checking that people know what they’re doing and offering help where it’s needed, whether that’s on the technical side or the commercial side. I do still get involved in actual engineering too – though it’s more about approvals or reviews rather than hands-on delivery. I enjoy getting to see all the interesting and awkward bits of lots of different projects. It’s a bit like being a consultant – you’re exposed to a wide variety of work and that keeps things technically interesting.  

Another big part of my role is people development. I coach a team of four Senior Engineers and try to make sure they’re happy, progressing and heading in the direction they want with their careers. I also get involved in business development – sales, networking and bringing in work.  

Being part of the SLT is great. It’s a really good group of people – we get along well and play to each other’s strengths. Every so often we take time out of the day-to-day to think at a higher level, which is something I really value. It’s helpful to take a step back and reflect with others, not just on your own. 

What has your current role taught you about your leadership style? 

This role has helped me understand my leadership style much more clearly. I have tended to lead by example and take a hands-on, pace-setting approach – which works well in high-pressure or fast-moving situations, but is not a good way to develop other people. I’ve learned the value of stepping back and giving others space to find their own solutions – even if they approach things differently than I would, and have been trying to use this more. It’s been a rewarding learning curve, and I feel I’m becoming a more balanced and supportive leader as a result. 

Have there been any particular project highlights? 

There are loads of project highlights. My favorite project of all time is still the Leadenhall Building Automatic Fire Escape Hatch. It was the first big job I did and saw through at Eadon. I did a decent chunk of the work myself and it was quite a complex project. It wasn’t easy, but we got a really good result out of it. It was also just a really wacky, one-of-a-kind project! 

What’s a piece of advice you received early on in your career that’s stuck with you? 

One early piece of advice I got at Eadon was that less is sometimes more when it comes to communication. I used to write long, detailed emails explaining everything thoroughly, thinking that was the best approach. But I found that busy people often don’t read all of that and they’d end up surprised in meetings. That was one of the first bits of proper feedback I received – something I’ve always felt Eadon does well. It hadn’t occurred to me that my carefully worded emails weren’t achieving what I thought they were. Sometimes it’s better to just say, “We have a problem – let’s meet.” That advice – ‘less is more’ – has really stuck with me.  

What first inspired you to pursue a career in engineering? 

I only discovered that engineering was ‘a thing’ in my late teens.  I was interested in science and art and originally wanted to be an architect. But as I got further into it, I realised the artistic side wasn’t really where my strengths lay. My Mum suggested structural engineering as an alternative, saying it was a bit like architecture without the heavy emphasis on art. That sparked my interest, and once I started researching, I realised this was what I was always supposed to do!

I ended up doing a General Engineering degree at Cambridge which was brilliant. It gave me a broad foundation – from learning how computers work at the chip level to writing software and understanding mechanical systems. Even the parts that are totally peripheral to my role now I found really interesting.

Through that experience in my Year in Industry, I realised I wanted a career that offered more variety than traditional structural roles. I focused on structural civil engineering in my final years but also took modules in mechanical engineering as well. Since graduating, much of my work has actually been mechanical – so I’d describe myself now as a structural and mechanical engineer.

What do you think makes for a great engineering team?

I think a great place to start is Patrick Lencioni’s framework on team dysfunctions, which one of my colleagues adapted to talk about functional teams. So, you need trust; the ability to engage in constructive conflict; holding each other accountable and focusing on collective results, not just individual success. That applies to all teams, not just engineering. But specifically for engineering, I think having a good mix of people is key. Some might be more academic and able to do complex maths when needed – and others have deep practical experience, ensuring our designs are buildable and usable in the real world. At Eadon, we’ve got that spectrum covered, and I think that versatility helps us tackle all sorts of projects.

How do you approach problem-solving? Do you have a set process?

I think I do have a set process, even if I wasn’t fully conscious of it at first. A while back, I helped formalise Eadon’s approach to projects, and a lot of it was based on what I was already doing. We framed it as: ‘Understand, Decide, Deliver.’ 

• Understand: Really figure out what the problem is. Sometimes the initial question isn’t the right one or the constraints aren’t as fixed as they seem. You need to challenge assumptions and start sketching out what a potential solution might look like. It’s also the time to identify the big unknowns or risks.

• Decide: This is where you make the key engineering decisions and firm up the design.

• Deliver: Then you document it all. By this point, the decisions are made, and it’s just about producing the necessary outputs. 

Personally, I tend to start with rough calculations based on a mental image of the solution. Other people might start with CAD models or sketches and work out the calculations after. So we take different paths, but usually end up in a similar place.

I think the key is spotting the big risks early – such as checking if an existing structure can support what you’re planning to attach to it. If not, the whole concept might need to change. Better to catch that upfront than redo everything later.

What’s your favorite thing about your job and engineering in general?

I’m going to cheat and say two things! First, the team of people I work with. Second, the projects we get to work on. Those are the main reasons I enjoy my job.

As for engineering in general, I like that it adds real value. It’s a profession where you can make a genuine difference and a tool that can be used for good. It’s also intellectually satisfying. There’s a mix of academic theory and practical problem-solving. You get to apply what you learned in university to solve real-world problems that couldn’t be tackled otherwise.

If you could solve any real-world problem using your engineering skills, what would it be?

Climate change would be the big one. I don’t think anyone could solve climate change alone with their engineering skills but I think being able to contribute to the development of practical fusion energy will be essential to addressing it. Even if we meet most of our energy needs with renewables – which is uncertain – we’ll likely need even more energy to remove carbon dioxide from the air and that’s going to need an awful lot of energy and I think, without wiping out enormous areas of wilderness, nuclear fusion needs to be part of the mix.