Help! I’ve just been made a manager

Your boss calls you into her office.

“Congratulations - I’m promoting you to team lead!”

Your mouth goes dry.

“You’ve been doing such great job on the last few projects, the leadership team thought you could help other people in your team perform just as good as you.”

Your stomach turns to stone.

“Your new role starts now. We’ll see how it works out, and come back in a few weeks to review.”


This experience may feel too familiar – and perhaps painful – to you. You get thrown into the deep end with a life jacket/anchor labeled “team lead”/”supervisor”/”acting manager”.

As we’ve read before, moving into a management position is not a promotion, it’s a career change. But fate (or your boss) may not agree.

How do you survive your first few weeks in your management role?

Get a job description

Getting a job description written down helps clarify your boss’s expectations about what functions your role is meant to perform, and what is expected of you. They’re ground rules that help you understand the parameters of your work.

Make sure you have a conversation with your boss about each part of the job description, to clarify your boss’s interpretation. Note down anything that was different or required clarification, then send a updated version to your boss, for both your records.

If you can’t get a job description, write your own.

You’re probably thinking right now “Oh no, it’s a trap!” or “Isn’t this what my boss should be doing?”, and you’re right, it is your boss’s responsibility. There’s a very real chance your boss doesn’t have time - that’s part of the reason why you’re getting your “promotion”. That’s not a justification, it’s just a fact. Your boss may not have been in this position before either, and is just making it up as they go along. A lot of companies don’t have good processes for how this sort of role change is meant to work, and thus don’t have any pre-canned job descriptions they can hand to new managers. Don’t even ask about training.

Writing your own job description is fantastic opportunity to define what exactly you’re going to be doing, in your own words, while demonstrating your communication and goal setting abilities.

Get 1-2 peers to review what you’ve written, and consider getting your new team to review the job description. This can help build rapport with them, and getting their buy in to what the new team is going to look like. But beware: if you’ve been given this new role over someone else that now reports to you, there may be tension – modify your technique to your audience.

Once the job description is written, send it to your boss with a “I know you’re busy, so if you don’t see any problems with it, no need to reply”.

Managing your workload

“I’m already overloaded” you’re thinking, “How am I supposed to look after all these people while doing my existing work?” – this is the biggest fear, and biggest challenge, when moving into a management role.

You have three options:

  • Keep trying to do your own work while managing others. This almost certainly will end in you doing a mediocre job of both. You’ll spend 30% of your time on engineering, 10% on people management, and the remaining 50% on context switching and self loathing.
  • Aggressively cut the scope of your personal technical workload, and manage the stakeholder expectations for those cuts. This frees you up to spend some of your time on people work.
  • Make your old engineering workload your team’s workload. Still cut the scope of the work, and manage your stakeholder expectations. Help the team become better at doing some of the work you were doing previously. Don’t forget to manage the stakeholder relationships for their work too.

Remember why this role change is happening: as a leader, you provide more value to the team as a multiplier than as an individual contributor. If you free up each person in your team to focus more clearly on their work, and complete that work more efficiently – that’s greater than any engineering contribution you can make as an individual.

The performance of the team will drop when the team is in this transition phase. The team is reconfiguring itself, working out what’s important, what’s not, how work gets done, who has what responsibilities.

If you can successfully manage the transition, the team will be more productive than it is as a collection of individual contributors. That is your goal.

Create feedback loops

Part of being a good at people work is creating strong feedback loops from the people in the team to you. Have a reliable, predictable avenue for them to report problems and suggest changes, then act on their information, building trust.

Organise regular one-on-ones with your team. Once a week, half an hour, away from the office if you can.

Be honest and upfront with them that you’re new to this, and are trying to work it out.

Be vulnerable about your limits and abilities. Ask them to raise problems with how you’re managing them immediately, and show you’re listening to them by acting on their feedback promptly. Build trust by listening and changing behaviour.

Find out their biggest fears and anxieties about the new work situation. Ask simply:

“Is there anything I can do to help make things better?”

Create a feedback loop from team to the rest of the organisation by publicly praising good work from individuals. Raise the profile of their work to the broader audience in your org by publicly calling out good work or congratulating them on the successful delivery of features, projects, or quick bug fixes.

Make sure you pass all the credit down to the team.

Hard truths

In my first year as a manager I spent most of the time trying to make sense of the new context I found myself operating in. Expectations were re-calibrated (sometimes brutally), people were disappointed (some even left), deadlines were missed (occasionally by wide margins).

These were realisations I came to that helped me cope in my first year:

  • Demand will always exceed capacity. Doesn’t matter how good you are at managing workload – team or personal – there will always be more to do. There will always be someone disappointed you’re not doing the exact work they want, when they want it. Fuck the haters.
  • Competence is rewarded with more work. If your boss or your boss’s boss sees you doing a good job, they will want to see how much further you can go. Put more cynically: no good deed goes unpunished.
  • There will always be a tension between doing technical work and doing people work. When you’re not in a pure-management role (i.e. team lead, supervisor) you still have engineering work to do, and finding the balance will be messy – especially as you’re new to this whole people management thing. You think you’ve got a handle on it, and something will knock you for six. Keep going, reflect, try out different things, and you’ll get there.
  • Technical output is no longer the sole measurement of your job success. Your own technical output is a false measurement for your responsibilities to the team. You will always be disappointed if you measure your current self against your past self, that past self that only had technical delivery responsibilities. Your disappointment will lead you to prioritising technical work over people work, consequentially screwing over the people who are looking to you for help and guidance. Prioritise people work.

Finally: everyone else is just making it up. Nobody comes into a management role with all the answers. The leaders you look up to have made heaps of mistakes that shaped their leadership and management style.

Get to it.

PreAccident Investigation Podcast Highlights, Sep-Oct 2015

These are notes I’ve taken while binge listening to the last two months of the PreAccident Investigation Podcast, which you should subscribe to.

Kent Whipple – The power of the story

  • When we investigate an accident, we don’t tell the story of what happened, we tell a story about what didn’t happen.
  • Identifying what didn’t happen doesn’t help you fix what did happened.

Listen to the episode.

Dr. Alan Frankfurt - High Reliability, Safety, and Delivering Babies

  • Highly reliable teams don’t realise they’re highly reliable, they don’t set off to become highly reliable, they set off to become more stable, safer, more effective, or learn.
  • Destroy vertical silos, create horizontal integrations. The silos stop us from working together and becoming as good as we can get. Horizontal integrations help people take ownership.
  • Prepare for events with a pre-brief: use a template, identify what the threats are, verbalise and share concerns.
  • Hold a post-action review soon after the operation, schedule around the surgeon because of time demands.
  • There are rarely technical issues, but there are always communication issues that come up.
  • Everyone in the team needs a role, and understand how that role fits into the goal of the team. “I’m gonna do my doctor thing, you’re gonna do your nurse thing, but I’m not any more important than you are.”

Listen to the episode.

Dr Jim Joy - Critical Controls

  • Risk registers end up being a list problems on paper that are useless as a management tool.
  • Critical controls are a more effective management tool for dealing with risks and events.
  • Controls are anything that prevents or mitigates an unwanted event, that we can use to improve our resilience when things go wrong.
  • Controls can be acts, objects, and systems.
  • Acts are behaviours we mandate or encourage.
  • Objects are tools that work by themselves.
  • Systems are combinations of acts and objects.
  • Training is not a control, supervision is not a control. We can’t measure it, we can’t validate it, we can’t audit it.
  • Once we have controls, we can define performance requirements (pressure valve is released at x pressure, the operator understands how to perform x task in context), measure, then validate those performance requirements are being met.
  • Once we have requirements, we can set targets to assess the reliability of the controls, which is more of an objective discussion around metrics.
  • We can then feed these metrics into the design of the controls based on what happens in our organisations.
  • We need to move beyond thinking about risks as likelihood x consequence.
  • Risk is the degree to which your controls aren’t working.
  • Health and Safety Critical Control Management Good Practice Guide from ICMM publications

Listen to the episode.

Dr Jim Barker - Complexity

  • We don’t manage complexity, we move with it.
  • Think about complexity as fluidity instead of non-linearity, because there are linear aspects to our complex systems (like time).

Listen to the episode.

Martha Acosta - The 4 Things Leaders Control

  • When leaders say “come to me with solutions, not problems” it seems like a great empowerment move, but they’re creating a distance between workers and management.
  • If people come up with solutions, wouldn’t it be more empowering to just let them go and implement them, and only come to you when they have problems they can’t solve?
  • The value leaders provide to their organisations is helping the people at the pointy end ask the right questions, and helping them create a solution at the pointy end.
  • “When significant change comes up against significant culture, culture always wins” - Edgar Schein
  • Culture is something that arises from behaviour. That behaviour tells us what matters, how we do things around here, what works and what doesn’t. The internalisation of that behaviour is what becomes culture.
  • Outsiders see culture. Insiders have difficulty seeing it.
  • Once we see culture externally, we think we can change culture externally.
  • The four things leaders control are Roles (what people do), Processes (how we do work), Norms (how we interact with one another), Metrics (what we measure and incentivise).
  • Anxiety in the leadership structure is contagious, and can turn into fear lower down in the org structure.
  • Social anthropologists see culture as a bunch of intertwining narratives. If you add an anxiety narrative to your culture’s story, that changes the story.
  • When you get people talking about their narrative in your culture’s story, that reflection produces surprises and uncovers how things work.

