This comes up occasionally. Plenty of small companies insist that they understand the need for the Systems viewpoint (great!) and that they’ve got it covered because their CTO or another senior engineer can cover it (not so great).
Let’s look at why this notion is generally misguided.
Systems isn’t In Charge
There’s a misconception about Systems Engineering for small systems (and by “small”, I mean things that aren’t airports, railway systems, planes, modern cars or power stations). It is often assumed that the Systems role is, de-facto, in charge of technical development, and tells everybody else what to do.
The idea is that Systems Engineers sit at the top of a hierarchy of integrated disciplines, commanding those below them via carefully-constructed specifications and generally swanning around like they own the place.
This may be true for some industries, where I’d argue it is typically a necessary reaction to what one of my colleagues from luxury automotive refers to as the “IP Barrier”. When your industry relies on incorporating complex, customised parts from many different suppliers who want to work to an interface specification but won’t let you see the internals of what you’re buying from them, and when integration is hard because of space constraints or common software / communication platforms then yes, a stack of systems engineers breaking down architecture and specifying black box parts is a good way to deal with that - this model tends to work in industries where the integrating organisation is largely made up of Systems people and the supplier organisations are largely made up of single-discipline designers. The hierarchy of Systems people sitting on top of a bottom layer of everyone else is only really appropriate where you have a hierarchy of systems managed by one organisation with the bottom-level parts produced by other organisations.
That isn’t what even very complex Medical Devices are like - we tend to own our own complexity right the way down. We rarely get to farm difficult things out for cash over a simple interface. We have to stare at every level of the horrors every day.
The fantasy of the all-powerful Systems Engineer occasionally leads to an absolute resistance to including the Systems role in a team, for fear of losing control.
But more often it just persuades people that the most senior person in the building is either already doing the Systems job or is the right person to take it on. In Medical Devices, the Systems Engineers are NOT in charge. They work alongside other disciplines, and just handle a different class of issues, in the same way that mechanical and software people handle different classes of problems. There’s nothing that says your most senior technical person is the best person to take the systems view - it just needs to be somebody who’ll be trusted and listened to by their peers, and in a small team, we’re all supposed to be listening to each other anyway.
Systems isn’t Simple.
Ok, but that doesn’t actually rule the CTO out as Systems Engineer, does it? Just because Systems doesn’t mean command, it doesn’t mean the commander isn’t still the person with the best overview, right?
True, at the outset, your CTO is likely to have the best view of the system as a whole. (S)he probably designed it. I mean, it’s a proof-of-principle prototype achieving 80% of necessary performance and looking like a massive box of speedframe, tubes and wires, but yes, at this stage the chief engineer undoubtedly understands it better than anyone else. So obviously, maintaining that overall view shouldn’t be a problem since they’re in charge of all the development work anyway - it’ll happen naturally, yeah?
The trouble is, Systems Engineering is about more than just coming up with an architecture and setting the wheels in motion to produce the component parts. System development is NOT just the sum of the other disciplines. It is not a simplified overview of the system, with the horrible details farmed out to the desks of other people. It isn’t a thin layer of elegant glue holding the messy bits together. It isn’t just about making a few big decisions, and it can’t be done effectively by a once-a-week steering committee or a one-every-six-months tiger team catch-up.
In fact, there is masses of detail at the system integration level, and you need a skilled systems engineer to help to hide it from the other disciplines. There’s most probably enough detail that your technical lead does not have time to deal with it. It isn’t half a job that can be dashed off as and when it’s needed, but a full-time, detail-heavy role ridden with its own tools (or, I suppose, huge and arcane spreadsheets), lists of minutiae and matted balls of complexity, demanding particular skills, training and above all focus. It needs one or more dedicated specialist junior staff far more than half the attention of a single vaguely interested senior guru with other fish to fry.
The top of your company moves upwards
So, let’s say you’ve taken all this on board, but as it happens your senior engineer is a seasoned Systems Engineer, has somehow carved out the time to handle the detail and wants to maintain control of the system-level design. Fine, that all sounds pretty good, and while I insist Systems is not “in charge” I’m certainly not going to argue with the elevation of one of my profession. Not to begin with, anyway.
The trouble is, your systems lead may do a great job at the outset, while your company is entirely composed of development staff and only has one thing on its mind: get the first product designed.
Just give it a year or two. First, you’re going to realise that you can’t turn out a successful product with just three people. Sure, you’ve got an electronics and embedded software genius, a godlike mechanical engineer and the high priest of all Systems people as CTO, but the day will come when you realise they don’t know everything. How’s your mechanical engineer at designing attractive casework? Does your software lead know anything about designing UI? Or cloud solutions? That usability study looks time-consuming - we’d better have a usability person. No, a usability team. And coordinators for the multiple study centres. That’s a lot of people - we’re going to need a bigger building. And a head of facilities. And a proper IT department. And we expect to have the product out next year, so we’d better find somebody to manufacture it and start advertising it. Then we need legal protection in case anything goes wrong. It isn’t long before your CTO spends all their time in meetings discussing how to run the company - helping the CEO to manage business-level complexity, not dealing with technical complexity. Representing an engineering team that no longer dominates headcount. Explaining why we didn’t include a Quality team on that list.
Then one day the mechanical lead finds a problem that requires revisiting the risk analysis and possibly a change to the architecture or an adjustment in system-level requirements. But the company’s detailed systems knowledge is currently sound-asleep on a plane somewhere over the Pacific on the way to meet a potential supplier in China, supervising a clinical trial on a Caribbean island or attempting to drink a potential customer under the table. It’s a hard life.
The company stretches. It gets wider, and as a result it has to get taller - more layers of management to deal with more people. Those who start at the very top are initially close enough to the bottom to stay in touch with it, but new layers get added between them. And more senior technical people who initially get their hands dirty with design are liable to end up as full-time managers.
To protect against people becoming unavailable like this, it’s better for your broad Systems knowledge to be spread across multiple levels, mimicking the structure of any other engineering discipline. If you have a Mechanical lead, you should have a Systems lead with similar seniority. If you have junior programmers, have junior Systems Engineers (yes, there is a role in Systems for new graduates). When you promote a junior electronic engineer, promote a junior Systems Engineer. Develop the team as you do everyone else.
Keep it Real!
To summarise all that:
Systems isn’t top of the development heap. It doesn’t have to be implemented at the most senior level.
Systems is a specialist task requiring focus and space, so expect to hire into the role or, at the very least, strictly ring-fence somebody’s time.
Product Systems Engineering needs to be kept with the product team. Your most senior people will eventually float away. Systems expertise vesting at senior level or in only one brain is vulnerable.
And above all, Systems does not belong at the bottom of your CTO’s to-do list!