This is a transcript of episode 255 of the Troubleshooting Agile podcast with Jeffrey Fredrick and Douglas Squirrel.

Do you find the yourself constantly fighting for making even small improvements? Randy Shoup has a way to avoid such “nickel and dime” conversations: agree with your peers on an innovation budget. In this episode Randy Shoup and Jeffrey discuss why these strategic conversations require learning how to speak executive, and why new engineering leaders often struggle to live up to their role in these conversations. Recorded live at DevOps Enterprise Summit 2022 in Las Vegas.

Show links:

Listen to the episode on SoundCloud or Apple Podcasts.

Introduction

Listen to this section at 00:11

Jeffrey: Welcome back to Troubleshooting Agile. This is Jeff Fredrick and I am once again without Douglas Squirrel, recording live at DevOps Enterprise Summit 2022, I am joined by Randy Shoup. Welcome, Randy.

Randy: Thanks, Jeff.

Jeffrey: So tell us a bit of your background! You’re here as one of the speakers, you’ve been involved in the DevOps Enterprise Summit many times, you’ve worked on the forum papers, all kinds of things. Tell people a bit about your background and why you ended up talking to events like this.

Randy: I’ll give you the background in just a moment, but I’m super excited to be part of this global DevOps community. I’ve learned so much from my peer engineering leaders in this community over the years. I love to speak and be a part of it and learn from everybody else. I started my career in 1990 and I spent maybe two thirds of the time since as an individual contributor. 2004 to 2011 I was an individual contributor at eBay, working on their search engine infrastructure.

Jeffrey: I’ve heard of eBay!

Randy: You’ll hear about them again in just a moment. So it was at the end of my time there where I shifted from being an individual contributor, never wanting to manage people, thinking that wasn’t something that I knew how to do or would be good at…into engineering leadership. I’ve sort of been a leader ever since. So after eBay, I tried my hand at launching a startup with a partner of mine and we were in the 99% instead of the 1%. Then I joined Google and ran engineering for Google App Engine: Google’s platform as a service. I spent some time running engineering for Stitch Fix, a clothing retailer in the United States with tons of data science and machine learning. I ran that up to an IPO, and then I went to WeWork and up to our not-IPO, as people have probably heard. Then until very recently I was chief architect and VP of Engineering at eBay again. So I returned to eBay to help eBay transform and get better at software delivery, architecture, all sorts of stuff.

Jeffrey: Right. You and I were talking in the speaker lounge and I thought it’d be interesting to talk in part because you have been looking for a new position, where you are going to go next. And one of things you said to me was there are some fights that you never want to have again. I thought it’d be a great podcast topic to discuss fights that you should have at least once! So maybe we’ll get through one of those, your top idea of a fight that if you haven’t had yet as an engineering leader, one you should have.

The Number One Argument to Get Into

Listen to this section at 02:49

Randy: Yeah, sure. Ideally it’s not an actual fight, but this is one that I always seem to have, whether it’s a fight or a negotiation, I always make this recommendation to engineering leaders: negotiate with your peer executives on an improvement budget. If you want to do something big and long term for your organization, whether it’s a migration to the cloud or to microservices, or whether it’s improving engineering excellence or improving security, any of these really long term sustained efforts, it’s much better to agree upfront on as an organization: “We’re going to make this level of investment in this.” You have that conversation with the product people, with the business people, with the legal and HR people, the whole suite of people that are deciding what the company is going to work on. My strong recommendation is to have the conversation at that level, because then it’s a strategic conversation, right? And then there’s another thing I do as part of that conversation. Let’s imagine that we’re going to spend 15% of our engineering effort on this thing or something like that. We agree that’s the appropriate level of investment up front. And then I always say some flavor of: “The reason you hired me is so that you don’t have to nickel and dime this. So first, I hope you’ll trust me to spend this budget wisely. But also, I promise you up down left and right, that I will be completely open and transparent about what we as an engineering team are going to do to solve this problem, how we’re doing it and why. I’m open to any feedback that you have. But, what I don’t want either of us to have to do, is per sprint or whatever your mechanism of delivery is, arguing about ‘should it be 10 hours of investment in this week or 20 hours?’ That’s not a conversation that is valuable for me or for the team or for you. But let’s agree on this overall budget because, again, that’s a strategic investment conversation.”

