10 Types of IT managers from hell

A Reg reader's guide

Your boss could well be a barely restrained psychopath. Indeed, it is probable that he is the living incarnation of Cthulhu himself. Or he may be a bumbling incompetent who'll sink your career along with his. You, the downtrodden techie, need to learn how to deal with him - and fast.

First, stop thinking of him as a person because it is making you too soft and disabling the parts of your brain that can effectively change his behaviour.

You are an IT pro: it is time to start acting like one. Forget emotional intelligence or touchy-feely “IT pros are from Mars, Bosses are from Uranus” rubbish. He is a defective component in your system – and you know how to deal with them.

What matters here is the output. When we talk of a corrupt index we aren’t passing a moral judgement any more than we believe that when you delete a file that the File Manager judges whether it has complied with ISO standards and either sends it to the Recycle Bin or to ascend to SkyDrive where it will be eternally stored on Steve Jobs' personal USB stick.

The defect removal mindset frees you from getting angry. Yes I know you’re angry, but that is a motivation, not a methodology. For this to work we must agree that what should happen is irrelevant when we know what will happen. If a file API should take both Windows \’s and Unix /’s but only takes the Unix kind, we put the /’s in since griping about it in the pub won’t get the job done. Same with your boss.

You already know that most of the effort in fixing a system is finding out what is wrong. My bitter experience is that randomly changing code or configs rarely makes things better, but by focusing your efforts on correcting a small part of his behaviour, you have a better chance than saying “Oracle performance is shit” - which is not useful, no matter how good it makes you feel. You need to sort out the indexes and buy yet more memory, but only after you’ve identified what sort of problem you face.

So let’s look at some AntiManager types.

1: The Visible Man

This is such a common bug that it is almost a feature caused by the fact that managers must multitask far beyond their capacity to do it properly. They stop thinking and start reacting to stimuli in the form of things they see and come to believe that things they can’t see don’t exist. This is, of course, a regression to babyhood where psychologists recognise a distinct part of your development when you realise that the person playing peek-a-boo isn’t being created by your observation of them. (and then at university discover that physics says it is)

This is one of the simplest to fix. You pander to their bug, in the same way that a buggy function that you haven’t the source code for can be fixed by a wrapper that takes input and makes it wrong in the right way. You make things more visible, stop planning your work by dependencies, delivery or tests, but instead by maximising observables and minimising the gaps between observable progress. The beauty of this fix is that not only will it make your boss like you better, you can tell him what you’re doing and he many well make the rest of the team follow your good example, helping you on your way to becoming an AntiManager of your own creation.

2: The VB 6 Expert

I liked VB6, despite being a C++ programmer at heart. It did what I told it and it made me look more productive. VB6 was such a classic that some thought it the perfection of its kind and there is a good chance that a former VB6 programmer of my generation is now your boss, though he will resent the “former” tag, so don’t use it.

As a C++ hacker who’s done multithreading you may notice that the personality bugs I describe come from that domain, because to become a real programmer you have to immerse so deeply that you think in terms of the system itself, not merely translate your thoughts into it.

The bugs come when he tries to apply VB6 or C++ style thinking to SQL or CUDA. Having got good at one thing, he doesn’t want the effort of changing and instead tries to make SQL code too procedural, or chafes at the patronising inadequacy of Java memory management, and ends up making you reinvent a square wheel memory manager to block Java’s round hole.

This sounds at first like old people not keeping up with new tech, but having recently come up to speed on mobile development, I feel like I’ve been fallen back in time to the 1980s where APIs were secret or barely documented and where swathes of functionality I’ve come to expect are missing. (or secret, who knows?)

Wrappers aren’t a good fix for this. The sheer size of the mapping defeats any gain you make; instead you join in him in hating the way this environment gets in the way. Perfection in this is researching limitations of the system or language and finding new things to bitch about. This will help you both get a better appreciation of what you’re dealing with.

3: The Busy Waiter

Evolution tells us that the urge to repeatedly ask “are we nearly there yet ?” must have some strong survival utility in later life to balance the number of kids who don’t make it through childhood for asking too many times. This applies equally in the case of project managers, though I’ve not worked out what that utility might be.

All of us, when first writing systems that talk to each other, try to code them as tight loops that bug the hell out of the target system. Sometimes we do this to the point where it never gets the chance to actually do the thing we’re waiting for. Just like you and your boss, isn’t it?

One answer is our old friend binary exponential backoff, making sure of the above scenario each time your stated delivery time goes up and not down, since despite all evidence many managers believe putting pressure on you to deliver always makes you get the job done more quickly. Yes, they do, just like the five year old stuck near me on a yet another broken BA plane. Don’t do this as confrontation. Instead talk to this prat and “discover” a new problem that takes longer each time he asks. Or you can actively tell him how things are going, using the message passing design

4: The Contagious workaholic / Presenteeism

It is easy to confuse time spent on a task with the quality of the output and the effort you put in. This is not like overclocking your PC. A bit of voltage here, a few clock cycles there and your PC goes a whole 6.143 per cent faster (don’t tell me you don’t measure to 4 significant figures). Then you hit some timing issue and lose two minutes every time it has to reboot – and 20 minutes of work that autosave didn’t. So there’s a maximum, just like with people. Sadly, the performance is either not visible in terms of work that has to be redone, or far too visible when people quit or seriously lose the plot.

These paired bugs often come from pressure that the manager is himself feeling, which is a relation of the antipattern Garbage in Garbage Out; as a scheduler he is getting bum control data. This is a more awkward bug to fix because you need to reverse the polarity of the neutron flux data flow. Your boss/task scheduler needs to demonstrate progress, which makes visible productivity (VP) our friend. The trick here is to find out what that VP needs to be, because a common reason for this form of panic behaviour is because your boss doesn’t know what bits of the workload are actually cared about by the people who yank his chain. That means sitting down with him to work these out.