Listen to the episode.

Dr. Eric Young – Patient Safety, Surgery

  • Checklists have become overused to the point where they’re causing more harm than good (Dr Young has seen 84 items on one list), need to be kept down to a page per Checklist Manifesto.
  • The best way to reduce error rates is to ensure a consistent team is working together to perform the surgeries.
  • This isn’t always a possibility, so ensuring consistent skills across all team members is the next best thing.
  • Dr Young is surprised more patients don’t get actively involved in their medical care by asking their doctors questions (e.g. why this brand of joint replacement over another?) and finding out more about their treatments.

Listen to the episode.

PreAccident Investigation Podcast Highlights, Sep-Oct 2015

These are notes I've taken while binge listening to the last two months of the PreAccident Investigation Podcast, which you should subscribe to.

Kent Whipple – The power of the story

  • When we investigate an accident, we don't tell the story of what happened, we tell a story about what didn't happen.
  • Identifying what didn't happen doesn't help you fix what did happened.

Listen to the episode.

Dr. Alan Frankfurt - High Reliability, Safety, and Delivering Babies

  • Highly reliable teams don't realise they're highly reliable, they don't set off to become highly reliable, they set off to become more stable, safer, more effective, or learn.
  • Destroy vertical silos, create horizontal integrations. The silos stop us from working together and becoming as good as we can get. Horizontal integrations help people take ownership.
  • Prepare for events with a pre-brief: use a template, identify what the threats are, verbalise and share concerns.
  • Hold a post-action review soon after the operation, schedule around the surgeon because of time demands.
  • There are rarely technical issues, but there are always communication issues that come up.
  • Everyone in the team needs a role, and understand how that role fits into the goal of the team. "I'm gonna do my doctor thing, you're gonna do your nurse thing, but I'm not any more important than you are."

Listen to the episode.

Dr Jim Joy - Critical Controls

  • Risk registers end up being a list problems on paper that is useless as a management tool.
  • Critical controls are a more effective management tool for dealing with risks and events.
  • Controls are anything that prevents or mitigates an unwanted event, that we can use to improve our resilience when things go wrong.
  • Controls can be acts, objects, and systems.
  • Acts are behaviours we mandate or encourage.
  • Objects are tools that work by themselves.
  • Systems are combinations of acts and objects.
  • Training is not a control, supervision is not a control. We can't measure it, we can't validate it, we can't audit it.
  • Once we have controls, we can define performance requirements (pressure valve is released at x pressure, the operator understands how to perform x task in context), measure, then validate those performance requirements are being met.
  • Once we have requirements, we can set targets to assess the reliability of the controls, which is more of an objective discussion around metrics.
  • We can then feed these metrics into the design of the controls based on what happens in our organisations.
  • We need to move beyond thinking about risks as likelihood x consequence.
  • Risk is the degree to which your controls aren't working.
  • Health and Safety Critical Control Management Good Practice Guide from ICMM publications

Listen to the episode.

Dr Jim Barker - Complexity

  • We don't manage complexity, we move with it.
  • Think about complexity as fluidity instead of non-linearity, because there are linear aspects to our complex systems (like time).

Listen to the episode.

Martha Acosta - The 4 Things Leaders Control

  • When leaders say "come to me with solutions, not problems" it seems like a great empowerment move, but they're creating a distance between workers and management.
  • If people come up with solutions, wouldn't it be more empowering to just let them go and implement them, and only come to you when they have problems they can't solve?
  • The value leaders provide to their organisations is helping the people at the pointy end ask the right questions, and helping them create a solution at the pointy end.
  • "When significant change comes up against significant culture, culture always wins" - Edgar Schein
  • Culture is something that arises from behaviour. That behaviour tells us what matters, how we do things around here, what works and what doesn't. The internalisation of that behaviour is what becomes culture.
  • Outsiders see culture. Insiders have difficulty seeing it.
  • Once we see culture externally, we think we can change culture externally.
  • The four things leaders control are Roles (what people do), Processes (how we do work), Norms (how we interact with one another), Metrics (what we measure and incentivise).
  • Anxiety in the leadership structure is contagious, and can turn into fear lower down in the org structure.
  • Social anthropologist see culture as a bunch of intertwining narratives. If you add an anxiety narrative to your culture's story, that changes the story.
  • When you get people talking about their narrative, that reflection produces surprises.

Listen to the episode.

Dr. Eric Young – Patient Safety, Surgery

  • Checklists have become overused to the point where they're causing more harm than good (Dr Young has seen 84 items on one list), need to be kept down to a page.
  • The best way to reduce error rates is to ensure a consistent team is working together to perform the surgeries.
  • This isn't always a possibility, so ensuring consistent skills across all team members is the next best thing.
  • Dr Young is surprised more patients don't get actively involved in their medical care by asking their doctors questions (e.g. why this brand of joint replacement over another?) and finding out more about their treatments.

Listen to the episode.

Blame. Language. Sharing.

Failure can lead to blame or inquiry in your organisation.

When failure leads to blame, organisations subscribe to the old view of human error. They construct a narrative that’s far worse than the reality, a narrative that focuses on a single root cause, which is inevitably human error because of the bad apples amongst us. Blame is reductionist and deconstructive, going down-and-in, treating people and systems as separate entities, with people at the root of the cause.

When failure leads to inquiry, organistations subscribe to the new view of human error. People and systems are one and the same, inquiry is angled up-and-out, focused on understanding the relationships and bigger picture ideas at play. This is difficult, because it involves acknowledging and embracing complexity.

When failure leads to inquiry, we embrace different perspectives, different stories, and different interests - and often these contradict one another. By embracing these differences, we create an opportunity for learning for people inside the organisation, navigating the chasm between Work-as-Imagined, and Work-as-Done.

Learning organisations have three distinct advantages:

  • They have feedback loops that deliver high quality feedback from the front lines,
  • Which allows people performing the work to focus on quality and delivery,
  • Which reduces the amount of defending of decisions.

These three advantages minimise the likelihood of a Cover Your Arse culture, where people focus more on implementing insulation against potential blowback from performing work, than actually performing the work itself.

I posit there are three contributing factors that inhibit learning in organisations:

  • Language we use when talking about and contextualising failure
  • Blame and the narrative we construct that is tainted by cognitive biases
  • Sharing of experiences in our organisations to uncover understanding

Language

The words we use when talking about events are really important.

Words are framing devices that can both enable and limit the scope of inquiry. These words are used during your investigations, retrospectives, learning reviews, brainstorming sessions, and post mortems. But most importantly they're used when having conversations daily with your colleagues.

Why is used to force people to justify actions, to attribute and apportion blame. Why goes down-and-in, focuses the inquiry on people, and is often used to phrase counterfactuals that focus attention on a past that didn't happen – "why didn't you answer the page?", "why didn't you check the backups?".

Why plays right into the hands of the Fundamental Attribution Error, where we explain other people's actions by their personality, not the context they find themselves in, but we explain our own actions by our context, not our personality.

How is about articulating the mechanics of a situation, and distancing people from the actions they took. How clarifies technical details - "how did the site go down?", "how did the team react" – but it can also limit the scope of the inquiry, as we focus on the mechanics, not the relationships at play in the larger system.

What uncovers reasoning, which is important for building empathy with people in complex systems. What makes it easier to point our investigations up-and-out, on the bigger picture contributing factors to an outcome. What encourages explaining in terms of foresight, and helps us take into account local rationality:

“people make what they consider to be the best decision given the information available to them at the time”

Dekker describes explaining in terms of foresight as understanding what people inside the tunnel looked like to the people that found themselves there, as they journeyed through it during an incident. What helps us uncover what the inside of the tunnel looked like.

Blame

Blame assigns responsibility for an outcome to a person. Often we use blame to say that people were neglectful, inattentive, or derelict of duty. It plays into this idea of bad apples, amoral actors in our midst who are working against the sanctity of pristine system the dirty humans keep fucking up.

But assigning responsibility for an outcome to a person ignores a truth – sometimes bad things happen, and nobody is to blame. Furthermore, things go right more often than they go wrong.

There are two cognitive biases at play when assigning blame to people: confirmation bias, and hindsight bias.

But what is a cognitive bias? Simply, a cognitive bias is a mental shortcut your brain unconsciously takes when processing information. Your brain optimises for timeliness over accuracy when procesing information, and applies heuristics to make decisions and form judgements.

Confirmation bias

With the confirmation bias, we seek information that reinforces existing positions, and ignore alternative explanations. Worse still, we interpret ambiguous information in favour of our existing assumptions.

Simply put: if you are looking for a human to blame, you're going to find one, regardless of contrary information.

We can counter the confirmation bias by appointing people to play the devils advocate and take contrarian viewpoints during conversations and investigations.

Hindsight bias

The hindsight bias alters our recollection of memories to fit a narrative of how we perceived and reacted to events. It's a type of memory distortion where we recall events to form a judgement, and talk about and contextualise events with knowledge of the outcome.

The hindsight bias is dangerous because it can taint all your interactions with your team. It is your culture killer, altering our how we recall our perception of events and actions in stressful situations, driving a self-defensive wedge between you and you colleagues.

It's vitally important to eliminate hindsight bias when conducting post mortems and investigations. The simplest way to achieve this is to explain events in terms of foresight, and this is made easier by using questions that start with "how" and "what". Start the conversation at a point before the incident, and work your way forward. Resist the urge to jump ahead to the outcome and work your way back from that.

