This is a transcript of episode 291 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.

What’s Next for Juan Pablo?

Listen to this section at 00:14

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

Jeffrey: Hi, Squirrel. So Squirrel, you invited our guest, Juan Pablo, back for a third appearance. You had some questions for him?

Squirrel: I sure did. So those who might not have listened to the previous two, and they definitely should because one has an amazing set of ideas here really matches up nicely with what we’re talking about every week, and what Juan told us about was a framework he’d come up with. Which is not very specific, doesn’t tell you which meeting to have, at which phase of the moon, but does tell you how your technology team is performing. He told us the story of implementing that at one company and all the ups and downs and the difficulties and the challenges that happened. And my question at the end, which we didn’t have time for, was, one, what’s coming next? So you’re starting a new project. You’ve probably learned a lot from implementing one time. What might you change in your core elements of your framework? What might you ask teams to do differently? Where do you think this is going next?

Juan Pablo: Hey, Squirrel. Hey, Jeffrey. How are you doing? Thank you for having me again. And jumping straight into the question. It’s a good question. I’ve been pondering it the entire week because I have a good idea of what I need my team to focus on the next 3 to 6 months. But I don’t have a fully staffed team, right. We have four engineers who’ve been at this company for three years and it’s their first job and the only job they’ve had.

Squirrel: And your previous experience was with hundreds of people, right? So it was a much, much larger organization.

Juan Pablo: Yeah, 400.

Jeffrey: Wow.

Squirrel: This is a huge shift.

Juan Pablo: Yeah, I know. I’ve had a few people, like, wonder why I made that choice. I miss startups in getting the chance of working. This one is like oriented towards Latin America, which I’ve always wanted to, to spend some time - I’m from Colombia. And so right now, everything sort of depends on me building a team, right? I think there’s four individuals there, I need to strengthen some skill sets, bring a few folks who have seen some of this stuff before. And but the goal is the same, right? I want teams that can ship products at a ridiculous speed without spending a ridiculous amount of time working. Right. Sustainable pace, huge impact.

Juan Pablo: Here, I think the framework will definitely be smaller. Um, because I’ll be able to select through the hiring process, whether folks already have some of these capabilities or not or understand or have demonstrated this in, in previous lives, um, especially managers, right? I think it gives me a good language to interview managers around. Like, “how have you like, tell me about a time when you’ve navigated ambiguity and what was the outcome?” And so that, that helps me validate demonstrated experience, which is what I’m looking for right now. Um, I have, I have a fairly junior team right now. They’re super talented. Just need a little bit more support. From there, yeah, sharpen the framework.

Juan Pablo: But. But if I’m honest, I am now the engineering manager. Right. So. So this framework is what I measure myself on. Can my team navigate ambiguity? I’m no longer the one who is like, evaluating, I’m like, I am both the person who is evaluating and the person who is responsible for this for this. So can my team navigate ambiguity? Can my team set goals? Can we ask for help? So. So I think I’ve become a user of the framework, and it’ll give me a new perspective on how it might work or not, and I’ll definitely evolve it. I think it should be shorter, it should be a little bit more concise. So I’m actually excited about what I’m going to learn through this experience.

Accountability

Listen to this section at 04:43

Jeffrey: Do you have a process by which you’re holding yourself accountable? Do you come and like grade yourself on any sort of regular cadence on, “how am I doing? What would I give myself or say, asking for help? Do I give myself an A or a B? Do I give myself five stars or four?” Like, how do you do you do that? And if so, how do you do it?

Juan Pablo: That’s a great question. I did have like an internal grading for my for my teams at at at Ritchie Bros. I didn’t share it publicly, but I had basically metrics, right? So I had a capability dashboard that had those 17 little blocks. And you could either have demonstrated it or not whether your crew was capable or not. So I’m going to use that for myself. I tend to check in with myself every 3 to 6 months. I have like a day where I block off and I do like my own planning and I do like my strategy. I just want to make sure that I’m not caught in the busy work. And so, yeah, I think I’m six weeks, five weeks into this new job. So in about seven I’ll have to look at do we have goals yet? Have we been- do people know about what we’re working on? Um, there’s going to be some tests that I can run around a survey in the teams, it’s a 25 person company, so it shouldn’t be difficult, but that’ll give me a perspective. So I do, I do rate myself and hold myself accountable.

Jeffrey: Have you shared this framework with the CEO saying, “here’s what you can expect from me?”

Juan Pablo: No, um, I don’t think he’ll hear this podcast, but, um, CEO is a young founder CEO, um, first time CEO. First time founder. First time, first job, first everything. So I, I will navigate that a little different. I think the level at which we are aligning on is more the company goals, right? Like are we making progress towards growth in my individual goals or like have we built a team? Are we shipping regularly? I do have some metrics, right? Like around cycle time and around, um, sort of deployment frequency, just the engineering metrics I’ve used for the past few years. And that’s what I’ll have the conversations with him eventually. I think once I have a better sort of feeling for whether it’s working or not, I’d probably introduce it.

