Book Depository: Primal Leadership

This book, by Daniel Goleman, Richard Boyatzis,  and Annie McKee, boasts a handful of plaudits on the back cover. There’s one copy at ROLI and it wasn’t well-thumbed.

If you’ve been assigned a team, and had to steer everybody through the maelstrom of adversity, distractions, and competing opportunities that circumstance will generally chuck your way, this book argues that there are two broad categories of approach. First, the resonant approaches, which are great for teams that are already motivated and capable. Then, the dissonant ones, which are best applied in determined bursts to teams or individuals who aren’t.

Experienced leaders of quality will naturally pick an appropriate style for the circumstance, although different people will have different favourite tools.

The book suggests that there are four resonant styles:

  • Visionary. Persuading the team to buy into an audacious long-term strategy.
  • Coaching. Orienting people to the organisation’s goals, individual by individual.
  • Affiliative. Encouraging harmonious interpersonal relationships to exist within the team.
  • Democratic. Soliciting individual opinions and perspectives.

and two dissonant ones:

  • Pacesetting. Applying aggressive individual targets and grinding these out of the team.
  • Commanding. Providing direction without supplying rationale or getting buy-in.

They are all suitable under certain circumstances and problematic under others. The democratic style, for example, will paralyse an organisation if its survival depends on making quick decisions. Coaching can fail if individuals’ styles don’t match those of the coach, or for people who need regular, detailed feedback and excessive contact hours.

Dissonant styles are great when you think people have lost motivation or are underperforming. They are engaging and can actually help reconcile people with their work, but there’s a risk of damaging the morale of those who feel rewarded when they’re given greater autonomy (most engineers I’ve met are like this).

Much of the rest of the book is about building emotional intelligence through coaching, introspection, and honest solicitation of feedback. Emotional intelligence is the thing that tells you which tool is best to deploy at a given time. There are a few pages explicitly on not being a dickhead, as it’s a poor long-term strategy — but how many tech CEOs, with their shareholdings and their eyes on a lucrative exit, are interested in building companies to last these days?

There’s also a section on why leadership can fail with even the best of styles and intentions. These reasons will be familiar to anybody who’s read MSP or received training in programme management: lack of executive buy-in; failure to align with the culture; failing to motivate people to understand why they need to change their behaviour.

A leader must be part of the team, so that bad news and drifting goals do not get withheld from them, and also so that respect can naturally be cultivated. However, leaders must also be visibly removed from the team. They are concerned about wider priorities, and the relationship of their team to the others, so they must not become engrossed in the minutiae of fine-grained problems and tasks. This is a hard balance to maintain.

Essentially, if you live to learn, you love what your company does, you’re genuinely interested in the welfare and dynamics of your team, and you’re supported by a functional mentorship scheme, you’ll be all right without this book.

At a little under 300 pages, it’s another seam of great information that might have been written as a twelve-page pamphlet, if only they’d removed all the flaccid case studies that people seem to think are needed in a book like this. This book’s volley of supporting stories are so generalised that they are neither memorable nor convincing. Added to this padding is the occasional foray into neuroscience. Without any central thesis about how neural anatomy relates to emotional intelligence, this ends up reading like the marginal scrawlings of a New Ager: it’s all amygdala here and occipital lobe there, and then a digression about radiating spiritual harmony.

So I suppose I’m fortunate that I found this book so hard to digest.

Putting together a new standard

The topic I jettisoned from my talk about MPE at last week’s conference was my thoughts about what makes a good Working Group, as I didn’t want to imply any criticism of the MIDI Manufacturers Association or its members.

As Chair of the MPE Working Group, I neither presume that I can pilot harder projects through technical and diplomatic adversity, nor will I tempt fate by attributing much talent to what might just be beginner’s luck. All I know is that, over the years, I have seen a couple of things.

Some time in the past, I sounded off about what is wrong with MIDI, and every now and then I still do, but always with a veneration for a standard that has managed to age so gracefully while seeing off so many rivals.