Doing this is hard and requires a lot of self-restraint. You'll make a lot of mistakes at first but keep at it and you'll get better over time. It's the responsibility of the whole team to call each other out when they see each other fall into the hindsight bias trap, using words like why and who.

We can also harness hindsight bias to give us insights into how things might break in the future.

Before you take a new service live, gather the team together and ask them to brainstorm on a whiteboard or post-it notes what they think will break when they go live. Then clear away any notes you've collectively taken, and ask them to imagine themselves 5 minutes after the feature has gone live. Now ask "what has just broken?".

You'll find the answers you get can be quite different.

Sharing

Sharing our experiences after an incident happens is vital for the organisation to learn from individual and shared experiences. By sharing our experiences we have the opportunity to embrace different and often contradictory perspectives, stories, and interests.

From these we can better understand what our organisations capablities and weaknesses are, both when things go wrong but when things go right. This creates an opportunity to navigate the chasm of Work-as-Imagined, vs Work-as-Done.

We do this by holding retrospectives, investigations, post mortems, or learning reviews, but the label we want to slap on the event is irrelevant. These events must be environments where people in your organisation feel they can speak their truth and experiences free of persecution or backlash. If you're in a leadership or management position, and people in your team are participating in these sharing experiences, be the shit umbrella you want to see in the world.

Other people in your organisation will likely be skeptical of the findings (especially if there is a culture of finding and singling out bad apples), so it's your responsibility to your people to shield them from repercussions. Again:

“people make what they consider to be the best decision given the information available to them at the time”

You have a limited window of opportunity to create an expectation that if you share there won't be blow back - if you fuck it up early on, people will be reluctant to share anything vaguely compromising about their experiences and actions in the future, and thus the organisation as a whole suffers.

Know the audience of the report you produce after you've shared experiences. Sometimes this means you have to construct multiple reports, one for each audiences. The story you tell across these reports should be the same, but alter the level of detail for the audience who is reading it. You may also need to omit different findings for different audiences.

Beware of weasel words that show up in the report:

  • "the team should have…" (counterfactual describing a past that never happened)
  • "the root cause of the outage was…" (there is never one cause, there are many contributing factors)
  • "human error lead to…" (humans or systems, not humans and systems)

Creating opportunities for sharing our experiences of incidents is mandatory for learning about what our organisations capabilities and weaknesses are when things go wrong.

To do this we have hold retrospectives or learning reviews or post-mortems, start at the beginning, and relentlessly eliminate our own and collective hindsight bias when talking about events by using what and how, not why and who.

Things go right more often than they go wrong, and we owe it to ourselves and our colleagues to understand what made our course of action the right one at the time, in spite of the outcome.


This piece is a writeup of the talk I gave at Velocity Amsterdam 2015.

Blame. Language. Sharing.

Failure can lead to blame or inquiry in your organisation.

When failure leads to blame, organisations subscribe to the old view of human error. They construct a narrative that’s far worse than the reality, a narrative that focuses on a single root cause, which is inevitably human error. This reductionist and deconstructive process has us go down-and-in, treating people and systems as separate entities, with people at the root of the cause.

When failure leads to inquiry, organisations subscribe to the new view of human error. People are part of the systems, inquiry is angled up-and-out, focused on understanding the relationships and bigger picture ideas at play. This is difficult, because it involves acknowledging and embracing complexity.

When failure leads to inquiry, we embrace different perspectives, different stories, different interests - and often these contradict one another. By embracing these differences, we create an opportunity for learning for people inside the organisation, navigating the delta between how we imagine work is completed in our organisation, and how it is actually done.

Learning organisations have three distinct advantages:

  • They have feedback loops that deliver high quality feedback from the front lines,
  • Which allows people performing the work to focus on quality and delivery,
  • Which reduces the amount of defending of decisions by practitioners.

These three advantages minimise the likelihood of a Cover Your Arse culture emerging, where people focus more on implementing insulation against potential blowback from performing work, than actually performing the work itself.

I posit there are three contributing factors that inhibit learning in organisations:

  • Language we use when talking about and contextualising failure
  • Blame and the tainted narrative we construct via cognitive biases
  • Sharing of experiences in our organisations to uncover understanding

Language

The words we use when talking about events are really important.

Words are framing devices that can both expand and limit the scope of inquiry. These words are used during your investigations, retrospectives, learning reviews, brainstorming sessions, and post-mortems. But most importantly they’re used when having daily conversations with your colleagues.

Why

Why is used to force people to justify actions, to attribute and apportion blame. Why goes down-and-in, focuses the inquiry on people, and is often used to phrase counterfactuals that focus attention on a past that didn’t happen – “why didn’t you answer the page?”, “why didn’t you check the backups?”.

Why plays right into the hands of the Fundamental Attribution Error, where we explain other people’s actions by their personality, not the context they find themselves in, but we explain our own actions by our context, not our personality.

How

How is about articulating the mechanics of a situation, which is helpful for distancing people from the actions they took. How clarifies technical details - “how did the site go down?”, “how did the team react?” – but it can also limit the scope of the inquiry, as we focus on the mechanics, not the relationships at play in the larger system.

What

What uncovers reasoning, which is important for building empathy with people in complex systems – “what did you think was happening?”, “what did you do next?”. What makes it easier to point our investigations up-and-out, on the bigger picture contributing factors to an outcome. What encourages explaining in terms of foresight, and helps us take into account local rationality:

“people make what they consider to be the best decision given the information available to them at the time”

Dekker describes explaining an incident in terms of foresight as understanding what people inside the tunnel saw, as they journeyed through it during an incident. What helps us uncover what the inside of the tunnel looked like.

Blame

Blame assigns responsibility for an outcome to a person. Often we use blame to say that people were neglectful, inattentive, or derelict of duty. It plays into this idea of bad apples, amoral actors in our midst who are working against the sanctity of pristine system the dirty humans keep fucking up.

But assigning responsibility for an outcome to a person ignores a truth – sometimes bad things happen, and nobody is to blame. Furthermore, things go right more often than they go wrong.

There are two cognitive biases at play when assigning blame to people: confirmation bias, and hindsight bias.

But what is a cognitive bias? Simply, a cognitive bias is a mental shortcut your brain unconsciously takes when processing information. Your brain optimises for timeliness over accuracy when processing information, and applies heuristics to make decisions and form judgements. If those heuristics produce an incorrect result, we say that’s an example of a cognitive bias.

Confirmation bias

With the confirmation bias, we seek information that reinforces existing positions, and ignore alternative explanations. Worse still, we interpret ambiguous information in favour of our existing assumptions.

Simply put: if you are looking for a human to blame, you’re going to find one, regardless of contrary information.

We can counter the confirmation bias by appointing people to play the devils advocate and take contrarian viewpoints during conversations and investigations.

Hindsight bias

The hindsight bias alters our recollection of memories to fit a narrative of how we perceived and reacted to events. It’s a type of memory distortion where we recall events to form a judgement, and talk about and contextualise events with knowledge of the outcome – often making ourselves look better in the process.

The hindsight bias is dangerous because it can taint all your interactions with your team. It is your culture killer, altering our how we recall your perception of events and actions in stressful situations, driving a self-defensive wedge between you and you colleagues.

It’s important to eliminate hindsight bias when conducting post-mortems and investigations if we want a just outcome. The simplest way to achieve this is to explain events in terms of foresight, and this is made easier by using questions that start with “how” and “what”. Start the review at a point before the incident, and work your way forward. Resist the urge to jump ahead to the outcome and work your way back from that.

Doing this is hard and requires a lot of self-restraint and practice. You’ll make a lot of mistakes, and it takes time to get good at it. Even when you’re good at it, you’ll still occasionally find yourself slipping into old habits. It’s the responsibility of the whole team to call each other out when they see each other fall into the hindsight bias trap, using words like why and who.

We can also harness hindsight bias to give us insights into how things might break in the future.

Before you take a new service live, gather the team together and ask them to brainstorm on a whiteboard or post-it notes what they think will break when they go live. Then clear away any notes you’ve collectively taken, and ask them to imagine themselves 5 minutes after the feature has gone live. Now ask “what has just broken?”.

You’ll find the answers you get can be quite different.

Sharing

Sharing our experiences after an incident happens is vital for the organisation to learn from individual and shared experiences. By sharing our experiences we have the opportunity to embrace different and often contradictory perspectives, stories, and interests.

From these we can better understand what our organisations capabilities and weaknesses are, both when things go wrong but when things go right. This creates an opportunity to understand the delta between Work-as-Imagined and Work-as-Done in our organisations.

We do this by holding retrospectives, investigations, post-mortems, or learning reviews – but the label we apply to the event is irrelevant.

These events must be environments where people in your organisation feel they can speak their truth and experiences free of persecution or backlash. If you’re in a leadership or management position, and people in your team are participating in these sharing experiences, be the shit umbrella you want to see in the world.

Other people in your organisation will likely be skeptical of the findings (especially if there is a blameful culture of finding and singling out bad apples), so it’s your responsibility to your people to shield them from the repercussions of being honest. Again, we are all locally rational:

“people make what they consider to be the best decision given the information available to them at the time”

You have a limited window of opportunity to create an expectation that if you share there won’t be blow back - if you fuck it up early on, people will be reluctant to share anything vaguely compromising about their experiences and actions in the future, and thus the organisation as a whole suffers from the missed opportunity to learn.

