Why accountability without empowerment is a sign of a toxic culture

TLDR; you can’t expect accountability without giving people context and freedom first.

Accountability: the fact or condition of being accountable; responsibility.
Autonomy: the right or condition of self-government.
Empowerment: authority or power given to someone to do something.

Accountability, autonomy and empowerment are words often used by organisations, used more frequently in isolation than together, to describe to their employees what they want from them. A value on their manifesto that they expect their employees to portray. The problem is, these concepts are interdependent. Expecting autonomy without accountability is a recipe for disaster. Expecting someone to be accountable without empowering them with the tools they need to succeed and the psychological safety that makes it ok to make mistakes is at best lazy leadership. Through my own personal experience of varying organisational cultures, I’ve captured a few brief thoughts on how this applies to my industry.

Accountability

Accountability is a concept I explore often. In coaching and mentoring, an extremely important part of the mentee achieving their goals is helping them to realise they need to be accountable for the journey. It’s also sometimes an uncomfortable part of management, to ensure team members commit to their own goals that they’ve set themselves. It’s a key part of developing as a leader, a point beautifully described in the 15 commitments of leadership (I wholeheartedly recommend the book) and dozens of other self development books. I’ve seen it go horribly wrong however when leaders make a team “accountable”, but flip a table when they take a risk, or worse don’t do the thing exactly how the leader described.

Autonomy

Got it, so we should just give employees complete freedom right?! 

Well not exactly. Reed Hastings, CEO of Netflix, in his book No Rules Rules talks about how “Freedom and Responsibility” is a little more complex than that. Hiring the right people, making feedback safe and eliminating controls are the foundations for giving autonomy through empowerment and accountability. While I wouldn’t recommend some of the practices he puts in place (like firing people on the spot if they’re not the right fit), I’ve been lucky enough to work in a purely generative culture too, and I can say that there are striking similarities between methods used in the book and “real life”.

Empowerment

The empowerment part is important. We need to get this in place before we expect any kind of accountability from our teams. In software development, we often use DORA’s State of DevOps research programme for highlighting the capabilities that are indicators of high performance in software delivery. Culture, including psychological safety which is so important in assessing a team’s feelings of safety and empowerment, is shown to be predictive of software delivery performance.

“According to research by DevOps Research and Assessment (DORA), organizational culture that is high-trust and emphasizes information flow is predictive of software delivery performance and organizational performance in technology”

https://cloud.google.com/architecture/devops/devops-culture-westrum-organizational-culture

When Mike gets his crayons out…

Westrum’s organisational culture a typology used for categorising organisational cultures into groups that illustrate a maturity level towards high-trust generative culture. You’ll see from the table below that there are many aspects in this table that are indicators of empowerment and accountability – or lack of it.

Table showing Westrum's typology of organisational culture
From Accelerate: The Science of Lean Software and Devops: Building and Scaling High Performing Technology Organizations

I’ve included a fourth model from experience in addition to the typology above, of which I’ve definitely been subject to:

I’ve mapped these four culture types onto a rather crude chart to show where each of them lie on an accountability / empowerment matrix:

The culture autonomy chart. Generative cultures have both high accountability and high empowerment, enabling a high degree of autonomy.

Some examples of the culture autonomy chart:

  • Generative Culture – “That was a great idea. Sorry that it didn’t work but it looks like the potential reward was worth the risk, good call. Let’s look at what we’ve learned from this.”
  • Bureaucratic – “I knew that wouldn’t work. I was just giving you a learning opportunity. You know that Dave on the testing team already tried that, don’t you?!”
  • Pathological – “How did you fail, I told you exactly how to do it! I need to tell the directors that it was your fault now or it will make me look bad!”*
  • Laissez Faire – “Who are you? Oh right, the guy with the ideas. You failed? No problem, go try another one. See you in a few months”**

*true story, unfortunately
**Also true story, though infinitely more fun than the previous one

