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.

The beauty of buzz-words

Why buzz-words and management-speak flourish, despite universal hatred for them.

The internet is replete with shouty, angry blog posts decrying the overuse of buzz-words and management-speak. There are people who have dedicated time and effort to creating buzz-word phrase generators, as a demonstration of the meaninglessness of such drivel. I myself once penned an ‘easy-reading policy” which explicitly precluded the use of an ostentatious word, where a plain one would do.

In fact, I don’t think I’ve actually ever met anyone who would openly say they were in support of management speak – have you?

And yet, despite this complete lack of support from the general population, the phenomenon persists. And thrives. I am constantly encountering new buzz-words, new “management speak” phrases, new clichés, new business jargon. Nobody I speak to in the industry is even vaguely making an effort to eliminate this element of their speech.

Why is that?

There are two reasons:

Management speech is an adornment of language which communicates the competence of the speaker, regardless of the content.

A familiarity with these buzz-words, empty phrases, clichés and jargon shows that the speaker is an expert in the realm of business. This phenomenon is not limited to managers. Every field of human endeavour has its own lexicon of terms, meaningful to its experts and inscrutable to others. In a beautiful meta-demonstration, the concept even has its own meme:


In a fundamentally linguistic way, saying “going forward” instead of “in future” is identical to saying “the genoa halyard” instead of the “the blue rope”. The actual information contained in the phrase is the same in each case, but I know which would give me more confidence in the nautical expertise of the speaker.

Management-speak can be an effective shorthand for a complex concept.

Jargon can act as a place-holder for a concept which doesn’t otherwise have a short, succinct expression. Can you think of a phrase which means “run the numbers”, but is shorter than that? “Ask our accountants to put together a spreadsheet of the relevant figures”? “Look at the costs in detail”? Neither of those phrases contains a single buzz-word, but they are undeniably more cumbersome and unwieldy as a result.

In the same way that a picture is said to be worth a thousand words, buzz-words and management-speak often reduce complex concepts to a familiar shorthand, easily and instinctively grasped. You don’t need to know anything about marketing or sales to understand that “low-hanging fruit” means “stuff that is easier to get to than other stuff”. Nobody would sensibly get behind a project which aimed to “boil the ocean”. These phrases create an image in your mind’s eye which effectively communicates the intended meaning, without requiring an MBA.

Additionally, sometimes the phrase doesn’t only provide a shorthand communication of an otherwise more complex concept, it also adds tone – an important factor in business and management communication. The much-maligned “going forward”, used as a synonym for “in future” doesn’t just replace that meaning, it adds movement and a sense of intent.

Now don’t get me wrong, I’m not saying that everyone who uses management-speak does so mindful of these factors. There are certainly those who are emptily parroting these phrases in place of actually saying anything meaningful. But the concept of management-speak itself isn’t the issue there – it’s the management doing the speaking.

Stephen Fry, for those of you familiar with him (and for those who aren’t, please stop reading this, go find his stuff, it’s much better) is the sort of person you might expect to be particularly pedantic about the use of language and the unnecessary re-arrangement of words for no other reason than to give managers a new way to say the same thing. You may be surprised to hear, then, that Stephen is, broadly, in support of the creative use language, over pure adherence to technical correctness.

“It is a cause of some upset that more Anglophones don’t enjoy language”

Perhaps we can stop thinking of management-speak as unnecessary obfuscation and see it instead as adding colour to what can otherwise be the grey, monotonous language of business meetings. Remembering, of course, to maintain a ruthless scrutiny of those who use it to replace, rather than enhance, meaning.

Management: How hard can it be?


Are you considering a career move from software development* into management? Perhaps you feel you’ve reached a roadblock or dead-end in your technical career path? Or a manager has left your organisation and your seniority and/or tenure means you have the opportunity to take up the role? Perhaps it’s your first step on the management path – a team lead or project lead role?

Well, I have some bad news. Technical skill and seniority does not translate into managerial aptitude. In fact, the better you are at your technical role right now, the worse off you will be as a manager. And it gets worse: If you are an awesome hacker, chances are you will not only suck at management, but you will also hate it with a passion.

In 2001, I was working for a major bank in the UK, on a huge internet banking project. We had a team of over 200, with the project being run by one of the ‘Big 8′ (as it was at the time) consulting firms. My role was initially mostly technical – I spent almost all of my time designing algorithms and writing code. Over the course of the project, the seniority of my role grew; by the end, I spent most of my time dealing directly with the business and project management team.

My lasting impression of management at the conclusion of that project was very simple: these people have absolutely no idea what software development is and no idea how to manage a software development team.

Don’t get me wrong, they were nice, friendly, earnest people. They were honestly trying to achieve the best possible result for the business and the project, but they were failing in so many ways to connect with the development group that I was just baffled. How could these managers, many of them with dozens of years of experience, be so bad at this? At lunch, the dev team would uniformly gather together and bitch about the latest management decisions, conjecture on the cost in wasted time and money and collectively boggle at how such seemingly fundamental mistakes could be made.

