This is a transcript of episode 297 of the Troubleshooting Agile podcast with Jeffrey Fredrick and Douglas Squirrel.
Don’t let your engineers outsource risk by settling for a list of tasks, instead give them real business-meaningful targets and permission to fail.
No show links this week.
Listen to the episode on SoundCloud or Apple Podcasts.
What are OKRs?
Listen to this section at 00:14
Squirrel: Welcome back to Troubleshooting Agile. Hi there, Jeffrey.
Jeffrey: Hi, Squirrel.
Squirrel: I think you have a story for us today.
Jeffrey: Yeah, I do. We’re coming near what is a traditional OKR season for people who do quarterly OKRs. And I’m working with a group and to help them-
Squirrel: So people know, OKR stands for objectives and key results. It’s a way of evaluating your technology team or any team.
Jeffrey: Yeah, and in building alignment on what you’re going to be accomplishing, which is, this group to help them prepare, I went back and look at their Q3 OKRs and now though as you say, the OKR stands for objective and key results. So you have a sense, a statement of what you’re trying to achieve is the objective and the key results, the things you’re going to measure to validate that you’re moving towards the objective. So you’re making essentially predictions. And I’d say the key results represent your theory of what it takes to achieve that objective.
Jeffrey: And what I found when I looked at this group’s key results is it was the results weren’t results, they were tasks. So you’d have is more like objective and project plan with task, task, task, task. So you’d say something like, you know, deliver this feature, put this data in this internal database, configure this. So it was a list of steps and they would add up towards delivering a certain capability. But there was nothing there that was, I would consider a result which would have been something like, you know, 10,000 users use this new capability in the quarter. That would be a result. But instead it was task, task, task. And that really struck me.
Squirrel: And probably many of our listeners are thinking, that sounds great. I would love to have a series of tasks so I could just tick them off and do number one and then number two and number three, That sounds great. What’s wrong with that?
Jeffrey: And I told these people, “this is great! …As a project plan and you should have a project plan. But don’t confuse the plan to achieve a result with the result you’re trying to achieve.” And that was the mistake that I saw here and a mistake I’ve seen many times. And it seems to be something that people are more comfortable to adopt results, quote unquote results that are things that they can control. They can control ‘do we deliver this feature?’ But the result of clients use it? Clients get value that feels a little bit more scary. And so I think there’s an element where people tend to move to those things that are within their control and that loses some of the value of remembering why we’re doing this. What’s the result that we’re collectively trying to achieve?
Squirrel: And of course I really like that you use the term comfortable there because setting objectives for any team, whether it’s technological or not, should feel risky. We should be feeling uncomfortable because we’re doing something that’s not known. I mean, if we are building a brick wall and we really understand our bricks and we know exactly where the wall goes and we can follow a repeatable process to do it, then we might say number of bricks per hour or number of feet of wall might be a reasonable measure for what we’re doing. But in almost no cases are the things we’re trying to lead teams to accomplish so well defined and so well known and so perfectly understood as the making of bricks and brick walls.
Jeffrey: Yep.
Squirrel: It’s not repeatable like that. And so discomfort is the thing you’re you’re aiming for. But people have a natural bias for obvious reasons, against being uncomfortable, so they seek greater comfort. And you had a great example of that with your engineering and product teams, I thought.
Jeffrey: I thought it’s funny about the brick wall. One thing is because what I often see is people I say, “Look, you don’t need to put into your key results the things that you can take for granted. And instead you’re looking at these things where you’re trying to learn and you’re trying to understand.” And one of the side effects that happens is these key results. These OKRs are are being set by the product team with the engineering team to understand what they are trying to commit to for the quarter, what they think they can can adapt. And when we go ahead and have something that’s more client facing towards what we actually want to learn now, we bring the two groups together and they can have constructive dialogs because if we see things like, well, we want people to use this new capability, you start understanding there’s things beyond just building it that need to happen, like maybe we’re going to need to tell our clients that exists. Maybe we need to train our support people on it. There’s suddenly a lot of other things-
Squirrel: You mean we might have to talk to customer service and marketing?
Jeffrey: That’s right! Exactly. There’s going to be other people. And because I think it’s very easy for product teams and by here I mean both product management and engineering together. But for the product teams to fall into the solution to everything is to build and they lose track of all the other pieces that are required to get traction with actually delivering value out to clients.
Squirrel: And I thought you had an excellent example also, Jeffrey. You were telling me about, before the podcast, where the engineers got challenged in this way and started to feel uncomfortable. And then they went to their product managers and asked them for some help. And I found the help entertaining. You want to tell us about that?
Jeffrey: What happens was I asked the product person, “Well, how did you end up with this list of tasks as your key results?” And they basically said, “Well, this is what the engineers said they wanted, they wanted to be told what to do so that they so they couldn’t commit to it otherwise if they didn’t know what they were being asked.” And and that’s the challenge. I don’t know if that’s the example you had in mind.
Squirrel: Absolutely. It’s exactly the one I had in mind, because what’s happening there is Jeffrey is explicitly doing what we’re telling you listeners to do. He’s encouraging not only the specifics of building key results that are business focused, but trying to create a culture across the team that encourages everyone to think that way.
Squirrel: And despite all of that effort, the engineers, because they have a bias toward comfort and certainty and knowing that they can tick things off a list and put the next brick in the brick wall, they want to outsource the risk and they look around and they say, well, who could take on this risk? Who could give me a list? And by giving me the list, take responsibility if the list is wrong. Well, gosh, there seem to be these product people around here. Maybe I can put the monkey on their back. And this is perfectly natural thinking and not in any way malicious, but it’s exactly the sort of thing that you want to resist. And if you see that your engineering team is putting on pressure for a list of tasks, resist that because that’s going to help. If you resist it, it will help you create the culture where the engineers might have to go help marketing to tell marketing customers about new features instead of building new features. Yes, and that’s counterintuitive and not obvious, not instinctive for engineers. And it’s risky. And so they need your help as an executive to give them the courage to do that.
Teams are Defined by Shared Problems
Listen to this section at 07:44
Jeffrey: As you as you’re describing this, it reminds me, I often when I coach people about what I consider the functional definition of a team, and I say this, you know, you can have a group of people who are not a team. What what makes them a team is that they share a problem. And one way to look at this is what we’re describing here, is when people say, “look, getting those people to use it, that’s your problem. My problem is just to deliver.”
Squirrel: This is demarcation. This is the danger. We’ve talked about it before, I think.
Jeffrey: Exactly. We’re splitting ourselves apart and saying we’re not really a team. And that’s if we go back here. That was the intention of OKRs, was to get people aligned on a shared problem that they will then work together to solve. It’s not designed as a way of splitting things off so that you can just focus and don’t care about the bigger picture.
Squirrel: It’s so instead of compartmentalizing and siloing and reducing the problem by dividing it into many pieces, we want to look at the problem as a whole so that when we describe the problem and we describe our solutions, customers understand it. Other people in the business understand it, and we can figure out how to actually deliver it in a way that works. Instead of ticking things off a list and saying, “Well, not my problem if it didn’t work.” Same as when you get building people in and they the person who’s fitting the drywall says, I can’t plug in that device, I’m not an electrician. So, demarcation sorry, can’t, can’t touch electrical things. Doesn’t get a building built. It doesn’t get software built.
Jeffrey: Yeah, and one thing that I think is a funny side result that may happen here and that I think is a positive result but people might be surprised by is if you actually are successful in building this alignment, then suddenly you might be introducing some productive conflict because you might have people saying, “Wait, I don’t understand. You’re asking me to build this, but how does that how does that get us to our result?”
Squirrel: And that would be really useful resistance.
Jeffrey: Exactly.
Squirrel: That would tell you something by way of conclusion. Let me tell a very brief story about a client question I got recently. The question was at one of my weekly events that I do as part of my Squirrel squadron group, and somebody said, “You know, it’s kind of funny as you’re describing this,” we’re just talking about a similar topic. He said, “Oh, that kind of gave me an Aha! Moment. I observed that what you’re doing and what you’re asking us to do might explain why nobody ever comes to our demos.” And I said, “What do you mean?” He said, “Well, we started having demonstrations of the new features and the new changes that we’re making to the software in the product. And for the first week or two, people came from across the business and they observed what we were doing. They asked us good questions, but then they stopped coming. And it strikes me that maybe the reason they stopped coming is because we weren’t describing what we were doing in terms that made sense to them.”
Squirrel: And the way we can connect that to what we’ve just been talking about is if you outsource all your risk, if you just reduce everything to a list of tasks, they’re going to be technical tasks. They will be meaningless to others and you will seal yourself off from feedback from them and the kind of advanced diagnosis, the advanced version of this, if the disease has progressed a long way, is that you get isolated and you say, “Well, we don’t know what those other people want. They just give us lists of things to do and we do our thing. And that seems to work just fine.”
Squirrel: And you can’t even see the problem anymore. Now, this person hadn’t got that far. He observed that no one was coming to the demos and didn’t conclude no one was interested. He was curious about what the problem was. So the setting of real results rather than lists of tasks is a way of putting positive pressure on the team to move toward that kind of thinking. And no matter how advanced they may be, I think that’s going to make a big difference if listeners can do that.
Jeffrey: Absolutely.
Squirrel: Fantastic. Thanks, Jeffrey.
Jeffrey: Thanks, Squirrel.