On the Phenomenon of 9-5 Systems Engineers		Date	2023-02-10
		Tags

This post de­scribes a phe­nom­e­non that I and some other sys­tems en­gi­neers that I’ve spo­ken too have no­ticed about our dis­ci­pline. This phe­nom­e­non is en­tirely anec­do­tal so I could be work­ing in out­lier com­pa­nies or com­pletely wrong. If this post rings true or false for you, how­ev­er, I’d love to hear from you in the com­ments to help un­der­stand whether my ex­pe­ri­ence is uni­ver­sal in this re­spect.

My null hy­poth­e­sis is this: com­pared to other dis­ci­plines of en­gi­neer­ing, there are pro­por­tion­ally far fewer vo­ca­tional sys­tems en­gi­neers. By vo­ca­tional, I am re­fer­ring to the idea of en­gi­neers who see the sub­ject of their job as more than just what they do 9-5 to pay the bills.

Vo­ca­tional en­gi­neers are those who spend con­sid­er­able time out­side of their job work­ing on re­lated hob­bies and/or con­tribut­ing to their dis­ci­pline. Ex­am­ples are me­chan­i­cal en­gi­neers who re­store cars, elec­tronic en­gi­neers who au­to­mate their homes or soft­ware en­gi­neers who con­tribute to open source pro­jects. You know the type­s—in large com­pa­nies, they of­ten band to­gether and spend lunchtimes drone rac­ing, soap­box racer build­ing or or­gan­is­ing an in­ter-de­part­men­tal hackathon.

Amongst the sys­tems en­gi­neer­ing dis­ci­pline, though, there seems to be far fewer of these vo­ca­tional types. The sys­tems en­gi­neer­ing com­mu­nity is in­deed smaller than the other en­gi­neer­ing dis­ci­plines but is the pro­por­tion that I’m con­cerned about. Most other sys­tems en­gi­neers that I’ve worked with would of­ten rather be down in a dis­ci­pline such as elec­tron­ics or me­chan­ics.

This post is not an in­dict­ment of these ‘hap­pen­stance’ sys­tems en­gi­neer­s—they of­ten do a very good job. How­ev­er, those that see them­selves as sys­tems en­gi­neers by vo­ca­tion have an im­pe­tus to push the dis­ci­pline for­ward—those with an emo­tional and iden­ti­tar­ian in­vest­ment in the dis­ci­pline are much more likely to want to make a name for them­selves within the com­mu­ni­ty. There­fore, a dis­ci­pline with fewer vo­ca­tional mem­bers loses its soul and will tend to pe­ter out over time as the older vo­ca­tional en­gi­neers die.

So, let’s ex­plore some of the as­pects of the mod­ern SE en­vi­ron­ment that may be lead­ing to this phe­nom­e­non.

The Sys­tems En­gi­neer­ing Com­mu­nity

To start try­ing to an­swer this ques­tion, I want to ask what does the sys­tems en­gi­neer­ing com­mu­nity look like? In three words: Old, White, Men. By com­mu­ni­ty, I’m talk­ing about those who en­gage with the dis­ci­pline pro­fes­sion­ally through IN­COSE and other groups (I’d also like to point out that my ex­pe­ri­ence is mainly in the UK). There­fore the com­mu­nity can feel ex­clu­sion­ary to those not in that cat­e­gory¹.

The com­mu­nity is also very aero­space and de­fence fo­cussed. This is un­der­stand­able as these do­mains have put the most re­sources into de­vel­op­ing the dis­ci­pline in the past. How­ev­er, there are dif­fer­ent stake­holder en­vi­ron­ments and re­source streams in other in­dus­tries that IN­COSE-style sys­tems en­gi­neer­ing does­n’t cov­er. Al­though the scope is slowly ex­pand­ing, those en­gi­neers from in­dus­tries not his­tor­i­cally as­so­ci­ated with sys­tems en­gi­neer­ing may feel un­wel­come in these spaces.

Pa­ter­nal­ism