As the global landscape tells us frequently, freedom does come at a price. Even in truly generative cultures there are expectations and obligations that come with autonomy, and consequences for not fulfilling these expectations. The difference in good cultures is that these expectations are instilled not through the carrot or the stick, not by adding extra processes that stifle innovation, but by good communication and leaders living good cultural values by example.

You can either be right, or you can be happy

On how being self aware is a bitch, why wanting to be right all the time is bad, and what that has to do with anything

The cruel irony about trying to become more self aware is that it makes you more aware of the dick moves that you’ve been making in your life until this point.

I recently started reading “The 15 Commitments of Conscious Leadership”. In it, it describes 15 principles which leaders should consciously commit to, prioritising responsibility and curiosity – the ability to be curious, rather than to be right. As I listened to the audiobook, something started feeling pretty uncomfortable. I started to dictate notes to my phone while I was driving, something I don’t often do unless what I’m listening to is really good. 

Paraphrased transcript of resulting conversation to sibling:

Me: “I’ve just realised, I think I often have an overwhelming urge to be right a lot. Do you get that?”
Sibling: “BWAHAHAHAHAHAHAHAHA”
Me: “Hmm. That’s not good. Why didn’t anyone ever tell me?”
Sibling: “I think we get it from mum tbh.”*
* That line was tongue-in-cheek – my Dad was biblically stubborn, and got pretty upset when other people couldn’t see his viewpoint.

Well shit. Another one to add to my development list. It’s already got “accountability”, “discipline” and “courage” on it. I liked it better in the good old days when I was in ignorant bliss about my emotional intelligence, and had no appetite for self-improvement. Well, not really, but it was definitely easier.

Common sense aside, it’s not as if it’s the first time I’ve read about this – Adam Grant’s “Think Again” is a great example with an entire chapter dedicated to “the joy of being wrong”. The book is about how not to define yourself by your beliefs and perceptions, and to seek out alternative viewpoints. But for some reason (maybe the slight tinge of spirituality in the authors’ explanation resonated with my faith), it only took two chapters into 15 commitments to trigger another back-to-the-drawing-board moment.

My wife of course has pointed this out on many occasions, having known me for 12 years, and of course I told her she was wrong. I know that she’ll read this and help me be accountable for making change. I’m way better at managing this at work than I am at home, but one thing I’m sure of in life is that you need to be your authentic self everywhere. It’s a lot easier making a change at work if you’re in a position of privilege or authority (I definitely do not have this at home).

I should probably link this to my industry at some point. Well, possible examples where people (who may or may not be me) have reacted the wrong way when they’ve been “right”:

  • When the sales / product team sell something without talking to the engineers about how long it will take
  • When developers’ unit tests weren’t “proper” unit tests and they needed to be written again
  • When leaders’ legitimate errors were pointed out to them at face value, sometimes in front of others (the moral high ground is a very lonely one)
  • When a solution has been architected the “right” way, but the business won’t sign off on it because it’s going to take too long

And the rest. Let me know if you can think of any common ones in the tech industry!

What can we do about it?

Wanting to be right is human nature. There is nothing inherently wrong with it. The damage comes when we are defensive, threatening, or even lie to twist the argument to make it sound as though we are right. We mix so much of our identity with our beliefs and ego that we physically feel threatened if they are challenged. Greater minds than me have talked about how we can work to avoid this and the books above are a good start. I’m not a fan of recommending “self-help” books but The Four Habits That F*ck You Up is rather good and rather funny, with some guidance about replacing your “Dogmatic Demands” with “Flexible Preferences”.

We mix so much of our identity with our beliefs and ego that we physically feel threatened if they are challenged

Me? I have an app called Habitica that’s a really fun way of gamifying your habits, and you gain or lose points depending on whether you’ve performed a good or bad habit respectively (for instance, I lose 4 points now if my need to be right causes me to flip a table). Also, I reflect every week using a personal survey relating to the things I think are important right now, commenting on things like how I’ve helped people, how much discipline I’ve had, and now how I reacted in situations where my beliefs were challenged.

And of course, it’s now open season for my family to keep me accountable for being “curious”. 