Know the audience of the report you produce after you’ve shared experiences. Sometimes this means you have to construct multiple reports, one for each audience. The story you tell across these reports should be the same, but alter the level of detail for the audience who is reading it. You may also need to omit different findings for different audiences so details don’t get misconstrued.

Beware of weasel words that show up in the report:

  • “the team should have…” (counterfactual describing a past that never happened)
  • “the root cause of the outage was…” (there is never one cause, there are many contributing factors)
  • “human error lead to…” (our world is humans and systems, not humans or systems)

Creating opportunities for sharing our experiences of accidents, incidents, and outages is mandatory if we want to learn about what our organisations capabilities and weaknesses are when things go wrong.

To do this we have hold retrospectives or learning reviews or post-mortems, start at the beginning, and relentlessly eliminate our own and collective cognitive biases when talking about events, by using what and how, not why and who.

Things go right more often than they go wrong, and we owe it to ourselves and our colleagues to understand what made our course of action the right one at the time, in spite of the outcome.


This piece is a writeup of the talk I gave at Velocity Amsterdam 2015.

Management skills for new leaders

At DevOpsDays Melbourne 2015 I facilitated an Open Space session on management and leadership.

The purpose of the session was for experienced leaders to share their stories and discuss what skills are required for effective leadership, so new managers and people who are thinking about making the switch could learn from people who have been before them.

You can find the original audio on SoundCloud.

This is a writeup of what was discussed in the session.

Reviews

At some stage you’re going to have to do a performance review.

Being honest in the review can be hard when you start, but the people in your team really appreciate feedback because it’s personal.

Reviews should contain no surprises. If you get to a review and your team member is surprised by something said, it’s too late. When you give feedback, be specific and call out specific good work – it shows that you as a leader are noticing and appreciating the work that’s being done. Generic platitudes of “good job” aren’t effective.

But don’t just wait for a review - force yourself to give feedback whenever you can. Showing that you notice what people in your team are doing is really powerful, and is a big influencer of behaviour. You might feel like you’re giving too much feedback to your team, but every person on your team is only seeing a slice of the feedback.

1:1s

Sometimes 1:1s are the last thing you want to do if you’re an introvert.

It shows up in your calendar, and you think “I wonder if I just don’t show up today?”. But when your boss doesn’t show up, you both stop talking about the 1:1, and mutually implicitly decide not to do more 1:1s. Force yourself to do them even when you don’t want to – you’ll often find within a minute that you’re enjoying it, because you’re feeding off the response you’re getting: that it’s important to them.

People might do 1:1s because they feel they have to.

Why should I do it? Why should I talk about family, weekend, work? We’re engineers! We know what each other do!

But people are more engaged if you know about their family, and they know about yours. It’s surprising to know these things work, but also relieving – it’s not black magic, it’s just how humans work. We attach to each other more when we’re socially connected.

You should be meeting people a minimum every fortnight, so there are no nasty surprises.

But separate 1:1s-as-a-status-update from 1:1s-as-a-personal-update. It’s important to do both, but separate the concerns.

Mentoring

Get team leads together in your organisation, and get them sharing experiences and lessons. Make sure new managers talk to one another, and bounce ideas around.

It’s also important to pair up new managers with an experienced manager to bounce ideas around.

These pairing doesn’t have to be in the same department, because it’s dealing with people problems, not technical ones.

Also think about finding someone to bounce ideas off outside of the company – talk to ex-bosses, find mentors, individuals. They give you a perspective because they’re not trapped in your day-to-day.

Best bit of advice ever given to David Spriggs, CEO of Infoxchange: “Treat all your staff as if they’re volunteers”:

David Spriggs delivering the quote

Listen to people, look after them. Don’t try and do too much work as a manager – you’re there to be a multiplier.

Role models

Everyone was likely managed by a good manager at some point.

We’ve all seen and experienced good things when working for good management. We often forget what those good things are when we make the change to management. You’ve got to re-learn it all. You’re not receiving it, you’re giving it. This is super hard.

Conversely, a lot of people have never had good technical management, so they may imitate what they’ve seen, perpetuating bad practices because it’s all they’ve ever known. For example: “I haven’t seen my manager in 3 months”.

Promotion vs career change

There’s a preconception that you have to do a lot of tasks as a manager.

You’re going up to get more responsibility, be paid more, and have greater input into the company direction.

Often people will get to a point in their technical career where they are unable to advance any further, and there are few companies that help people go further on the technical career development track. Rackspace have the technical career track, where engineers can be paid more and have more input in the company than some execs.

As managers we need to create the opportunity for our people to grow in the direction they want.

Traditionally, people in tech have been promoted due to technical ability and intelligence – less on emotional intelligence, and their ability to communicate with people. The higher up in the org structure you go, the more your ability to socially interact with other people becomes important.

You have to critically assess how good you are at that. Make sure you’re getting feedback, as well as giving feedback.

Celebrating successes

Linda Rising’s “Do Food” pattern from Fearless Change talks about introducing food into celebration and retros, as a way of bringing the team together.

Just a coffee goes a long way. Removing people from the office environment allows them to open up more about problems and successes.

How do you make food or drink celebrations work with remote teams? Everyone buys their own food and drink, gets reimbursed, shares on the video conference.

If you’re going to cater celebrations, be aware of dietary requirements. If you’re doing regular 1:1s, you’ll know people’s dietary requirements ahead of time.

Distributed teams, remote workers, co-located offices

What works: dedicated chat rooms, per-product streams, that people can opt into as they please. Non-technical folk should hang out in those rooms too. Also have a general themed rooms too, like “devops”. Having management in those rooms is a great way to identify problems in the organisation before they spiral out of control.

There’s a certain etiquette when working remotely. People don’t realise that they need to digitally note things that are said face-to-face, so other people who aren’t in the same room are up to speed. To prime co-located teams for working remotely, spread the team across the office so they’re not physically located together.

Wayne Ingram asking questions about managing an inherited distributed team

Sometimes you need to pull people together into the same place regularly (e.g. every 3 months). The frequency and size of events will vary from team to team.

If you don’t have regular face to face communication, the co-located offices and people can fall into old patterns. Even if you send someone to the other office permanently, they adopt the culture of that office, become “one of them”. Exchanges need to be two-way.

There are cultural concerns around remote work in different countries. In some cultures there is a certain level of prestige around having your manager come and visit you. If your boss doesn’t come to visit, and other teams have their bosses visit, that’s a negative mark against you.

Teams that are partially distributed are harder to manage than fully distributed teams. As a manager you can send people that are together home to work, so they work like the people who are distributed. Consider walking around the office before/during/after standups to show the office environment beyond the normal meeting rooms. It makes people feel included.

When you’ve made the wrong move

What happens when you’ve made the career change, and you realise you don’t want it any more? How do you address the impression that you aren’t successful when you go back to your prior role?

It’s important for your organisation to recognise the challenges people are facing in their new roles and support them.

“The fact is, if you’re miserable in a leadership role, you’re probably not doing a good job. Save your team the pain, and change.” – Hannah Browne

Move towards a position you provide the most value in, and you are the most happy in.

It’s not a promotion, it’s a career change helped people realise that the move is not “I have all this responsibility and stuff I need to look after”, it’s “I have different things to think about, I have new stuff to learn about people, communication, relationships, how to be the multiplier”.

Leadership is a fundamentally different set of skills to engineering.

Discussing how to recover from a bad career change

We don’t look at a hairdresser, or a carpenter, and say the hairdresser should be able to knock you up a house, and the carpenter can dye your hair.

In our knowledge industry we expect that people can change the work they do at the drop of a hat – with minimal mentoring, support, training, guidance, advice – and be successful. We all have a role to play to help people who take the step and decide they don’t love it to not feel like they’re losing face.

Go back to something you love and are passionate about. You have invested years of development in those skills.

Leadership vs Management

Aren’t leadership and management separate things?

The feeling in the room was that to be a good manager you have to be a good leader, but you can be a good leader without being a good manager.

Leadership isn’t a position, it’s a function that anyone can adopt. David Marquet’s Turn The Ship Around is a great case study of encouraging a culture of distributed responsibility, creating leaders at all levels of your organisation.

Management has a bad name, leadership is the trendy alternative, but they are distinct things. When leading you have to look after your people, because you’re working for them.

We’ve heard the term “management heavy”, but you don’t really hear the term “leadership heavy” - maybe that’s an insight into the differences between the two functions?

Leadership cuts across different jobs and industries. Management less so, because it can be focused on technical details. Leaders that are great working with, encouraging, motivating, collaborating with people are successful.

Story time from Chris Madden:

Startup during the dotcom, hired 25 engineers, had a great team. But there was nobody in the team that was suitable to lead.

Startup leadership went out, found someone who had run restaurants, and had herded cats in the film industry. Although he didn’t have any technical experience, he was parachuted into this great team of engineers.

The engineers respected him because he was successfully doing work that they weren’t good at.

One thing new managers can be bad at is knowing when to be direct. You don’t want to tell anyone what to do because “you should just decide”.

But eventually you’ll get feedback from the team that sometimes they just want you to make a decision, set a direction, so they can get on with the job.

Regardless of whether you’re in a management or leadership position, make sure you have good feedback loops from the team.

Understanding your team

Understand how your people are working.

If you’re in a leadership position but come from an operations background, spend time understanding how developers work and think.

“No-one gets out of bed in the morning with the express purpose of making your life miserable”