Per­haps be­cause of the aca­d­e­mic land­scape, the de­mo­graph­ics of the com­mu­nity or the in­dus­tries that dom­i­nate the dis­ci­pline, sys­tems en­gi­neer­ing has a prob­lem with pa­ter­nal­ism.

What do I mean by this? I’m re­fer­ring to the gen­eral feel­ing that, as a sys­tems en­gi­neer, your job is not to de­velop bet­ter ways of do­ing things, leave that to the re­ally clever peo­ple in IN­COSE. The few IN­COSE mem­bers that make up this elite cadre know their sys­tems the­ory and use it to de­velop some great works of sys­tems en­gi­neer­ing such as the IN­COSE hand­book. How­ev­er, with­out com­mu­ni­cat­ing this sys­tems the­ory down to the mass­es, tai­lor­ing these works to lo­cal con­texts is hard and of­ten re­quires hir­ing one of the elite cadre as a con­sul­tant. The ben­e­fits of this sta­tus quo to the cadre are ob­vi­ous.

In his mag­num opus, Brain of the Firm, Stafford Beer gives us the fol­low­ing warn­ing:

When we dis­cover that a par­tic­u­lar tech­nique works, we train a cadre of peo­ple in its use. This is a sen­si­ble thing to do, in its way; but the grotesque con­se­quences have by now been so of­ten re­peated that we should take note of them. The peo­ple who have been trained in a set of tech­niques that have been found to work in oc­ca­sional con­texts pro­ceed to in­sti­tu­tion­al­ize their ac­tiv­i­ties: they con­sti­tute them­selves a pro­fes­sion, they pro­vide them­selves with pro­tec­tive sanc­tions, they cease to be in­no­v­a­tive, and they do what they can to block the fresh ini­tia­tives of oth­ers. [p.320]

Now, I’m not say­ing that IN­COSE has got to the state de­scribed by Beer but I do be­lieve that the group may be on the path there.

Im­prov­ing the dis­ci­pline’s base knowl­edge of sys­tems the­ory would em­power newer mem­bers to ques­tion cur­rent meth­ods, spot prob­lems with them and de­velop novel ones. It would also break the bot­tle­neck on tai­lor­ing within the in­dus­try. Em­pow­er­ing newer mem­bers of the com­mu­nity to ques­tion the sta­tus quo en­sures that we will con­tinue to evolve and will give those newer mem­bers a feel­ing of own­er­ship over the dis­ci­pline that cur­rently does­n’t ex­ist.

Sys­tems En­gi­neer­ing within Com­pa­nies

Sys­tems en­gi­neer­ing is a job. With­out stat­ing the ob­vi­ous too much, the ma­jor­ity of sys­tems en­gi­neer­ing oc­curs within en­gi­neer­ing com­pa­nies. Be­cause it in­volves com­plex pro­jects, there are very few, if any, hob­by­ist sys­tems en­gi­neer­ing en­deav­ours. There­fore we should seek to un­der­stand what sys­tems en­gi­neer­ing looks like in prac­tice un­der cap­i­tal­ism if we wish to un­der­stand the state of the dis­ci­pline.

For one rea­son or an­oth­er, there is a lack of sys­tems en­gi­neer­ing course ant uni­ver­si­ties in the UK com­pared to the num­ber of va­can­cies within the dis­ci­pline. Some com­pa­nies have, ad­mirably, risen to this chal­lenge and hire grad­u­ates/ap­pren­tices with a view to train­ing them in good sys­tems prac­tice from scratch. I my­self was lucky enough to find my­self on such a grad­u­ate scheme.

This brings with it the risk that these new hires will not en­joy the dis­ci­pline that they have en­tered with no prior ex­pe­ri­ence of. Per­son­al­ly, I had no idea what sys­tems en­gi­neer­ing was when I got onto my sum­mer place­ment in it. It was, per­haps, pure luck that I would find some­thing that I’m so pas­sion­ate about so early in my ca­reer. Some of my con­tem­po­raries found that sys­tems was not for them. Some are still sys­tems en­gi­neers, but many have de­fected to other dis­ci­plines, in­dus­tries or vo­ca­tions.

