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

A Framework for Effective Engineering Teams

Listen to this section at 00:14

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

Jeffrey: Hi, Squirrel, And Squirrel, it’s not just you and I today we have a guest today.

Squirrel: Fantastic! Who’s that?

Jeffrey: Yeah, this is Juan Pablo. Would you introduce yourself?

Juan Pablo: Of course. Hey, Jeffrey, Squirrel. Thank you for having me. I’m Juan Pablo Burica, live in New York City, engineering leader for bit, and excited to be here. Thank you for having me.

Jeffrey: Well, thanks for coming. So, Juan, I was really excited to have you on. About a few weeks ago, maybe a month ago now, you were a guest at the San Francisco CTO Club where I’m a member, and you came and shared with us your framework for what you think makes effective engineering teams. And I thought this would be fantastic content for our listeners, just exactly the kind of things that people care about. Of course, we’ll put a link to your framework, an article on that in the show notes, but I was hoping you could come and talk about that. So maybe start with where did this come from? What led you to create this framework in the first place?

Juan Pablo: And of course. Well, like most things, came from a real pain. So I right after I left Stripe, I was leading the engineering team for Latin America at Stripe. I jumped into a pretty big company called Ritchie Bros, which is the largest global auctioneer of heavy machinery. Not a tech startup, a company with a IT team, pretty large IT team actually, that wanted to become a tech company.

Juan Pablo: And so as SVP of engineering, I was given the mandate of turning the organization into a technology organization. And the first few months, right, like discovering the gaps, coming from either the startup world or Stripe where the basics of having autonomous teams that move towards shipping software is pretty much like understood or to some extent. And the world I was in, which was more of a like a consultative IT considered group of about 400, 500 people. We didn’t even have the same sort of language to talk about. What was success? What was I expecting?

Juan Pablo: And so the first few months were very painful, right? 3 to 6 months, how do I get the teams to take risks and take ownership of their goals and all these things? And so I finally started drafting what is akin to like an engineering ladder but for teams. If I take junior people and show them what I expect from them through an engineering ladder look like, here’s how you grow, here’s how you do your job, here’s what success looks like. And what if I do the same thing for a team, right? And how would that look like? And so that that was that was the origin, the origin story.

Jeffrey: Yeah, that’s great. I can really appreciate that. So one thing that you capture in there is you’re moving from not just a software company, but a product company at Stripe, right? And I know and Squirrel, I’m sure you can say this too. The difference between people that are product companies versus ones that are are not product companies. Juan, you’re describing it as not tech companies, but it’s also not just tech companies, but like product is a different discipline.

Juan Pablo: You’re absolutely right. Yeah, you’re absolutely right. That’s a good distinction.

Squirrel: By that I think Jeffrey means software products because-

Jeffrey: Yes.

Squirrel: -physical products, I work with a lot of physical product companies, too, and their world is completely different. Whether it’s building hardware, technological hardware or printing things or constructing buildings or something like that. Their thoughts about software are very different and that’s a great interest of mine. So I’m really curious where this took you.

Jeffrey: This idea of coming in and saying like, ‘okay, we have these people and they’re not trying to convert to being a tech company.’ And you’re bringing in, ‘well, this is what big league product companies do, are very different.’ I had a friend who did a very similar thing in a company, and he had a kind of similar result, which is he had to go around and kind of define this is what good looks like at a team level. So I can see why you would turn to that. What was the response then, within the company once you started defining it?

Company Response

Listen to this section at 04:16

Juan Pablo: It was actually, the majority of it was embraced really well, there was of course, many, many questions, not just from from the team members. Yes. Many from from managers, like ‘what do you mean? Is this now like how you’re going to grade me or how are you going to supervise me?’ Right. Like there were many concepts that were foreign but we started with a pilot.

Juan Pablo: And so introducing these new processes, so I picked a few teams that were the closest to product engineering teams. And we set a few of like, ‘here’s some new ceremonies we’re going to start adopting right there. Here’s a product review. Here’s some places where you can check in. And what I’ll use to give you feedback is the framework.’ Right?

Juan Pablo: And so I think my favorite part of the framework is there are real examples of what being capable at something looks like versus what it doesn’t. And that was developed just through the process of introducing the framework, because clarity in expectations was the most important thing. So what do you mean my team should be able to set goals? Well, if you don’t know where you’re going, then you don’t know how to set goals. So I could have those conversations and sort of illustrate. And it-

