TL;DR

Leadership and management are distinct but interconnected disciplines, and for various reasons engineers can struggle with both. My military background means that I’ve been fortunate enough to go through a few passes of structured leadership training. Some of that has been very helpful, some not so much. Engineers want to fix things, but working with other humans to make that happen isn’t a simple technical skill as it requires careful understanding of context and communications – something that situational leadership provides a model for.

Background

A couple of things have had me thinking about leadership in the past week. First there was Richard Kasperowski’s excellent ‘Core Protocols for Psychological Safety'[1] workshop at QCon London last week. He asked attendees to think about the best team we’ve ever worked in, and how that felt. Then there was Ian Miell’s interview on the SimpleLeadership podcast that touched on many of the challenges involved in culture change (that goes with any DevOps transformation).

My early challenge

I joined the Royal Navy straight from school, going to officer boot camp at Britannia Royal Naval College (BRNC) Dartmouth. I did not thrive there, and ran some risk of being booted out. On reflection the heart of the problem was that I was surrounded by stuff that was broken by design, and the engineer in me just wanted to fix everything and make it better.

A picture taken by my mum following my passing out parade at Dartmouth

I was perceived as a whiner, and whiners don’t make good leaders. The staff therefore had concerns about my leadership abilities[2].

One of Amazon’s ‘Leadership Principles‘[3] appears to be expressly designed to deal with this:

Have Backbone; Disagree and Commit

Leaders are obligated to respectfully challenge decisions when they disagree, even when doing so is uncomfortable or exhausting. Leaders have conviction and are tenacious. They do not compromise for the sake of social cohesion. Once a decision is determined, they commit wholly.

Basically – don’t whine once the decision has been taken – you’ll just be undermining the people trying to get stuff done.

My opportunity for redemption

Because I was so bad at leadering the Navy sent me for additional training on Petty Officers Leadership Course (POLC) at HMS Royal Arthur (then a standalone training establishment in Corsham, Wiltshire). Dartmouth had spent a few days teaching ‘action centred leadership‘ (aka ‘briefing by bollocking’) – it was all very shouty and reliant on position power (which of course officers have). POLC was four weeks of ‘situational leadership‘, where we learned to adapt our approach to the context at hand. Shouty was fine if there actually was a fire, but probably not appropriate most of the rest of the time. I learned two very important lessons there:

1. Empowerment – seeing just how capable senior rates (Navy terminology for NCOs) were, it was clear that in my future job as their boss I mostly had to get out of their way.
2. Diversity – the course group at POLC was pretty much as diverse a group possible in the early 90s Royal Navy. We had people from every branch, of every age, and at almost every level[4]. It was here that my best team ever experience referenced above happened, which in some ways is strange as we formed and reformed different teams for different tasks across the four week course. One thing that made it work was that we each left our rank badges outside the gate, as we were all trainees together. Over the duration of the course the diversity of backgrounds and experience(s) really helped to allow us as a group to solve problems together with a variety of approaches.

Putting things in practice

Years after POLC, when I made it to my first front line job, an important part of my intro speech to new joiners was, ‘my only purpose here is to make you as good as you can be’. This was very powerful, my department mainly much ran itself, I provided top cover and dealt with the exceptions, and my boss was able to concentrate on his secondary duties and getting promoted. Pretty much everybody was happy and productive, and along with Eisenhower’s prioritising work technique[5] I had an easy time (which became clear when it came to comparing notes with my peer group who in some cases tried to do everything themselves).

Influence and the (almost) individual contributor

It turns out that first front line job at sea with a department of 42 people was the zenith for my span of control in any traditional hierarchical management context. I’ve continued to be a manager since then, but typically with only a handful of direct reports and little to no hierarchical depth. In that context (which is pretty typical for modern technology organisations) it turns out that leadership can be much more important than management. Such leadership is about articulating a vision (for an outcome to be achieved) and providing the means to get there (which more often than not is about removing obstacles rather than paving roads).

This is where engineers can show their strength, because the vision has to be achievable, and engineers are experts in understanding the art of the possible. From that understanding the means to getting there (whether that’s paving roads or removing obstacles) can be refined into actionable steps towards achieving outcomes. The Amazon technique of working backwards codifies one very successful way of doing this.

The point here is that leaders don’t need the position power of managers to get things done, and that situational leadership presents a better model for understanding how that works (versus action centred leadership).

Conclusion

Engineers typically have an inherent desire to fix things, to make things better, and early on in their careers this can easily come across badly. An effective leader understands the context that they’re operating in, and the appropriate communications to use in that context, and situational leadership gives us a model for that. Applying the techniques of situational leadership provides a means to effective influence in modern organisational structures.

I was very lucky to be sent on Petty Officers Leadership Course – it was a career defining four weeks.

Notes

[1] Google have found that psychological safety is the number one determinant of high performing teams, so it’s a super important topic, which is why I wanted to learn more about the core protocols. This is also a good place to shout out to Modern Agile and its principles, and also Matt Sakaguchi’s talk ‘What Google Learned about Creating Effective Teams‘.
[2] In retrospect things would have been much easier if somebody (like my Divisional Officer) had just sat my down and said ‘this is a game, here are the rules, now you know what to do to win’, but it seems that one of those rules is nobody talks about the rules – that would be cheating.
[3] At this point it’s essential to mention Bryan Cantrill’s must watch Monktoberfest 2017 presentation ‘Principles of Technology Leadership‘, where he picks apart Amazon’s (and other’s) ‘principles’.
[4] Whilst ‘Petty Officer‘ is there in the course title attendees ranged from Leading Hands to Acting Charge Chiefs (who needed to complete the course to be eligible for promotion to Warrant Officer).
[5] When I first heard about this technique it was ascribed to Mountbatten (I’m unclear whether it was meant to be Louis Mountbatten, 1st Earl Mountbatten of Burma or his father Prince Louis of Battenberg) – the (almost certainly apocryphal) story being that as a young officer posted to a faraway place he’d diligently reply to all his correspondence, which took an enormous amount of time. On one occasion the monthly mail bag was stolen by bandits, leading to much worry about missed returns. Later it transpired that very few of those missed returns were chased up – showing that almost all of the correspondence was unnecessary busy work that could be safely ignored. It’s interesting to note here that POLC was created at the behest of Lord Louis Mountbatten and Prince Phillip was one of the first instructors.