This is a transcript of episode 290 of the Troubleshooting Agile podcast with Jeffrey Fredrick, Douglas Squirrel, and special guest Juan Pablo Buriticá.

Computers think in 1s and 0s, but the best tech teams welcome ambiguity and profit from vagueness.

Show links:

Listen to the episode on SoundCloud or Apple Podcasts.

Cutting Shipping Time

Listen to this section at 00:14

Squirrel: Welcome back to Troubleshooting Agile. Hi there, Jeffrey.

Jeffrey: Hi, Squirrel, and welcome back also, Juan Pablo, our guest. Talking about his framework for capable, high performing engineering teams. So, you know, thanks for coming back, Juan

Juan Pablo: Hey, y’all. How are you doing? It’s good to see you again. Thank you for having me yet again.

Jeffrey: So the cliffhanger from last time was: you developed this framework. You joined this company. It was not a tech company. You were coming from Stripe, a very, you know, software product company into a company with a different culture. You develop this capability model. But I was asking I’m curious, like, so what was the impact of bringing this in and how long did it take? So as you kind of describe the process and evolution of the teams, because from a change management perspective, I know that this these kind of changes don’t don’t happen overnight.

Juan Pablo: I think it still taking I would say. We made significant progress. I think our first objective was to ship a product, a digital product in a matter of weeks.

Jeffrey: Wow!

Juan Pablo: I think when I joined to, when we shipped that product was probably like six months, and the product to actually ship took, I think we shipped our engineering platform in about 12 weeks. So that was a product that shipped in still months. But then we did ship a new inspection report, I think, in four weeks, a month. But we went from like yearly releases of software to shipping stuff in weeks. And I think, to me that that’s when it started working, right? When we had, I think we had 6 or 8 teams out of the entire organization, which was sort of a small portion responsible for driving these new products. And they started acting more as a product engineering organization than a traditional or like an internal consulting IT shop.

Squirrel: Now, Juan, let me stop you for a second just because what I notice is the most noticeable thing about your framework. And I was saying last week how much I liked this. Part of it is that it is ambiguous. It doesn’t go into detail. It doesn’t tell you ‘now your standup should be 17 minutes long and they should happen on alternate Thursdays when the moon is full.’ It just doesn’t give you that kind of specificity, which is what people are often thinking they need to do. Because ‘if we could just do Scrum right,’ ‘if we could just get all the details right,’ ‘if we could just do the correct ritual at the right phase of the moon, then we would get to these results.’

Squirrel: But you didn’t do that. You created these frankly vague criteria and it must have driven some people bananas because they said, ‘how can I judge this? How do I know whether I’m asking for help enough and so on?’ But that is what worked. And I think that’s really interesting for our listeners, some of whom may be be trying to turn to the right page in the Scrum manual to to do the right thing. And we keep saying, ‘don’t do that.’ Am I right about that? What was your experience of using this imprecise method to get to a tremendous, precise result?

Juan Pablo: You’re absolutely right and that’s an incredible observation because I did face those questions and I had that sort of like leadership under me, right? People were saying, ‘but we just need to do this or like we just need to get the right point or the-‘ And so that’s when I said, ‘I don’t care if you count chickens or t-shirts or whatever. Right? It really it does not matter to me if that works for you, that’s good. But this is what works for the organization. And as long as you can demonstrate that you’re capable of doing things, I’m not going to mess with your sort of lower, lower level processes or internal processes. That’s actually like you should have them, something that works and aligns the group. That’s fine. But the entire there’s not going to be 400 people who are going to have to meet on Thursdays for five minutes when the moon is right because that’s what someone believes that shipping software looks like.’

Juan Pablo: And the other important part of this is. Of course, I lived through this. I had the experience of ‘oh! Maybe if I do these things right-‘ and then I learn like none of this works, and then what am I doing wrong? And I had to figure out the hard way. And it’s the motivation of those processes is what matters, right?

Thinking not Dogma

Listen to this section at 05:01

Juan Pablo: There’s a really interesting thing I’ve seen that happens with standups all the time, right? Standups start, then someone suggests maybe we should do it as async written down. Then people stop reading it, then eventually standup stops working. And then what people realize is that the synchronous nature of that ritual is what drives some of the effectiveness, like being in person and having those discussions. So they come back to that. So motivating my teams to understand why some of these things work. Some of these processes could work rather than them just adopting dogma without thinking is exactly the driving nature of this framework. Have them think.

Jeffrey: I like that you just put it, which is like, ‘this is what the organization needs.’ Because when you get something like broadcast state as one of your capabilities, it’s sort of like the idea we don’t we don’t care how you’ve run your process. But however it is, you need to be broadcasting the state to the rest of us because that’s how the organization is going to know what’s going on. I think it’s a good example of the boundary. You’re almost saying like, ‘we need a certain interface to your team, as an organization to be effective. How you operate internally, the exact recipe isn’t important. Does the organization get out of it what they need?’

Jeffrey: I’m going to come back to the question of how long, because you said you’re working with a team. You got a product that shipped in six months and then you had stuff going in weeks, how long do you think it took the fastest team or the median team or the slowest team? You what was the range of like the penny dropping and people understanding and starting to live these capabilities?

Juan Pablo: Of course, a gradient, I think the teams that I work the closest with onthese sort of more modern initiatives for products got it the fastest. But also because I selected them right. I selected-

Jeffrey: The most ready.

Juan Pablo: Yeah. I took out of the teams that were there. I brought in ThoughtWorks on one end to help me give me some some support. And then I took four of our teams, four of our internal teams and they were selected. So I also want to make sure that I give that context. They caught it fairly quickly, I think 2 to 3 months.

