What does a Systems Engineer actually do? We asked eight of them
Updated: 2 days ago
We asked eight systems engineers three questions at ASEC 2025. What do you enjoy about the job, what do you find hardest, and what would you tell somebody starting out. That produced 24 answers. None of them named a tool.
ASEC is the Annual Systems Engineering Conference, run by the Institute for Systems Engineering. IfSE is the UK chapter of INCOSE, has around 1,600 members, and is licensed by the Engineering Council to award professional registration. The eight engineers we spoke to came from BAE Systems, WSA, Matchtech, maritime defence and independent consultancy, and one of them was the President of the Institute itself. We interviewed them one at a time, so nobody heard what anyone else had said.
What they talked about instead
Requirements came up and so did verification, which is what you would expect from people who do this for a living. SysML, Cameo and DOORS never did, and neither did any standard or modelling language. What filled the 24 answers instead was conversations with clients who cannot yet describe what they want, with teams who have stopped listening to each other, and with stakeholders who assume an engineer holds authority they do not have.
Three languages on one programme
Charlie is a senior systems engineering consultant. Asked what she enjoys most about her work, she described sitting between the technical people, the project people and the commercial people, acting as a translator until everyone is working from the same understanding of what is being built.
When we asked what she finds hardest, she described the same thing again.
She talked about two teams who have been arguing for months. Both want the same outcome, but they describe it so differently that neither side has noticed, and her job is to get past the way each of them words its position and find the value sitting underneath, which usually turns out to be close to identical. She then said something you rarely hear from anybody that senior: she is trained in listening, she does it every day, and she still finds it hard.
That is a fair description of what the role is for. A systems engineer owns how the parts of a system fit together, and some of those parts are teams rather than components. An interface control document, the agreed written record of how each part talks to every other part, exists on most programmes for the hardware. Very few programmes have anything equivalent for the people, which is why the work ends up with somebody like Charlie.
You are the glue, and nobody trains you for it
Nintse Dan chairs the IfSE Early Careers Forum and works as a senior systems engineer in maritime defence. She described the systems engineer as the glue holding the system together, the person who ends up interfacing with every other discipline on the project, and then added that communication is one of the things engineers struggle with.
A graduate engineer is taught thermodynamics, control theory and materials. Very few are taught how to sit in a room with three teams who disagree and leave with one agreed requirement. That is what systems engineering capability means in practice.
Seven answers about people, one about technology
Adam Lancaster, Head of Engineering Capability for Systems Engineering at BAE Systems, gave the one technical answer to our second question. He talked about the difficulty of embedding new technology into legacy platforms, which is a real and expensive problem in defence, and one his own employer lives with daily.
Everybody else named people. They talked about managing stakeholder expectations, about getting colleagues on board with a concept when the schedule is already tight, and about talking a client out of a solution more complicated than the problem requires. Aiden Wood, Defence and Security Director at Matchtech, put it more bluntly: he loves people, and people are hard work.
Malcolm Thomas, Technical Director for Systems Engineering at WSA, put it in terms of restraint. The hardest part of his job is stopping the team over-engineering things, particularly when a client is pushing hard for something they have not yet worked out how to describe.
Where all eight agreed
Every one of the eight gave a version of the same answer. Be curious, ask questions, and do not be afraid to look stupid.
Nintse Dan was the most specific about why. Curiosity is what makes a systems engineer effective and what keeps risk down, and her words were that you have to be nosy and you have to investigate. Her practical version of that advice is to immerse yourself in verification activities and read the test specifications, because that is how you find out what a system actually does rather than what its documentation claims it does.
Charlie remembered being told early in her career to sit in the room and ask, on the grounds that the more senior people present are often afraid to ask the same question, so asking it helps them as much as it helps you.
Peri Mehmet, a systems engineer of ten years who now teaches for us, made the same point from the other side. The question you are embarrassed to ask is usually the one everybody else in the room is waiting for somebody to ask.
Emma Hay, a Systems Engineering Capability Engineer at BAE Systems, was blunter about what it takes. Nobody is coming to save you, she said. You will have to go out and find what you need, you will make a lot of mistakes on the way, and you should get a thick skin.
Those eight people work in defence, maritime, consultancy and recruitment, and between them they have decades of experience. They gave us eight different answers about what they enjoy and eight different answers about what they find hard. On what a junior engineer should do, they gave one.
So, what does a systems engineer actually do
They own the interfaces. Some of those sit between subsystems. The difficult ones sit between people describing the same goal in different language.
There is a cost to getting that wrong and it is well documented. A problem that costs about £1 to fix at the requirements stage costs roughly £10 by the time it reaches design, and £100 or more once the system is built and in service. Barry Boehm published those ratios in 1981 and programmes have been proving them ever since. The Littoral Combat Ship is the same problem at the largest scale. The GAO put it at over $60bn and no single component on it failed. The ship and its mission modules ran as two separate programmes, with nobody owning the interface between them.
The work itself is requirements, verification and integration. Whether any of it holds together depends on somebody noticing the boundary that has no name against it.
One thing to do this week
Before your next design review, write down the question you would normally keep to yourself. Then ask it. If you chair the review rather than sit in it, do the opposite. Count the questions in the minutes of your last one. If there were none, that was not agreement.
Requirements, interfaces and verification. That is where the job starts, and where SE 101 starts.
Comments