Sometimes people will drive you insane. But everyone has their own stuff going on. People behave how they do for a reason, so spend time understanding why.

Recognise that everyone is different. A technique that works for one person won’t be guaranteed to work with the next person in your team. By having social interaction with the people in your team, you can work out what’s required of you to work with that person effectively.

Devops and changing roles within a team is a useful mechanism for building empathy. There’s the difference between understanding what someone is going through and actually living it.

Dan Pink’s Drive discusses a new model for understanding people’s motivations. Once you remove money as a concern, people are driven by autonomy, mastery, purpose. When you have 1:1s, use Drive as a framework for working out which category they fit into.

Involve the team in the decision making process. Don’t be “my way or the highway”.

Talk about ideas, collectively own it, build consensus around decisions. The work we’re all doing is hard, and you have to be pretty clever to do it well. As the team grows and gets better, you can start thinking “I wouldn’t be able to be part of this team”.

If you leave the team, there should be someone in place to take over your responsibilities.

The value you provide as a leader

You know you’re doing your job as a leader right when you realise that there’s more value in the communication you facilitate than the tasks you’re performing.

You’re not the leader because you’re the best at every job. You’re not delegating tasks because you’ve run out of time to do the tasks.

You’re delegating because you genuinely believe the people you’re giving the work to can do it better than you. Your responsibility is to create a context in which people in your team can succeed. You do this by talking to them, understanding their motivations, giving them purpose.

Sometimes people think that management or leadership isn’t something they can do, because they’re engineers, and it’s not their responsibility, and they’ll need to change the org structure to achieve the outcome.

But leadership is the responsibility of everyone in a team, and it’s within all your abilities.

Resources

  • Meetup: Melbourne Agile Dev Managers on Meetup, “MAD managers”
  • Meetup: Once you’re in a leadership position, or are aspiring, there’s the Melbourne CTO and Sydney CTO schools.
  • Podcast: Manager Tools. Two US-based management consultants talking about new topics every week.
  • Newsletter: Software Lead Weekly is a free weekly newsletter of curated management and leadership articles. Oren Ellenbogen maintains a Trello board of all the articles included in the newsletter over the last few years.
  • Book: Oren wrote a book called Leading Snowflakes off the back of the Software Lead Weekly newsletter. It’s specific to people making the transition from engineer to engineering manager.
  • Book: Talking With Tech Leads by Patrick Kua on Leanpub, lots of interviews with managers
  • Book: Behind Closed Doors by Esther Derby & Johanna Rothman is a good introduction to software development team management.
  • Book: Turn The Ship Around by David Marquet. A great case study of encouraging a culture of distributed responsibility, creating leaders at all levels of your organisation.
  • Tool: iDoneThis, SaaS, sends an email to each person in your team asking “what have you done?”, you itemise everything you’ve done, sends back to your team or your manager. At review time you can go over accomplishments in fine detail, and raise issues as they come up.
  • Photos in this post are from the DevOps Australia Flickr set, under a CC BY-NC 2.0 license.

Management skills for new leaders

At DevOpsDays Melbourne 2015 I facilitated an Open Space session on management and leadership.

The purpose of the session was for experienced leaders to share their stories and discuss what skills are required for effectively leadership, so new managers and people who were thinking about making the switch could learn from people who have been before them.

You can find the original audio on SoundCloud.

This is a writeup of what was discussed in the session.

Reviews

At some stage you're going to have to do a performance review.

Being honest in the review can be hard when you start, but the people in your team really appreciate feedback because it's personal.

Reviews should contain no surprises. If you get to a review and your team member is surprised by something said, it's too late. When you give feedback, be specific and call out specific good work – it shows that you as a leader are noticing and appreciating the work that's being done. Generic platitudes of "good job" aren't effective.

But don't just wait for a review - force yourself to give feedback whenever you can. Showing that you notice what people in your team is doing is really powerful, and is a big influencer of behaviour. You might feel like you're giving too much feedback to your team, but every person on your team is only seeing a slice of the feedback.

1:1s

If you're an introvert, sometimes 1:1 are the last thing you want to do.

It shows up in your calendar, and you think "I wonder if I just don't show up today?". But when your boss doesn't show up, you both stop talking about it, and mutually implicitly decide not to do it. Force yourself to do them even when you don't want to – you'll often find within a minute that you're enjoying it, because you're feeding off the response you're getting: that it's important to them.

People might do 1:1s because they feel they have to.

Why should I do it? Why should I talk about family, weekend, work? We're engineers! We know what each other do!

But people are engaged more if you know about their family, and they know about yours. It's surprising to know these things work, but also relieving – it's not black magic, it's just how humans work. We attach to each other more when we're socially connected.

You should be meeting people a minimum every fortnight, so there are no nasty surprises.

But separate 1:1s-as-a-status-update from 1:1s-as-a-personal-update. It's important to do both, but separate the concerns.

Mentoring

Get team leads together in your organisation, and get them sharing experiences and lessons. Make sure new managers talk to one another.

New managers can bounce ideas off each other. It's also important to pair up new managers with an experienced manager to bounce ideas off too.

These pairing doesn't have to be in the same department, because it's dealing with people problems, not technical ones.

Also think about finding someone to bounce ideas off outside of the company – talk to ex-bosses, find mentors, individuals. They give you a perspective beacuse they're not trapped in your day-to-day.

Best bit of advice ever given to David Spriggs, CEO of Infoxchange: "Treat all your staff as if they're volunteers":

David Spriggs delivering the quote

Listen to people, look after them. Don't try and do too much stuff as a manager.

Role models

Everyone was likely managed by a good manager at some point.

We've all seen and experienced good things when working for good management. We often forget what those things are when we make the change to management. You've got to re-learn it all. You're not receiving it, you're giving it. This is super hard.

Conversely, a lot of people have never had good technical management, so they may immitate what they've seen, perpetuating bad practices because it's all they've ever known. For example: not catching up with people regularly, "I haven't seen my manager in 3 months"

Promotion vs career change

There's a preconception that you have to do a lot of tasks as a manager.

You're going up to get more responsibility, to be paid more, to have greater input into the company direction. Often people will get to a point in their technical career where they are unable to advance any further, and there are only a few companies that will help people go further. Rackspace have the technical career track, where engineers can be paid more and have more input in the company than some execs.

As managers we need to create the opportunity for our people to grow in the direction they want.

People traditionally in IT have been promoted due to technical ability and intelligence, less on emotional intelligence, and their ability to communicate with people. The higher up in the org structure you go, the more your ability to socially interact with other people becomes important

You have to critically assess how good you are at that. Make sure you're getting feedback, as well as giving feedback.

Celebrating successes

Linda Rising's "Do Food" pattern from Fearless Change talks about introducing food into celebration and retros, as a way of bringing the team together.

Just a coffee goes a long way. Removing people from the office environment allows them to open up more about problems.

How do you make food or drink celebrations work with remote teams? Everyone buys their own food and drink, gets re-imbursed, shares on the video conference.

If you're going to cater events, be aware of dietary requirements. If you're doing regular 1:1s, you'll know people's dietary requirements ahead of time.

Distributed teams, remove workers, co-located offices

What works: dedicated chat rooms, per product streams, that people can opt into as they please. Non-technical folk should hang out in those rooms too. Also have a general themed rooms too, like "devops". Having management in those rooms is a great way to identify problems in the organisation before they spiral out of control.

There's a certain ettiquette when working remotely. People don't realise that they need to digitally note things that are said face to face so other people who aren't in the same room are up to speed. To prime co-located teams for working remotely, spread the team across the office so they're not physically located together.

Wayne Ingram asking questions about managing an inherited distributed team

Sometimes you need to pull people together into the same place regularly (e.g. every 3 months). The frequency and size of events will vary from team to team.

If you don't have regular face to face communication, the co-located offices and people can fall into old patterns. Even if you send someone to the other office permanently, they adopt the culture of that office, become "one of them". Exchanges need to be two-way.

There are cultural concerns around remote work in different cultures. In some cultures there is a certain level of prestige around having your manager come and visit you. If your boss doesn't come to visit, and other teams have their bosses visit, that's a negative mark against you.

Teams that are partially distributed are harder to manage than fully distributed teams. As a manager you can send people that are together home to work, so they work like the people who are distributed. Consider walk around in the office before/during/after standups to show the office environment beyond the normal meeting rooms. It makes people feel included.

When you've made the wrong move

What happens when you've made the career change, and you realise you don't want it any more? How do you address the impression that you aren't successful when you go back?

It's important for your organisation to recognise the challenges people are facing in their new roles and support them. The fact is, if you're miserable in a leadership role, you're probably not doing a good job. Save your team the pain, and change.

Move towards a position you provide the most value in, and you are the most happy in.

It's not a promotion, it's a career change helped people realise that the move is not "I have all this responsibility and stuff I need to look after", it's "I have different things to think about, I have new stuff to learn about people, communication, relationships, how to be the multiplier".

Leadership is a fundamentally different set of skills to engineering.

Discussing how to recover from a bad career change

We don't look at a hairdresser and a carpenter and say that the hairdresser should be able to knock you up a house, and the carpenter can dye our hair.

In our knowledge industry we expect that people can change the work they do at the drop of a hat – with minimal mentoring, support, training, guidance, advice – and be successful. We all have a role to play to help people who take the step and decide they don't love it to not feel like they're losing face.

