The crippling cost of free

Business will see delivery team’s function to “deliver”, but all teams do many other functions – most of which fall outside normal controls.  They aren’t products, projects, epics, stories – they’re ad hoc requests.

  • Requests for estimates/quotes
  • Requests for technical options/investigations
  • Recommendations
  • POCs
  • Re-prioritisations
  • Response to customer requests

The common link is that there is little or no visibility of cost to requester – all cost is borne by the delivery team and rarely tracked as “real work”.  Friction can arise when it is not clear to the business the volume and content of work being executed outside of that which is monitored and reported on (e.g. in burndown charts, project plans, etc)

Spikes are somewhat analogous within agile methodologies, but often these requests are additional or external to the methodology.

Symptom is unhappy stakeholders – slow turn-around time for responses, key resources become unavailable or ineffective, unable to access technical skill sets they need to address customer (and potential customer) requests

Potential solutions

Try forming a group who has specifically allocated time for dealing with these items – they’re the interactive interface to the business, protecting the delivery team who are focused on delivering agreed work

May have different rhythm to delivery group – shorter turn-around, daily/bi-weekly/weekly as opposed to sprint cycle

Invite stakeholders and visualise workload – kanban/WIP management better than burndown/scrum, offload prioritisation onto stakeholders – you want to prioritise, what do we drop out?

Systematise common components – quotes, technical documentation for inclusion in customer responses, types of analysis/investigation (1, 3, 5 day spikes) with risk factors and criteria defined and understood

 

The Zone: Banned for life

As a developer, you need long, undisturbed periods of time in order to concentrate on the problem at hand. Your best, most productive time is when you are in ‘the zone’.

Any developer worth their salt has experienced this state, where the outside world disappears, you’re holding 20 variables in your head at once and are being incredibly productive. A lot of job satisfaction is generated from this place; I personally equate it with the creative satisfaction that artists experience. It’s powerful stuff.

The bad news: To introduce even minor managerial responsibility – say a team lead role – into your job description, is to receive a lifetime ban from ‘the zone’. Once you become a hub for communication and decision-making, your chances of getting enough unbroken time to get into that effective, productive state are effectively zero. You are likely to be regularly frustrated at the constant interruptions of your colleagues.

The fix: I’m afraid the only effective solution I’ve seen to attempting to split your time between coding and managing is to give up on one or the other. If you’re attached to the management element of your role, you should seek to also ramp up other non-coding activities that can be completed in shorter bursts.

Design, documentation, code reviews, coaching and client interaction all fall into this category. If you’re attached to your coding, don’t be afraid to say as much and just pass up the whole management thing altogether.

Maker’s schedule vs manager’s schedule: http://paulgraham.com/makersschedule.html

 

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.

The beauty of buzz-words

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:

pancake-bunny
http://knowyourmeme.com/memes/pancake-bunny

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.