Jeffrey: That’s fantastic. There’s so many things that brings up. It sounds very simple, but there’s a number of parts that are I know from coaching different engineering leaders and executives that are in practice quite daunting. Very early on you used the phrase “your peer executives.” Now, I point that out because a lot of times when an executive technical leader shows up in the C-suite, they don’t feel like a peer. They feel like their career has been as an order-taker. Their career has been secondary to the needs of the business. So the idea I think actually that’s a really key part of what you’re describing is that you are a peer, equivalent to the head of sales, to the CFO, whatever the titles are, however fantastic they sound, you are their peer. What do you think about that?

Randy: I completely agree, and actually the fight that you never want to have is, “Hey, please treat me as a peer.” Do you know what I mean? It’s one of those things where, “if you can’t change your organization, you should change your organization.” This is a real experience that engineering leaders have. If engineering is not thought of as an equivalent function to the other things in that room, product, business, legal, risk, compliance, whatever you have in the C-suite, that is a deep, deep problem. So I guess that’s a prerequisite, is to be able to go in and have that conversation, “We’re all mature adult executives and we all have the shared responsibility and the shared incentives around making the company more successful.”

Jeffrey: Right.

Randy: So the first prerequisite is being in the room and being able to have that conversation. Then the next thing is 100% our job: to not just say, “Hey, I need 20% of engineering effort. I’m not going to tell you why.” It’s like any other strategic investment. You have to give the why, and you have to give that why as a business argument. I don’t even want it to be an argument. It’s not worth doing if we can’t frame it with business and customer metrics. “We together want to improve customer satisfaction, we want to improve reliability. We want to be able to move a lot faster.” And come with a common currency that everybody else making such pitches is using. Whether that currency is money, revenue that we’re going to gain or losses we’re not going to sustain. It could be people, the level of benefit that we get, the ROI as expressed in people or other resources. Those are the currencies that we speak in at the executive level, right? People, resources, and money. If we as engineers or engineering leaders want to do a thing and we can’t express why we want to do that in those terms, then it’s going to be hard to have the conversation in a principled way.

Introduction

Listen to this section at 08:51

Jeffrey: That’s right. I’m often coaching people who are a CTO for the first time or VP of engineering for the first time, something of that nature. The first bit of advice I give them is related to what you’re describing, but subtly different. “You have to be on the same team as your boss. Your boss needs to know you’re on the same team.” So your CEO needs to believe that first and foremost you’re trying to achieve their objectives for the company.

Randy: Yeah.

Jeffrey: And once you’ve done that, then you’re in a position to start talking to those currencies relative to the company’s mission. But what often happens with people used to being engineers and thinking critically, and their first response to anything that’s being suggested, well, if they agree, they say nothing.

Randy: Yeah.

Jeffrey: If they see some potential problems, they raise them. They don’t say the part that they agree with, only the part they disagree with. So someone will say, “We want to achieve this 20% growth.” And they say, “Hmm, you know, that doesn’t really fit with the way we’ve allocated people so far.”

Randy: “It’s not going to work because X.”

Jeffrey: It’s not going to work because of X! Now what they intend is to say “We should solve this problem together.” But what people hear is “I’m not on board.” What I like about your framing here is by making it in the currency of the executive team and the question of strategic investment, you’re aligning it back to what’s driving this. “We want to achieve this change. There’s this place we want to get ultimately, for customer benefit, for business benefit. Now what investment are we going to do.”

Randy: Right. I’ll reframe what we both said. Step one: you need to be in the room. Step two: you need to demonstrate trust in the form of outcomes. As an engineering leader my peers and I both need to understand that we’re all about driving the customer and business outcomes, about “How are we going to get the things that the company cares about?” Step three: if I personally believe that there’s something different that we should do, some long term initiative that we need in engineering, I need to connect it to those outcomes. It needs to correctly compete with all the other things that we could be doing with our investment. The opportunity cost of doing my cloud migration versus other things that we could be doing needs to be in ROI and business currency terms.

Jeffrey: I’ll take this briefly to a darker place: you describe this as something you’ve learned to do over time. So what I read into your story here is in places where that hadn’t been done, instead what you see is a lot of as you put it, nickel and diming. What does that look like? How would someone know they’re being nickeled and dimed on improvement, or they themselves are doing it to someone else?