That relates to the other cause of presenteeism, which is the opposite of the former VB6 programmer, where the tech you use is utterly outside his understanding so he falls back on the simplest stupidest metric. You fix this by setting expectations, sharing with him that you will do A in X time, B in Y time and making sure you are not bullied into shortening them.

5: The bastard boss

You’re unimpressed with this being the fourth entry which means you are well on the way to being types five, six and seven types of an AntiManager. Bastardity is a measure of scale, not one of correctness. When you spot a variable with the wrong value you don’t say it is “less wrong” because the discrepancy is small; it is right or it is wrong. Did George Boole live in vain?

The consequences may be greater if you’re doing stock control or trading mortgage-backed securities, but the defect itself is independent of the size of the damage it causes and so is the process for debugging. The code is just like your manager - it does not care about the consequences, you do; which is why you need to be objective. So to be blunt, there are no bastard bosses, just crap boss bug fixers.

6: The Priority Stacker

As I showed (in four) you have this bug without even having anyone to boss around. You focus too much on the most important thing and expect me (your humble correspondent) to deal with it first, regardless of efficient schedules. In any environment where changes in objectives happen (like all environments) this means you start and stop things so frequently that you find yourself typing the right code into the wrong function. Thus, your team is thought to be shit because you never actually deliver anything, but are always nearly about to deliver the Most Important Thing.

In multithreaded programming, we sometimes deal with this by increasing the minimum amount of time that can be spent on a task before its urgency is re-evaluated, which means guiding your boss to specific periodic meetings at which things are changed.

Also randomness is our friend here as well; a way to ensure that important tasks that lack urgency ever get done is to occasionally pick one at random and do it. To do this you almost certainly will need to lie, saying that this week’s critical task is dependent upon it. Yes, lie. Call it a white lie if you must, or, as in the first use-case, call it a “wrapper” around reality – but this is for his good as much as your own.

7: Credit Thief

Some bosses try to take credit for every good thing their team achieves, despite my article on getting to the top where I explain how extolling the virtues of your team makes you look a better manager to your peers and bosses. But it appears that some people don’t read my articles, so the first and easy fix is to find a way for your boss to read it – which is, of course, why God invented anonymous email accounts, in case he takes it the wrong way.

Like many of the trickiest bugs, you can argue that this is working as designed and that your role as a foot soldier is to make your boss look good. Even on a purely selfish basis, it helps if your boss is seen as wonderful because it helps him get stuff like pay rises and better office space for you.

8:Daycare Boss

Buggy bosses see their team as burdensome unwanted children, interrupting their real work of networking with the rest of the “management team”, talking to “key business sponsors” or chatting up attractive admin staff.

This is of course analogous to a duff pointer. He’s doing the wrong thing to the wrong objects and the best thing for him is garbage collection. But you don’t have permission for that, so you help him do what he wants to do by creating an increasingly virtual interface to what the team is doing until he becomes as fully disconnected as he clearly wants to be. After all, the whole point of VMs is that no matter how badly they screw up, they don’t affect you.

Reduction of unnecessary information flows will make him happier, as well as making his occasional attempts to actually manage the team less frequent and damaging.

9: The shouty boss

We all lose it occasionally and at one level, showing a bit of passion is better than letting things drift because he doesn’t really care.

You’re not naïve enough to believe the Error Box that pops up when a program dies asking if you want to help Oracle or Microsoft make their products actually work properly? I’ve never got anything useful back from this – nor have you – and HR departments are like that. As one HR director put it to me “my job is protecting the management from the staff.”

Memory protection in Windows/Linux is there for the O/S, not the apps who are terminated if they get troublesome. Recall a few years back when it was disclosed that no complaint for bullying had ever been upheld at the BBC, because as we know TV is such a supportive environment.

A good way of dealing with aggression is contagious sympathy. After a rant ask your boss if everything is OK; this may help you understand what the real problem is, but the payload is that unless he is beyond help, some internal consistency checks will trigger and he may moderate his behaviour.

But if it is getting that unbearable, mentioning gently to others that your shouty boss is under a lot of pressure and you’d like to work out ways of helping him is good team player simulation. Remember that you are being monitored, in the sort of environment where bosses dump this crap on you, and your words will be taken down and used against you.

10: The moron

This is actually the easiest to deal with, just so long as you never ever let them think you’ve worked out that this is their bug.

A good measure of intelligence is the number of things you understand and the depth to which you grok them so lack of intelligence is worked around by keeping the number and depth lower.

This expresses itself in a way familiar to those of you who’ve done search engine optimisation. Identify their buzzwords to work out what I call “Business Correctness,” the more lucrative sibling of the political kind. Despite their track record, Accenture get a lot of business by using words like “team” because managers like teams (defined as doing what they are told) and in your firm there will be terms like “risk reduction”, “delivery” and “cost reduction”. Some even still talk of “quality”.

All you have to do is note these terms and use them more often; firstly to make you look like a “good team player” and secondly as decoration on anything you want to make look better or worse, though in general positive BC words work better.

There are of course more types of AntiManager than this and feel free to share them in the comments below, but the point I’d like you to take away and use is that you can model their behaviour using skills you already have to turn their documented features into something useful.

Dominic Connor has been an occasionally competent CIO in the City as a mismanaged grunt programmer and as a City Headhunter attempts to atone for past misdeeds by helping people get better jobs, or at least less bad ones.

Sponsored: How to Process, Wrangle, Analyze and Visualize your Data with Three Complementary Tools

Biting the hand that feeds IT © 1998–2019