Why not 'Systems Integration Engineer'?

Albert Nemec
4 min readDec 16, 2021

Hi again. This is a follow-up to my previous piece on "What is DeliveryOps". Read first for richer context.

I admit. While I received general appreciation of the "AI Blue" from the last article. The amount of DeliveryOps engineers I hired is zero.

Intro by self-busting

I get it. I won't be a terms-coiner in this lifetime. And after all, I also do get mildly suspicious of new made-up terms.

A self bust

Zero offense to past coinages like HR to PeopleOps, hiring to talent, DevOps to Site Reliability, IT to tech, marketers to ambassadors and educators to evangelists.

If you read the job description, you most likely concluded… Oh, you mean "Systems Integration Engineer".

Counter-bust

If you have arrived at this conclusion, most likely, you looked at the stack, then you gazed at the anticipated output of this stack being applied, and there's the result: Integration!

Effectively, you identified what and how. Now, why did you do that?

Why #1

Most resumes and job descriptions are actually either skill-based or outcome-based. Together, they form the landscape in which job-searching, job evaluation, and job-offering are to be conducted.

Then, in the classic hiring process, most time will be spent on "Can you do it?" and "What you'll get".

These two parameters are crucial. Like in any trade. But the real nature of the situation goes beyond trade. The trade is just a local 'game', that lives within a broader story, initiated (and to be concluded) by why

Why #2

Actually, there are 2 whys inside of that why.

  1. Why does the role exist? (Why is the company hiring for this role right now?)
  2. Why does the candidate exist? (Bit hyperbolic.. Read as "Why did the human decide to exist as candidate")

That's what actually is important. Loss of 'why' or vision of a new one, is the thing that drives this whole process through an eternal cycle of resignations and new employments.

How far does why fly? Far out. Why?

You can actually, build the whole process around the why. Cover letters being the default, instead of the resume, describing various whys.

Job description describing the history of the teams, of the entity, of the individuals, spin-offs, plans, experiments, failures, successes, and realizations that lead to this job description, or actually to the person reading it.

serious thought

Finding with the candidate, how this job could actually be a natural continuation to a trend in their lives.

Tailoring the name of the role to reflect the purpose, the objective of the role. Rather then just sticking to empty, essence-less description of a hand that shakes hands, a wielder of things, the sayer of words, the person who clicks.

Not to get too preachy, approaching the last part of the article, but the names above do seem bit.. dehumanizing and reductionist, don't they?

Full circling on the 'DeliveryOps' name

full circle

Alright. After such a flamboyant display of linguistic ethos, I guess selling 'DeliveryOps Engineer' as humanizing doesn't feel very symmetrical in cadence, huh?

At the very least, it is a name that stems from the purpose. To 'ops the delivery', thus lubricating the machine of deliverance, to conduct oneself engineerly on supporting their colleagues in product delivery.

Final remark

Lt. Cmdr. Geordi La Forge

Did you know that in Star Trek, orange uniforms do not belong to engineers, as is commonly believed, but to members of 'operations' super-category in the crew? Maybe that'll shed some light on why Mr. Worf and all of the security team wear orange.

However, those who indeed operate (like Dr. Beverly Crusher, being a doctor) are not part of the 'operations' team. How strange.

Finaler remark

Thank you for reading to the end. If you liked this article, smile faintly and lightly chuckle. It'll look like you just had a flashback.

--

--

Albert Nemec

Civilian writing about programming and strange ideas in a mildly stylized and semi-digestible way.