Juan Pablo: The most important pieces started working and we started having conversations where like, ‘all right, if I have to broadcast state where to or how to like, where do I plug in? And so the interface thing that you say is right,’ then I would say like, ‘Right, everyone, on Friday we will send this email to here and that way we all can understand the state.’ I

Juan Pablo: I’d say the other teams that we started bringing around, it took them between 3 to 6 months to grasp the most important ones, and actually take ownership of primarily the ambiguity, the goal, asking for help. I think many of them still struggled with negotiating dependencies but I’d also say that is a probably like an organizational flaw around just planning, right? We didn’t have good planning and so there wasn’t a lot of space to understand even what dependencies had come up.

Juan Pablo: I’d say six months overall, six to 18 months drove the 80% of the progress towards this. I think they’re still at the edges. There’s still a lot of things to resolve. But good enough, especially for an organization that’s 50 years old, right? It worked out really well.

It’s Always Going to Take Longer Than You Want

Listen to this section at 09:04

Jeffrey: We hadn’t discussed this, I didn’t know what timelines you were going to come up with, but my intuition was, from having done similar things is: it’s longer than a lot of people might think. Because if you look at your best case and this maybe was took longer than you expected at the time, you took a team of people that you teams that you thought were closest to being ready. You had pretty heavyweight support with ThoughtWorks being there as well. You’re working with them intensely trying to ship this product. They’re getting a lot of coaching. You might have thought, ‘well, how long could this take? A couple of weeks, maybe 3 or 4 weeks would feel like about right.’ But then actually it would took more like you said, 2 to 3 months, in the in the best case. Was that a surprise to you or-?

Juan Pablo: It was not not a surprise, but it was something I didn’t want to accept. Right. I was still stubborn enough, even though deeply inside I was like, ‘this is going to take a while.’ I was like, ‘No, this should take two weeks. This should take three weeks.’ And so I was like, very stubborn around that. But no, like organizational change overall, I think generally 6 to 18 months, depending on the complexity of the change is is what I expect. Even at a startup, right? Even at a startup like driving, like implementing DORA metrics, the right way, like actually in a way that they’re effective, took me six months at a startup that moved fairly fast.

Squirrel: And not everyone will know the DORA metrics, so we’ll make sure to link those in the show notes. Keep going.

Juan Pablo: So, yeah, I think it’s always going to take longer than you want it to.

Jeffrey: I just thought it’d be useful for our audience to hear that, for people who are thinking, ‘okay, what’s a realistic amount of time?’ And one thing is you probably did see some results quickly, right? Because this is like how long it took for people to be really into it. But I imagine you were seeing some incremental progress, some benefits of the conversations earlier, even if the teams hadn’t fully adopted everything, they really hadn’t internalized the mindset.

Juan Pablo: Yeah, I think from previous change management efforts that I have caused, I now started with pilots, right? So I picked a few small teams, so that I could minimize the risk of them not being successful, and then show them to the rest of the organization as an example so the rest could follow. And that, I think, increase the likelihood of success. Usually when I do those pilots around around new processes because it’s the teams that start evangelizing how things are working. And it’s not just the suit up there saying how people should work, right? So that was that was the that tends to be the most impactful thing when I when I do the these big transformations.

Jeffrey: You told me that you just recently changed organizations. Do you already know your first pilot or have you already started your first pilot? What’s the is there anything from the framework that you’re going to think like, ‘yep, this is what I want to work on first?’

Juan Pablo: Awesome. Great question. Yes, I’ve just hit five weeks at a startup, so I moved from a team of a few hundreds to four, so…

Jeffrey: Okay! Wow!

Juan Pablo: So it’s a drastic change. I am starting with the ambiguity, but they’re really good at it, actually. So what I found is, this crew has been working in such an ambiguous environment for so long that most of them are very good at navigating ambiguity, resolving issues and actually shipping everything by themselves. I’ve seen features that come from like an engineer like, ‘oh, here’s a problem, here’s the right. I wrote the code, here’s a PR and it works,’ and walks the customer through the issue and it’s like, ‘Oh wow, that’s absolutely wonderful.’.

Juan Pablo: And then there’s a little bit more like, ‘well, I’m sitting idle, I don’t know what to do.’ And so but I have a single team. So right now my priorities are a little bit different around setting individual expectations and probably strengthening the team around hiring a few folks. But yes, I definitely have the top five are what I’m expecting from the crew to begin with.

Jeffrey: Yeah, that’s your core. Navigating ambiguity, Set goals, ask for help, broadcast date, negotiate dependencies. Fantastic.

Squirrel: Excellent. Well, you know, what I want to do is ask you, Juan, more about where that’s going, because you’re starting the new project. You’ve learned a lot from one very interested in where you’re taking this next. But we’re out of time for today. So I’m wondering if you’ll come back just one more time for us next week and if we can ask you about where this is going? What the next step is? What where do you add to the framework or what you’d change in it? Would that be okay? Are you willing to come back one more time for us?

Juan Pablo: Of course, this conversation has been lovely. Why not make it one more week?

Squirrel: Fantastic. Okay, well, so if listeners are interested in learning more about this, first of all, they can find all of Juan’s information in the show notes, the link to the article that describes this framework. And there’s Twitter and probably lots of other ways to get in touch with him. So that’s the first.

Squirrel: And of course, come back next week and we’ll conclude our series with one with a look at the future. Where’s one’s framework headed? Where can we be even more ambiguous and more successful? We’ll see you next week. Thanks, Jeffrey. And thanks, Juan.

Jeffrey: Thanks, Squirrel.

Juan Pablo: See you all.