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 ongoing way.
Transparency Is Power
The last thing I would say is something that my boss, Mazen Rawashdeh, the CTO of eBay likes to tell me all the time, which is, transparency is power. What you'll find is when you are willing to communicate good news and bad news, and you do that openly, honestly, and transparently, that gives you a lot of credibility within the organization and a lot of respect from your peers. It gives you the power to help to influence decisions in the ways that you like.
Continuous Delivery
We've talked about motivation and integrity. Now let's talk about competence. The first thing I'd like to say here is simply making sure that we're doing our main job, which is regularly delivering solutions to customer problems. We want to make sure that we're showing a consistent trajectory of incremental value that flows from the ideas that we have, all the way through to production. We want to make sure as best we can to deliver on the commitments that we make. When things don't go as planned, we want to be super honest that things aren't going as planned. We want to openly and honestly and transparently provide options about different ways that we can solve the problem.
In order to deliver things consistently and continuously, we want to make sure that our team and feature map doesn't look like this, where everybody's working on something in parallel and nothing completes for months. Instead, we like to have our roadmap look a lot more like this, where we bunch people up working together on the highest priority items, and that we're delivering incremental value along the way. This makes us resilient to this very common situation where, as we're going along and delivering on our multi-month project, there's a change in priority and we need to do something differently. If we have delivered incremental value along the way, that's ok, because we've still delivered something to customers and we've provided value. If we have waited and not delivered anything along the way, all of that effort that we've spent, the entire team maybe, is wasted, because nothing has actually made it to customer hands.
Estimating Effort
The last thing I want to talk about here in terms of confidence is estimation. This is a common problem and stress inducing thing for engineers and engineering leaders. The first thing I want to say is, it is a completely legitimate request from your business and product partners to ask you to estimate effort. Why? Because it helps to do planning and resource allocation between and among things that we're doing as a business. Also, the software that we produce hopefully matters to somebody. There are also downstream implications of when we deliver stuff. Maybe it's for marketing. If we were delivering software to warehouses, maybe there are physical changes that we would make to the warehouse that are contingent on or dependent on changes to the software. It actually matters when we do stuff.
The other thing, though, is estimation is difficult. If we knew the answer, we wouldn't call it an estimate. The critical thing that we need to do as leaders is to communicate the uncertainty here. The perfect accuracy is impossible. Frankly, it's rarely required. Rather, the best way to do it is to think about things in terms of ranges. Maybe I can't promise you three months out that it's going to take exactly 12 weeks of work, but maybe I can say, "It's going to be a range of 8 to 16 weeks." Then in a week or two, I'm going to know more and maybe I can narrow that effort estimate down to 10 to 14 weeks, or 11 to 13 weeks. We should progressively refine those estimates over time.
The other way to approach this problem is instead of saying how long is it going to take to do X thing, and it doesn't matter how long it takes, we're going to do it anyway. Instead, think about it as, how much effort are we willing to invest in doing this thing, and time-box it. Let's time-box it to one, two week effort, or four weeks of effort, something like that. See what we can get out incrementally in that time. That's another way of shifting the uncertainty. Instead of making it clear on the scope and uncertain on the time, we make it clear on the time and uncertain on the scope.
We Need To Go Faster
We've talked about motivation, integrity, and competence in terms of our communications with business partners. In the last section, let's see if we can apply these lessons or apply these techniques to three different common scenarios that you're going to face as an engineer or an engineering leader. The first scenario is a little bit the response to that estimate, which is, "Randy, you told me that this is going to be eight weeks, and actually I need it in four," or in general, we need to go faster than what you're saying, Randy.
Negotiating Tradeoffs
Now we're in a negotiation. If you think you're not in a negotiation, you are missing some important context about what's going on. The critical thing is to understand this very common triangle of scope, quality, and time. If we fix two of these, we've already fixed the third. We absolutely don't want to compromise on quality. If the business decision or the right thing to do for the business is to hold the time constant, then the thing that we have to vary is the scope. Maybe we need to reduce the number of things that we do, again, delivering things incrementally along the way can really help with this. Negotiating scope rather than negotiating quality is absolutely the right thing to do here.
The other related response is, "If we're going to deliver what you asked for in four weeks, here's what I need." That could be, "I need to slow down a bunch of other things that we're working on," or, "If we do things in four weeks, we're going to have accumulated a ton of technical debt. Therefore, I need the next eight weeks after that four weeks to dig ourselves out of the technical debt that we just knowingly accumulated." In any event, the key thing is not to say, "We can do it in four weeks," and be stressed and angry in your mind that they're asking you to do something impossible. It's expressing the tradeoff openly and honestly, and making sure everybody has the common context, so we can together make the right decision. Sometimes the right decision is to deliver it in four weeks. Sometimes the right answer is to deliver it in eight. The only way we're going to make that decision correctly as a group is if we talk about it together and share the context.
Technical Debt
The next scenario is how to deal with technical debt. I'm sure this is a really common thing that every engineering leader has had to think about. The first thing I like to do, as in all things, is to frame the problem. The critical way to frame it, is there quality and reliability? In other words, the things that technical debt are impacting are business concerns. These are things that actually directly impact our customers, and so we need to think about them in a business way. How do we value those things? The key thing that we can do as engineering leaders is to help to value technical debt in a common currency that matters to the business and customer. That could be time, in other words, engineering effort. That could be people, or that could be money. These are the things that the business and product people are going to be able to weigh against the time and money and people that they would value features in. We need to be able to speak the same language so that we're doing tradeoffs in an informed way.
Improvement Budget
Another technique that I found for dealing with technical debt in an effective way, is talking about things. Talking about it, not onesie-twosie, but negotiating upfront with product and business partners, what I'll call an improvement budget, or a lot of people talk about this as engineering excellence, or maybe essential engineering. Talking about it as an allocation or a budget upfront, where we make an explicit investment as a company in improving our software and improving the productivity of our developers. We agree on some upfront investment. Common things in the industry would be anywhere from 25% to 35% or 40%. Somewhere in those ranges are pretty common.
Then a critical thing that as engineering leaders we should do is make sure that we are controlling the spending of that budget, but we're being transparent about how we're doing it and that we're spending it wisely. The way I like to think about it is retain the autonomy to spend this budget in the appropriate way, but also by the same token, provide transparency to our business partners about how we're doing it. In case people are feeling weird about that, you should maybe point out that making these kinds of engineering decisions is exactly why you were hired. If I can't be trusted to be a good steward of this particular budget, then probably, I shouldn't be working here.
Site Incident: During and After
Last scenario here is a site incident. We have some incident or outage, and what communication situations do we want to do in this situation? I was very lucky, several months ago, to be part of a group of excellent folks that put together a white paper for IT Revolution, called, "A Framework for Incident Response, Assessment, and Learning." If you're interested, you can go download this for free from IT Revolution, and read in more detail some of the things I'm going to say here. During the incident, we want to make sure that we are maniacally focused on restoring service to customers. Anything else that we might think about doing is secondary and needs to wait until after the incident is done and the service is restored. We want to make sure as a consequence, that we are shielding the team. If there's inbound communication, make sure that, to the extent possible, buffer that from the team that's actually working the outage. A way to help that to not be a problem is to make sure that you've set up this situation where you are doing clear, structured communication, maybe hourly, or every 15 minutes, something like that. Letting people know what the current status of the outage restoration is. I can't emphasize this enough. Even when there is nothing to report, say, "Here's the situation, we're still working it." As soon as you stop communicating that, the exact same people will start to get freaked out and are going to start to ping your engineers. That's during the incident.
Let's talk about what happens after the incident. I hope everybody is doing blameless postmortems. This is something that I found hugely valuable at every place I've worked in the last 20 years. This helps us to identify and understand the contributing factors that went into the outage. We come up as a team together with a bunch of action items and learnings, things that we're going to improve to make things better. I want to make sure that we communicate that effectively to product and business partners. Also, a critical thing that we can do as engineering leaders is follow up to make sure that those action items actually get prioritized, and they actually get done.
As Churchill liked to say, "Never let a good crisis go to waste." When there is an incident, it is actually our job to make sure that we do action items and learnings that come out of it. As John Allspaw, one of the great gods in DevOps of incident response likes to say, "Incidents are unplanned investments, but they're also opportunities. It's our challenge as engineering leaders to make sure that we maximize the ROI on the cost that we've already incurred by having the outage."
Conclusion
We talked about motivation, integrity, and competence. We've actually used a bunch of common scenarios to test the things that we've learned. There are a bunch of people, I'm sure, in the chat already, saying, "What if the product and business partners don't listen to me? What if my organization doesn't care about technical debt?" The first thing I would suggest is that you try to change your organization. You try to point out the actual business implications of the decision making that are happening. When that's not successful or if that's not successful, then I have a wonderful quote from Martin Fowler for you, which is, "If you can't change your organization, you can change your organization."
See more presentations with transcripts