Squirrel: Juan, Juan, Wait a minute. Wait a minute, wait a minute. There’s something super important there, because what I find often and this happens both with engineers who are very black and white thinkers and folks who are very much not engineers and don’t understand them and are looking for control. What both of those groups tend to do is to take what you just said and say ‘what we need is clarity. Excellent. So you should define 7.2 goals and the 7.2 goals should be at least 43 words long, and each one should contain a cue.’ And they get very clear.

Squirrel: But that’s precisely not what’s in your definitions. Your definitions are things like navigate ambiguity or what you’re looking for is team characteristics that are inherently unclear. But by having examples, you’re creating greater clarity and alignment about something that is fundamentally a fuzzy concept. So I just wanted to draw that distinction, and that’s one reason I thought your framework was very interesting is that it isn’t like some of the worst versions of Scrum or OKRs or the other kinds of things that people do where they’re trying to follow a ritual and get all the movements right without really understanding anything about what they’re doing.

Jeffrey: It’s not a cookbook.

Juan Pablo: So you’re absolutely right.

Squirrel: Yeah.

Juan Pablo: Since it comes from engineering ladders, and I had that experience with engineering, like, ‘why do I have to be to become a senior engineer?’ ‘Well, you should do this, this and that.’ ‘Well, that’s a checklist. I’ve done it, am I senior now?’ I’m like, ‘No, like you missed the whole point.’ So I didn’t want to have that conversation with the team. And so I wanted to be clear in the expectations, but also be clear that I expect them to think beyond what is like in the framework and actually embrace it.

Juan Pablo: So thank you for that distinction. I think we were at how it was received. So yeah, basically we rolled it out, through pilot. Eventually we sharpened the language. I still think there’s too many capabilities there. At some point you have to like summarize or categorize or something. But I just pushed out to the world a draft and have received pretty good feedback.

Listen to this section at 08:29

Jeffrey: Now, we’re talking about this ahead of time and you did say that there are few of them that you think are essential, that from your list, there was a few that you think of kind of as non-negotiable. Let’s start with one I really liked, this is your lead off one in the article ‘navigate ambiguity’. That’s fantastic. I got to say, if I’m going to choose one principle that I want from my teams it’s that they have the ability to navigate ambiguity. Tell us about that one. What is it? Why did you have it first? Why is it on your short list of must haves?

Juan Pablo: My career comes from start ups where there is no structure, there’s no support, there’s not a lot of guidance, there’s a lot of ambiguity. I found that when I would get teams that were very good at navigating that ambiguity, it made the organization a lot more effective at achieving goals, right? Because it wouldn’t all depend on me to bring clarity to the individuals, but rather pointing them in directions and having them find that clarity themselves and taking ownership of the clarity, taking ownership of the goals.

Juan Pablo: And actually we would get even better results, better products when engineers could understand like could sort of process that, hey, there’s some foggy direction, but there are good outcomes at the end of it if we can all process it. And so that became the fundamental piece, because even with that one, you can derive the rest of them, right?

Juan Pablo: The navigate ambiguity is like, ‘yeah, well what else? Oh, well, if I need to navigate ambiguity, then I need to have possibly like a way to set my goals, right? And ensure that there’s some alignment with leadership on whether I should be going in this direction or not. And then if I don’t, then I should be capable of asking for help, right? Because my goals aren’t clear and this is a biggie. So then who is going to help me if I can help myself? And then I should also be able to report how I am progressing on these goals or these progresses. And if I depend on someone, then I should be capable of negotiati-.’

Juan Pablo: So they all sort of fall back from that narrative. And I’d say, yeah, the top five are my favorite ones, I’m still in such a large organization I needed very good examples of things that I wanted or not. I think if I wrote this for a smaller team, it would be smaller.

Jeffrey: Right? So the fact that it was so large is because it was a large org. But your core here then you said, so we’ll start with your top five, you had so navigating ambiguity from that you think the other key ones are set goals, ask for help, broadcast state, and negotiate dependencies. And your view is that, ‘well you could derive those’ and I agree because I think what struck me about your navigating ambiguity is the idea that you talk about people here being proactive.I thought of this as you’re looking for people to be high agency in the face of ambiguity. So it’s not just that things are ambiguous, but that they’re engaging with ambiguity, trying to make things less, less ambiguous.