The HD Working Group has been meeting at least weekly for more than a decade now to define a successor to MIDI, and we’ve all been waiting, reading, and preparing. It’s not been an easy journey, and HD has recently stumbled at one of the last hurdles. The MIDI Manufacturers Association functions as a democracy of individual companies, and getting a new idea ratified means convincing important stakeholders that they will benefit from your changes and not be threatened by them.

This has always worked for small changes. But a wholesale replacement for MIDI must be non-disruptive, and a non-disruptive replacement is a paradox. After ten years of development, the HD spec is more complex and intimidating than MIDI, there’s no straightforward compatibility between the two, and it’s too new even to be clear how it’ll be used. MIDI has survived nearly 35 years being meddled with and patched up — MPE is just the latest way of doing this.

The HD spec would fix a lot of our problems automatically and for good, but it’s in a tricky place. Every passing year, the tweaks to the old spec gain some ground on the new, and the case for the new diminishes.

Either in its current or a modified form, I want HD to thrive. It seems that there are a few options open to the Working Group to keep it alive, all of which might work, in varying shades of palatability. Some of these are happening, and some aren’t:

  • Keep working on the market model, convincing the company representatives who intend to vote ‘no’ that it’s in their interests to vote ‘yes’.
  • Allow companies to start commercialising the draft specification without permission, on the basis that the first few compatible products will create a small ecosystem, prove a market for HD devices, and establish a commercial case without frightening incumbents.
  • Encourage software framework developers to add implementations of HD to make it easier for third parties to assimilate.
  • Approach a different standards body, such as the USB Implementers Forum or the ISO, to ratify the specification as a standard that is independent of MIDI, and bring it back to the MMA as a fait accompli. This might be less hard, but risks destroying the MMA by driving it into irrelevance (or making it look like this is the intention). Doing so could alienate much of the industry.
  • Go back to the drawing board, and work out a roadmap where MIDI 1.0 can be turned into MIDI 2.0 by backwards-compatible steps, each of which will require a little work in exchange for some exploitable advantages. For example, MIDI 1.1 could mandate full-speed USB, assume bidirectionality by default, revise its note model to support MPE, respond to the System Exclusive Device Inquiry message, and abandon Polyphonic Aftertouch (the messages for which might then be reappropriated at some point in the future). All of these have clear commercial value, ease communication with computers, and pave the way for a ten-year plan of improvement. The new spec gets chucked away, but not the underlying vision, which is actually the important part. Who, after all, knows what the market will need by the time MIDI 2.0 sees the light of day?

The last one would, of course, be terrible. HD isn’t at this stage and I hope it doesn’t reach it. For what it’s worth, though, here is my conclusion from what little I’ve seen of Working Groups.

Creating a new specification is just like software design …

  1. Have a short attention span, because you never know which way the industry will turn tomorrow.
  2. Surgically fulfil specific, identifiable needs.
  3. Always have an up-to-date implementation so that the spec makes sense.
  4. Engineers have enough to learn. Resist the temptation to change established practices. Even if it hurts a bit, make the old spec fit new requirements.
  5. Put something out within a year, or two things will happen: the world will forget you, and the sunk cost fallacy will sink its teeth in. In other words, hardly anyone will volunteer to junk more than a year’s work even when it’s the right thing to do.
  6. Capture neat ideas in a roadmap, and leave space to put them in, but promise as little as possible. Non-essential features should be marshalled into a to-do list for a future spec. They may never be needed in practice, so don’t burden early adopters with them.