Per­haps this will­ing­ness to train sys­tems en­gi­neers from scratch in these few com­pa­nies has less­ened the de­mand on SE as an un­der­grad­u­ate de­gree. There seems to be a high at­tri­tion rate in all dis­ci­plines of en­gi­neer­ing at the mo­ment; many en­gi­neers that I know, in­clud­ing my­self, have found that there is a strong pay and pro­gres­sion in­cen­tive to move from com­pany to com­pa­ny. HR de­part­ments re­ally do seem to favour hir­ing ex­ter­nally than pro­mot­ing and recog­nis­ing in­ter­nal tal­ent. Ex­ter­nal hires tend to be bet­ter re­mu­ner­ated than those who are in­ter­nally pro­moted too. This leads me to ex­plore a spe­cial type of com­pany that es­chews in­ter­nal de­vel­op­ment al­most en­tire­ly.

Par­a­site Com­pa­nies

The de­mand for sys­tems en­gi­neers is high, per­haps more so than other dis­ci­plines to­day. This is ex­ac­er­bated by the rise of what I call par­a­site com­pa­nies. Par­a­site Com­pa­nies are those that refuse to in­vest in their own staff. Of­ten con­sul­tants, these com­pa­nies hire in new tal­ent when­ever they need it to ful­fil a con­tract but see train­ing-­to-­fit as too big an over­head.

These com­pa­nies are typ­i­fied by a low train­ing bud­get and high turnover of staff, es­pe­cially amongst those in their early ca­reer who feel as though their ca­reers are be­ing stunted be­fore they’ve even be­gun. Com­pa­nies like this can be ef­fec­tive ma­chines for de­stroy­ing a bud­ding sys­tems en­gi­neer’s pas­sion.

These par­a­site com­pa­nies seem to out­num­ber those that are will­ing to train sys­tems en­gi­neers and there­fore ex­ert a pull fac­tor on sys­tems en­gi­neers out of the com­pa­nies that do in­vest in staff skills. How­ev­er, there’s an even big­ger pro­por­tion of the SE em­ploy­ment space that dom­i­nates in in­dus­tries such as au­to­mo­tive, those that have iden­ti­fied the prob­lem but don’t know quite how to solve it. Let’s call these the Elec­tri­cal In­te­gra­tors.

Elec­tri­cal In­te­gra­tors

Most re­sources about sys­tems en­gi­neer­ing promi­nently dis­cuss the prob­lems that not us­ing SE tech­niques on com­plex projects cause. Sim­ply put, with­out SE, your com­plex sys­tem is un­likely to do what you wanted it to do when you plug it to­geth­er. This could be the be­hav­iours that you wanted don’t ex­ist or you get ex­tra be­hav­iours that a thor­oughly un­de­sir­able, some­times even dan­ger­ous. These prob­lems of­ten only man­i­fest at the in­te­gra­tion stages of a project on the right hand side of the Vee.

Com­pa­nies iden­tify this as a prob­lem that re­quires fix­ing. How­ev­er, with­out the sys­tems knowl­edge re­quired, they of­ten hire peo­ple to fix these is­sues at the elec­tri­cal in­te­gra­tion stage. Due to this work be­ing on phys­i­cal end of the process, en­gi­neers with strong mecha­tronic but lit­tle sys­tems ex­pe­ri­ence are hired. These en­gi­neers ef­fec­tively be­come su­per­hero fire­fight­ers (see next sec­tion) solv­ing prob­lems as they’re dis­cov­ered in tests (or even in pro­duc­tion!).

How­ev­er, com­pa­nies with this sort of cul­ture rarely have good re­quire­ments processes or good trace­abil­ity from tests back through the de­sign to cus­tomer need. There­fore, tests tend not to be about ver­i­fy­ing de­signs against re­quire­ments or val­i­dat­ing against cus­tomer need—they’re more of a shot­gun ap­proach to in­di­vid­ual test en­gi­neer’s best guess at what a cus­tomer might do with the sys­tem and what they might want to hap­pen. Such test­ing regimes are akin to try­ing to catch wa­ter in a wicker bas­ket when it comes to val­i­da­tion.

