IT Engineers: a spotter’s guide.

I have worked with many IT engineers over the years and they’ve all been delightful, engaging people. They’ve told me about the types of engineers they’ve encoutered and I’ve passed on their descriptions below:

The Unengaged Engineer

Often an intelligent individual with wide-ranging interests from Sumerian numismatics to hot air ballooning but none whatsoever for doing the job they’ve been hired to do. They will browse endlessly on subjects which interest them and this may even extend to the theories of the technology they’re supposed to be working on. However, they don’t like anything too operational and seem unable to translate any theoretical knowledge to the practical realm.

If forced to do work, after a bad performance review perhaps, colleagues will quickly tire of having to spoon-feed them and so our unengaged engineer will be left in peace again to pursue their outside interests. Generally tolerated because they fill a berth on the on-call rota they can survive surprisingly well in large enterprises as they never make mistakes because they don’t do enough to.

The Hotshot Engineer

Not to be confused with the Know-it-all Engineer. These engineers know their stuff and walk the walk. They love to do things, love to fix things. Given a problem they will excel at troubleshooting, caring little for protocol. However, they don’t like obstacles such as change control, documentation, or other people. They can put on a professional front when faced with obtuse or unhelpful colleagues but will quickly snap if forced to engage with them for any length of time.

Their lack of tact can be amusing to observe but means they have to marshalled away from thin-skinned higher-ups. They can self-destruct but generally leave for fresh challenges before being pushed out for their maverick ways.

The Pedantic Engineer

This engineer will take two to three times longer to do everything, but it will be done correctly: tested, documented, and diagrammed, with all configuration changes minutely commented. A team full of them would be a nightmare but it’s good to have one of them around. They generally pull standards up as slacker engineers feel duty bound to at least follow half of the procedures that they should in the shadow of such an exacting exemplar.

The Know-it-all Engineer

The first thing this engineer will do when arriving at a company is explain what is wrong with your network, processes, technologies and basically everything you’re currently doing. They will outline how things should be done, often giving examples of how they single-handedly turned around an organisation when their innate genius was recognised and lauded. Surprisingly, they will not necessarily show the same inclination to right the wrongs of the new organisation they have joined; the shambles they have encountered being too much even for their skills. Often, their theoretical expertise extends into areas way beyond anything they are charged with supporting. Sometimes, they will actually say something that will make sense but tragically everyone will have long since stopped listening, so these occasions are missed.

The Over-Engineer

This individual knows a lot and they like to use as much of what they know as possible when designing a solution. Their designs will be clever but fiendishly overcomplex so they end up being the only engineer who can understand them. They share an aversion to documentation with the Hotshot (and let’s face it, most engineers) but will happily explain everything to anyone. And they will have to; many times: ‘So we get to this website through this ipsec vpn tunnel which uses cert authentication and its own PKI infrastructure, and then the traffic goes down a GRE tunnel and is reverse proxied to… you know, Bob, couldn’t we just post the five-a-side team sheet on the noticeboard?’)

To re-iterate the above are all shameless caricatures bearing no intentional resemblance to any engineers living or dead.