Transcript
Van Couvering: This is David Van Couvering. I'll be talking to you about the important skill of being able to talk like a suit. Why do we want to talk like a suit? Actually, no one wears suits anymore. It's just a fun term to mean people who you work with, that are focused on the business goals. Often, we talk about how engineering is focusing on how to build something, whereas our business partners are focused on what to build. Often, we're struggling with some tech debt, some issues in our code. Many of us feel that we can never spend time on that. We never seem to be able to put time into cleaning up tech debt that we always have to build more features. It can be very frustrating. This talk is to help you figure out how to talk to your business partner in a way that makes sense to them, and helps them understand the value of investing in improving and reducing tech debt.
How Engineers Often See Tech Debt and Legacy Code
Often, how engineers see tech debt and legacy code is these kinds of experiences. It's really difficult to work with. I don't know what's going on here. It keeps breaking in ways I don't expect. It really takes a long time to get anything done. It's difficult to debug. It's ugly, frustrating. It's not cool or fun. When we're talking about legacy code to our business partners, we say we really need to clean this up, for these reasons. Sadly, often what our business partners hear is, tech debt and legacy. It's like, engineers like to complain. They always want to keep things nice and clean. Yes, it's a problem, but I've also got this feature to deliver. They're not seeing it from the lens that makes sense to them, and so they just don't give it a priority. I'm not saying this is true for all business partners, many product owners and managers I've worked with really get this. I know there's also a lot of frustration in the industry where people feel like their business partners don't get this and feel like they're not being heard.
It's important to understand that our business partners are focused on the business, and they aren't really recognized for this vague concept of reducing tech debt. Everyone knows we should reduce tech debt in a general way, but when push comes to shove for a particular sprint, often the feature is always still more important. Why is that? Because they really are more recognized for consistently shipping high quality features on time, and under budget. Delivering on the OKRs that they've set up for the quarter or the year. Yes, they are responsible for making sure the employees including us engineers have high engagement and satisfaction. Is that enough reason to invest an entire sprint or two in tech debt versus shipping more features? Usually not from their perspective. There's this blah, blah, blah syndrome, where you as engineers feel like you're not being heard, and so we as developers are frustrated and checked out. Also, there are business opportunities that are usually missed, and business risks increase as the tech debt increases. There's real consequences to this.
Flip Side: The Risks of Engineering-Driven Work
The other thing is, I've also been in organizations that are very engineering driven, meaning like the engineering leads, and engineers call the shots. Then there's a risk of that too where you end up building things that are fun to build, and interesting, or, "I know there's an open source version of this out there, but I think we can do better." All sorts of reasons that are maybe not the best reasons, but they're driven by our own motivations as engineers, and we're not really thinking enough about the business. When we don't talk like a suit, often we build things that maybe we shouldn't be building just because we're wearing glasses as it were, of an engineer, when we're thinking about what we want to put time into.
Talking Like a Suit
Let's talk about how we can talk like a suit. There's many ways people address this. The framework that I found has really helped came from this book, "Building a Story Brand," by Donald Miller. It's basically helping you construct a good story where the business partner is the hero. I just found the structure really simple and a really great framework for me to think about how to reframe what I'm trying to say, so that it really clicks with my business partner and helps them understand the value of what it is we want to do.
Structure of a Good Story
In this book, they say there's a structure of a good story. Then this repeats itself in many stories. I'm not sure it's always exactly like this, but it's definitely a common structure. It's very useful because stories are very engaging and for a certain reason. It's because they bring us in and help us go through an experience, and we get caught up in it. Here's a structure of a good story: character, has a problem, meets a guide, who gives them a plan, calls them to action, that helps them avoid failure, and ends in success. I'm not going to try and give you examples of actual stories, where this plays out. I will walk through each piece of this in more detail, and apply it to telling a story about tech debt that makes sense for a business partner.
Examples: Refactoring, and Complex Client/Service Communication
I want to do a couple of specific examples to help you think about this, with real actual problems. I find it really helpful. One is, we've got some nasty package, or module, or component that is just really difficult to work with. Another example I've seen fairly frequently is, we've built a client-service communication pattern that's really complex. Let's say, we have a web client, iPhone, Android client, and they all need to talk to all these backend services that we've built in a nice microservice way. Now all these clients are having to call these services and then orchestrate the results, merge them together. Get the results they want, and present them for the user. This, as we'll talk into more, has a set of problems.
What Is the Problem?
How about we describe this problem. A first pass of this might be, the spaghetti package, look, every time we try to change something it breaks in unexpected ways. It takes forever to figure out what we need to change. Pull requests are huge, and it's just hard to find reviewers. We might say for this client servicing, every time we need to build a new feature, we have to duplicate the code in each client. Service teams have to build these specialized APIs. The clients have to pull down all these results to pick what they need. It's really frustrating. When we describe the problem in this way, we've fallen into the trap of us being the hero of the story. This is not about us as engineers. This is not who we're trying to talk to. We have to be very careful not to fall into this trap, where we describe the problem from our perspective, versus from the business partner's perspective.
Communicating the Problem
Before I go into how you might describe this for the business partner, I want to talk a little bit more about the structure of communicating the problem based on this book. It's always good to have a good villain, and you identify one that's relatable. That everyone, "Yes, I get it." It's singular. You don't want to have five villains. That's confusing, just have one. I'll talk more about how you can focus on that. Make it real. Don't make up a villain that doesn't exist. Then there's three levels of conflict. There's the external problem. There's the internal conflict for the actual hero. Then there's this philosophical problem, like people should be nice to each other, or it shouldn't be this hard. It's just like a general feeling of, it shouldn't be this way. You want to have a singular villain, singular problem. There are usually multiple problems, and you want to try to identify the one that is the biggest concern. One thing that you might do is you come up with some ideas about certain external, internal problems that might exist. Then you might talk to your business partner and see which one they really relate to the most. Or you look at the data and see which one is causing the most problems in terms of maybe productivity or value.
Spaghetti Package Problem Summary
Let's go through an actual example of defining the problem using these pieces of a problem statement: villain, external, internal, and philosophical for the spaghetti package problem. Of course, there can be other reasons why this package is a problem, but let's just pick one. Let's say this is the one that's most concerning to our business partner is productivity, like being able to deliver features quickly. The villain in this case is we've got this system, you can imagine some Gremlin, almost, that just seems to slow down feature delivery, and it's very frustrating. The external problem is I want to be able to deliver features quickly. The internal problem, something that's more about me as a business partner versus the external problem is I really want to impress my management and do a good job, and increase my chances of career success by demonstrating that we're delivering lots of features. That we have high productivity and we have high reliability. Philosophically, really, why is it so hard? It shouldn't be so hard to roll out new features. Why is it such a struggle? That's, again, taking it from the perspective where the business partner is the hero, here's how you might explain the problem.
Client/Service Complexity Problem Summary
For the client/service complexity problem, there's all sorts of reasons why this can be a problem. There's that performance concern, maybe. Again, it could be productivity, like it's so hard to get a feature out the door. Let's say the biggest frustration for our business partner is that they really want to do lots of user experience innovation, and they've got this villainous system that makes it really hard to do that. The external problem is I want to quickly experiment with new user experiences. Internally, maybe, it's, I just want to feel inspired and creative and feel like we're doing a good job here. Philosophically, it's like, I've been at other companies where it's just really hard to innovate and experiment on the UI, and here it's just so hard, and it shouldn't be this hard. That's a problem statement from the perspective of the business partner in a suit.
Back it Up with Data
When you're presenting this problem statement, you really want to see if you can actually demonstrate it with data. Because otherwise it may start feeling like you're making something up just to get something that you want done. They may not be experiencing this problem as much, or they may not be noticing it's a problem. If they're not noticing it's a problem, then you can show them how it's a problem. Or they're saying, "Yes, it's really slow. I don't know why." You can show them one of the core reasons why things are slow. For example, maybe you can show, from start to finish, here's how long it takes to build features. Notice, whenever the feature touches this particular package, the time it takes to build this doubles. Or maybe you can have a number of engineers share how they have to go back and forth between the frontend and the backend every time they want to change the UI.
One thing I've noticed that can be challenging to communicate is if everything's fine now, but as we look forward into the future, for whatever the business is planning, there are going to be real problems. Sometimes you have to say, looking at our business goals, for example, we want to be able to go into new markets, or we want to double the size of engineers by next year, or we really need to integrate with third parties. Identify what these longer term business goals are, and then point how the situation as it is today may be fine, but very soon, it's going to become a real blocker for the goals of the business, and could be a serious risk. Sometimes what you're communicating as an engineer is risk coming up versus a situation that's today. That's an important part of our job is learning how to express those risks in business terms. If you can't find the data, and this has definitely happened to me, you need to ask yourself, is this really a problem, or is it just me wanting to be a perfectionist engineer? If it's not really causing a huge problem, maybe step back and ask if it's something you want to ask to invest time in?
You Are the Guide
What is our role as engineers in this story? Not as the hero, we're the guide. We're the one who has empathy, and authority, and we're trusted. We're the one who's going to help them solve this problem, and we're going to give them a plan. You want to have empathy. You give the problem statement and you share how, "I really get it that this is the concern. I don't want this to be this way too. I can really see why this is a problem." It may just be the way you talk to your business partner, but really take on that feeling of being someone who's there to help them. Demonstrate your competence, showing how you've refactored a system like this before, and you've seen great success. Cite examples from the past. If you actually don't have experience in this particular problem, then you should probably find a trusted advisor, maybe a more senior engineer who's mentoring you, who is going to help with this project, to help your business partner feel comfortable that you have what it takes to make the change necessary in a reasonable amount of time.
Give Them a Plan
Then, you give them a plan. You want to show them a path that gives them confidence and reduces their anxiety that we don't know how to solve this problem. I've seen this plan in the past, a bad plan, "We need two years, give us the best engineers, and in two years, we're going to completely change everything." It's just too much of a black box, too long of a time period. You're not going to be able to maintain momentum, it will probably get defunded halfway through. You really want to break things down in demonstrable steps that deliver value in each step. This is the agile-lean way. It's important to do it not just with features, but also with tech debt. As you do this approach, it builds trust and it builds momentum.
Example Plans
Some example plans for the spaghetti package, say, "We just want to analyze and write up all the responsibilities of the package." Identify which responsibility gets the most activity. Maybe factor that out first. Evaluate what a difference it's making. If it's making a difference, let's keep going until we're not seeing much value for each level of effort. Or you could say we're going to time box the effort for two or three sprints. Again, you're focusing on let's do one small thing, see how it goes, and keep going. For the client/service complexity, maybe we just want to say, we want to identify a couple best approaches, maybe we want to go to GraphQL, maybe we want to build our own BFF, backend for frontend. Then we're going to pilot these approaches with one service, or maybe we'll decide we think it's going to be GraphQL, let's try it out. Then evaluate again. Then, if that's looking really good, you're seeing good results, let's start rolling out to the other services and keep evaluating if the time to build new features in the frontend is getting better.
Call Them to Action
Then you need to call them to action. What actually do you need from them? "We need three engineers for three months for phase one, and then we reevaluate," that's going to be for a big project. Or, "Just give us two people for two weeks, and we'll do an analysis and come back with a detailed plan." Or, "We just need to constantly carve out time each quarter for ongoing maintenance and tech debt." This is just something we need to make sure we allocate time for.
Avoiding Failure and Reaping Success
Then the last step is giving them a vision of the improved future. How do they avoid failure? How will they reap success? Examples of avoiding failure, we're not going to get bogged down every time we need to touch this package. We're not going to get outpaced by our competition, because they're innovating so much faster on their UI than we are. Visions of success. As we clean this up, we'll be able to deliver more features faster with higher quality. Or, as we move to better client-service architecture, we'll be able to quickly iterate our UX and build a much more compelling experience.
Have Relevant, Measurable Success Metrics
As you're doing these changes, as much as possible, try to have relevant measurable business success metrics. Have these metrics be the outcomes of what you're doing that are business outcomes, quality, productivity. Whatever it is you're saying you're going to improve, how do you measure that? How do you show that it's getting better? If things aren't improving, be willing to have honest discussion about this. Because part of being able to get trust and momentum is showing that you're actually improving. Hence, we need to be able to prove that that's happening.
Putting It All Together - Elevator Pitch
Just putting it all together, quick summary. You'd probably go into more detail when you're presenting to your business partner, but it's how you might say it very quickly in an elevator. "I know how important it is to you to be able to reliably and rapidly deliver results." You're explaining what their problem is, and saying that you get it as a guide. "I've noticed that every time we have to touch this one package, we get bogged down in complexity, and it takes us much longer to deliver. It shouldn't take this long to ship seemingly simple features." That's the philosophical statement. You're basically helping them see that you have this problem, you understand the problem, and you know what's important to them.
Now you describe how you have the expertise that is needed to give them confidence that you can fix this. "In my years as an engineer, I have regularly seen a little refactoring effort pay back big results." Now this is a call to action, "Let's allocate two people for two to three sprints to clean up this package." Then you talk about how this helps them avoid failure and guarantee success. "By doing this, we should stop running into so many unexpected bottlenecks and see a noticeable difference in our speed and consistency at delivering features." You can see how that's a much better story for a business partner than, "We engineers are really frustrated with this package. It's so hard to work with. We don't understand it. We can't figure it out." Those are real problems, but it's not going to necessarily motivate your business partner as much as a story does, where there's a hero.
We Should Be Thinking Like Suits Anyway
Even if we don't need to convince our business partner, and they're giving us a carte blanche to do whatever we want because they really trust us, we should be thinking like suits anyway. It's really easy for us as engineers to get hypnotized by shiny new things, the latest technology that's come out. We all do. We tend to be overly optimistic, especially when we're excited about something about how much work is involved. We can often get a little cocky and create these really big projects that don't deliver incremental results, a boil the ocean project. That can really have really poor results ultimately. We're often not fully in tune with our own customers' needs, we so much have our head in the engine of the car that we're not thinking about what it means to drive the car. By stepping back and putting on a suit, as it were, when we're thinking about tech debt projects, it helps us start to identify better with our customers.
Suit-Talk Is an Engineering Superpower
I really think that the suit talk is an engineering superpower as you're growing in seniority as an engineer, and you're trying to communicate more with business partners, and you're trying to have more impact and influence. Being able to think and talk this way is really a powerful skill. I highly recommend practicing and trying to get better at it.
Resources
If you want to learn more, here's a number of really great books around this. There's, "Building a Story Brand," of course. Randy Shoup had a great talk in QCon Plus 2020, which is on a similar theme called communicating effectively with business partners. Then there are these books that are all great books about tech debt, and measuring outcome, how to best demonstrate value, how to calculate value, all sorts of things like that. All lots of great books here for you to take a look at.
Questions and Answers
Schuster: Is a pilot, in your mind, the same as a proof of concept. It's something that you build and you throw away, or is it something that you integrate into the actual product?
Van Couvering: Proof of concept is another great tool for being able to reduce risk and prove confidence in what you're offering by saying, let's just try this as a spike or a proof of concept. Usually, proof of concepts are something that you throw away, you just put it together to demonstrate that it looks like it should work. Whereas for me a pilot is something that you actually work with a particular team or actually say, let's just do this for one example. If it's unsuccessful, then you might roll it back. If it's successful, it's something I think you would keep when you do a pilot.
Schuster: Some of the steps that you mentioned, building proof of concept, for instance, takes time. How do you sell that investment in time to your fellow suits? How do you say, this is worthwhile, gathering the data is worthwhile. How do you do that?
Van Couvering: I think in order to even make your case, you might have to spend time gathering data. Yes, it's true, you can't spend like, a full time, sprint of your time just gathering data. I think you probably need to time box it somewhere. If it takes longer than that, then maybe work with what you've got. Say, "Look, I'm seeing trends here. Can you give me a little time to uncover? I think what we're seeing is that we're having a lot of trouble delivering features, because it looks like this particular package is a real problem. Can you give me a little time to dig into that a little bit more," could be really effective. Again, it's all about cost benefit, if I can give you a lot of benefit with this much cost, then usually they're willing to do it. It is a tricky one, because it's cart before the horse, and how do you get bootstrapped?
Schuster: If your company has a 20% program, 20% spend on your own things, would you use that for that, or should that 20% type of thing be used for something else?
Van Couvering: If you can actually get the work done with the 20%, that's great. You have 20% of your time and you probably have way more than 20% of things you could be working on. For me, personally, I like to give myself a business justification to help me prioritize what I want to put my time into. Even if I don't need to get external approval. Or, there's something that's going to require more than 20%, then you might use your 20% to say, we need to do this big initiative to move from monolith to microservices, which is a much bigger effort than 20% would cover, I've seen. Again, in general, I like to convince myself that what I'm doing is delivering the most value.
There's another part of 20%, which is, just have fun. Do stuff that is just fun, because engineers like to do. Often, you discover stuff that ends up being really useful, and mostly for engineers. That's the part I like from hack days and 20% time, is just doing whatever you want. Maybe what you want is to do something bigger, in which case, what you want to do is gather the data and make a good case. This is more for something that's not necessarily you haven't been given time to play. This is where you need to actually get approval for time.
Schuster: Often, stuff like optimization are particularly interesting for that, because you have just no much better data than, I made this 10 times faster. Whereas with refactoring, it might be a bit harder to sell.
Do you have any advice to progressively convince the engineering teams that building and showing data to convince the suits is something actually valuable, not a waste of time? How do you break that it's not going to be a waste of time.
Van Couvering: I can imagine people saying, it doesn't even matter if I make a good case, they're still not going to let me do it. It could be you're in an environment like that, where it's just that kind of relationship with product where they don't have a lot of trust or respect for engineers. They don't trust them to know what to build. I would love to see the particular situation, because to me, often, the first thing you need to do is establish a better relationship. Maybe you can just do it with a small thing where you demonstrate, "I get you. I understand where you're coming from. If you just give me two days, I've just delivered this thing that made a big difference for you." Then this trust starts building. I can totally get it where, if over many years, you just feel like it's been hopeless for a long time, you've checked out, for those engineers, it may be harder to convince them. For me, then I'd probably want to demonstrate that, I was able to do this, so maybe you want to try it too. Yes, getting that flywheel started can be hard. I totally get that.
Schuster: As a developer who once was a young developer many years ago, you have to overcome the fear of the suits in a way. Because I'm a developer, I don't deal with suits. You yourself may have thought like that.
Van Couvering: This is about becoming a better developer, so when you're ready to take that next step, this is a muscle that you need to start growing.
Schuster: I particularly like your focus on the data. Again, being as a younger developer once, I had different motivations for doing things. Switching to that fancy new language was the most important thing, I didn't realize the cost. Actually, getting the data keeps me honest, basically, or keeps yourself honest.
Van Couvering: Then the thing is, now you establish trust with the business and they let you do more things.
Schuster: As an engineer, if I identify a problem, when do you think it's a good idea to make PMs involved and how to split the workload accordingly?
Van Couvering: I've found it works best as a conversation. I've done this in backlog grooming, but it can happen elsewhere. Part of this is like you give them a plan, because it's scary to say to the PM, "There's this big thing we need to do, and it's going to take a lot of time." It's better to say, "Here's a plan, so that we can be sure that this is the right path. We're going to deliver incremental value. Here's the first few steps we're going to take." You don't want to break up the entire plan, maybe the first few steps, and say, ok, and then we'll reevaluate. Then I think that you offer that as, "Here's how I'm thinking we break it up. What do you think?" They can give you some feedback. Often, it's good to come with a proposed plan, but be willing to get their input on to how you might change it. Versus coming with a blank slate and saying, what's the plan?
Schuster: Project estimates can be from small to big depending on the project. How do you separate out cost savings from refactoring from just normal project cost in a way that is believable?
Van Couvering: You're saying that there's this overhead of projects that have a cost, and so how can you demonstrate that the refactoring has made a difference?
Project overhead costs? You're trying to demonstrate that we did something that added value. How do you know that, because it could just be lost in the noise of the overall project cost? That's a tricky one. Hopefully, the refactoring has a significant impact, so you actually see the difference. Again, there's cost versus value. I think often a refactoring, you're identifying a particular thing. Usually the biggest problem when you've got a big, ugly piece of code that needs refactoring is that everything takes a long time, in that particular piece of code. If you can look at all the different tickets that went through the system, you can separate out which ones touched this bad code and which ones didn't. You can demonstrate a difference between how long it takes. Then when you do the refactoring, you can show, now these stories that touch this code have taken this much shorter time. That'll be the same regardless of whether there's project overhead or not. That's how I'm thinking of it. That's one idea that I have. That thing of trying to isolate the one variable and show the difference with when you change that variable.
What are some techniques to create bridges between business and technology on a continuous basis to make the job of making business case easier?
I've found that the best way to create a bridge is this thing of being a guide, someone who understands their perspective. Not just in when you're making proposals, but in day-to-day conversations, like when you're talking about a feature, you can say, if we did it this way, I think it would bring this much more value to the business because X, Y, or Z. Start thinking about those metrics and measures that are important to the business, help you become someone that they trust more as someone who gets it from their perspective. Then, of course, the other thing is, I've noticed in general when engineering continuously helps the business by delivering things that make a big difference, whether it's tech debt or not, then they start trusting you more, that they know that you are the other part of a guide, which is that you have capability. They can trust you to do it and get it done. Those are the two things that come to mind. To me, establishing trust is about listening, reflecting, understanding. That talk on psychological safety is very similar, mirroring, basically helping them feel like they don't have someone they have to fight against but someone who's their partner.
There's also a battle here against learned helplessness where your efforts didn't work before, and therefore, it makes less likely to try again. That's really hard to counteract.
I think you need to try to get to small incremental progress. That's why I talk about building momentum. When you can deliver value in small increments, then that trust starts building and you get this momentum, and they're more willing to let you keep going. Learned helplessness is a really tricky one, because both the engineers are like, "Just tell me what to do. I give up." Then the leader is like, "These engineers always need to be told what to do, so how can we trust them to do anything?" It takes work to get out of that cycle.
See more presentations with transcripts