… Except for the bits that aren’t.

  1. Keep the door open. Never work in secret or limit discussion. These days, being courteous and responsive to keyboard warriors is part of your marketing campaign. However —
  2. Don’t let your guests take over. Good specifications need clear ownership, so limit scope and limit control.
  3. In this industry, don’t sell your spec for money, as it will need all the help it can get. People have grown very accustomed to getting stuff for free.
  4. Make it really easy. Great documentation isn’t enough these days: people expect TED talks, code libraries, unit tests, and preferably source code for a working demo.
  5. Persistent and contrary people will drive you crazy along the way. It may not look like it, but many of the people that work you the hardest will turn out to be your greatest friends and advocates. Like you, they want this specification to meet their needs and succeed in the wider world, which is why they push back so hard. Do all you can to understand them, be unfailingly polite and positive, and go out of your way to accommodate them if that’s what it takes to keep them on-side.

Book Depository: The Five Dysfunctions of a Team by Patrick Lencioni

The first part of this book concerns an experienced CEO called Kathryn, who is brought in to fix a software company. Agonisingly, she turns around its dysfunctional leadership team, its decision-making, and its results. The second part unceremoniously picks apart the desiccated carcass of the tale, adding worksheets and teaching material.

Pyramids as diagrammatic aids are troublesome at the best of times, as it’s never certain from first glance what the illustrator wants to say about the hierarchy of information. Do we head from base to summit, as one might climb a real pyramid, or is our eye supposed to scan from apex to base, starting with the smallest stage to tackle ever larger ones? How important are the middle sections? How do the tiers interrelate? The Five Dysfunctions themselves are depicted as a pyramid. Thus the only graphical aid in the book requires the whole text to explain it.

Never mind. The core message is that great teams argue, all the time. They argue to determine the company’s goals; they argue to decide how money and time is spent; ideally, they argue without ego. Teams that hold meetings where no conflict happens hold very boring meetings, where nothing is decided, and people zone out, dumbly acquiesce, or cower in fear. Lencioni says that the most fundamental dysfunction is an absence of trust. Problems aired in company meetings matter to everybody, and everybody has a different perspective of what’s important and why, so meetings should be dramatic: full of tension, disagreement and discussion.

Trust is thus drawn at the base of the pyramid. This is the first place you visit when fixing a team, and the thing that must be right before anything else can be addressed. Every member of the team has to trust the others. To invite disagreement, they must allow themselves to be vulnerable to criticism and counter-argument without their openness being abused by ad-hominem attacks or disingenuous political manoeuvring, and this requires responsible facilitation. The antithesis of trust is invulnerability: if you don’t argue, you won’t ever lose.

Absence of trust / Invulnerability

Without complete trust, there cannot be honest conflict. The next stage of the pyramid concerns unfiltered conflict. In a supportive and respectful environment, ideas are primal, truth wins, and it doesn’t matter who has volunteered a suggestion, only how appropriate and useful it is. Conversely, in places where a person can be shouted down for dissent without an adequate counter-argument, there will be people who feel they are being ignored for political reasons. They will not buy into the eventual decision.

Fear of conflict / Artificial harmony

The result of hours of conflict and resolution is a plan that the whole team can commit to. If there isn’t universal agreement, some people will not contribute sufficiently to the plan, so the overall mission of the company will not be coherent or complete.

Lack of commitment / Ambiguity

Commitment to a plan then leads to responsibility to deliver that plan. This means maintaining high standards throughout the whole team, and yet more conflict: holding team members to account if they miss targets, ignore work, or get distracted by other goals.

Avoidance of accountability / Low standards

People may be members of many teams, while also attending to their personal ambitions. One of these teams must come first. If you’re on the leadership team, this your first team. Maintaining trust and confidentiality in this team is paramount because it’s how a company succeeds. It’s important that your team can expect you to work towards the collective goal, that conflict will be handled with discretion, and that the whole team can get on your case if you don’t perform.

While it’s easier to let people pursue individual, ego-led projects than holding them to account when they fail to deliver collective goals, it’s the wrong thing to do. You accept such attitudes at your peril.

Inattention to results / Status and ego

These problems are simple to state but, as we see in other books, it’s not always possible to dismantle political structures that preserve internal truces. Sometimes teams cannot be made to work like this without replacing parts of them, or forcing them to change in the face of an external crisis.