“You can either be happy or you can be right” is a deliberately provocative title. It is an adage often used as a humorous observation of dynamics in a relationship, but even then I don’t think it’s either-or. There is as Grant says joy to be found in being wrong. There is a time and place to stick to your guns – when fighting political / social / racial injustice, being a good Ally, and so on. But in the interests of creating and sustaining relationships, particularly in leadership, we need to embrace the spectrum in between right and wrong, and respect that the University of Life is always trying to teach you something new.

Photo banner courtesy of https://pixabay.com/users/ryanmcguire-123690/

Lessons from trying to be Agile in a Waterfall industry

Nine months ago my journey led me back into R&D in the life sciences industry, working with (amongst other things) software in a medical setting. The healthcare industry is clearly heavily regulated. Moving from releasing web products several times a week to software that’s released a few times a year (if you’re lucky) has been an eye opener. 

Tasked to bring in a new process, it would have been easy to slip into the wrong mindset – long spells of developer work, followed by copious manual documentation and a throw over the fence to a testing team for a few months. A few post-deadline back-and-forths between testers and developers thrown in at the end for good measure, obviously. I’ve seen it happen with installed software in far less regulated industries, and frankly, there’s rarely an excuse for it. Seven months later, we gained our ISO 13485 certification using the agile process we created. 

If you work where you don’t need to worry about your software telling someone they’re ill or not, and the thought of deploying anything less than daily horrifies you, this post might not be for you. It is interesting however that many of the fundamental principles and practices still (or should) apply even in a regulated industry. How did we steer clear of the waterfall trap? Here are the lessons we learned:

1. Get the right quality team

It would be easy for a quality team to force a process upon a new software team because that’s the way that they validate everything else – usually by using a hideously inefficient and burdensome quality software. Whilst that definitely exists, we were lucky enough to have a quality manager working with us that saw the need for agility, and how the systems that we implemented (in this case Azure DevOps) were a better match for compliance in an agile software development process. Having a quality team with this flexible mentality is crucial, and may require a lot of dialog upfront before anything new is implemented.

2. Get help from subject matter experts

Just to make sure we were on the right track, we consulted an external embedded software house that had experience implementing agile processes in the medical industry. There’s no way I was going to wave the Agile card if what we were proposing wouldn’t actually meet regulatory requirements. Luckily, there is a highly respected set of guidelines that offers some fantastic direction on the use of Agile practices in the medical industry (though the fact they felt the need to capitalise AGILE still drives me crazy).

3. Use DevOps practices

Turns out that if you follow the same good DevOps practices that high performing teams do, you’re most of the way to being compliant anyway. I was confronted with the unfortunate reality that most of our instrumentation products shared the same code repository, and relied on a gatekeeper to manually build the code in the correct configuration to produce the right product. The first task was to create a “master” build in Gradle that would take parameters based on which flavour software we wanted to build. Then, a separate build pipeline was built for each software flavour that built their respective installers and artefacts. We could then connect this to release pipelines for each flavour and have a record of all work items, pull requests and artefacts linked to a particular release was given to the validation team (and yes, there are rare occasions where a separate testing team makes sense – like when developers can’t use a pipette and people’s lives depend on it).

If you want to learn more about how good DevOps practices lead to high software delivery optimisation, read Accelerate or the latest State of DevOps report at the time of writing.

Start measuring your shippable work items so you at least know you’re moving the needle on deployment frequency. While a 10 day average isn’t ideal from start to ‘done’, it’s better than 60, and it’s getting more consistent.

4. If you don’t store your documentation in your QMS, you’re not going to burn.

Living, accessible documentation is essential for software teams to be agile. It’s no good gathering cobwebs in a quality system that takes an age to find anything (or worse, no one has access to). If you want to change your branching strategy slightly, you don’t want to be spending weeks getting a change approved by a QA who knows nothing about branching strategies.

Here is a blog by the consultancy I mentioned previously on the topic of living documentation for software teams in regulated industries. The idea is that your wikis / repos / markdown files are absolutely fine, as long as they’re kept up to date and go through a robust, audited pull request procedure and you’re able to produce them in an auditor-friendly format. This can all be automated, and in my experience, most modern software lifecycle systems are more secure and auditable than many quality systems on the market anyway.

