Editor’s Note: On the 13th of June 2020, PPI’s Managing Director published an article about the concept of systems engineers versus systems engineering. This topic has received much attention in just a few days of its posting.
From LinkedIn:
Bethany Smythe asked me recently for a view on why the candidate pool of Systems Engineers in the market appears to be so tight – particularly SEs with in-depth hardware and software backgrounds.
My reply started with the premise that engineers who are educated in systems engineering (SE) and practice engineering using a SE approach perform much better than those who don’t. So they are eminently employable. The demand is there but the supply is limited (mainly because of our flawed engineering education systems). Hence the scarcity.
I went on to observe that, personally, I rarely use the term “systems engineer”, but I have lived and breathed SE since 1985, the year when I realised how incompetent I was as an engineer. I was a good technologist in my field – radio engineering – but I didn’t have a clue as to how to go about applying that expertise in a way that consistently produced great results.
My view has solidified over the years that every engineer is, or should be, a systems engineer within the scope of their assigned engineering role(s). SE is not something different to engineering in general; it is a way of practicing engineering in general. The variables are the scope of the task, and degree of SE formality that is appropriate to that scope.
I am not alone in my view. Many companies implement the ethos of every engineer being a systems engineer. That affects their hiring, their engineering procedures, their learning culture, their learning strategy, and their reward systems. And their performance!
My colleague Paul Davies added some further thoughts, observing from 40 years of experience, that there are two essentially different approaches that organisations give to systems engineering:
Type 1 is a “stovepiped” industry, where the executive power is in the hands of single-discipline engineering empires. Systems engineering is recognised as a necessary annoyance to glue the designs together, but the practitioners are subservient to whichever single-discipline expert happens to be in charge of the particular project, and the career prospects are limited. I can relate to Type 1 easily, having had many engineers but few managers from “Type 1” organizations on my SE training courses, and having consulted to such organizations. Thankfully I have never been an employee of a Type 1 organization!
Type 2 is an organisation whereby systems engineering is firmly embedded, and the chief engineers on all projects are recognised experts in the integrative discipline. Indeed, single-discipline engineers are allocated to projects, to have their work directed by the cross-discipline “systems engineers”; and SE is seen as a desirable career aspiration.
Paul observes that there are gradations in between, and one of the goals of a prospective employee, at interview and by background research, is to ascertain where on the continuum his or her prospective employer lies. And thereby hangs a key to the original question: a prospective employee will want to work for a Type 2 company, not for Type 1. Paul sees Defence employers as typically further towards Type 2; the construction and energy sectors tending to be towards Type 1. Which is why Type 1 organisations find it hard to recruit SEs.
I share Paul’s views in the sense of Type 1 and Type 2 organizations being common, but I add a Type 3 organisation, where engineers work mainly in multidisciplinary teams, making the more important decisions collaboratively, creating a learning environment in which engineers may start single-discipline, but evolve to become multi-disciplinary, usually whilst maintaining their original discipline strength. Some change discipline in the process, for example from electronics to software. The further along this evolutionary path an engineer travels, the more suited that person becomes to a role of leading a multi-disciplinary team, everything else being equal. But engineers at any point on this journey can be, should be, and often are practicing systems engineering. The leaders in sectors who develop complex products in competitive markets tend towards Type 3.
Some systems are engineered to comprise a diversity of technologies, for example a car. Other systems are engineered to comprise essentially a single technology, examples being a mechanical Swiss watch, a drug, a consulting company, Sydney Harbour Bridge, and MS Word.
The principles of systems engineering apply to all of these engineered systems; the benefits accrue accordingly. We can agree, however, that the more complex a system is, the more risk there is due to that complexity, and the more valuable systems engineering practices become. We can also agree that, everything else being equal, the greater the diversity of technologies involved, the more complex a system solution is likely to be.
All of this shows up well in the excellent SEI/AESS/NDIA study “The Business Case for Systems Engineering Study: Results of the Systems Engineering Effectiveness Survey”, CMU/SEI-2012-SR-009, November 2012. That study also looked at the proportion of projects that implemented systems engineering as described by Paul as Type 2, versus “systems engineering to be practiced by all engineers”. The study concluded that the percentages were roughly equal, and the project performances were not different to a statistically significant degree.
That would seem to suggest that my advocacy of “systems engineering to be practiced by all engineers” is neither supported nor negated by the data. But there is more to it than that, not investigated in the study. My experience is that there is a big difference between having a policy of “systems engineering to be practiced by all engineers”, and having an engineering workforce in which that practice is occurring at a significant level of competence. The main challenge is the cost of educating the whole workforce. As a consequence, the education tends to be superficial, at least initially. With a good implementation of SE involving amongst other things genuinely expert leadership, SE champions and SE focus groups, substantial growth of SE competence towards a “way of life” level occurs over time.
Sadly, training a small group of SE leaders and having them try to influence the work of others remains a lot cheaper than training a whole engineering workforce, not withstanding the high return on investment (ROI) from doing the latter.
Only when SE appears in all undergraduate engineering degrees will the need to train an engineering workforce in systems engineering disappear. I see such initiatives appearing more frequently, and I am involved in some of them.
I have on my do-list a paper for my company’s systems engineering newsletter PPI SyEN, titled “Systems Engineers or Systems Engineering”, the content of which is already in my head. The paper will start with the principles of systems engineering, show that 13 out of the 14 main principles apply to the engineering of anything from a dollar coin to a new model commercial aircraft or the country of Singapore, and then look at ROI .
What do you think, systems engineers as a separate species, or systems engineering as a ubiquitous practice?