Jeffrey: So your example, I like here because your whole framework is described as example of like you want teams to be capable of this and you say, ‘well, here’s an example of not capable and here’s an example of capable.’ So not capable in navigating ambiguity is ‘we’re not making any progress because no one has told us what to work on.’ So because we’ve not received direction, we’re not doing anything. I think I’ve seen that before.

Squirrel: Oh yeah.

Jeffrey: And by contrast, your capable example is ‘last week we emailed the CXO to clarify how we could contribute to their quarterly goals. Attached is our draft proposal. Any objections or feedback?’ You know, so someone’s saying like, ‘hey, we’ve taken action, we’ve done this, here’s here’s our draft.’ You know, we’re taking steps to kind of take those vague intentions that you described and then make them concrete in actual here’s our concrete proposal, and I think that’s great.

Guiding Conversations

Listen to this section at 12:47

Jeffrey: And one thing I also like about this is that you see these people as an interactive process. You know, you describe the attributes of doing it as people who are communicating effectively and and seeking feedback. So it’s not just that people were proactive and got a direction and went off and did it. You know, ‘okay, we’ve we’ve spent the last three months or last three weeks working on something because of something you said three weeks ago.’ Tell us a little bit about that. Like what’s that for you, that process of the interactions And of course, Squirrel and I, we put a real focus on conversations. So what are the kind of conversations you expect to be happening there?

Juan Pablo: Well, the framework comes from conversations. The examples come from conversations and the way that I implement it was also a conversation. I think the most valuable meeting I would have with the product engineering team would be our fortnightly product review, which is where all of this would come up, right? So we would start, ‘hey, so where are we at?’ ‘Well, we haven’t made any progress.’ Like, ‘wait, what?’

Juan Pablo: And so, of course, I wouldn’t feign surprise. I would try to keep my face, but I’d say. Right, like, ‘I expect you to be capable. If you’re if you’re not making progress, if you’re just idle, that’s not a good thing. So walk me through like, what have you heard about your goals? What do you think that you could influence in a positive way? You have eight engineers just sitting around. We have all of these challenges around the company. Like, what do you think? And so what do you need in order to take one of these?’

Juan Pablo: And so, like, having that conversation would eventually sort of illustrate, again the expectations and also the actual ownership and responsibility that they had. Because we were coming from a culture that was very much like command and control, no one can do anything unless this high person approves it. And you have to ask for like all this permission. Just really, really bureaucratic as well. And so that was the the the back and forth that we were having and it came from many of these examples.

Jeffrey: What was the result? So I have two questions about this. So this framework sounds really interesting. Like the engagement you’re describing sounded really natural. The two questions I have is, one is, so what was the result? Where did what was the impact of this model? And also, how long did it take? Because I can’t imagine you went and had like one meeting. You gave people the document to read. They’re like, ‘oh, we we get it now, Juan, thanks, we’re off. We’re now capable in all 17 dimensions.’

Squirrel: Hang on. Before you answer that one, I’m going to suggest because we’re close to the time that we usually take for our podcasts. So could we do a cliffhanger? You know, we’re going to be waiting for the other shoe to drop for another week, if you don’t mind coming back and helping us understand sort of how did this land? What happened after you brought this in? How did you feel about that?

Juan Pablo: Yeah, absolutely. I don’t mind at all seeing you next week.

Squirrel: Fantastic. Okay, so if listeners are interested in navigating ambiguity and are wondering how on earth we can do something so ambiguous and help the teams to be effective while asking them to be ambiguously good at being ambiguous, then they can get in touch with us at agileconversations.com, where you’ll find videos and talks and articles and all kinds of stuff and ways to get in touch with Jeffrey and me. But even better, go and read Juan’s article, which you’ll find in the show notes. And Juan, is all your contact information there. Is there any place people should get in touch with you?

Juan Pablo: Yeah, I think there’s a Twitter link there in the article. And if not, we can post my Twitter.

Squirrel: We’ll put it in the show notes for sure. Fantastic. And of course, the other way for people to hear from us again is to come back next week when we’ll have Juan again and we’ll be talking about how he actually implemented this crazy sounding framework. It’s going to sound alien to many of our listeners and we’ll find out how it actually worked out. Thanks, Juan and Jeffrey.

Jeffrey: Thanks Squirrel.