5. Definition of Release

In healthcare, you’re not going to be releasing a product to a customer multiple times a day. At least not one that’s locally installed in a public sector environment. You generally have little control over the appetite for change of the various governing bodies and indeed individual sites. So then how can we conceivably aim to be an elite performing team according to the widely accepted DORA metrics? You aim to use all the previous steps to create validated, tested, shippable increments anyway. I mean everything – review lifecycle, packaging, deployment to an immutable release pipeline and signed off – preferably with automated documentation and release notes. If there’s a regulatory blocker, or the customer is simply reluctant to update their procedures with a new software module (even if it has features in it they’ve requested and want!), you’re still safe in the knowledge that those releases have gone through a complete release process in isolation and are ready to go. For us, that’s “production”. Just don’t let it end up like this:

https://www.comicagile.net/comic/done/

In summary

In the time that we’ve had I’m pretty proud of my small team taking a 12 year old codebase that had no automation to speak of into a cloud-first, DevOps driven compliant process. Not only that, but we’ve learned a ton going through this process that will help us build our next generation of digital products. 

We’ve still got a long way to go. If anyone has any other insights in remaining agile in a medical setting, or you can see some hideous oversights in these lessons, please do let me know. Just don’t be mean.

It’s a cliché, but don’t accept the status quo or your environment as an excuse to abandon an agile mindset. Get the right people around you, make noise, and move the needle – one day at a time.

Why we should think before labelling someone as a millennial

My degree was in astrophysics. When I mentioned that I studied astronomy to people, the response, “can you read my horoscope?” was more common than I’d have liked. Why did that bother me? It wasn’t that people didn’t know what astrophysics was, or even that they were probably just trying to wind me up (success). It’s the idea that a huge swathe of the population can have the same characteristics based on when they were born. This perception is particularly bad news for Virgos in China applying for a job, for instance. So, when a seasoned manager described me as a “millennial” based on my wanting to understand the feelings of people, I set out to figure out why that evoked a similar response and why something so seemingly harmless could be a problem.

In the discussion, I was describing the Insights Discovery colour wheel (other personality profiling tools are available), explaining that I tend to align with the supporting-coordinator role. I explained that while this doesn’t define me, it indicates that I have strengths such as empathy, and taking a coach-first approach. I’m concerned with how people feel, myself included. The response was, “Oh, you’re definitely a millennial then”. They might as well have said, “Ah, got it. You’re a Taurus.” (I am, by the way).

Insights Discovery personality types https://www.wearebowline.com/blog/8-personality-types-a-deeper-dive-into-insights-discovery/

There’s absolutely nothing inherently wrong with what the person did here. There was no call-out needed, no discriminatory slur, and to be crystal clear, I am not comparing this to any experience of marginalised or persecuted groups (based on race or gender for instance) who are still unfortunately attributed to dangerous labels on a daily basis. So why then in this “harmless” case can labelling still be damaging?

The story that I told myself I heard was, “Oh, you value people and care about how they feel? That’s a weird thing for a manager to do. It must be because you’re a millennial”. Far-fetched, I know (we’re all human, and we all fill in the blanks with stories). Even so, there were two implications here that didn’t sit well with me: One, that my generation could be branded so easily as all having the same characteristics (and controversial opinions abound as to why this could be). Two, that my values and purpose – the things that I’ve worked so hard for years to define and curate – have been given to me and my fellow snowflakes by the inevitable product of bad parenting, as Simon Sinek calls it a “bad hand”, and a series of unfortunate economic balls-ups.

millennial – noun – “a person reaching young adulthood in the early 21st century”

Google Dictionary