Com­pa­nies with this sort of sys­tems en­gi­neer­ing prac­tice can be ef­fec­tive at solv­ing prob­lems with a ded­i­cat­ed, in­tel­li­gent and sea­soned team of in­te­gra­tor-heroes. How­ev­er, the same prob­lems will ap­pear again and again across projects when their source is at the start of the Vee cy­cle. As com­plex­ity in­creas­es, these com­pa­nies will find their costs of re­work and test­ing sky­rock­et­ing. The Elec­tri­cal In­te­gra­tors an­tipat­tern is of­ten cou­pled with the box-tick­ers (see lat­er) prob­lem when a well mean­ing man­ager starts a sys­tems de­part­ment to try and dis­solve the prob­lems to the cha­grin of the rest of man­age­ment.

As these elec­tri­cal in­te­gra­tor type sys­tems en­gi­neers are work­ing far off the right hand side of the Vee, they tend to see sys­tems en­gi­neer­ing the­ory as not ap­plic­a­ble to their job. These en­gi­neers are there­fore un­likely to en­gage with the wider com­mu­nity and don’t iden­tify with be­ing a sys­tems en­gi­neer. If they work in a com­pany with a box-tick­ing sys­tems de­part­ment, they may even build a re­sent­ment to sys­tems en­gi­neer­ing for al­low­ing the mess that they have to clean up.

Box Tick­ers

I have to talk about the most soul-crush­ing places a sys­tems en­gi­neer can find them­selves. In a box-tick­ing ex­er­cise. Per­haps you’ve found your­self in this po­si­tion—the sys­tem un­der de­sign is com­plete and some sys­tems doc­u­ments are re­quired to be pro­duced so that you can pre­tend that you fol­lowed a sys­tems ap­proach to the cus­tomer.

In­vari­ably, the sys­tems work will find prob­lems with the de­sign, that it does­n’t meet the cus­tomer re­quire­ments or that its not even close to an ef­fi­cient de­sign for the prob­lem at hand. The sys­tems team may then be pres­sured to form­ing their work to met the de­sign in the mid­dle–to pre­tend that this un­eco­nom­i­cal de­sign was the best one all along.

Even worse, some “sys­tems en­gi­neers” are forced to use re­quire­ments and/or SysML to doc­u­ment the ex­ist­ing de­sign at a suf­fi­cient level of ab­strac­tion to sat­isfy reg­u­la­tors and cus­tomers. Un­like sys­tems en­gi­neers who ac­tu­ally get to per­form some in­con­se­quen­tial sys­tems think­ing, these en­gi­neers don’t even get the cyn­i­cal con­so­la­tion of get­ting to say “I told you so” when the project does­n’t go as well as hoped.

Projects that fol­low ei­ther of the above ap­proaches are of­ten hid­den by a val­i­da­tion method that I like to call Val­i­da­tion by In­tim­i­da­tion. This is where a cus­tomer rep­re­sen­ta­tive is pres­sured into ac­cept­ing a pro­duc­t/ser­vice de­spite it not meet­ing their needs. This is usu­ally due to the sunk cost fal­lacy where the cus­tomer does­n’t want to look in­com­pe­tent by let­ting a project over­run that may have been run­ning for decades and/or cost­ing mil­lions of eu­ros. I’ve ex­plored this phe­nom­e­non in a pre­vi­ous post—I be­lieve that its a big fac­tor in why bad sys­tems en­gi­neer­ing gets a pass.

The ex­pe­ri­ence of be­ing a box-ticker is soul-crush­ing. David Grae­ber, in his in­cred­i­ble work of mod­ern an­thro­pol­ogy Bull­shit Jobs, notes that forc­ing peo­ple to do work that has no ef­fect on the real world is sub­ject­ing them to moral, spir­i­tual and psy­cho­log­i­cal harm. Grae­ber points out in his de­f­i­n­i­tion of a bull­shit job that:

