This is a transcript of episode 163 of the Troubleshooting Agile podcast with Jeffrey Fredrick and Douglas Squirrel.
In the first of a two-part series, Johan Abildskov of Eficode has a conversation with Jeffrey and Squirrel about culture, transparency, curiosity, and how to use all three to adopt DevOps methods successfully. Special addition: a video version of today’s podcast!
Squirrel: Welcome back to Troubleshooting Agile. This episode is the recording of a interview by Johan Abildskov, an amazing system admin and DevOps person from Eficode in Denmark. Johan wanted to talk to us as preparation for our conversation with him on stage at the Eficode DevOps conference. We had so much to say to Johan that we split this conversation over two episodes. This week we’re going to be giving an introduction, so if you’re new to us, Agile Conversations, and the methods that Jeffrey and I use, this would be a perfect one for you. With that, let’s get into the recording.
Johan: Hello and welcome to what we might call an ‘Agile Conversation.’ I am Johan, and I have the honour of being here with Jeffrey Fredrick and Douglas Squirrel, who have written the fantastic book Agile Conversations. I work as a DevOps consultant and I’ve spent much of my time in organisations and teams trying to improve how they work from both a technical and a cultural perspective.
The Importance of ‘Soft Skills’
Johan: Often, even though projects like Google’s Rework or Project Aristotle demonstrate psychological safety and collaboration skills are the key drivers of high performing teams, I feel we as engineers highly undervalue the soft skills. Even the phrase has negative connotations. I’ve been told ‘Johan, you’re such a fluffy consultant.’ People question our technical ability simply due the fact that we also care about other things. So I’m glad we can have this conversation and you can enlighten me and our lovely audience as to some of the tools and techniques you’ve developed, and some of your experiences, because I really enjoyed the concreteness and applicability of your book. I really like the way we can put culture and the way that we interact as humans at the forefront of everything. So perhaps starting with this accusation that we can be ‘too fluffy’ or that soft skills are an inferior skill compared to the technical ones. Do you have any narratives that deal with this?
Squirrel: We have an old friend, Mark Coleman, who actually helped us with the book launch and all kinds of other stuff. He’s a very clever guy who knows a lot about product marketing of software. Mark likes to say that ‘soft skills’ are actually ‘really f-ing hard skills.’ I really like that comment because it’s absolutely accurate. These skills take about as long to learn as playing tennis well. Not at a world class standard, but it’s going to take you a few months of practise to get good at some of the skills that we’d like to teach. Certainly we won’t get through it in this session. If somebody else says they have a one-session fast track to mastery, we’d love to attend it, because we don’t know that path. But we do know something that’s hard, that takes lots of practise and knowledge and understanding, but that has tremendous rewards. Things like ‘infrastructure as code’ and unit testing and gosh, maybe developers and operations being together in the same team. What a crazy thing, you could call that DevOps or something. All of those things you can accomplish better if you can adopt these skills. But they’re not the skills you learnt at university. Nobody at university told you you were going to have to do difficult emotional work. Guess what? That’s what we’re here to tell you you need to do.
Jeffrey: I think this idea of technical skills at the fore with soft skills second is a bit antiquated. It misses how much collaboration is in modern knowledge work. Not to say that’s true for everyone, I’m sure there are people who happily spend their days working in technical isolation from one another and are perfectly productive, and that’s what’s called for in their environment. Most of the people I interact with, that’s not their reality. In fact, most of those people are embedded in and part of teams. So you could say they work with people as much or more than they work with computers and technology. The difficulty is that they’ve never been taught how to work with people. As you mentioned, Project Aristotle found psychological safety has been the primary determinant of what made an effective team. So the impact of this knowledge gap is not a small one, it’s actually quite significant.
Johan: One thing that I noticed, Squirrel, you call it difficult emotional work, and Jeffrey, you touch on it when you say we haven’t learnt to work with these things. I’ve had the privilege of participating in a conversational dojo where we did some work, and the promise that we were given is that that learning is painful or learning is uncomfortable?
Jeffrey: Learning is horrible. I should clarify as I get a lot of pushback when I say this. Many times people respond, ‘oh, I love learning! Well, you probably mean you love reading. There’s a difference between learning something new, and the kind of learning that happens in the conversational dojo, where we practise the skills from Agile Conversations or more generally, conversational skills. We will analyse our conversations with the aim of learning how to do better. Now the thing is, when we are learning about our contributions to conversations, we’re not just learning a new fact about the world. We’re learning something about ourselves and generally something that we didn’t believe was true, and this is what makes the work difficult and painful when it’s being done successfully, and it’s also why people avoid the work. I might have a talk, for example, like ‘Are you frustrated? It might be your fault.’ The reason is people generally, when they think of frustration, look at the locus of control as outside themselves. ‘I’m frustrated because of them. I’m frustrated because of those people over there.’ When we do the analysis and we ask, ‘well, what’s your contribution?’ People often find oh, actually, they’re doing a lot to contribute to what they’re claiming to be frustrated by. So they’re still frustrated, but now it’s because of them, and that is kind of a painful and uncomfortable moment.
Squirrel: It’s also a wonderful opportunity, because it’s the opportunity to do something about it. Suddenly you can take action. I had someone I was coaching, and I said, ‘isn’t it wonderful to find out that it’s your fault?’ And she said, ‘no, it’s not.’ I said, ‘But what does it being your fault mean?’ She said, ‘well, it means I can do something about it.’ That’s where we want to be.
Jeffrey: That’s the choice, really. What we’re talking about is clearly optional. You don’t need to learn these conversational skills. You don’t need to look at your contribution. If you choose to remain frustrated, I’m not going to blame people for that. It’s a much safer alternative to just blame other people and sit back and say, ‘aren’t we great and wonderful and isn’t the problem with those people over there.’ If what’s important to you is feeling good about yourself, then you can prioritise that. If you want to prioritise being effective in a team, however, then I would advise something else. If you want to be effective in a team I would advise you do learn these skills despite the discomfort. The challenge is that people won’t recognise that they need to learn these skills. This is what makes this a very hard sell. People generally agree culture is important. People agree that psychological safety is important. They agree clearly that if we’re going to have effective conversations, we want to hear from everyone. They believe that they already do this and they believe that they’re good at it. What we’re here to tell you is that you’re probably wrong. If you haven’t deliberately studied it, you’re probably bad at it. The reason I say that with some confidence is because I’m going to assume that you’re human, and thus suffer from things like cognitive biases that lead to predictable types of behaviour. Essentially people are very good at conversations for addressing all the problems they can see. The problem is cognitive biases mean there’s some things we cannot see, and that’s where the problems persist: in our cognitive blind spots. The skills we teach are about how to see in those places that you haven’t before. When you do that, you see mistakes that you’ve been making all along but were invisible to you. That’s the kind of horrible learning moment. ‘I didn’t think I was one of those people.’ That’s the challenge. The good news, though, is that this is a learnable skill. You can learn to see your conversations differently and all it takes is a piece of paper and a pen.
A Client Story
Squirrel: And the ability to fold the piece of paper in half. If you have that much origami skill, you’re in good shape. I had a phone call just before coming on to record this, from one of my clients in San Francisco. She was phoning to say, ‘I’m frustrated with my developers. I’m not getting the right thing from them. I want to do better. I want to use Jira better.’ That’s where we started. I said, ‘could we roleplay for a minute? Could you be the developer? I’ll be you.’ It only took us like two lines of exchange. I said, ‘I’d like to build this feature,’ and she as the developer said, ‘sure.’ I said, ‘gee, it sounds like you might be sad. Is that right? Are you feeling sad?’ And she said, ‘Wow!, I could never do that. That’s completely different. What would that be like, to say that to a developer?’ We were off to the races. That was the type of practise and learning that you can get from studying your conversations, making them a first class element of your development toolset, something that you can work on and improve. We’re talking all about how horrible it is, and it takes you as long as to learn a game of tennis. But there’s amazing moments of searing—if painful—insight that you can get very quickly. So that’s the upside.
Actionable Advice on Beginning Your Journey
Johan: One thing that you capture in that tiny exchange is psychological safety, the space to be able to take interpersonal risks. But trust is built in years and lost in seconds, so part of the first roadblock around this is daring to take that risk in ambiguity. ‘Is the right step?’ How does one begin to work around this without all the skills, teams, awareness, or reflection? What are the first things we can do?
Squirrel: I’ll tell you two very basic things that you can get started with, things that anybody who’s listening to us could immediately implement. And then I’ll tell you a third one is a little more challenging because I feel like throwing in a third one. First of all, say what you see. I modelled it in that very brief example, and the brevity of the example is important. You can get a tremendous amount from a tiny piece. In that tiny example, I observed something just from her role-playing. In being the developer to help me help her, she exhibited signs of sadness. She was looking at her shoes and speaking with a depressed sound. And so I said what I saw, that was the first step. ‘I observe that you might be feeling sad.’ If I’d been in person I might have said, ‘you’re looking at your shoes and I notice that your voice is a little quieter.’ I’m observing things that a camera would record. That’s the first part. The second action is I’m asking a question. So just that one example captures two of the key things that are really helpful. Observable data—what each of us can see—and curiosity. ‘Does this match what you see?’ There are many other explanations for speaking in that way. ‘I’m feeling deferential, I’m kind of scared of you, I’m concerned that you might not respect me, I’m feeling very excited to meet you and I’m a very shy person so I’m looking at my shoes and speaking quietly.’ There are lots of explanations you could come up with, and having genuine curiosity about the facts that you just noted and what’s behind them gives you a really great basis for having a trusting relationship. ‘Now that we both understand you’re feeling sad, let’s see if there’s something we can do about that, because I like you and I’d like you not to be sad. How could I help you with that?’ The investment is not massive. The kinds of changes you can make—asking more questions and saying what you see—are are small interventions. They’re habits to get into that have tremendous valuable results, as they did for this product manager from San Francisco who had her mind blown by a couple of lines.
Jeffrey: And what is she saying? She’s saying basically ‘we have this team and there’s some dynamics on it that aren’t quite right. I’m not getting the results I want. I’m not quite sure what to do.’ That sort of frustration that people might feel things just aren’t quite right on their team is usually accurate. They’re not getting the energy dynamics, drive, collaboration, whatever it is, they can just say, ‘am I happy with the dynamics I have or not?’ And now the problem is, if the answer is ‘not,’ this is where what we talk about is very different from what you’ll find in most Agile books, or the DevOps books, or even DevOpsDays talks. DevOps conferences will talk about culture, how important culture is, and you need to collaborate. But then they say, ‘and you collaborate by getting everyone colocated, or if you’re on Zoom, then you have virtual coffees, and you need retrospectives.’
Squirrel: I just found it on page ninety two of the Scrum book. Here it is, ‘hold a retrospective. Do it this way.’
Jeffrey: Exactly. ‘If that’s not working, try a liberating structure. Here’s the cookbook.’ Sometimes it works. You just put people together and human nature comes in and they work things out. They’re sharing the problems, they’re sharing their ideas, and everything just works and that’s great. But the problem is sometimes it doesn’t work and we lack generally a theory about what’s gone wrong. You know it’s gone wrong, but not why. You’re trying the same standups, the same retrospectives, the same planning meetings, the same things. You’ve just changed the people, so it must be a problem with the people. But that’s not it. The problem is you were able to have the good dynamics before and not now. But you can change the dynamics as long as you can learn to see them and understand them. That’s where Agile Conversations comes in. We lay out five different conversations that are important for any high performing team: the trust conversation, the fear conversation, the ‘why’ conversation, the commitment conversation, and the accountability conversation. All these actually are built on a foundation: in chapter two, we lay out the core skills of just being transparent and curious. Just start with that. Chris Argyris, a business psychologist theoretician, noted that when there’s a potential for threat or embarrassment, humans react with a defensive mindset, with defensive reasoning. It’s this defensive reasoning that inhibits our ability to speak up and say what we see. It interferes with us connecting with people, with having a positive dynamic. When we’re in this defensive space our limbic system kicks in, fight or flight or freeze, so we maybe say nothing or maybe argue what we think is right, but without listening to the person. Or we just accept what they say even though we’re not happy with it, we don’t share our feelings. We don’t bring all we know. We don’t bring our full selves to the situation, and when we’re not bringing our full selves, we’re not going to have those joyous, fantastic dynamics we can have on the best teams. In my view, that’s what’s at stake, and this is why I’m so excited about it, because I’ve worked on some great teams, I’ve had some great dynamics. If other people could experience that, they would never settle for anything less. I would like to have people have that kind of experience and not settle for less, and to learn what to do when they’re not getting it, which really, always comes down to what conversations are you having or not having amongst the people on the team?
Johan: Thank you so much.
Squirrel: That’s the end of this week’s recording. We’re going to be returning next week with the rest of the interview.