Jeffrey: That sounds, it’s interesting to me. It sounds like, as you as you’ve developed and shared it so far, this is really like how you as the engineering leader are judging your organization. Saying, “I want these properties of my organization, of my teams,” and then you yourself are accountable to your business partners, to your CEO, whatever, with a different set of metrics, which really it sounds like you really focused on delivery cadence, maybe stability. You know, what other sort of things here, are we to use a Squirrel’s line? Are we being insanely profitable or not? Like sort of you’re more looking at sort of the overall outcomes from the business perspective. And then this is how internally you’re telling people these are the properties that we have that allow us to reach those business goals.

Juan Pablo: Yes, and comes from what I’ve observed is that just getting software out is unintuitive. Shipping software is is a very unintuitive process. So that’s why I believe that we gravitate to very like precise frameworks like Scrum. Like, oh, you have to do this! Because it gives us some false sense of security, right? I can control all these things and then something is going to come out and software is just not… like that.

Juan Pablo: If I have conversations around velocity or around this sort of stuff at the executive level, I’ve lost. Right? I’m trying to explain to other people how software works and they’re never going to get it because they’ve never shipped software. They haven’t lived through that process, so they just don’t have that context. And now my approach is I don’t even have that battle. The conversations we will have are over something that I am happy to walk you through. It’s like this is why deployment frequency matters. This is why cycle time matters or this is. Or we can look at business metrics in how the organization might or might not be sort of performing. But I’m not bringing you into like the arena of how software is built or how the team is just acting because that’s my job. And that’s why you hired me. So, yeah, so that’s that’s been my approach in the latest years.

Jeffrey: Fantastic. Well, I know that would fit with the kind of conversations that Squirrel and I have on both sides of this divide, both with the engineering leaders and as well as the business leaders to say, “you know, you definitely can talk to your engineering leaders and ask them to be accountable on business metrics and, you know, ask for explanations in business terms and talk about business impacts. And you shouldn’t accept people who want to take you through the steps of software development.” That’s- you’re shaking your head. You maybe have seen that happen before?

Juan Pablo: Totally. I’ve seen it from both sides. I’ve been sort of pressed to do so. Right? Like no, like, show me the show me the pull requests. Like, no, we’re not going to talk about line of codes. We’re like- that’s- I know that gives you like- the analogy is like, do you check how many emails salespeople are sending? You don’t.

Juan Pablo: Let’s not get this deep into that now. What I’d say is it’s also our fault as engineering leaders that we don’t learn enough about the business. Or we don’t develop our communication skills enough to communicate how engineering processes or the ways of working have an impact on the business. I think Nicole, Dr. Nicole Forsgren, and her crew gave us with through the door framework and the door matrix and the book ‘Accelerate’ gave us lovely tools to try to show how software delivery has actual impacts on organizational culture and performance beyond just engineering. Now it’s our responsibility to walk through that and learn how to stay at that level and make other executives comfortable with that so that they don’t feel the need either to have to understand how software works or we are also not having- like I think if we’ve talked about scrum in an exec meeting, we’ve lost.

Jeffrey: I love it.

Questions for Engineers

Listen to this section at 12:10

Squirrel: I’ve gone even further. I’ve printed up certificates. If listeners want to write to me, I’ll send them a copy. Official certificate signed by me that say that for people who are not engineers and the certificate says that you are permitted to ask questions of software developers and goes on to list some of the questions you can ask. And they’re just similar to the ones you were saying.

Squirrel: One, you can ask about the business impact. You can ask about when this will be finished. You have permission to ask those questions. One of the sad things is us engineers have a tendency to shut down those conversations. Shift into velocity mode, into telling people about our scrum rituals, and that’s not what’s helpful. So Jeffrey and I are big fans, and that’s one reason we really wanted you to come on, is to help our listeners get a different perspective on why that why those methods. Why that instinct is one to fight, and it’s better to open up for questions at the right level. I got one more question for you, Juan. Does the framework have a name? Because I’m just going to start calling it the Juan Framework because I need to call it something

Juan Pablo: Uh, It doesn’t have a name. And I think if we give it a name that people start using it in ways that should… You can name it if you want. Right now, for me, it’s just a capability framework for building exceptional product engineering teams. As in the title of the post.

Squirrel: Perfect. Well, we’ll come up with some nifty acronym.

Juan Pablo: Acronym or something.

Squirrel: Exactly. Something that’s as good as DORA. Good news.

Juan Pablo: Great. Can’t wait until- Can’t wait until consultants are charging for it.

Squirrel: Perfect. That sounds absolutely terrifying, in fact. So look, if listeners want to hear more and learn more about this, what’s the best way for them to get in touch with you, Juan?

Juan Pablo: So we’ll share the my Twitter on the notes. Probably also my email if you want to write. I’m happy to- And then we’ll also share the link for the article. I think those three things should be should be good.

Squirrel: Fantastic. So check the show notes. Everything about Juan is there. Thanks, Jeffrey, and thanks Juan.

Jeffrey: Thanks, Squirrel

Juan Pablo: Thank you all for having me. Keep this good work. It’s really, really cool. Thank you for having me.

Squirrel: Thank you so much.