Bull­shit jobs are not just jobs that are use­less or per­ni­cious; typ­i­cal­ly, there has to be some de­gree of pre­tence and fraud in­volved as well. The job­holder must feel obliged to pre­tend that there is, in fact, a good rea­son why her job ex­ists, even if, pri­vate­ly, she finds such claims ridicu­lous.

The above prob­lem is ex­ac­er­bated for sys­tems en­gi­neers as, es­pe­cially when our work is in­con­se­quen­tial, we’re told to not com­plain be­cause “at least this project is do­ing sys­tems en­gi­neer­ing”. This re­frames any de­bate on how our sys­tems en­gi­neer­ing can be more ef­fec­tive into one on the ex­is­tence of the sys­tems en­gi­neer­ing team. It of­ten hides the sin­is­ter un­der­tone of “we would­n’t have a sys­tems team if X stake­hold­er/higher man­ager did­n’t want one. Don’t rock the boat: be grate­ful that your job ex­ists at al­l.”. In this way, box-tick­ers are of­ten con­stantly re­minded that oth­ers don’t be­lieve that their job holds real value and this con­stant re­minder leads many to in­ter­nalise this be­lief.

As some­one who, at cer­tain points in their ca­reer, has been in this po­si­tion, this is an in­cred­i­bly de­mor­al­is­ing place to be. Build­ing part of your iden­tity around a sub­ject that you your­self sus­pect is not ac­tu­ally valu­able is not some­thing many peo­ple want to do. Those that want to con­tinue in this vein might do so only by be­liev­ing that they’re “gam­ing the sys­tem” and drive them to be­come fire­fight­ers who climb the greasy pole to get out of sys­tems. Per­son­al­ly, I be­lieve that the preva­lence of the box-ticker sys­tems en­gi­neer may be the most harm­ful cause of the lack of vo­ca­tional sys­tems en­gi­neers.

The Man­age­ment Con­veyor

Sys­tems en­gi­neers can of­ten find them­selves within a priv­i­leged po­si­tion within pro­jects. Along with project man­age­ment, sys­tems en­gi­neer­ing is a cen­tral part of a well-­func­tion­ing project and there­fore the sys­tems en­gi­neers tend to be well ac­quainted with all of the myr­iad teams and tasks within a pro­ject. This means that, when man­age­ment po­si­tions open up within a pro­ject, sys­tems en­gi­neers are well placed to take these po­si­tions. This can make sys­tems en­gi­neer­ing an at­trac­tive field for en­gi­neers who want to climb the greasy pole over other vo­ca­tions.

This prob­lem can be ex­ac­er­bated if the sys­tems team is fire­fight­ing or a box-ticker de­part­ment as lit­tle sys­tems the­ory knowl­edge is needed to per­form these roles. Peo­ple skills be­come para­mount as you can ef­fec­tively fire­fight by fa­cil­i­tat­ing ‘task forces’ of en­gi­neers from af­fected sys­tems. Sus­tain­ing a box-tick­ing de­part­ment can be done ef­fec­tively by a charis­matic en­gi­neer adept at buzz­word bin­go—no deep knowl­edge of sys­tems the­ory re­quired. Good peo­ple skills are very use­ful for ef­fec­tive sys­tems en­gi­neer­ing but, if not bal­anced with good sys­tems prax­is, can mean that sys­tems team hir­ing and pro­mo­tions se­lect against ef­fec­tive sys­tems en­gi­neers and pro­duce an en­vi­ron­ment where sys­tems en­gi­neer­ing is seen as man­age­ment con­veyor rather than a dis­ci­pline of en­gi­neer­ing with a strong the­o­retic back­ground.

It’s just com­mon sense