First of all, the definition of “millennial” from Google Dictionary (and many others concur) is “a person reaching young adulthood in the early 21st century”. So yep, objectively I am one. No argument there. If we’re looking at things the timeline can affect, I was raised by baby-boomers, in a time where I probably got a participation award at some point, thought I was entitled as a teenager (ever met one who didn’t?), and led a privileged, economically stable upbringing. I did go through the economic crash of 2008, losing tens of thousands in the housing market, and I did have crippling student debt. Whilst there’s evidence to suggest things are objectively harder for us as a generation, I question how any of this could have an effect on the values and characteristics of effectively an entire generation and why that would lead to a labelled generalisation.

https://www.goldmansachs.com/insights/archive/millennials/

At the end of my reflection, I think the issue was the implication that because I was an empathetic, coach-style, feel-first type personality, it must be because I was a millennial. I think it was the reduction of my self-awareness journey over the last few years to a label shared with an entire generation that made me contemplate how powerful labels can be. Lord knows I wasn’t always empathetic. I had some shameful experiences with junior developers early in my career. It’s taken some painful life events, some deep self-reflection, and learning how to support these values with resilience (not to mention a qualification in coaching) that I’ve defined and developed these values.

Here’s the reason why I try not to use labels. When you attribute a person’s individuality to an arbitrary group of people – when you reduce their life experiences to a label – you are dehumanising them. People’s lives are not just shades of grey, they’re rainbow coloured, an infinite spectrum filled with nuances and life experiences that shape them as humans. Don’t get me wrong, I like being labelled as a ‘coach’ – but I’d probably take issue if someone said “you’re a good coach, you must be a Taurus”.

When you attribute a person’s individuality to an arbitrary group of people – when you reduce their life experiences to a label – you are dehumanising them

When we’re about to label someone based on their characteristics, even if it’s just a subconscious bias in our head, it’s in our power to stop and think – is this label really a part of their identity that they’re proud of? Or are you taking away from their individualism as a beautiful, worthy and fallible human being?

Of course, my response in this case was not a 900 word essay. It was, “yeah, I don’t really like labels.” But then, that was a very millennial thing to say.

Being an engineering manager and a coach

TLDR: Listen to people and have good intentions. Read time ~ 6 mins

For anyone who’s spent five minutes trying to understand me, they know that my purpose is to grow myself to grow others. My path in the last few years seems to have been driven by a deep need to understand how to be a better coach, so I’ve captured some of my thoughts from that journey from both successes and failures. I’m not expecting any of this to be ground-breaking, but hopefully it does encourage a few managers particularly in the digital sector to have better coaching conversations with your team (If you want to find out the fundamentals about being a coach as an engineering manager from a better writer than me, check this out).

I’ve written this post from the perspective of an engineering manager, but most of these observations could easily relate to any manager who wants to be more of a coach.

Start with understanding your coachee’s values and purpose

I’m assuming here that you’ve already built up some basic rapport with your team member, the next step is truly understanding their values and purpose. I’ve already written about this in a previous post with a good practical exercise to do this. If you haven’t figured out your own values, do this exercise yourself first. Understanding others’ values and intrinsic motivations leads to empathy, a key skill in coaching. Empathy leads to objectivity, trust, and a quicker path to goal resolution.

I notice that engineers in my experience are reluctant to spend a lot of time digging into themselves like this. This may be because of more common analytical and logical thought processes that go on in engineers. During a team building exercise, I once heard an engineer interrogate the facilitator’s fundamental understanding of neuroscience, missing the irony that the psychometric test proposed that overanalysis was a team weakness.

Whatever the reason, persist with good intentions. Performance, behaviour and beliefs usually stem from these values and builds a solid base for the following points.

Coaching only works if people want to be coached

That’s not an excuse to avoid coaching conversations. If you’ve done the work to discover what people value, most of them can be coached – even if it’s to save their job. But hire for a growth mindset and coachability and it will be so much easier. I’m not a fan of hiring top tech talent if they’re not able to handle feedback.

With those team members that don’t want to be coached, your job then is to actively listen, with compassion, empathy, and consistency, to find out why that is. Do they feel like they’ve peaked and don’t need help? Are they sceptical of the process? Is there not enough trust there in the relationship? 

