Introducing: The Arcane Engineer
The engineer shapes you’ve seen everywhere
After spending enough time on LinkedIn and other social sites and reading blog posts, you’ll start to see all of the different “shapes” of engineers. Just in case you have no idea what I’m talking about, here’s a few common ones:
I Shaped
Has deep expertise in one area, but otherwise little breadth. Generally considered a specialist in one area.
T Shaped
Has deep expertise in one area, but also a broad general knowledge along other areas.
Π (Pi) Shaped
A combo of I and T, specializing in several areas with enough of a broader skill set to bridge the gap.
Tree Shaped
Has many branches of knowledge of different length connecting back to a central area (the trunk).
These are all well and good, but if we compare these to what is expected of an Observability Engineer or SRE, none of them really fit the bill. Generally speaking, folks in these types of roles are expected to know everything; we know that’s not possible.
Something special. Something mystical. Enter the Arcane Engineer.
At NoBS, we flip this around and say “you need to have the ability to learn anything”. So when we are looking for engineers and training engineers, we don't look for one of these previously talked about shapes; instead, we look for something special. Something mystical. Someone who has read the tomes. We need…Arcane Engineers. They’re shaped like this:
Now, you might be saying to yourself, “Wait, Nick…”
“…why are you comparing engineers to a powerful magic seal used in rituals to summon the horrifying Yog-Sothoth from the Outer Realm that will surely bring the destruction of time and space?!”, and you’re not wrong to think that. Well, two reasons really, the first one being way more esoteric than the second.
Yog-Sothoth is an all seeing all knowing entity, and given what I mentioned earlier about engineers being expected to know everything, being omniscient would be pretty rad.
If we look at the shape itself, it explains more about what we’re really looking for in an engineer.
Let’s leave the Eldritch behind and talk more about point 2. In fact, let’s just use a picture first.
When systems collide, so must our skills
In observability, we need all of our skills to intersect and tie together, and be tied together in the grand scheme of observability. After all, if you don’t know how something works, and you don’t know how many things work together, how can you create proper observability around it?
This field is about much more than having one specialty and a broad knowledge. It’s about understanding how and why things work, the different ways different companies use them, adapting to new challenges, and framing everything with the lens of “how do I know when something goes wrong with a complicated system”.
So if you’re interested in pursuing the dark arts and summoning an unspeakable horror from another dimension helping customers gain insight into critical processes and solve complicated problems, we’re on the lookout for you. Get in touch.