Go back to something you love and are passionate about and have invested years of development in those skills.

Leadership vs Management

Aren't leadership and management separate things?

The feeling in the room was that to be a good manager you have to be a good leader, but you can be a good leader without being a good manager.

Leadership isn't a position, it's a function that anyone can adopt. David Marquett's "Turn The Ship Around" is a great case study of encouraging a culture of distributed resposibility, creating leaders at all levels of your organisation.

Management has a bad name, leadership is the trendy alternative, but they are distinct things. When leading you have to look after your people, because you're working for them.

We've heard the term "management heavy", but you don't really hear the term "leadership heavy" - maybe that's an insight into the differences between the two functions?

Leadership cuts across different jobs and industries. Management less so, because it can be focused on technical details. Leaders that are great working with, encouraging, motivating, collaborating with people are successful.

Story time from the room:

Startup during the dotcom, hired 25 engineers, had a great team. But there was nobody in the team that was suitable to lead.

Startup leader went out, found this person who had run restaurants, been in the film industry. Although he didn't have any technical experience, he was parachuted into this great team of engineers.

The engineers respected him because he was doing work that they weren't good at.

One thing new managers can be bad at is knowing when to be direct. You don't want to tell anyone what to do because "you should just decide".

But eventually you'll get feedback from the team that sometimes they just want you to make a decision, set a direction, so they can get on with the job.

Regardless of whether you're in a management or leadership position, make sure you have good feedback loops from the team.

Understanding your team

Understand how your people are working.

If you're in a leadership position but come from an operations background, spend time understanding how developers work and think.

"No-one gets out of bed in the morning with the express purpose of making your life miserable"

Sometimes people will drive you insane. But everyone has their own stuff going on. People behave how they do for a reason, so spend time understanding why.

Recognise that everyone is different. A technique that works for one person won't be guaranteed to work with the next person in your team. By having social interaction with the people in your team, you can work out what's required of you to work with that person effectively.

Devops and changing roles within a team is a useful mechanism for building empathy. There's the difference between understanding what someone is going through and actually living it.

Dan Pink's Drive, investigates peoples motivations. Once you remove money as a concern, people are driven by autonomy, mastery, purpose. When you have 1:1s, use Drive as a framework for working out which category they fit into.

Involve the team in the decision making process. Don't be "my way or the highway".

Talk about ideas, collectively own it, build concensus around decisions. The work we're all doing is hard, and you have to be pretty clever to do it well. As the team grows and gets better, you can start thinking "I wouldn't be able to be part of this team".

If you leave the team, there should be someone in place to take over your responsibilities

The value you provide as a leader

You know you're doing your job as a leader right when you realise that there's more value in the communication you facilitate than the tasks your performing.

You're not the leader because you're the best at every job. You're not delegating because you've run out of time to do the tasks.

You're delegating because you genuinely believe the people you're giving the work to can do it better than you. Your responsibility is to create a context in which people in your team can succeed. You do this by talking to them, understanding their motivations, giving them purpose.

Sometimes people think that management or leadership isn't something they can do, because they're engineers, and it's not their responsibility, and they'll need to change the org structure to achieve the outcome.

But leadership is everyone in the teams' responsibility and within their ability.

Resources

  • Meetup: Melbourne Agile Dev Managers on Meetup, "MAD managers"
  • Meetup: Once you're in a leadership position, or are aspiring, there's the Melbourne CTO and Sydney CTO schools.
  • Podcast: Manager Tools. Two US-based management consultants talking about new topics every week.
  • Newsletter: Software Lead Weekly is a free weekly newsletter of curated management and leadership articles. Oren Ellenbogen maintains a Trello board of all the articles included in the newsletter over the last few years.
  • Book: Oren wrote a book called Leading Snowflakes off the back of the Software Lead Weekly newsletter. It's specific to people making the transition from engineer to engineering manager.
  • Book: Talking With Tech Leads by Patrick Kua on Leanpub, lots of interviews with managers
  • Book: Behind Closed Doors by Esther Derby & Johanna Rothman is a good introduction to software development team management.
  • Book: Turn The Ship Around by David Marquett. A great case study of encouraging a culture of distributed resposibility, creating leaders at all levels of your organisation.
  • Tool: iDoneThis, SaaS, sends an email to each person in your team asking "what have you done?", you itemise everything you've done, sends back to your team or your manager. At review time you can go over accomplishments in fine detail, and raise issues as they come up.
  • Photos in this post are from the DevOps Australia Flickr set, under a CC BY-NC 2.0 license.

Talk-To-Think, Think-To-Talk, and leadership

This cop threw me to the ground, cos hip hop is violent,
Said "You got freedom of speech, just choose to remain silent"

– Hilltop Hoods, Mic Felon

Effectively communicating with people in and around your team is the most important skill you need to develop as a leader.

How you communicate with people in your team defines how you build relationships and trust. Understanding how you communicate with people is key to being an effective leader and multiplier.

There are two main communication styles: talk to think, and think to talk.

Talk-to-think

Talk-to-think values speed over accuracy.

It is rapid fire brainstorming.

You say what comes to mind, no filter.

Don't hold back. Be bold. Agitate.

It's messy, chaotic, beautiful.

This communication style is excellent for covering lots of ground quickly, especially if you're trying to quickly sketch a picture of a problem domain and potential solutions amongst of group of people. You use approximations of terms and ideas - the details don't matter as much, as long as you communicate the gist.

Think-to-talk

Think-to-talk values accuracy over speed.

It is measured, sometimes slow, but always methodical. You don't say what comes to mind immediately - you spend time thinking about articulating your ideas and arguments before saying them. You chose your words carefully, and embrace the ebbing silence.

Think-to-talk is excellent for covering a smaller, sometime sensitive topic area with depth and nuance.

Your communication style

You tend to use one style over the other, but the styles are not mutually exclusive.

I am firmly in the Think-To-Talk camp. When I started my career change I spent a lot of time befuddled why some conversations flowed effortlessly, and others felt like a bucking horse I could barely hold onto.

Realising that my experience was not universal and I needed to level up on my communication styles is one of the things I wish I was told when I became a manager.

Everyone is different. Some people's communication is dominated by one style, others are someone in between. Some can fluidly move between styles, others take a while to transition, if at all. Fluidity and style are intersecting spectrums.

The good news is that either style can be learned - they just require practice and patience.

And you need to be adept at both if you're going to be an effective leader.

Leadership and the two styles

You likely are proficient with one of the styles. Now you're in the midst of your career change, you need to start cultivating the other style.

Why? Because your job will have you in situations where you'll need to pick and choose the style based on the problem you're dealing with. Also, it's not about you - the people you lead are going to employ a mix of styles that you'll need to match and adapt to.

You'll often find that conversations stick to one communication style. Through experience you'll get better at predicting ahead of time what style is called for, based on the topics, and who you're talking to in your team.

Always be cautious of what you think you know - the situation may change and you'll need to change your style. As Mark Twain said:

It ain't what you don't know that gets you into trouble. It's what you know for sure that just ain't so.

Sometimes you'll need to switch styles mid-conversation. This can happen mid-1:1 when you're switching from The Idea to The Person. Making that switch can be hard, and you'll probably mess it up. That's cool, we've all been there. You'll get better with practice, just keep at it.

One of the most important things you can do to cultivate your skill is to spend time every day reflecting on the conversations you're having with your people. Do it at the end of every conversation, or at the end of the day. Just make sure you do it.

The two questions you need to ask:

  • What style was in use by people in the room?
  • Was the style appropriate, given the topic?

What style should I use?

The context of the conversation determines what style you use. It's your job to identify that context. Practice, practice, practice.

When picking the style, ask yourself: What are the implications of the conversation for the people involved? Are you talking about ideas, or people?

Talk-to-think is brilliant for discussing ideas. You'll use it heavily for technical problem solving, when sketching out a problem and devising potential solutions as a team. Talk-to-think can also be used for organisational problem solving, when discussing org structure problems, organisational debt or inefficiencies. The caveat is that you need to be really fucking clear with the team that the conversation is a hypothetical brainstorm, and nothing is changing. It's risky, and I would avoid having those sort of organisational problem solving discussions unless you know your team exceptionally well, and are confident in your ability to reroute the conversation when things get dicey. Tread with care.

Think-to-talk is brilliant for discussing people. This is the style you'll want to use in your 1:1s when talking about reporting lines, career development, rates and salaries. Slow, methodical, precise conversations are important for setting expectations and not creating confusion and uncertainty about peoples positions within the company.

You need to be aware that the people you're talking to may simply not be comfortable communicating in your preferred style. Sometimes the other person isn't that good yet at using your preferred style. This will feel like a drag to you, because you want to use the most efficient style for the situation.

But it's not about you.

It's your responsibility to identify what's going on and compromise. Look for cues that your style isn't working. When using Talk-To-Think, the other person will be talking less and less, withdrawing from the conversation. When Think-To-Talking, the other person can be frustrated their conversational energy isn't being matched.

How you are perceived

Sometimes you'll misjudge the conversation and pick the wrong style.

If you're using Think-To-Talk with a Talk-To-Thinker you'll appear haughty, aloof, coldly calculating, surgical, and uncaring.

Talk-to-Thinking with a Think-To-Talker will paint you as scatterbrained, flippant, irrationally vigorous, overbearing, interrupting, and uncaring.

You'll note that uncaring is shared. An empathy gap is at the root of the miscalibration.

