Decisions: Striving for average

When I wrote about how moving from a technical role to a management one is going to suck, I highlighted what I believe is the key reason: it involves a fundamental, religious shift in your personal values and motivation. One example of this is that as software developers, we strive constantly towards a commonly defined and accepted ‘best’ possible solution. In management, there is no such thing.

When I was new into management, I invested a lot of time trying to ensure I was doing the best I could by every single one of my employees because I believed that was my new objective measure of success. At the time, someone passed on the sage piece of wisdom that “if everyone loves a decision you’ve made, you’ve made a mistake”.

During those early years, one of the things I implemented was an employee awards program. I’d read some of the literature around the hazards of replacing intrinsic rewards with extrinsic ones, so my system required that people were nominated only by their peers (rather than management) and there was no monetary prize, just kind words read out at the monthly town hall meeting in recognition of good work.

I remember very clearly my horror when, shortly after the first of these awards, an employee (we’ll call him Jim) requested to speak to me, so he could complain about this new recognition system. In my mind, this was a wholesome, uncontroversial way to give team members a pat on the back. What on earth could Jim be upset about?

In the meeting, Jim pointed out that he had worked alongside one of the people who had been recognised under the new program. The recognition had been for hard work and commitment to reach a critical project milestone. Jim made the point that he had done the same sort of work, on the same project, under the same conditions, but that he had worked an extra few hours in the final week, because his area was one of the last to go through testing and bugfixing. Jim was upset that someone else had been recognised and by implication, he had been excluded.

The bad news: No matter how universally loved you imagine your decision will be, there will always be someone who hates it and thinks you are an idiot for even entertaining it for a moment. Lavish your team with new aeron chairs, free drinks and massages? Well, unless you’re Google, your financial controller is going to come asking questions in very short order.

Flexible work hours for night-owl developers? Project managers will arrive with their new project plans indicating that the impact on the analysts, customer reps and the test team means a revised delivery date of shortly after man has walked on Mars.

The fix: Strive for average. Seriously. You are there to make decisions between competing interests – that’s your job! – and it will almost never be the best option to take one extreme or the other.

You need to be able to weigh the information you have to hand objectively and look for the decision which delivers the best balance of outcomes. In my experience, good decisions are greeted with a shrug of acknowledgement and never spoken of again. If you are cheered and carried off on the shoulders of your audience, the question should arise in your head – what price has to be paid for today’s inebriating adulation?

Sober questions about risk analysis, commercial exposure and fiscal responsibility may face you tomorrow.

Communication: Nobody will understand a word you say

The stereotype of technical experts being bad at human interaction has been around since … well, about 1980, according to Google’s incredible n-gram viewer:

This idea that very logically-minded, rational, analytical thinkers are bad at relating to their fellow human beings is, of course… well, actually, broadly accurate.

While not everyone is as bad as Sheldon, the reason that character works so well amongst the geek population is that we all recognise a little of ourselves in him. The nuance, accoutrements and niceties of common, “real-world” interaction sometimes seem pointless, baffling or stupid to us.  Human communication is a system for transmission and reception of information which, in terms of fidelity, wouldn’t fare particularly well against two tin cans and a piece of string.

Every time you have to communicate with a fellow human being in your time as a software developer, there is a standard which serves to strip away subjectivity, reduce the signal to noise ratio and improve the consistency and quality of the shared understanding of that information. UML, use cases, flow charts, DFDs, ER diagrams – even code itself. These are the standard tools of trade for a developer and we like the certainty they provide.

The bad news: None of those tools exist in management. The effectiveness of your communication as a manager will be not be judged by any sort of objective standard.

“Right” and “wrong” become entirely subjective concepts. Not so long ago, at a company function, I was chatting with some of my closer colleagues – people who share a similar set of views, tolerances and ideologies. People who will be friends even if I leave the company.

One of them was talking himself up long and loud, as he often does. At one point in his monologue of self-adulation, I made the comment “You’re sort of like Jesus, really, only with less crucifixion.” I was joking of course and just doing my best to keep his ego somewhat in check.

The next morning, I had an email in my inbox from someone who had been standing nearby – not in the group, but just within earshot. He had taken offence to my mention of Jesus and the implied blasphemy against the holy word of his religion. He chastised my misunderstanding of the importance of the story of the crucifixion and offered to set me right.  I politely declined, with a very carefully worded email, offering apologies for any unintended offence.

Obviously I had no intention to offend with my comment, but simply by overhearing what I’d said, I’d managed to offend someone. In the world of management, this issue arises constantly.  The intent of the message behind what you say and the perception of the message by those who hear it may be poles apart, depending on a huge range of personal context factors. In this case, the issue was resolved between the two parties involved, but I have seen similar situations escalate to HR remediation and beyond, into the realm of legal action.

The fix: You know how you’ve been making fun all your life of ‘management-speak’? How managers hedge their words and don’t just come out and say what they mean? You’re going to need to do that. An understanding of language is going to be critical to how you are perceived.  Forwarding around “inappropriate” jokes or images just went from being a cheeky way to build camaraderie with your colleagues to a risky, potentially career-ending move.

You’ll need to build a variety of communication styles which you can employ, depending on the situation. When you’re speaking to large groups, you have to be most careful. Emails, read twice before sending – they are a permanent, archived and therefore retrievable record. You can drop your formality among close colleagues, but as my experience shows, even then you need to be careful who is standing nearby.

Feedback loops: Error 504, forever

One of the key elements of an efficient working environment for a developer is feedback loops which are as short as possible. When I was writing code daily, I invested what I thought was a fanatical amount of time and effort in reducing the overhead of every dev-related cycle.

Checking out, writing code, compiling, stepping through, altering code, spinning up remote resources, rebooting web servers, restoring test databases, checking in – everything was automated and stripped down to the shortest possible cycle time.

Then I started working with some other very senior developers – and really learned the meaning of fanatical. Macros, keyboard mappings, shelling out to scripts… they took the art to a whole new level. Seeking out short feedback loops is instinctive for developers. It is fundamental to our productivity and helps keep us in the zone.

You can often distinguish a good developer from an average one, by what they do when they encounter long feedback loops. Average developers climb on chairs and start sword-fighting. Good ones are working on the build script, so they don’t have to wait so long next time. They are fundamentally motivated by the results of that loop and it is simply instinctive to reduce the time it takes for those results to be returned, in any way possible.

The bad news: Nothing you do in management will have a short feedback loop – at least not in terms of time frames you are used to. Development loops range from sub-second up to minutes at the very most. For management decision-making, the range runs from hours to never – and it’s almost always never. Because a corollary to long feedback loops in management is that you will also never, ever be sure that a decision you made actually caused the outcome you observed later. Developers drink directly from the bottle of job satisfaction when it comes to identifying, working on and fixing problems. Managers are left sucking the dregs out of the carpet. A week later.

The fix: You quite simply have to let go of this one. You need to focus on acting through others and thinking in the long term. If you find yourself thinking “it would just be quicker to do it myself”, stop. It may be quicker this time, but what about next time? And the time after that? Working through others means you have to build knowledge, skills and understanding in your team, even if it pains you to watch it first time around.

Perversely, you also need to drop your standards. Your team will have a variety of skill levels within it and sometimes the junior dev won’t write code to the standard you would have yourself. Participate in code reviews, provide feedback and concentrate on the team, rather than the task.