What Does a Space Systems Engineer Do?

There is a particular moment in almost every spacecraft programme when the engineering problem stops being about any single component. The payload works. The avionics work. The flight software works. The power system works. The communications system works. And the spacecraft still has to work, as a whole, and that is where systems engineering earns its keep.

A systems engineer looks across the boundaries between disciplines. They ask whether the pieces actually fit together, whether the requirements describe the right thing, whether the architecture can deliver the mission, and whether there is enough evidence to demonstrate that the finished spacecraft does what it is supposed to do. It is one of the broadest technical disciplines in the space industry, and, in our experience, one of the easiest for candidates and hiring teams alike to misread on a CV.

What systems engineering actually is

ESA describes systems engineering as the process of designing, developing and verifying a space system as an integrated whole that fulfils the mission within acceptable technical and programme constraints.¹ That definition is worth sitting with, because the systems engineer is not necessarily the person designing every subsystem. They are making sure the overall system makes sense: what orbit does the mission need, what payload does it require, how much power will it consume, how stable does the spacecraft need to be, what thermal environment will it see, what communications architecture is required, what does the ground segment need to do, and what happens if something fails. Those questions cross traditional engineering boundaries quickly. That crossing is the job.

Present across the whole lifecycle

Systems engineering begins before most people would think of the spacecraft as a spacecraft at all, often when the team has little more than a mission objective. From there, it helps translate that objective into a technical concept, touching mission needs, concept of operations, requirements, architecture, trade studies, interfaces, subsystem allocation, design, integration, verification, validation, operations and eventually disposal or end of life. On a small spacecraft, one engineer may cover a remarkably broad slice of that list. On a major programme, systems engineering becomes a large discipline in its own right, with specialists in requirements, architecture, interfaces, safety, verification and configuration.

Requirements engineering: where the discipline actually starts

Good systems engineering starts with good requirements, which sounds simple and rarely is. A weak requirement can create years of downstream confusion. A useful one is clear, necessary, testable or otherwise verifiable, traceable and consistent with the rest of the system, and NASA’s own systems engineering guidance explicitly links requirements to their eventual verification approach, including analysis, inspection, demonstration and test.² A good systems engineer is already thinking about verification while writing the requirement, not afterward. A useful habit we see in the strongest candidates is asking, at the moment a requirement is drafted, how anyone will prove it is true. If nobody in the room can answer that, the requirement usually needs another conversation before it goes any further.

Architecture: where the trade-offs become real

Once the mission needs and requirements are understood, someone has to decide how the system will actually achieve them, and that is architecture. Do you use one sensor or two? How much redundancy? What orbit, what processor, what communications link, how much onboard autonomy? Should a function live onboard or on the ground? There is rarely a clean answer to any of these. The job is understanding the trade, and being able to explain why one was made over another.

Interface management

A spacecraft is, in a very real sense, a collection of interfaces: mechanical, electrical, thermal, data, software, operational and organisational. A large share of integration problems are not caused by one subsystem being badly designed. They happen where two perfectly reasonable subsystems meet, and their assumptions do not quite line up: the flight software expects one data format while avionics provides another, or the GNC algorithm assumes a sensor update rate the hardware cannot reliably sustain. This is why interface management is such a valuable systems engineering skill, and why the systems engineer is so often the person asking exactly what passes across a given boundary, and who owns it.

Verification and validation are not the same question

Verification asks whether the system has been built correctly against its requirements. Validation asks whether the right system has been built for the mission and its stakeholders in the first place. NASA’s software engineering guidance draws the line explicitly: verification concerns producing the product correctly, while validation concerns confirming that the right product is being produced.³ You can build something perfectly against the wrong requirement, and you can also satisfy a requirement on paper that never produces a useful mission outcome. Systems engineers sit close to both questions at once: does it meet the specification, and does the specification actually describe what the mission needs?

Systems engineer versus systems architect

The titles overlap, though the emphasis can differ. A systems engineer often carries responsibility across the lifecycle, spanning requirements, interfaces, integration, verification and technical coordination. A systems architect tends to spend more time on the structure of the system itself: how functions should be divided, where responsibilities should sit, and what trade-offs should shape the design. In practice, experienced systems engineers usually do a good amount of architectural work, and experienced architects need solid systems engineering fundamentals underneath them. The two disciplines are close cousins rather than separate species.

MBSE is changing the job

This is where Model Based Systems Engineering enters the conversation. Traditionally, systems engineering has been heavily document driven, with requirements in one place, interface descriptions somewhere else, architecture diagrams in another document, and test results elsewhere again. The problem becomes obvious as systems grow: you end up with many descriptions of the same system, all of which need to stay consistent with each other. ESA has been pushing MBSE for over a decade for exactly this reason, aiming to improve digital continuity across the mission lifecycle and supply chain as space systems become too complex to represent reliably through documents alone.⁴ The model becomes a structured representation of the system, not simply another diagram to keep in sync.

What we look for in a space systems engineer

A strong candidate might bring experience across requirements engineering, system architecture, trade studies, interface management, verification and validation, configuration management, risk management, integration, mission operations, MBSE and cross disciplinary engineering. We would still be cautious about turning that list into a checklist. The best systems engineers we have placed are simply curious. They ask why. They want to understand the payload, the software, the power budget, and what an operator actually does at two in the morning during an anomaly. That curiosity tends to matter more than another certification.

The defining skill is the ability to see the whole machine without losing sight of the detail. A systems engineer needs enough depth to challenge a specialist, and enough breadth to understand how that specialist’s decision affects everything else.

Why this discipline matters so much on complex programmes

That combination, depth and breadth held at the same time, is genuinely difficult to find, which is exactly why experienced systems engineers become so valuable once a programme grows past a certain complexity. The systems engineer’s job is simple to describe and hard to do: make sure the spacecraft works as a system. Almost everything else in the discipline exists to make that one sentence true.