The fi­nal an­ti-­pat­tern that I want to cover is the per­cep­tion that sys­tems en­gi­neer­ing is “not a real en­gi­neer­ing dis­ci­pline”. The phrase that I think typ­i­fies this per­cep­tion is the phrase “Sys­tems en­gi­neer­ing is just com­mon sense”. Apart from the fact that ap­peal­ing to com­mon sense is of­ten used as jus­ti­fi­ca­tion for some of the most ob­jec­tion­able views in our so­ci­ety, com­mon sense is hard to de­fine. Com­mon sense seems to be the pre­serve of mid­dle-aged white men—the peo­ple who make up the ma­jor­ity of British man­agers. In fact, our so­ci­ety at­trib­utes oo­dles of com­mon sense to those mid­dle-aged, no-non­sense, “I’m just say­ing what every­one’s think­ing” types.

When we say “sys­tems en­gi­neer­ing is just com­mon sense” these man­ager types (e­spe­cially those with lit­tle knowl­edge of sys­tems think­ing) think “I’ve got a lot of com­mon sense” which leads them to de­duce that they must be re­ally good at sys­tems en­gi­neer­ing. I’ve heard peo­ple with this at­ti­tude claim that sys­tems en­gi­neer­ing is not real en­gi­neer­ing as it has no the­o­ret­i­cal or math­e­mat­i­cal foun­da­tion.

I be­lieve that this at­ti­tude is a cause of the bur­den of sim­pli­fi­ca­tion that sys­tems en­gi­neer­ing suf­fers more than other dis­ci­plines. As sys­tems en­gi­neer­ing is “just com­mon sense” ap­ply­ing the­ory and maths to its prac­tice is seen by these peo­ple as an act of over-­com­pli­ca­tion. I’ve been in meet­ings where the sys­tems team has been told to sim­plify their SysML out­put but the man­ager is happy to let the elec­tri­cal team talk Fourier trans­forms. Per­haps this is­sue is caused by the lack of sys­tems en­gi­neer­ing ed­u­ca­tion in com­bi­na­tion with the at­ti­tude that comes with the priv­i­lege of be­ing a white and/or mid­dle class and/or man typ­i­fied by “If I don’t un­der­stand it or al­ready know it, it must ei­ther be unim­por­tant or made up”. I cer­tainly think that this prob­lem is ex­ac­er­bated by the pa­ter­nal­ism prob­lem men­tioned be­fore—when our dis­ci­pline is ef­fec­tively hid­ing our the­o­ret­i­cal ba­sis from the prac­ti­tion­ers, it be­comes eas­ier for peo­ple to mis­un­der­stand hid­den the­ory as a lack of the­o­ry.

Con­clu­sion

I be­lieve that the fac­tors ex­plained above have cul­mi­nated in a ‘gen­eral vibe’ that sys­tems en­gi­neer­ing is not a vo­ca­tion of real con­se­quence. This acts as a bar­rier that ul­ti­mately re­duces the num­ber of sys­tems en­gi­neers who make the dis­ci­pline a large part of their iden­ti­ty. This is partly due to there be­ing a num­ber of fil­ters al­ready around en­gi­neer­ing for class and gen­der as well as the lack of sys­tems ed­u­ca­tion and aware­ness in ed­u­ca­tion be­fore mas­ters de­gree level or grad­u­ate scheme ed­u­ca­tion. Af­ter this, the fac­tors above push sys­tems en­gi­neers away from en­gag­ing with the praxis of the dis­ci­pline and pre­vent peo­ple from feel­ing that they can im­prove it and/or iden­tify with it.

How might we go about fix­ing this?

To re­it­er­ate the premise in dif­fer­ent terms, sys­tems en­gi­neer­ing as a dis­ci­pline needs to fos­ter a greater num­ber of vo­ca­tional sys­tems en­gi­neers to en­sure that it can in­no­vate and solve the ever-­com­plex prob­lems of the fu­ture. Above I have ex­plored what may be caus­ing this per­ceived prob­lem, so now its time to sug­gest some ways for­ward to fix­ing it. Be­low are a few ideas that I’ve had on the topic but I’d wel­come any chal­lenges to these ideas in the com­ments.