Randy: I came from individual contributor-ship and thinking only about the software and the engineering, not framing things in inappropriate outcomes. In not great cultures when you feel like you’re an order-taker, or in better cultures when you feel that all the tasks that we do as an engineering team are open for debate by everybody. When you feel either or both of those things, we’re being either told what to do or when we’re able to come up with our own things to do that they’re open to debate…sometimes that’s appropriate and I always welcome people’s feedback, but particularly for executives, that’s the wrong level. Their minds should be doing different things other than, “Well, how many hours are we spending on X or Y or Z?” Do you know what I mean?

When to Check Yourself, or Them

Listen to this section at 13:36

Jeffrey: I have a story that came to mind. When I was newly an executive at a company about ten years ago, had just become CTO, our head of sales came from New York and was visiting our office in London. While walking through they made a comment along the lines of, “Well, you could get twice as much done if you didn’t have people pairing.” My response was to ask him and the rest of the executive team, the two founders and the CFO, to all come in the office. I explained what had happened, and continued, “I just want to make it clear you have no business making a comment about how we do our job. If you feel like we’re not delivering results, I’m very open to hearing it. I would love to hear your thoughts on anything you think we’re not delivering, or if we’re falling short of our targets. Definitely want to hear that. But for how we do our work, you’re not qualified to comment.”

Randy: One hundred percent, in the exact same way as I am not qualified to comment to the sales person “That is an inappropriate way to incentivize salespeople, to allocate them, to deploy them. You’re doing your sales job wrong.” I don’t that! As an executive, I care that the sales people are doing their job and I want to be helpful to that. It’s not that it’s none of my business, but it’s not in my area of expertise to suggest methods to them. And same for them to me.

Jeffrey: Let’s be clear, I didn’t mind if he’d said it to me in private. It was on the floor among the engineers.

Randy: It’s super inappropriate to make that claim, yeah. They shouldn’t go to us in the same way you shouldn’t go to a sales kickoff and tell the sales people there they’re selling stuff wrong.

Jeffrey: “You’re doing it all wrong.” You’re not going to win friends and influence people.

Randy: No. And you probably don’t even know what you’re talking about.

Jeffrey: So this is a fight you’d never want to have again. But if our listeners find themselves in this position we can try to give them a guide to what to do. It sounds like: be willing to step up and speak “executive speak,” connect what you’re doing to the mission of the company and talk in the currency that executives speak.

Randy: Yeah. I think one of the reasons why that’s hard for engineers is as soon as you say “executive speak,” there’s this thing that goes on in the back of the engineer’s mind. “Oh, I don’t market. I don’t do sales. That feels dirty to me, wrong even.” But executive speak isn’t lying. You’re not saying things that aren’t true. You’re not even papering over anything. You’re like, “Look, I’m a partner in this organization and I share the goal of the organization to be better. Here’s the thing that I think we can do that I think is worth investing in. And here’s why we should do this with some set of resources and thus not do something else.” Like you have to have a real argument there. You have to be principled in that. That’s what it means to be a peer executive of all these other folks.

Jeffrey: I like that you captured that is doing your job.

Randy: That is our job!

Jeffrey: You have expertise that they don’t have and they rely on you to step up and do the translation of “Based on my domain expertise, this would be appropriate for us. Now it’s just a function of working out how much we’re willing to spend on it.”

Randy: Yeah. As Jason Warner likes to say in his podcast about engineering leadership: “When you are a senior engineering leader in the company, you are a senior leader of the company first and an engineer second.”

Jeffrey: I always say this: your first team is the executive team. Your domain organization, your functional organization? That’s your second team.

Randy: Right. And those ideas are not in conflict with each other. “I’m a peer and a partner. What I bring to the table uniquely among the people that are at this table is I bring the engineering team and the engineering capabilities that that we have. That’s my role here.”

Jeffrey: That’s right. We framed this in terms of what it takes to get an innovation budget, or a change budget, or improvement budget, transformation budget, or however you want to put it. But I think the lessons behind it, what makes it work, are a lot more applicable. Randy, what’s the best way for listeners to get ahold of you?

Randy: Twitter is a great place to have these kind of conversations. If people want to reach out on LinkedIn, I’m easy to find there as well.

Jeffrey: Fantastic. Thanks, Randy.

Randy: Thanks, Jeff.