When I was at university, a couple of mates and I had established a rule which has served me well since then. If one of us complained or bitched or moaned about something long or often enough, he could be called out on it with a standard question: “So what are you going to do about it?” I love how simply this question shifts the conversation. You’ve bitched enough. Either you think this issue is worth taking action over, in which case do it. Or you don’t, in which case, please shut up about it.

So when that project wrapped up, I returned to Australia with one thought in my head: get into management. I mean, how hard could it be?

Turns out, quite hard.

With fifteen years’ experience managing technical teams now behind me, I have what appears to be a relatively rare combination of technical and managerial experience. I’ve been part of the solution architecture group on international, multi-year, multi-million dollar projects and I’ve also managed diverse teams of over 100 technical staff.

A shift from a technical role into a management one doesn’t just require you to manage your time differently. It doesn’t just require a new set of skills, or using different buzz-words. It requires a fundamental re-wiring of your core beliefs. It’s not a vocational shift, it’s a religious one.

At the core of almost everything we do as software developers is a simple principle: meritocracy. The belief which underpins this is that there is an objective way to judge the value of what we are doing. Given a particular context, we can compare competing proposals and select the better of the two. We constantly strive to move towards this ‘better’ end of the scale in our skills, our tools, our methodologies and our solutions. Personal status, rank, experience, tenure – all are meaningless, save as rough heuristics for who gets listened to first. It’s the idea, the concept, the design, the implementation, the explanation – the value – which wins, not the person. Objectivity is king.

This view of our art is diametrically opposed to that of management. In management-land, context and value are fluid concepts. Relationships, whether commercial, professional, social or political, are the driving force. Perspectives and perceptions combine, conflict and criss-cross, constantly changing, to create a shifting web of motivations. Selecting which motivation to act on is a subjective fishing trip in an ocean of subjective interpretation.

Never was this more starkly demonstrated to me than in 2012, during an exchange I had with the General Manager of my division. A few weeks earlier, in our weekly catch-up, he mentioned that he felt we had a “delivery quality” issue in one of our regions. That team reported to me, so obviously I took the news seriously and asked him why he had that impression. He told me that there had been reports that we were issuing a lot of credits – essentially refunds – on work done in that region recently.

Hearing his reasoning, I immediately relaxed. I knew that any credits had to go through me for approval and that there had only been one which had. It was for a very small amount and was due to the poor performance, over a year beforehand, of an employee who had since left the company. I also had very good knowledge of how the accounting process worked for this region – credit entries on the P&L were quite commonly just the result of accounting adjustments being made (for example correcting a double-billing error from the previous month). I knew with certainty that these credits didn’t mean we had an issue with the quality of our delivery.

I detailed all of this in broad terms to the GM and figured that would be the end of it. The delivery team certainly couldn’t be blamed for an artefact of how our accounting process worked.

Over the next few weeks though, the GM continued to repeat the mantra that there was a delivery quality issue in that region. He brought it up in a number of different meetings, to a variety of other managers and stakeholders – including upwards reporting to the Group General Manager. I was baffled. He was doing reputational damage to this team across broad sections of the business, even after I had explained the situation. I urged him on a number of occasions to review the credit list for accounting adjustments, rather than to continue to report that there was delivery quality issue – to no avail.

For our next scheduled catch up, I went and got the credit list myself. I categorised each entry, along with evidence of the accounting adjustments and why they were being made. I was ready once and for all to put the issue to bed.

After I presented the data, along with my detailed analysis which categorically proved there was no delivery quality issue, he said something I will never forget: “I understand what you’re showing me, but I’m not the sort of manager who makes decisions based on these kinds of facts. I’m more of a ‘gut feel’ sort of person and my gut feel tells me that we have a delivery quality issue in that region.”

I still tell this story today, particularly to people with technical backgrounds – the punch-line always gets a laugh. To them, it’s an almost-perfect real-world manifestation of Dilbert’s PHB.

Once you finish laughing though, it’s worth considering that many managers would not see any issue with what that GM said. Their value to their organisation is their subjective judgement – being able to draw their own conclusions from a range of inputs, even in the face of overwhelming evidence to the contrary. It’s seen as ‘strong leadership’. Glossy business literature is rife with stories about managers who trusted their gut when all the evidence was against them – succeeding despite the odds.

This is the cognitive dissonance you will need to resolve, as you take up management duties. Very rarely is any managerial decision-making done based on anything which could be called objective data. Pursuit of certainty is almost always counter-productive. It is too costly, takes too long and is anyway probably irrelevant by the time you achieve it.

You’ll need to make frequent, rapid decisions, based on competing expectations, considering relationships first and you’ll never, ever, be (completely) right. Welcome to management.

*I imagine this concept applies equally to other technical fields, but I have the greatest depth of experience with software development.