Nobody wants to be perceived as any of these things. Watch for cues, be aware of how people are reacting to what you and others are saying.

Are you slowing the conversation down by not engaging more vigorously? Are you getting too caught up in detail? Switch to Talk-To-Think.

Are you confusing the other person by using lots of potentially conflicting ideas? Are they growing more concerned with every word that comes out of your mouth? Switch to Think-To-Talk.

Be the Talk-To-Think umbrella

People spend a lot of time looking up at what the people above them in the org structure are doing, what they're saying, who they're saying it to, and how often they say it. Couple that with a Talk-To-Think communication style up the chain, and it constantly creates and cultivates concerning confusion and uncertainty.

It is damaging as fuck to people in your team because they don't know how seriously to take ideas from people further up the chain, forcing them into a terrible feedback loop of watching for more cues that have them despairing further.

If you see Talk-To-Think communication coming from above, especially around strategic direction, it's your duty to sheild your team from that and turn that noise into signal. Distill those opinions into facts, create certainty for your team.

Be prepared

Before you walk into a conversation, you owe it to your people mentally prepare for the style you need to use. This doesn't have to be an ornate, time consuming ritual - some simple priming is enough.

If you are a Think-To-Talker going into a Talk-To-Think melee, try listening to uptempo trigger music, or going for a walk or quick jog around the block.

Talk-To-Thinker going to the Think-To-Talk doldrums? Listen to downtempo trigger music, or limit sensory inputs by nesting yourself in a quiet dark room.

Have a routine. Prime yourself, have triggers, experiment and change. Where possible integrate some sort of physical activity into the trigger, and avoid screens.

Understanding your communication strengths and weaknesses is one of the hardest but most rewarding things you can do in your management career change.

Diligent and disciplined mastery of this alone puts you heads and shoulders above the rest, and the people you lead will respect you for treating them how they want to be treated.

Talk-To-Think, Think-To-Talk, and leadership

This cop threw me to the ground, cos hip hop is violent,
Said “You got freedom of speech, just choose to remain silent”

– Hilltop Hoods, Mic Felon

Effectively communicating with people in and around your team is the most important skill you need to develop as a leader.

How you communicate with people in your team defines how you build relationships and trust. Understanding how you communicate with people is key to being an effective leader and multiplier.

There are two main communication styles: talk to think, and think to talk.

Talk-to-think

Talk-to-think values speed over accuracy.

It is rapid fire brainstorming.

You say what comes to mind, no filter.

Don’t hold back. Be bold. Agitate.

It’s messy, chaotic, beautiful.

This communication style is excellent for covering lots of ground quickly, especially if you’re trying to quickly sketch a picture of a problem domain and potential solutions amongst of group of people. You use approximations of terms and ideas - the details don’t matter as much, as long as you communicate the gist.

Think-to-talk

Think-to-talk values accuracy over speed.

It is measured, sometimes slow, but always methodical. You don’t say what comes to mind immediately - you spend time thinking about articulating your ideas and arguments before saying them. You chose your words carefully, and embrace the ebbing silence.

Think-to-talk is excellent for covering a smaller, sometime sensitive topic area with depth and nuance.

Your communication style

You tend to use one style over the other, but the styles are not mutually exclusive.

I am firmly in the Think-To-Talk camp. When I started my career change I spent a lot of time befuddled why some conversations flowed effortlessly, and others felt like a bucking horse I could barely hold onto.

Realising that my experience was not universal and I needed to level up on my communication styles is one of the things I wish I was told when I became a manager.

Everyone is different. Some people’s communication is dominated by one style, others are someone in between. Some can fluidly move between styles, others take a while to transition, if at all. Fluidity and style are intersecting spectrums.

The good news is that either style can be learned - they just require practice and patience.

And you need to be adept at both if you’re going to be an effective leader.

Leadership and the two styles

You likely are proficient with one of the styles. Now you’re in the midst of your career change, you need to start cultivating the other style.

Why? Because your job will have you in situations where you’ll need to pick and choose the style based on the problem you’re dealing with. Also, it’s not about you - the people you lead are going to employ a mix of styles that you’ll need to match and adapt to.

You’ll often find that conversations stick to one communication style. Through experience you’ll get better at predicting ahead of time what style is called for, based on the topics, and who you’re talking to in your team.

Always be cautious of what you think you know - the situation may change and you’ll need to change your style. As Mark Twain said:

It ain’t what you don’t know that gets you into trouble. It’s what you know for sure that just ain’t so.

Sometimes you’ll need to switch styles mid-conversation. This can happen mid-1:1 when you’re switching from The Idea to The Person. Making that switch can be hard, and you’ll probably mess it up. That’s cool, we’ve all been there. You’ll get better with practice, just keep at it.

One of the most important things you can do to cultivate your skill is to spend time every day reflecting on the conversations you’re having with your people. Do it at the end of every conversation, or at the end of the day. Just make sure you do it.

The two questions you need to ask:

  • What style was in use by people in the room?
  • Was the style appropriate, given the topic?

What style should I use?

The context of the conversation determines what style you use. It’s your job to identify that context. Practice, practice, practice.

When picking the style, ask yourself: What are the implications of the conversation for the people involved? Are you talking about ideas, or people?

Talk-to-think is brilliant for discussing ideas. You’ll use it heavily for technical problem solving, when sketching out a problem and devising potential solutions as a team. Talk-to-think can also be used for organisational problem solving, when discussing org structure problems, organisational debt or inefficiencies. The caveat is that you need to be really fucking clear with the team that the conversation is a hypothetical brainstorm, and nothing is changing. It’s risky, and I would avoid having those sort of organisational problem solving discussions unless you know your team exceptionally well, and are confident in your ability to reroute the conversation when things get dicey. Tread with care.

Think-to-talk is brilliant for discussing people. This is the style you’ll want to use in your 1:1s when talking about reporting lines, career development, rates and salaries. Slow, methodical, precise conversations are important for setting expectations and not creating confusion and uncertainty about peoples positions within the company.

You need to be aware that the people you’re talking to may simply not be comfortable communicating in your preferred style. Sometimes the other person isn’t that good yet at using your preferred style. This will feel like a drag to you, because you want to use the most efficient style for the situation.

But it’s not about you.

It’s your responsibility to identify what’s going on and compromise. Look for cues that your style isn’t working. When using Talk-To-Think, the other person will be talking less and less, withdrawing from the conversation. When Think-To-Talking, the other person can be frustrated their conversational energy isn’t being matched.

How you are perceived

Sometimes you’ll misjudge the conversation and pick the wrong style.

If you’re using Think-To-Talk with a Talk-To-Thinker you’ll appear haughty, aloof, coldly calculating, surgical, and uncaring.

Talk-to-Thinking with a Think-To-Talker will paint you as scatterbrained, flippant, irrationally vigorous, overbearing, interrupting, and uncaring.

You’ll note that uncaring is shared. An empathy gap is at the root of the miscalibration.

Nobody wants to be perceived as any of these things. Watch for cues, be aware of how people are reacting to what you and others are saying.

Are you slowing the conversation down by not engaging more vigorously? Are you getting too caught up in detail? Switch to Talk-To-Think.

Are you confusing the other person by using lots of potentially conflicting ideas? Are they growing more concerned with every word that comes out of your mouth? Switch to Think-To-Talk.

Be the Talk-To-Think umbrella

People spend a lot of time looking up at what the people above them in the org structure are doing, what they’re saying, who they’re saying it to, and how often they say it. Couple that with a Talk-To-Think communication style up the chain, and it constantly creates and cultivates concerning confusion and uncertainty.

It is damaging as fuck to people in your team because they don’t know how seriously to take ideas from people further up the chain, forcing them into a terrible feedback loop of watching for more cues that have them despairing further.

If you see Talk-To-Think communication coming from above, especially around strategic direction, it’s your duty to sheild your team from that and turn that noise into signal. Distill those opinions into facts, create certainty for your team.

Be prepared

Before you walk into a conversation, you owe it to your people mentally prepare for the style you need to use. This doesn’t have to be an ornate, time consuming ritual - some simple priming is enough.

If you are a Think-To-Talker going into a Talk-To-Think melee, try listening to uptempo trigger music, or going for a walk or quick jog around the block.

Talk-To-Thinker going to the Think-To-Talk doldrums? Listen to downtempo trigger music, or limit sensory inputs by nesting yourself in a quiet dark room.

Have a routine. Prime yourself, have triggers, experiment and change. Where possible integrate some sort of physical activity into the trigger, and avoid screens.

Understanding your communication strengths and weaknesses is one of the hardest but most rewarding things you can do in your management career change.

Diligent and disciplined mastery of this alone puts you heads and shoulders above the rest, and the people you lead will respect you for treating them how they want to be treated.

CD for infrastructure services

For the last 6 months I’ve been consulting on a project to build a monitoring metrics storage service to store several hundred thousand metrics that are updated every ten seconds. We decided to build the service in a way that could be continuously deployed and use as many existing Open Source tools as possible.

There is a growing body of evidence to show that continuous deployment of applications lowers defect rates and improves software quality. However, the significant corpus of literature and talks on continuous delivery and deployment is primarily focused on applications - there is scant information available on applying these CD principals to the work that infrastructure engineers do every day.

Through the process of building a monitoring service with a continous deployment mindset, we’ve learnt quite a bit about how to structure infrastructure services so they can be delivered and deployed continuously. In this article we’ll look at some of the principals you can apply to your infrastructure to start delivering it continuously.