Dr Ron Westrum categorises organisational cultures into pathological, bureaucratic and generative, made popular in the digital industry by the book Accelerate and the work by DORA which discusses how important this is to create high trust, fast-flow environments. Thankfully I’ve not worked in a pathological culture, but what I can tell you having worked in bureaucratic ones is that engineers seem to be reluctant to accept their manager as a coach. This could be because their managers have climbed through the tech tree and found no other way to progress other than management (you don’t need me to tell you why this doesn’t always end well), or simply that the culture puts more emphasis on managers to favour product over people. Either way, the best way to break down that barrier is a consistent attitude to a coaching approach, trust, and time.

Westrum’s typology of organisational culture, “Accelerate: The Science of Lean Software and Devops: Building and Scaling High Performing Technology Organizations”, Nicole Forsgren, Jezz Humble

It’s worth mentioning that as a manager, you can’t solve everything with a coaching approach. Knowing when to make something a coaching conversation, and when not to, can be a tricky business.

Know when something is not a coaching conversation

It is a fine balance being both a coach and a manager. A good coaching relationship is based on a sense of equality, and as autonomous as I like to feel my teams are, being a manager means there’s a power dynamic there that makes equality tricky (this article has an interesting take on managing those power dynamics). You may find a scenario where you are helping someone on an improvement plan, which by design does not facilitate impartiality. Coaching techniques should still be used (active listening, empathy, evaluating options with pros and cons, accountability), but be very aware that sometimes the agenda is necessarily yours, not theirs.

There are times when it’s just not a good idea to try a coaching approach. 

  1. When you have the definitive answer, and they don’t. See, “How do I put a support ticket in to IT?”, “Where do we keep the project repositories?”. Trying a coaching approach here gets annoying very quickly.
  2. When they don’t have context, and you do. When I’m coaching someone outside of the work environment, a coachee definitely has more context about their problem than me. But employees will often not be able to come up with good solutions if they don’t have the same business context as you do as a manager. See, “What am I supposed to work on if I don’t know the roadmap?”, “What technology should I learn next?”.

Other than these, try to look everywhere for the opportunity to make interactions with your team a coaching conversation, and provide early and candid feedback as often as possible (see Kim Scott’s excellent book Radical Candor).

Ensure actions and accountability

This goes for any coaching programme, but it’s so easy to slip out of the habit as a manager. Any good coaching conversation, particularly in a structured format (such as a 121 or an appraisal) must result in actions for the employee, accountable to the employee, and preferably set wholly by the employee.

A trigger for me is when someone says “Yeah, I should actually do X about that.” Especially if there’s a strong degree of trust, it’s all too easy for both parties to be satisfied that this is the end of it, both genuinely believing that this will happen at some point in the future when the dust settles and the next big feature’s over the line. Well, there are always more features, and expecting the dust to settle is like expecting a magic supercoding ninja to swoop in and clear all your technical debt for you. 

Try creating a new habit. When you hear the “I should”, instead of assuming it will happen, create accountability by asking questions like “Will you?”, “When will you?”, “Is that all you need to do?”, “How would you feel if you completed that sooner rather than later?”.

Coaching the individual by coaching the team

If coaching an individual isn’t getting the desired outcomes, coaching the team as a whole can encourage a positive attitude in the individual and reach the same outcomes. Human beings are social animals, and desire acceptance and validation from the troop (“The Chimp Paradox” is a really fun book that explores tribe mentality and is essential reading for coaches). If you coach the behaviours in others, eliminating the validation of negative behaviours from the rest of the team, you instantly create an environment where the undesired behaviour is not accepted within this troop and thus seek other forms of acceptance. Or, of course, they find another troop.

Summary

The key in trying the coaching approach as a manager is persistence. Sure – adapt, learn, try new things, ask different questions – but the gold comes only after a long period of truly trying to understand others and genuinely wanting them to be their best self. The proudest stories I have in my career are seeing people excel as a result of the actions they have set themselves from coaching conversations. Sometimes the eureka moment with a coachee just happens, when you least expect it, way down the line when something just clicks. It’s a culmination of the small things, the small iterations of listening, questions and actions, that deliver people to greatness.

Resources: