Communicating Effectively with Your Business Partners

Transcript

Shoup: I’m Randy Shoup. I want to talk to you about communicating effectively with your business partners. I’m currently a VP of Engineering and Chief Architect at eBay. I’ve also been an engineering leader at Google, and Stitch Fix, and WeWork. A bunch of the lessons that I’ve learned at those companies are informing a bunch of the things that we’re going to learn about.

Elements of Trust

One of the most important things about communication in any situation, whether it’s personal or professional, is trust between all the parties involved. I want to use this lens of trust to talk through the first section. Trust has a bunch of different elements to it. There’s motivation or benevolence, as some of the psychologists like to call it. Are we motivated by the right things? Integrity, which is openness, honesty, transparency. Then, competence. Are we capable or do we have the ability and skills to do the things that we want to do? I want to use that as the lens to talk through the first section. Then I want to go through three scenarios that are really common for engineering leaders to face as they work together with business and product partners, and see how we can apply some of these lessons to those common scenarios.

Business Outcomes

Let’s jump into it by starting with motivation. The first aspect I want to talk about here is as an engineering leader, and as an engineer, for that matter, focusing on outcomes over outputs. It’s not what we produce, or how much effort we put into it, it’s what benefit does the customer and the business get out of the work that we’re doing? The critical thing, of course, here is to understand as an engineering leader, what are the business outcomes we’re trying to drive? We need to make sure that there are clear business metrics so that we understand the business metrics that we’re trying to drive, whether it’s revenue, or profitability, or market share, or decreasing customer churn. What does the business care about, and that’s what we should care about too.

We also need to make sure that we understand customer metrics as well. We need to be able to make sure that we understand the performance of key customer flows. What our customer is trying to achieve as they’re at eBay, for example, trying to list an item, or buy something, or bid on it, or something like that. Similar to that, at eBay, we track failed customer interactions, where somebody has attempted to do one of those flows, and it doesn’t complete correctly. We make sure we track those and try to figure out what’s going on.

Then another thing that we’ve found valuable at eBay is tracking availability to business. That’s essentially, when we have a site-impacting or customer-impacting event, how much revenue did we lose, essentially? We use that as our metric to figure out the operational availability of our software.

Engineering Outcomes

The other thing, of course, in the modern world is to try to think about, how can we define engineering outcomes separate from the business or laddering up to business outcomes? I hope everybody is familiar with this book, Nicole Forsgren, and her co-authors, the “Accelerate” book. These are what are called the four key metrics that come out of the state of DevOps research that is put in the book. These are deployment frequency. How frequently are we deploying our primary application to production? Lead time for change. How long does it take us to go from commit to working software in production? Time to restore service. This is when there’s some customer-impacting event, how long does it take us to get that service back to the customers? Then lastly, change failure rate. What’s the percentage of time when we do one of those deployments that we need to roll it back, or a hotfix it, or something like that? You’ll notice that all of these are outcomes, these are things that are themselves good, and that we as engineering teams should be measuring ourselves along these metrics. There’s a bunch of work that I’m currently doing at eBay around measuring ourselves along these metrics as well.

Outputs

Things that we might want to track but we absolutely shouldn’t manage to, are these kinds of outputs. For example, eBay, in the old days, used to track developer effort in something called train seats, which was an engineer’s time times two weeks. I remember this, for me, horrific update from a VP of engineering way back when, where she was telling us proudly how we had delivered 5000 train seats to the business. I’m thinking, “You just essentially said we cost the business $50 million, or something like that.” That’s a cost metric, an output metric, not an outcome. Maybe a little bit controversially, I think of story points in the same thing where it might be interesting to track it along the way to see our velocity, but it’s not an actual output that matters to customers. Lines of code is for sure something that is not particularly interested in customers, and isn’t something we should be managing to. Then, again, a bit controversially, I’m not a big fan of using code coverage as a primary metric to measure quality. It’s one output that we might look at, we might track. I find the time to restore metric and the change failure rate metric from the “Accelerate” book are much better and more objective outcomes that have to do with quality.

What Problems Are We Trying To Solve?

The next question that we should always be asking, as engineering leaders, and as engineers as well, are these seven words. I’d like you to remember these seven words, what problem are we trying to solve? Why are we asking this problem? We’re asking it because we need to understand what the business and the customers are trying to achieve in order to build the best software. Also, it helps us to contribute an engineering mindset to the product and business discussion. When we’re talking with product and business, what we can do is offer our ability, our training in disciplined problem solving. Whether people watching this are engineers that have formal training, or just have joined engineering later in life, whether you know it or not, you have been training yourself in taking a big problem, breaking it down into smaller problems in a disciplined way, and solving those individual things individually. That’s a thing that engineers are really good at doing. We practice it every day. It’s our job to contribute that disciplined problem solving mindset and approach, to help clarify and refine customer problems and help offer options in our conversations with product and business counterparts.

It also helps us as well, because once we have clearly stated a problem, it becomes a lot more obvious to everyone in the room, whether engineers or otherwise, how to solve it. As Charles Kettering liked to say, “A problem well stated is a problem half solved.” The other thing is, our job as engineers is to solve the customer problem, and not necessarily by writing code. Engineering is about solving problems, and only sometimes do we solve those problems by writing code. A bunch of times when I was working at Stitch Fix, we had physical warehouses, and one of my teams built software for them. A bunch of times, we’d have conversations with the warehouse folks where they’d want us to change the software. As we got through that conversation, we realized that actually, the more efficient approach would be to slightly alter the business process, but keep the software the same. That’s a thing that we provide value in that conversation, even if we haven’t written a line of code.

Tell It Like It Is

We’ve talked about the motivation aspect of it. Now I want to talk about integrity. What I mean here is openness, honesty, transparency, that sort of thing. I can’t say strongly enough that in order to gain trust and communicate effectively, you need to tell it like it is. We need to both share the good news, when things are going well, but we also need to share the bad news. I have always found that the right answer is to never hide what the situation is, whether good or bad. The value that we can provide in those conversations is by sharing engineering context. What I found over again, is when people disagree in the workplace, it’s rarely because one person is good, and the other person is evil, or one person is smart, and the other person isn’t. Rather, it’s because the engineering person, for example, and the product or business person, each have different aspects of the context, and that Venn diagram isn’t a full overlap. There are things that the engineer knows about the system that he or she isn’t communicating. There are things that the business person or product person knows about the customer problem set, for example, or maybe the business context, that he or she isn’t communicating. By communicating both those things together, I have found most often that well-meaning people tend to agree on what the solution is going to be. When we don’t, then we need to have this model of what Intel like to call, disagree and commit. We make our best case openly and transparently about what we think we should do. If the consensus of the room is to go do something else, great, I’m still just as committed to making that successful, even though it wasn’t my idea.

The Curse of Knowledge

The other thing we can offer here is, again, helping to explore the options and tradeoffs and implications of decisions that we make. There’s a cognitive fallacy that we all as humans have, called the curse of knowledge, where we think that a thing that we know is obvious to everybody else in the room. That is rarely the case. It’s particularly rarely the case when we’re talking about engineering context, that a lot of other people aren’t trained in. It’s our job to help make sure that our business and product partners understand the engineering context so we can make the appropriate decisions about how to move forward.

Regular Communication

The other thing I want to talk about here in terms of integrity is regular communication. It’s always a good idea to have a regular cadence of structured communication, both up to your management chain, down to your teams, laterally among your peers. This is just as important when things are good as when things are bad. This allows us to communicate visibility into the status of things that are going on, issues that we might be having. If you want to think about it, from an engineering perspective, it’s very similar to a monitoring stream that we might produce from a service. The reason why we do this is, as Steve McConnell likes to say, “The half-life of trust is six weeks.” Steve McConnell, a longtime Microsoft DE, wrote “Code Complete” and a bunch of other great books, has noticed that when there’s no communication, there tends to be this degradation of trust between different parties. By regular communication, we can help to restore that trust in an…