On being a fish out of water
Boring people with your interests is brilliant, especially when they’ve no reasonable excuse to run away. Being a singularly un-fascinating person since my kids arrived, I now have only two topics with which to belabour people: fatherhood and Systems Engineering. The first is, as I hope most people realise, not something to be volunteered until requested out of genuine need – walking up to people and telling them how to deal with their offspring’s foibles is unacceptable and, as a father voicing uneducated opinions at other exhausted men, risks being met with bleary-eyed physical violence. No such risk applies to Systems Engineering and I delight in visiting it upon the ears of the slowest-moving member of whatever social group I happen to be in*.
However, I have realised lately that this is not true in all company. Ironically, the place I feel least inclined to talk about Systems Engineering is in any gathering of Systems Engineers. Communication with them is surprisingly difficult and during my recent excursions back into the world of INCOSE and SaRS I initially worried that my Systems capability had somehow deteriorated since I left the aerospace industry. On reflection, however, I realise my discomfort is a consequence of the particular sort of Systems Engineer I am resulting in significant differences between my own day-to-day experience and that of the majority of the profession. Allow me to explain.
Some History
Going back a few decades, the history of Systems Engineering has long been bound to industries that deal with things on a massive scale. The space, aerospace, defence, nuclear power and latterly automotive industries, for example, all bring together large, interdisciplinary teams to produce finely-honed products performing challenging and complex functions, and this made them fertile ground for the germ of the Systems approach. Search the web for historic advice on any given Systems technique and the skewed, slightly speckled PDF scan of an ancient-looking Courier-font document will be headed with the name of Lockheed Martin, Boeing, Toyota or Ford.
More recently, the techniques have been transferred usefully to less awesome systems, in my case medical devices**, where regulation and the commercial imperative to wrap cutting edge science with manufacturable, supportable engineering with a short time to market make the approach compelling.
And so the majority of Systems Engineers still spend their entire careers in the more traditional big industry organisations where I started out before jumping ship to medical. So what? Why does that make it hard to talk to my colleagues from Southampton, Coventry and the M4 corridor?
La Diffèrence
The trouble is, Systems has had to change to be usefully applied in medical device development.
Traditional industry tends to employ large numbers of systems engineers. A few sweeping generalisations in the work they encounter:
Systems are big – many people, many companies together work on their development,
most interfaces to be managed are to other engineering systems,
interfaces to human beings occur, of course, but are made reasonably predictable through controlled training of those humans relevant to the specific interface in question (the consumer automotive industry is a notable exception).
This means you need a lot of systems engineers, all talking to each other and very few with a complete picture, to deal with the interfaces. But you can often deal with humans almost as if they were an engineering system – predictable, testable, and able to be represented by proxy by yet more systems engineers. When considering a technical ensemble solution as a single “system”, most of the complexity is at subsystem boundaries with less to worry about at the system boundary. Managing this complexity is a case of agreeing behaviour between engineering peers.
Let's look at the typical domains of interest for a top-level system owner:
The high level of formality and time allowed for precise system and subsystem definition allows engineers at each level to limit their scope and work largely to specifications pre-agreed through peer-to-peer communication.
Medical devices are a little different. Typically:
They are not terribly complex internally (although exceptions exist, especially where large amounts of data or surgical robotics are involved) and the staff required to develop each one is small,
most medical systems are stand-alone, and don’t really talk to other engineered systems,
interfaces to humans and human processes dominate, and the humans in question can be either very unpredictable (in the case of patient-administered devices) or very imaginative (in the case of expert clinicians).
To illustrate, let’s make some dodgy guesses at where things might sit relative to each other:
This adds up to mean small numbers of systems engineers (typically one person on the project has that title, although others may behave similarly – for example I tend to think of the human factors role as part of the Systems function) and lots of trouble with human unknowns.
It also means boundaries between responsibilities become more blurred. Let's look now at the domain of interest for a medical devices Systems specialist:
Much of the complexity is at the system boundary and dealing with it is a case of learning the context and working out how to live within it. This is the job of the Systems function, and no particular person usually exists to adequately represent the context. The engineer must go out to discover it through bookwork and repeated interviews and observation of many similar stakeholders.
Internal complexity is lower and is dealt with less formally, but the difficulty in integrating scientific capability tends to mean the Systems view must go to a deeper level in each subsystem in order to help rapidly debug unintended interactions.
This wider-reaching view makes the Systems role in medical devices very interesting – you genuinely need to understand the whole project in reasonable detail and the finessing of paper analyses is less central to the job (although they remain an important part of it). This is why my job is fun. It is also why trying to cobble a challenging medical device together without the systems view is inadvisable.
So, to relate this back to my initial social troubles, the differences outlined above mean the tools and techniques encountered in medical devices differ significantly from those employed by the other 95% of Systems people. There are plenty of passing similarities but the imbalances above tend to mean that, at the very least, analysis techniques used very carefully in big industry are used much more lightly in medical devices. In addition, aspects such as human factors have developed separately in the medical field and their implementation does not directly correspond to equivalent functions in other industries. All-in-all, the language, mindset and working environment for the two ends of the Systems scale are all very different, and this makes talking about my profession with those who arguably know it best rather awkward.
Vive it!
Having recognised the source of my discomfort, I don’t intend to let it be. While I have happily sat and listened to William Peine, director of R&D at medical leviathan Medtronic, expounding the importance of Systems Engineering in medical devices, I find that the discipline is not well known among smaller companies who have not yet been there and done that. There is still plenty of scope to innovate the application of a systems approach within small, nimble teams, with the promise of reduced risk and accelerated development without requiring excessive formality.
I encourage everyone in my position to overcome personal unease in engaging with the more formal side, with the intention of gaining a deeper appreciation of our differences so that we can better draw on and adapt (presumably lighten) appropriate techniques to solve problems in our increasingly complexity-bound industry.
* It’s a sharp lesson in fight or flight - nobody goes back for their handbag twice.
** Although note that, as connectedness and data exploitation grows, the medical devices field draws us gradually back towards the huge complexity of the historic engineering marvels. The future promises the need to consider the hospital network, the hospital as a whole and finally an entire national health service as a system of systems. For now, we have just a sniff of this and most Systems work is confined to concern with individual devices and their directly-interfacing clinical technologies and processes, plus their production and maintenance.