Retrospectives for Humans
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 66 | |
| Author | ||
| Contributors | ||
| License | CC Attribution 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/46614 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
VideoconferencingMusical ensembleMultiplication signIncidence algebraWordArithmetic meanJSONXML
01:18
Bridging (networking)Water vaporMultiplication signSurfaceCausalityDirection (geometry)Order (biology)DivisorData storage deviceSheaf (mathematics)Traffic reportingObservational study
02:59
Length of stayInsertion lossState of matterSimilarity (geometry)Greatest elementBridging (networking)Regulator geneWater vaporSpur <Mathematik>Observational studySheaf (mathematics)SurfaceRow (database)Arithmetic meanCellular automatonData structureOperator (mathematics)Condition numberSoftware maintenanceRhytidectomyDampingMultiplicationInheritance (object-oriented programming)Process (computing)VideoconferencingAreaAsynchronous Transfer ModeComputer simulationStability theorySpeech synthesisOpen setMetropolitan area networkComputer animationLecture/Conference
06:51
Structural loadData integrityBridging (networking)Stress (mechanics)Fluid staticsMathematical analysisPairwise comparisonSound effectSurfaceThresholding (image processing)Moment (mathematics)Software crackingComputer-generated imageryHypermediaDecision theoryMultiplication signStructural loadWater vaporPoint (geometry)Software crackingIntegrated development environmentGoodness of fitPhysical systemMereologyBuffer solutionBridging (networking)Revision controlArithmetic progressionCondition numberLattice (order)Shape (magazine)PlanningOrder (biology)Archaeological field surveyPhysical lawChannel capacityRepresentation (politics)Content (media)Moment <Mathematik>NumberData conversionMoment (mathematics)Formal languageProcess (computing)Scheduling (computing)Set (mathematics)SurfaceSound effectResultantBuildingCrash (computing)MathematicsDataflowReading (process)GodError messageThresholding (image processing)Lecture/Conference
12:27
Computer-generated imageryRootError messageCausalityBeat (acoustics)Decision theoryError messageMultiplication signCASE <Informatik>Group actionComputer-assisted translationComputer clusterIncidence algebraSphereElectronic mailing listMereologyProcess (computing)DivisorSingle-precision floating-point formatRootBridging (networking)Latent heatSpeech synthesisLine (geometry)Shared memoryComplex systemResultantTrailInclined planeData conversionMathematicsData managementEmailPhysical systemFrictionFormal languageMoment (mathematics)Statement (computer science)InformationCausalityLattice (order)Computer animationLecture/Conference
19:42
Interrupt <Informatik>Event horizonGenderDecision theoryEntropie <Informationstheorie>ComputerComputational complexity theoryData conversionResultantGroup actionMultiplication signTrailRotationOrder (biology)PlanningInteractive televisionContext awarenessMoment (mathematics)WordQuicksortOcean currentProcess (computing)CausalityBitIncidence algebraFile formatDependent and independent variablesInheritance (object-oriented programming)Lattice (order)NP-hardPresentation of a groupShared memoryTask (computing)Decision theoryData managementLipschitz-StetigkeitEvent horizonFigurate numberDistance
26:57
Multiplication signLattice (order)Context awarenessClosed set
28:08
System programmingData structureTelecommunicationFormal languageInformation technology consultingShift operatorFrame problemBounded variationPhysical systemMoment (mathematics)Data conversionService (economics)Line (geometry)BitMereologyData structureQuicksortRule of inferenceMultiplication signDifferent (Kate Ryan album)Group actionCartesian coordinate systemTelecommunicationProduct (business)Boundary value problemGame theoryResultant
32:00
Multiplication signInheritance (object-oriented programming)Level (video gaming)Speech synthesisRevision controlOnline helpPlastikkarteContext awarenessScheduling (computing)AuthorizationNP-hardLattice (order)TwitterFormal languageWordSlide ruleQuicksortCausalityPoint (geometry)Different (Kate Ryan album)Term (mathematics)Electronic mailing listWhiteboardData managementBitLecture/Conference
35:46
XMLComputer animation
Transcript: English(auto-generated)
00:02
Thank you for coming to Retrospectives for Humans.
00:20
Before we begin today, I want to acknowledge this has been a really frightening and difficult few weeks for a lot of people, with tragedy and violence touching a lot of people that I know. And if that's you, I'd like to offer my sympathies. It can be difficult to function normally and pay attention to everyday business at times like these. It can be even harder to learn new concepts.
00:42
So please do what you need to do during this. Take care of yourself. I don't think this talk requires any content warnings. If it does, and I've missed it, I apologize. I would appreciate hearing from you afterwards. All right, I'm here to talk about retrospectives. These are incident retrospectives, but most of the things I'm gonna say today
01:00
will probably also be useful to you in an agile retrospective, should you choose to do that. The subtitle of this talk could also be Words Mean Things. Let's talk disasters where no one was hurt. Seattle has the two longest floating bridges
01:21
in the world, and in 1990, one of them sank over the Thanksgiving Day weekend in a storm while it was being repurposed. The public reporting to this day is extremely simplistic, but the official investigation found that there were five factors involved, and all of them were required for the bridge to fail. At the time that the bridge sank, you can see this is a picture of that happening,
01:42
they were scraping off the surface of the bridge with water, it's called hydrodemolition. They were going to change the direction of traffic on the bridge, because they were building a span nearby, so they were gonna expand how much traffic the bridge could take. The EPA told them that they were not allowed
02:01
to let the water run off into the lake, that that was a serious environmental problem, so they had to figure out a way to store the water so that it could be trucked off and treated. You can't store water in piles, so they needed to find a container to put it in. The thing that occurred to them after much study was that they would store it in the hollow pontoons
02:23
of the bridge itself. Floating bridge is made of these hollow sections like a ship's hull, it's made out of concrete in this case, and this bridge was actually floating higher than it was designed to float, and had lots of extra flotation ability that they decided to use in order to store the water
02:41
so they could truck it away. When this happened, no one was on the bridge, it was over the holiday weekend, so everyone was off, and one pontoon sank slowly and dragged seven more down after it, so this was a slow cascading failure. Extra fun.
03:07
This is a video of some of the coverage of what happened, I'm gonna play it for a few minutes.
03:21
Built in 1940 in Seattle, the Lacey V. Murrow Bridge was named after the director of Washington State's Department of Transportation. The bridge stood for 50 years, but in November of 1990, a rehabilitation and maintenance operation on the bridge led to disaster,
03:45
including a short but deep section of Seattle's Lake Washington. The Murrow Bridge floated on a row of 25 hollow concrete pontoons, each 350 feet long. The pontoons were bolted together for stability
04:00
and anchored to the bottom of the lake. The conditions are just right for use of such a structure because the water conditions under which they're installed are perfect, that is, very seldom is there any ice,
04:20
very seldom is there a heavy current, and the water is very deep, 200 or more feet. In the fall of 1990, the Murrow Bridge was undergoing a facelift by means of hydrodemolition, a process in which highly pressurized water is used to break up the roadway.
04:43
Since environmental regulations prohibited dumping the contaminated water into the lake, it was temporarily stored in the empty pontoons via access holes, which were cut into the tops and sides of some sections. The water level inside the pontoons was carefully monitored so the structure
05:01
would not be compromised. On Thanksgiving weekend, with bridge crews short-handed, a heavy storm hit the Seattle area. Rainwater drained into the open pontoons. Winds from the storm whipped up the surface of the lake, propelling splash water into the pontoons as well.
05:24
On the morning of November 25th, eight waterlogged pontoons sunk into the lake, taking those sections of the bridge down with them and severing 12 anchoring cables of a bridge that was being constructed nearby. While luckily no one was injured, the cost of damage was estimated at $69 million.
05:43
An investigation of the accident came to a sobering, if unsurprising, conclusion. After a very extensive study and very sophisticated computer modeling methods, the conclusion was that concrete pontoons simply don't float when they're full of water,
06:03
a very unsophisticated mode of fate. The Lacey v. Murrow Bridge was rebuilt two years later. Though it looks the same from the outside, the pontoons that support the bridge have been divided into smaller sections to minimize damage from leaks, a precaution that underscores the structural similarities
06:22
between floating bridges and floating ships. The pontoons were designed with multiple cells, not unlike the multiple cell super tankers so that failure in one place would not bring down the entire pontoon. So he got the laugh he was looking for.
06:44
Happened here. That's not what I wanted to have happen, apologies. Where is my mouse? So this was a giant disaster. They checked a lot of stuff. I'm not even gonna read all of that off to you. It was an incredibly thorough investigation. I was able to get a paper that was published
07:01
by the people who fronted this investigation and read the original text of what they determined the failure to be. This part I am gonna read. This is what they found was the problem, several problems. The loads that created significant leakage were the combined effects of all accumulations of water,
07:21
including rain after the windstorm, longitudinal flow on the surface of the bridge, and pumping through November 24th, 1990. These loads caused static moments, that's to say pressures, that exceeded the threshold for leakage. Existing cracks were opened sufficiently to allow water to leak into the pontoon. Progressive and accelerated sinking began at this time.
07:44
So there's a lot of things that we've got going on here, right? We found that there were existing cracks in the bridge. The survey did in fact find that there were, this bridge was built in the 40s, 40s, 30s? He told you at the beginning of the video, now I can't remember. So the bridge was in excellent shape for its age. It had cracks that were expected in concrete of that age,
08:03
but not as many as they would have expected. The cracks were smaller than expected. Their bridge was floating higher than designed. That's the extra flotation capacity that I talked about before. So the bridge was not just in decent shape, it was in spectacular shape. It was dramatically over-engineered. And so they found they needed to put the water someplace.
08:22
They did very careful surveys of the bridge and how much flotation there was, and they calculated an error, like a buffer for their error and worked really hard to make sure that they were being careful when they did this, right? It was very thorough. But still somehow this happened.
08:44
The official investigation missed something huge. The crews were having trouble pumping the water out on the schedule that was set by the engineers, and there is a mention of that in the paper, but there's no explanation as to why. I don't know if they didn't do an investigation or if they simply didn't document
09:01
the result of their investigation, but there was a social problem here. There was a schedule set. It involved trucks that were pumping water, carrying it off the bridge. It involved water being stored evenly, hopefully across the pontoons that they were storing it in, and for some reason, the crews couldn't stick to that schedule. We don't know why, and so we don't truly understand
09:23
what happened here. We know that the water was higher in some pontoons and lower in others, which was causing torque on the bridge, which helped open those cracks. We know that the trucking crews were behind. There could have been not enough trucks. There could have been not enough drivers. There could have been a strike.
09:40
There could have been pay problems. Any number of things could have gone into this, and we're never gonna truly understand. So as thorough as this was, as really good as the true investigation was, and as different as that is from the sound bite that made us all laugh, we still don't truly understand what happened here,
10:00
which is just such a good representation to me of the things that it's easy to miss in a retrospective. So we all laughed. He says, you know, you fill a bridge full of water, it sinks, but no one does things that they think are going to blow up the world, right? It's easy to look at that and be like, oh, you stored water in the bridge, oh my God.
10:21
But they stored water in the bridge very carefully with a very firm plan for how they were going to continue to have this be okay, and it still didn't work. So the lesson here is remember that even as you have that feeling of like, you know, face palm, here we go again, it's probably more complicated than that.
10:41
Asking about what a person knew and what the conditions were at the time that they made a decision will give you good insight for effective change. So let's do better than that. Now this is gonna be a crash course. I condensed like double the amount of content into this time, so we're gonna run fast.
11:01
If you have more questions, come find me afterwards. Facilitation, we're gonna talk about how to have a good meeting, other ways to think of this, servant leadership, psychological safety. As a facilitator, your job is to keep the conversation blame-free, not let people make bad jokes, and to run a pretty decent meeting that people are willing to sit in instead of checking out of.
11:21
So let's talk about how we talk about all of this. First thing, foundational, Miller's Law. In order to understand what another person is saying, you must assume that it is true and try to decide what it could be true of. You're being asked to imagine what it is like to be another person, probably at another time,
11:41
at another place, in another context, right? This is the only way to truly understand a system or a person or an environment or a happenstance that was not one that you personally lived through, or even one that somebody else lived through next to you, because no two people ever have the exact same experience, even in the exact same moments.
12:01
I learned about this from Suzette Hiden-Elgin in The General Art of Verbal Self-Defense, which is a fairly, yes! Which is a fairly old book at this point. I do recommend it, it talks a lot about language and how we talk to each other and the ways that we can create conflict and de-escalate conflict. This is a critical tool to use
12:21
when you're conducting a retrospective. So keep this in mind, start it here, everything else is gonna build on this. Now let's talk about blame. English is a pretty blamey language, right? I might say to myself or to another person, you knocked over that vase. Why did you knock over that vase, right?
12:41
Those are both statements that are about blame and fault. You, yeah, you. I'm talking to you, don't just walk away from me. That feels awful, right? That's terrible. Starting a sentence with you draws a line between yourself and the person you're speaking to.
13:01
So does using it too often. It creates an oppositional conversation. There's the person saying you and the person who's being you'd at. Why? Why is another part of blame. Why did you do that? Why did you do it like that? That also feels terrible. Asking a question that starts with why
13:21
is a request for a justification. It immediately puts the person you're addressing on the defensive. Why questions get answers in agentive language? Because I knocked it over. The vase is broken because I knocked it over. Agentive language has blame in the very grammar. It talks about a person doing a thing.
13:41
It's strongly remembered by English speakers. So then, after you've asked this question and you've gotten this answer, you've ensured that everyone who heard it remembers that I knocked over the vase. Other things not to say to people, especially in a retrospective, but often at other times too, you always, you never.
14:02
Every time we do this, you, you should. You should just. You should only do it like this. There's more, but these are the least wanted. If you have a sibling, anything your sibling ever shouted at you when they were mad that made you see red, goes on this list.
14:21
Anything that your child, if you have a child, has said to you that just made you want to completely blow your top because kids are really good at that, goes on this list. You might, if you're talking about an API or an RFC, use these words. Especially, like, RFCs have this very prescriptive language, right? So sometimes we can't avoid it.
14:40
But remember that when you describe the behavior of a system, you are describing the decisions that some people made when they built it, right? It's more upsetting if those people didn't know the consequences of the decisions that they were making, which they didn't. No one can be perfectly prescient. So you are saying things about decisions that people made that they probably
15:00
didn't even understand that they were completely making. Why didn't you just fix it the last time this happened? How many times have we heard this, right? This is terrible. I'm gonna take this apart because this is not compassionate and it's not effective at helping us
15:21
understand the problem. This construct assumes that it's happened before. Maybe more than once. That it could have been fixed the last time it happened. Easily, that's the just. That you was the right one to fix it and that there was no good reason not to fix it.
15:40
That's a lot of assumptions in one very short sentence. Here's some better things to say. How could you or how could we? What? What happened? What do you know? What did you know? What if? What if we tried this? What if we tried that? Could we, next time, try this?
16:03
What do you think about this proposal that I have? What would you have wanted to know in the moment where you did that and you made that decision? All of these are designed to get more complex answers when used in a question. When you're asking a question, think about what you can say that will get you the longest answer.
16:22
It's a habit that a lot of us get into in business communication, right? We try to be short and declarative and stick to the point, especially when you're sending emails to an executive who only reads three sentences. Sometimes that's your manager. It's not my manager, but sometimes, right? So we get into this habit of being really concise, and that is an extremely useful habit in a lot of circumstances.
16:40
But in a retrospective, you wanna ask complicated questions. They get complicated answers. This is a creative process, both for you and the other people who are participating. One of the things that all of you are trying to do together is imagine a better world. When you ask these better questions,
17:00
what you're looking for is called a remediation item, an idea for a change that we can make to code, to documentation, to playbooks, to processes that will give a different outcome in the future. At Heroku, we call this contributing factor discovery because complex systems have complex failures, as we saw with the bridge, right? There's no one specific thing that caused that bridge to fail.
17:21
And if we talk about a single root cause, that constrains our thinking. It keeps us considering that there's only one reason that something broke, which is never the case. We don't deal with spherical cows on frictionless inclined planes. We deal with the real world, and it's very complex.
17:41
We often hear that something went wrong because of human error, but human error isn't where you should stop your investigation. It's where you should start it. People make the best decisions that they can with the information they have at the time. So how did the human make the error? What allowed the error to happen? How did the error take the system down? How long did it take the human to notice the error?
18:01
The answers to those questions can give you things that you can change so that next time, if the exact same thing happens, you'll get a different result. Fallacy. Well, now that we know about this kind of mistake, we can just not do it again. That doesn't work. Who's gonna get more sleep next week?
18:22
We all think we're going to, are we? Probably not. Depending on humans to avoid errors is unreasonable. People can't be perfectly vigilant. They can't be better rested. They can't just not have a screaming baby next time. They can't have a cat who's not trying to climb on them when that's what he always does every night.
18:40
The human you had today is the human you're gonna have tomorrow and the human you're gonna have next week, and you have to plan for that human, not an idealized human. Okay, let's talk about how to have a great meeting. Who's with me? All right, if you're facilitating, have an agenda.
19:04
Stick to it. Stay on time, stay on topic. This helps keep you from missing things by running out of time. It lets participants know what you'll cover and when. It helps participants stay with the group because people who have fallen behind are self-conscious and are less likely to participate, and you won't be able to hear what they had to say about the incident and their perspective on it.
19:24
Digressions can be boring for the group or can inhibit group participation, especially if one person is filibustering or has that hobby horse that they drag out every time. That discourages other people from sharing. Staying on track helps make sure everyone stays engaged. If you're a participant,
19:41
your job is to help the group stay on track. Before you share something in a retrospective, ask yourself if what you have to say is on topic and needs the entire group's attention. If one of those things is not true, save it for a different context. Find a different way to bring it up. Try to work with the facilitator to keep everything moving forward.
20:03
Keep your eye on the agenda. Stay engaged. Try not to respond to people slacking you. It's really hard, but try. Even if you have nothing to contribute right now, because if you are paying attention to someone else and what they say, you might have a response that moves the conversation further along.
20:20
It's not just about what each particular person says. It's about the interaction between the participants and the conclusions that you can all come to together. Finally, note-taking. I don't have time to go into my very long rant about note-taking. Try to make sure it's fair. Try to rotate it. Pitch in if someone else is taking notes in a Google Doc or some other kind of shared format.
20:42
Try to make sure that it's not always on one person, and it should never be on the person who's facilitating, because you can't pay attention to everyone else in the room and be taking notes at the same time. It's not a possible task. As a facilitator, you're gonna need to practice interrupting.
21:00
It's necessary when people start to rant, complain, get off topic. It can be super, super uncomfortable. Remind yourself that you can't achieve the goals of the retrospective if behaviors that take the meeting off track go unchecked. The best way to practice this is to think about a time that you experienced when someone needed to be interrupted and they weren't.
21:23
Remember how unpleasant and frustrating the result was. Everyone's just sort of sitting there seething. You're pretty sure everyone else around you is really unhappy, too. We're not getting anywhere. This person is taking all the air out of the room, and we're not coming to any useful conclusions here. Remember that feeling wherever it feels in you. Then imagine yourself in that moment having said,
21:43
thanks, teammate, but we're really far afield, and we need to come back to the topic so that we can finish on time. Or everyone working this incident did the best they could, and we're here to figure out what we need to know to help things go better next time. Or even, wait a minute, please, if you need time to think.
22:00
Do this gently but firmly. The person you're interrupting may even come to you, and thank you later. That happened to me with a large billing outage that we had a few years ago, and the senior exec for billing was really upset, and I had to shut him down. He came to me afterwards and said, I was really angry because I didn't realize that you were actually on it. I thought that because everyone was so calm
22:21
and so good at this, it meant that you didn't care, and I was wrong, so thank you for telling me. It's not always gonna be like that. But sometimes it is. As a facilitator and as a participant, look at who's talking and who isn't. One of your jobs as a facilitator
22:41
is to make sure everyone gets a chance to speak, even if they choose to decline that chance because they don't have anything to say. Don't assume that just because a person is silent, it means they have nothing to contribute. They might be shy, they might be having a hard time interjecting, they might be having a bad day. Keep an eye on the participants to see who might want to speak and be afraid to interrupt. Things to watch for.
23:01
Wiggling, leaning forward, licking lips, biting lips, waving their hand a little bit, lips pursed as if they're ready to speak, frowning, nodding, other really engaged behaviors. Sometimes those are the behaviors of someone who is excited to say something next. Sometimes it's active listening and you ask them if they have something to contribute
23:22
and they don't in that moment, that's also fine. Try to take time at least twice during your retrospectives to stop the discussion and invite anyone who hasn't spoken to speak up. When you do that, you need to wait.
23:42
Wait until it gets uncomfortable and then wait a little longer. Most times when people ask, do you have any, anyone have any questions, anyone have anything to say, they wait, okay, let's go, right? And that's too quick. It's too quick for someone who needs time to marshal their thoughts or to marshal their courage or whatever it is that they need internally
24:01
in order to be able to speak. You need to give them time for that. Okay, let's talk about humor, or we could not talk about humor, but let's talk about humor. It's really easy to mess up when you're making jokes in a retrospective. You might have heard the saying, comedy is tragedy plus time. In a retrospective, there has not been enough time.
24:25
Furthermore, someone, maybe everyone in that retrospective, feels like they screwed up and they cost the company money. They cost their teammates time and maybe sleep, and they made everyone present have yet another meeting, and maybe even their manager is there.
24:41
So it's critical to avoid making people uncomfortable by making jokes that are inappropriate in this context. Jokes you should not make. Anything that makes anyone in the room feel even a little bit uncomfortable, even if they don't really notice it or they won't share it with you.
25:00
Right, a lot of times when people are uncomfortable, they're not ready to share that they're uncomfortable with the person who is the proximate cause of that feeling. Bad jokes, anything your parents say when they're mad or they think you haven't been home recently enough? Anything you say back? Anything a manager or other employee ever said to you
25:21
that made you feel bad? Anything you ever said to a coworker that made them laugh uncomfortably and maybe wince a little bit? Jokes about getting fired or firing people really a bad plan. Jokes about politics, religion, or current events. Here's some things I shouldn't have to mention and I'm gonna say them anyway.
25:41
Race, gender, sexuality, fat jokes, jokes about disabilities, any joke that contains the word crazy, jokes about any one person or their decisions or their wisdom or their plans or their face. You can probably make jokes about Murphy's Law, entropy, computers being terrible,
26:01
you can be really silly or serious about, I'm sorry, really serious about silly things. One of my favorite examples is Las Vegas, colloquially known as fabulous. Maybe you can make a joke with a person about something that they are proud of about themselves but this is tricky. If you knew that I liked making jokes about myself as the girl with her hair on fire, which I do,
26:23
you might be able to make that joke, it might be okay. The issue with that joke is that if somebody else in the room doesn't know that I think that's fun, it can make that person uncomfortable and so I would usually still try to avoid it in a retrospective. And definitely, if you didn't know that I made that joke about myself, don't make it.
26:43
If you can't make jokes, how do you listen in the mood? You can be kind, thoughtful, caring, call out successes, you can thank someone for their honesty and their contributions, you can be warm and welcoming. So what about when things go wrong?
27:01
What do you do when other people blame or make bad jokes? What about when you make a mistake as a participant or a facilitator? If you mess up, you can tell you've made someone uncomfortable, you made a bad joke, you said something, blame me by accident, apologize, correct yourself and move on. It's important to be sincere but matter of fact.
27:22
Don't take time to wallow, don't be performative, just say, I'm sorry, let me rephrase that, let me ask you what you would have liked to know at the time and that's it. If you take time to feel shame and embarrassment and guilt in the retrospective, you're taking everyone else's time to feel that with you.
27:42
It takes away from the mood of gentle inquiry and curiosity that we're trying to have. It's not effective if you're apologizing in almost any context to put your guilt out to the person who's asked for your apology or to the person to whom you are apologizing. It's much better to process that yourself with close friends, with your manager,
28:02
with your mentor, whatever, and keep the meeting moving. Sometimes people will blame themselves and you might need to intervene. This is particularly hard. You just need a short request that they stop and then you need to move on.
28:20
If the person is embarrassed or wants to explain, if they're having that moment where they want to have their guilt with everyone, give them just a moment, thank them sincerely and then move on again. Try things like this is a blameless retrospective and that means not blaming anyone, including yourself. We're here to make sure no one gets blamed, including you.
28:41
Please don't blame yourself. That's not what we're here for. Critically, you don't have to be witty. You don't have to be clever. You don't have to be on top of your game. You just need something very simple that asks someone to do something different than what they just did. Don't try to win, don't try to one-up anybody.
29:03
Your goal is to remind people of the ground rules and keep things moving. If someone asks a blaming question, remind them that we're trying to avoid blame. This is a blameless retrospective. Can I help you rephrase that? Here's how I would suggest that you say what I think that you meant to say. Does that sound right to you? And keep it going.
29:25
Someone makes a bad joke, this is all you gotta say. Please don't make jokes like that in a retrospective. Very simple, move on. You don't have to define it. You don't have to have a conversation about what the boundaries and the edges are and was this inappropriate or was that inappropriate. All you have to say is please don't make jokes
29:40
like that in a retrospective. Doing the retro is not the time to have a teachable moment or to try to stage an intervention. You don't need to convince anyone of anyone. You just need them to stop as quickly as possible so that everyone else can get back to business. If their joke is something like I fat-fingered it, again with the self-blame, you can gently say one of the things I said before or you can just ask them to not make a joke like that
30:01
in a retrospective. That's also reasonable. Once you've gotten them to stop and the group has moved on, don't bring it up again. It's done. As far as you're concerned, it's finished. We never need to talk about this again. If they come to you and ask why it was inappropriate, you can choose to explain if you feel like you're in a place where you can have that conversation or you can not.
30:21
You can just reiterate that it's not appropriate for a retrospective and ask them to please not do it again. All right, so what's the point? Your retrospectives are part of the communication structures of the organization, which produces the systems that you're running.
30:41
It's turtles all the way down. Probably many people in this room are familiar with it, but I didn't know that Melvin Conway is still alive. I didn't know that he coined this in 1968. This is just such a brilliant insight to me that you can look at a service or an application and you can see the fault lines
31:02
and where people didn't know how to talk to each other and where they weren't able to figure out what the UI should look like compared to what the API looks like before it all went out the door, right? So retrospectives will also, the results of your retrospectives will be reflected in the product that you produce.
31:23
Let's go make bigger, more interesting mistakes. Some acknowledgements, I won't read them all out. I am indebted to a lot of people for a lot of the sort of linguist and social concepts in here, some of the technical concepts,
31:41
but also in how to teach and how to address people when I'm trying to show them and not just tell them what I'm trying to do. Thank you all for coming. It looks like I have a little bit of time for questions. Okay, so the question is how do you approach it
32:02
when someone is senior and they are blaming or making uncomfortable junior folks in a retrospective? Have I got that right? Yes, okay. So that sounds to me like the kind of cultural problem where you need probably an executive sponsor, right? You need someone near that person's level
32:22
who is on board with the idea of a blameless retrospective who can talk about it and who can sort of help you spread that word to those folks. Sometimes, depending on the relationship that you have with the person who's doing the blaming, you might be able to take them aside afterwards and talk to them yourself.
32:40
There are some people in my company where I think I have a good enough relationship that I would be able to do that, but it still always helps to have someone at the high level who is on board with what you're doing and can help evangelize. That is super hard. Sometimes, oh, I apologize, yes. How do you interrupt someone who does not take a pause between their sentences?
33:01
It's super hard. What I will do sometimes, all of our retrospectives are on Hangouts because we're a remote company, and so I will try to break in a couple of times. In some ways, I have a slight advantage in that I'm usually the only woman in the meeting, and if I'm speaking as the facilitator, I don't have to remind them why I'm speaking.
33:20
The sound of my voice reminds them. As a facilitator, you might have to remind them. If you try and break in three times, you can't get in. I have not yet gone to the point of non-consensual muting, but that might be a thing. In a physical environment, I might even stand up and sort of physically take the floor
33:43
and say, please save that for later. Okay, so the question is, where do I find the knowledge base? I am not completely sure. If you come up to me afterwards, I can give you my card, and I can give you the slides for the longer version of this, which has at least some of that,
34:01
and that offers for anybody in the room. I don't know, but I also haven't been watching what other people have written, so there might be more out there that I'm not aware of. Recommendations for a manager book club. The book that I recommended before is The Gentle Art of Verbal Self-Defense. It's a long title.
34:23
There's a bunch of different versions of that book which were written for specifically different contexts. I think that the original is actually quite good. I didn't think that the others added a lot in terms of contextuality. I always recommend that book with a little asterisk, which is that the author wrote it,
34:41
and she is a pacifist. She was an absolute pacifist, and so she believed that it was always better to redirect, reframe, to take the hurt herself than to defend, and so you can see that in the way that she recommends handling some of these things. I don't always agree as an adult with her tactics,
35:00
but I think that it's a really excellent way to start thinking about language. Other books, I feel like there's some, I need to, I will try to collect a list of books and tweet them. Yeah, okay, so the question is, what do you do when things get a little bit off track? They're still related to what you're talking about, but too in-depth, and the shorthand we use at Heroku
35:22
is you're off in the weeds, let's come back to the point, let's schedule a follow-up if we need to talk about the technical details of this further. Most companies where I've talked to my peers, they have some shorthand like that, like you're really involved in the details that are not appropriate for this moment, so I would look for that shorthand
35:41
within your company if it exists.