Welcome to the eighth installment of Tech Team Talk!
Tech Team Talk has so far brought voices from across the software ecosystem: engineering, data, product, program, leadership. Each one looking at familiar dynamics from a different seat.
This piece does something different: it steps outside the software world entirely.
Introducing Jennifer Hughes
I’m really pleased to welcome Jennifer Hughes to Tech Team Talk, thank you for being here!
Jennifer is General Manager of Transicon, a long-established automation firm working in mechatronics. She’s also been a long-time reader of TIE, which is part of how this piece came about.
What drew me to Jennifer’s perspective is that mechatronics has been wrestling with the challenges software leaders face today: rapid technological shifts, legacy system complexity, the pressure to deliver integrated and reliable solutions – for decades. In her field, multidisciplinary alignment isn’t optional, it’s the foundation for delivering anything at all. The leadership lessons, it turns out, are remarkably transferable.
It’s a cross-disciplinary masterclass. The problems software teams face aren’t unique, and the solutions might be hiding in the disciplines we rarely look at.
Now over to Jennifer!
What Software Leaders Can Learn from Mechatronics
I’m a General Manager in mechatronics. The discipline where mechanical, electrical and software engineering meet.
When we shut down a factory to install a system, there’s no rollback. No patch. No second attempt. It has to work, first time. That constraint changes how you think about engineering. Not just the technical work, but the way teams operate, communicate, and take responsibility.
It looks different from software on the surface. But the more I talk to engineering leaders across disciplines, the more I notice we’re navigating the same terrain:
Rapidly changing technology,
Teams that span generations and skill sets,
Customers who don’t always understand what they need until something goes wrong,
And the relentless pressure to modernise without losing the people who make the business what it is.
If you lead a software team, most of what follows will feel familiar. The stack is different but the gaps are the same.
The gap nobody planned for
When you run multidisciplinary teams, the work that falls between people is the work most likely to go wrong. Not the work anyone is responsible for, that gets done. It’s the work that sits in the overlap, the handoff, the thing everyone assumed someone else had covered.
We learned this on a project some years ago. The control panel was built. The software was written. The machine was mechanically complete, sitting in our workshop, ready for site. Then everyone looked at each other. The machine cabling (something we’d always done on site) hadn’t been assigned in the schedule because it sat between disciplines. Two weeks added to the programme, just like that.
We called it minding the gaps, and it became a principle we’ve built into how we work since. At every stage of a project we now ask: what exists between the things people own? Who picks that up? We introduced more formal project reviews, and for larger work we brought in dedicated project managers rather than loading that responsibility onto the engineers alongside everything else.
The equivalent in software is everywhere: the feature that sits between two squads, the security requirement assumed to be someone else’s problem, the deployment step that dev thinks ops owns and ops thinks dev owns. The gap doesn’t care whose responsibility it was supposed to be.
Stewarding a company through rapid change
I’ve been with Transicon for thirteen years. In that time, the nature of what we do has changed more than in the previous three decades combined.
When I arrived, we were doing work for a loyal set of manufacturing customers. But we were delivering control and automation systems without much of the integrated technology we now take for granted. What we do now – networked industrial systems, real-time data integration, digital twin testing, cyber-secure OT infrastructure – would have been unrecognisable to the business I walked into.
I didn’t plan to steward a transformation. Nobody does. You just look up one day and realise the ground has shifted, and you’re responsible for helping people cross it.
A large part of what we do is legacy upgrades: taking a customer’s old industrial software system, understanding its underlying process deeply, and rewriting it for modern hardware within tight production windows. The machine still has to do exactly what it always did. The process has to be translated faithfully before it can be improved.
You cannot modernise what you don’t first understand. I think about our own company the same way. You can’t whitewash a department with new technologies and expect it to function. The legacy: the experience, the craft, and the institutional knowledge is load-bearing. Any genuine upgrade has to be built on top of it, not in place of it. Software engineers navigating the same tension with their own legacy codebases will recognise this immediately.
Managing external change
The clearest example of external change forcing internal change is cyber security. We’d been advising customers on operational technology security for years before most of them took it seriously. Then a major cyberattack hit the UK automotive supply chain with an economic impact running into hundreds of millions of pounds, and everything changed overnight.
What people hadn’t grasped is that compromising an industrial control system isn’t like stealing data. Gain access to the controller for a production machine, adjust the tolerances fractionally, and you could scrap millions of pounds of product before anyone notices. The ransom cost is often the smallest part of the damage.
Overnight we needed networking specialists we hadn’t previously employed, customers who felt they were paying more for the same system they’d always had, and our own engineers thinking differently about the systems they were designing. That’s three simultaneous change programmes inside one business, while still delivering projects on time.
What that period taught me is that you can’t manage change by announcement. You manage it by showing people what it means for their specific work, in language they already understand.
For customers, that meant translating cyber risk into production risk, language they’d been fluent in for decades. For our engineers, it meant framing new skills as an extension of what they already did well.
How to help your team through change
These are the four things that have made the most practical difference for us.
1. Don’t expect everyone to change at the same pace
We have engineers who have been doing this for decades. Their knowledge is load-bearing in ways that don’t always appear on an org chart. When things go wrong on site, and they do because drawings don’t capture everything in a physical world, it’s the engineers who’ve been there before who make the difference. You cannot replicate that with new tools.
We run the apprenticeship programme deliberately for this reason. Early-career engineers bring comfort with emerging technologies and a willingness to question assumptions. Experienced engineers bring hard-won judgement and the kind of calm under pressure that only comes from having been there. Neither group has the full picture. Together, they do.
The newer engineers lead the charge on what’s coming; the experienced engineers know what the theory won’t tell you.
2. Be honest about what you don’t know
There is a corporate habit of expecting leaders to project certainty. When I started saying ‘I don’t know, what do you think?’ rather than reaching for an answer I didn’t have, two things happened: I got better information, and the team felt trusted.
Those two things compound over time. ‘I don’t know’ is one of the strongest things a leader can say. It signals confidence, not weakness.
3. Ask constantly: should it be me doing this?
This is the one I’d push hardest on.
Not as a way of avoiding difficult work, but as a genuine question about whether holding on to a task is actually serving the team. When a leader does everything, the team stops growing.
I spent too long thinking it was faster to do things myself. It was, in the short term. The cost was a team that had learned to wait for direction rather than act from initiative. Rebuilding that trust in people’s own judgment takes far longer than delegating well in the first place.
4. Resist the pace of change becoming the point
There is a corporate FOMO that grips businesses, the feeling that if you’re not adopting everything new at full speed, you’re falling behind.
When Industry 4.0 and the Internet of Things became buzzwords, some of our engineers looked at each other and said: we’ve been doing this for twenty years, we just didn’t call it that.
Ground your team in what they already do well before adding what’s new. It makes the new thing far less threatening, and it reminds people that their existing skills still have value.
Managing with kindness is a business strategy
We have low staff turnover. In a sector with a genuine skills shortage, in a discipline where experienced engineers are hard to hire, that is one of the most valuable things I can point to. It comes from a culture where people know they will be looked after.
A while ago a new engineer joined us, experienced, talented, clearly good at what he did. One day he was justifying something to me that didn’t need justifying at all. I said as much. He paused and said: ‘I’m sorry. I’m just not used to people treating me decently.’
Engineering can be a high-pressure environment. The stakes are real, the timelines are tight, and when things go wrong on site, people feel it. It’s easy for culture to drift towards harshness when the pressure is on. But an engineer who is anxious, under-trusted or exhausted does not do their best work. They make mistakes. They leave. And the knowledge they take with them when they go is not easily replaced.
Managing with kindness doesn’t mean avoiding hard conversations or tolerating poor work. It means respecting people’s skills, being honest with them, giving them room to grow, and treating their wellbeing as a business concern rather than a HR formality. Those things are not separate from performance. They are what performance is built on.
Burnout is a leadership responsibility
I came from a culture that glorified long hours. There was a version of me that genuinely believed if the spreadsheet wasn’t balanced by 10pm, the world would end. I was seduced by that mindset for longer than I should have been. The hero complex is real, and it’s corrosive.
Projects have peaks and troughs. The initial design phase is intensive: full cognitive load, blank sheet of paper, problems that have never been solved before. Then there’s a quieter period while components arrive. Then commissioning on site, which is intense again. We try to use that rhythm deliberately. During the quieter stretches, we let people recover. We don’t expect anyone to manufacture urgency when there isn’t any. We don’t celebrate overwork.
For leaders in the middle – managing upward to the business and downward to the team simultaneously – the pressure is particular. You are carrying two sets of expectations, and the temptation is to absorb both rather than push back on either. The advice I’d give anyone in that position: put your own oxygen mask on first. You cannot sustain a team through change if you’re running on empty, and the people who depend on you need you to be functional more than they need you to be heroic.
The same question applies here as everywhere else: should it be you carrying this? Some of it should. Some of it belongs elsewhere. Learning to tell the difference is one of the most important things a leader can develop.
What getting it right makes possible
At our core, we are the people who help the people who make things, make things. That hasn’t changed. But what we’re capable of making possible has.
Thirteen years ago, Transicon was a business with a loyal customer base and an appetite for risk that was, understandably, fairly conservative. What I’ve watched happen as we’ve grown the team, built the culture, and held our nerve through change is a gradual and then quite dramatic expansion of what we’re willing to take on.
We now work on projects I couldn’t have imagined pitching when I arrived. We have supported the BIFoR FACE experiment, the Birmingham Institute of Forest Research’s Free Air Carbon Dioxide Enrichment facility in a Staffordshire woodland, one of only three such experiments in the world and the only one in the Northern Hemisphere. The facility pumps elevated CO₂ around mature oak trees to simulate 2050 atmospheric conditions, generating data on how forests respond to climate change.
We’ve recently had a team return from the Amazon rainforest. Where we supported AmazonFACE, a Met Office-backed international research programme running equivalent experiments in the Brazilian Amazon, one of the most critical and vulnerable ecosystems on the planet. It is genuinely extraordinary work to be part of.
We sponsor dendrology kits (BIFoR in a box) so that schoolchildren can take part, measuring trees and observing environmental change firsthand. We do our own STEM bits in schools to inspire the next generation of engineers.
It is not what you might expect from an automation engineering company. But it is what becomes possible when the business has the confidence, the capability and the stability to say yes to things that are genuinely difficult.
That’s the payoff for getting the people side right. Not just retention numbers or reduced recruitment costs, though those matter. It’s the expanding capacity to say yes to work that is more complex, more ambitious, and more meaningful than what you were doing before.
The gaps are the same, whatever your stack
Mechatronics and software engineering look different on the surface, and they are. The terminology, the tools, the specific failure modes – all different. But the leadership problems are universal:
Managing change without losing your people
Building teams that span experience and expertise
Creating cultures where people can say what they don’t know
And protecting your team from burnout while still delivering.
The technology will keep changing, in our world and in yours. The answer isn’t to chase every new thing, and it isn’t to resist change until it forces itself on you. It’s to build a team stable enough and trusted enough to meet change without being destabilised by it. That starts with minding the gaps in your projects, in your culture, and in yourself.
Thank you
Thank you to Jennifer Hughes for sharing your perspective and insights with Thriving In Engineering readers!
If you want to find out more about Jennifer, head to her LinkedIn page: Jennifer Hughes | LinkedIn.
Want to add your voice?
Tech Team Talk is shaped by the people building, supporting, and collaborating around engineering every day. If you have a story, reflections, or perspective that could help others better understand this ecosystem — I’d love to hear from you.
You can reply to this post or get in touch: contact@thrivinginengineering.com
Two points really stood out to me. Sometimes rollback is simply not a practical option, and unforeseen problems often show up in the overlap between work people clearly own.
I worked at a company that built shipping software that had to be deployed on customers’ POS equipment. Arranging deployment time across those locations was extremely costly for the customer, so a rollback was something we worked very hard to avoid. It changed how carefully we had to think about readiness before deployment.
I also really like the practice of explicitly asking: what sits between the things people own, and who owns that? Those overlaps and handoffs are often where the problems nobody anticipated show up.