Hackathons & Col­lab­o­ra­tive De­vel­op­ment

Com­pe­ti­tions are a great way to trial new ideas, meth­ods etc. in a crit­i­cal but fun en­vi­ron­ment. Hackathons em­body this by cre­at­ing a safe en­vi­ron­ment to try new ideas while adding an el­e­ment of com­pe­ti­tion to drive in­no­va­tion.

SCiO, a sys­tems think­ing prac­ti­tion­ers’ group, has a great bi­monthly on­line de­vel­op­ment ses­sion where sys­tems prac­ti­tion­ers can bring re­al-life or in­ter­est­ing prob­lems. These ses­sions con­tain ex­perts in the field who are more than happy to ap­ply their knowl­edge and ex­plain con­cepts to less ex­pe­ri­enced prac­ti­tion­ers. I thor­oughly rec­om­mend that sys­tems en­gi­neers join SCiO as the knowl­edge of sys­tems the­ory that the ex­pe­ri­enced mem­bers hold is in­valu­able. You can join here: http­s://www.sys­tem­sprac­tice.org/mem­ber­ship.

Bet­ter Com­mu­ni­ties

De­vel­op­ing a sense of be­long­ing in new mem­bers to the sys­tems en­gi­neer­ing com­mu­nity is a great way of en­sur­ing that the dis­ci­pline grows. New sys­tems en­gi­neers need spaces that are friend­ly, open and where the more ex­pe­ri­enced en­gi­neers are happy to share their knowl­edge.

Last year, Sys­tems en­gi­neer Zsolt San­dor started a sys­tems en­gi­neer­ing pro­fes­sion­als Dis­cord server that has be­come an in­cred­i­bly vi­brant com­mu­nity for dis­cussing prac­tice and the­ory in sys­tems en­gi­neer­ing. This com­mu­nity is rapidly grow­ing and has be­come a wel­com­ing place for dis­cus­sions for en­gi­neers at all skill lev­els.

Of course, any com­mu­nity comes with the risk of hard­en­ing into an ex­clu­sion­ary clique. It is there­fore im­per­a­tive that we must put in place processes and mea­sures to en­sure that these com­mu­ni­ties re­main open and de­mo­c­ra­tic and do not de­velop ex­clu­sion­ary fea­tures from shib­bo­leths to out­right dis­crim­i­na­tion. Any com­mu­nity must en­sure that it pro­motes di­ver­sity and that it takes novel con­tri­bu­tions in good faith rather than re­ject­ing them be­cause they weren’t de­vel­oped by some­one in the ‘in-crowd’.

The bal­ance be­tween pro­vid­ing a sense of be­long­ing through dis­tinc­tion and en­sur­ing that this dis­tinc­tion does­n’t be­come dis­crim­i­na­tory is a tricky one to main­tain. Find­ing new in­ter­ested peo­ple and en­cour­ag­ing them to bring their own thoughts to the con­ver­sa­tion is an im­por­tant part of find­ing this bal­ance. I be­lieve that al­low­ing peo­ple to feel like they are part of the de­vel­op­ment of sys­tems the­ory and prac­tice over time is the key to this which leads me to my fi­nal point:

De­moc­ra­ti­sa­tion of Praxis

Sys­tems en­gi­neer­ing the­ory can­not be the pre­serve of a few in­di­vid­u­als in big de­fence com­pa­nies who write the books and to whom the rest of us must blindly fol­low. We must break the pa­ter­nal­ism and en­sure that our peers are em­pow­ered to be true sys­tems thinkers. If we do, I be­lieve that there will be a rev­o­lu­tion in new tools, processes and meth­ods within the dis­ci­pline that will al­low it to meet the com­plex prob­lems of the fu­ture.

---

1. It may also lead to old white men be­liev­ing that they can get away with ab­hor­rent be­hav­iours.↩︎

Site proudly generated by Hakyll | Theme based on Oskar Wickström's Monospace Web.