How to CD your infrastructure successfully

There are two key principals for doing CD with infrastructure services successfully:

  1. Optimise for fast feedback. This is essential for quickly validating your changes match the business requirements, and eliminating technical debt and sunk cost before it spirals out of control.
  2. Chunk your changes. A CD mindset forces you to think about creating the shortest and smoothest path to production for changes to go live. Anyone who has worked on public facing systems knows that many big changes made at once rarely result in happy times for anyone involved. Delivering infrastructure services continuously doesn’t absolve you from good operational practice - it’s an opportunity to create a structure that re-inforces such practices.

Definitions

  • Continous Delivery is different from Continuous Deployment in that in Continuous Delivery there is some sort of human intevention required to promote a change from one stage of the pipeline to the next. In Continuous Deployment no such breakpoint exists - changes are promoted automatically. The speed of Continuous Deployment comes at the cost of potentially pushing a breaking change live. Most discussion of “CD” rarely qualifies the terms.
  • An infrastructure service is a configuration of software and data that is consumed by other software - not by end users themselves. Think of them as “the gears of the internet”. Examples of infrastructure services include DNS, databases, Continuous Integration systems, or monitoring.

What the pipeline looks like

  1. Push. An engineer makes a change to the service configuration and pushes it to a repository. There may be ceremony around how the changes are reviewed, or they could be pushed directly into master.
  2. Detect and trigger. The CI system detects the change and triggers a build. This can be through polling the repository regularly, or a hosted version control system (like GitHub) may call out via a webhook.
  3. Build artifacts. The build sets up dependencies and builds any required software artifacts that will be deployed later.
  4. Build infrastructure. The build talks to an IaaS service to build the necessary network, storage, compute, and load balancing infrastructure. The IaaS service may be run by another team within the business, or an external provider like AWS.
  5. Orchestrate infrastructure. The build uses some sort of configuration management tool to string the provisioned infrastructure together to provide the service.

There is a testing step between almost all of these steps. Automated verification of the changes about to be deployed and the state of the running service after the deployment is crucial to doing CD effectively. Without it, CD is just a framework for continuously shooting yourself in the foot faster and not learning to stop. You will fail if you don’t build feedback into every step of your CD pipeline.

Defining the service for quality feedback

  • Decide what guarantees you are providing to your users. A good starting point for thinking about about what those guarantees should be is the CAP theorem. Decide if the service you’re building is an AP or CP system. Infrastructure services generally tend towards AP, but there are cases where CP is preferred (e.g. databases).
  • Define your SLAs. This is where you quantify the guarantees you’ve just made to your users. These SLAs will relate to service throughput, availability, and data consistency (note the overlap with CAP theorem). 95e response time for monitoring metric queries in a one hour window is < 1 second, and a single storage node failure does not result in graph unavailability are examples of SLAs.
  • Codify your SLAs as tests and checks. Once you’ve quantified your guarantees SLAs, this is how you get automated feedback throughout your pipeline. These tests must be executed while you’re making changes. Use your discretion as to if you run all of the tests after every change, or a subset.
  • Define clear interfaces. It’s extremely rare you have a service that is one monolithic component that does everything. Infrastructure services are made of multiple moving parts that work together to provide the service, e.g. multiple PowerDNS instances fronting a MySQL cluster. Having clear, well defined interfaces are important for verifying expected interactions between parts before and after changes, as well as during the normal operation of the service.
  • Know your data. Understanding where the data lives in your service is vital to understanding how failures will cascade throughout your service when one part fails. Relentlessly eliminate state within your service by pushing it to one place and front access with horizontally scalable immutable parts. Your immutable infrastructure is then just a stateless application.

Making it fast

Getting iteration times down is the most important goal for achieving fast feedback. From pushing a change to version control to having the change live should take less than 5 minutes (excluding cases where you’ve gotta build compute resources). Track execution time on individual stages in your pipeline with time(1), logged out to your CI job’s output. Analyse this data to determine the min, max, median and 95e execution time for each stage. Identify what steps are taking the longest and optimise them.

Get your CI system close to the action. One nasty aspect of working with infrastructure services is the latency between where you are making changes from, and the where the service you’re making changes to is hosted. By moving your CI system into the same point of presence as the service, you minimise latency between the systems.

This is especially important when you’re interacting with an IaaS API to inventory compute or storage resources at the beginning of a build. Before you can act on any compute resources to install packages or change configuration files you need to ensure those compute resources exist, either by building up an inventory of them or creating them and adding them to said inventory.

Every time your CD runs it has to talk to your IaaS provider to do these three steps:

  1. Does the thing exist?
  2. Maybe make a change to create the thing
  3. Get info about the thing

Each of these steps requires sending and recieving often non-trivial amounts of data that will be affected by network and processing latency.

By moving your CI close to the IaaS API, you get a significant boost in run time performance. By doing this on the monitoring metrics storage project we reduced the CD pipeline build time from 20 minutes to 5 minutes.

Push all your changes through CI. It’s tempting when starting out your CD efforts to push some changes through the pipeline, but still make ad-hoc changes outside the pipeline, say from your local machine.

This results in several problems:

  • You don’t receive the latency reducing benefits of having your CI system close to the infrastructure.
  • You limit visibility to other people in your team as to what changes have actually been made to the service. That quick fix you pushed from your local machine might contribute to a future failure that your colleagues will have no idea about. The team as a whole benefits from having an authoriative log of all changes made.
  • You end up with divergent processes - one for ad-hoc changes and another for Real Changes™. Now you’re optimising two processes, and those optimisations will likely clobber one another. Have fun.
  • You reduce your confidence that changes made in one environment will apply cleanly to another. If you’re pushing changes through multiple environments before they are applied to your production environment, you reduce the certainty that one off changes in one environment won’t cause changes to pass there but fail elsewhere.

There’s no point in lying: pushing all changes through CI is hard but worth it. It requires thinking about changes differently and embracing a different way of working.

The biggest initial pushback you’ll probably get is having to context switch between your terminal where you’re making changes and the web browser where you’re tracking the CI system output. This context switch sounds trivial but I dare you to try it for a few hours and not feel like you’re working more slowly.

Netflix Skunkworks’ jenkins-cli is an absolutely godsend here - it allows you to start, stop, and tail jobs from your command line. Your workflow for making changes now looks something like this:

git push && jenkins start $job && jenkins tail $job

The tail is the real killer feature here - you get the console output from Jenkins on your command line without the need to switch away to your browser.

Chunking your changes

Change one, test one is a really important way of thinking about how to apply changes so they are more verifiable. When starting out CD the easiest path is to make all your changes and then test them straight away, e.g.

  • Change app
  • Change database
  • Change proxy
  • Test app
  • Test database
  • Test proxy

What happens when your changes cause multiple tests to fail? You’re faced with having to debug multiple moving parts without solid information on what is contributing to the failure.

There’s a very simple solution to this problem - and test immediately after you make changes:

  • Change app
  • Test app
  • Change database
  • Test database
  • Change proxy
  • Test proxy

When you make changes to the app that fail the tests, you’ll get fast feedback and automatically abort all the other changes until you debug and fix the problem in the app layer.

If you were applying changes by hand you would likely be doing something like this anyway, so encode that good practice into your CD pipeline.

Tests must finish quickly. If you’ve worked on a code base with good test coverage you’ll know that slow tests are a huge productivity killer. Exactly the same here - the tests should be a help not a hinderance. Aim to keep each test executing in under 10 seconds, preferably under 5 seconds.

This means you must make compromises in what you test. Test for really obvious things like “Is the service running?”, “Can I do a simple query?”, “Are there any obviously bad log messages?”. You’ll likely see the crossover here with “traditional” monitoring checks. You know, those ones railed against as being bad practice because they don’t sufficiently exercise the entire stack.

In this case, they are a pretty good indication your change has broken something. Aim for “good enough” fast coverage in your CD pipeline which complements your longer running monitoring checks to verify things like end-to-end behaviour.

Serverspec is your friend for quickly writing tests for your infrastructure.

Make the feedback visual. The raw data is cool, but graphs are better. If you’re doing a simple threshold check and you’re using something like Librato or Datadog, link to a dashboard.

If you want to take your visualisation to the next level, use gnuplot’s dumb terminal output to graph metrics on the command line:



  1480 ++---------------+----------------+----------------+---------------**
       +                +                +                + ************** +
  1460 ++                                            *******              ##
       |                                      *******                 #### |
  1440 ++                    *****************                 #######    ++
       |                  ***                                ##            |
  1420 *******************                                  #             ++
       |                                                   #               |
  1400 ++                                                ##               ++
       |                                             ####                  |
       |                                          ###                      |
  1380 ++                                      ###                        ++
       |                                     ##                            |
  1360 ++                               #####                             ++
       |                            ####                                   |
  1340 ++                    #######                                      ++
       |                  ###                                              |
  1320 ++          #######                                                ++
       ############     +                +                +                +
  1300 ++---------------+----------------+----------------+---------------++
       0                5                10               15               20


CRITICAL: Deviation (116.55) is greater than maximum allowed (100.00)

Conclusion

CD of infrastructure services is possible provided you stick to the two guiding principals:

  1. Optimise for fast feedback.
  2. Chunk your changes.

Focus on constantly identifying and eliminating bottlenecks in your CD pipeline to get your iteration time down.