The Power of Telling People What You Want

My name is Matt. My pronouns are he and him. And I'm here to talk to you about the power of telling people what you want. Have you ever found yourself arguing for something you consider table stakes? Have you ever found yourself needing to implement a feature in a way you feel in your gut is wrong? Or have you ever. Have you ever found yourself working unsustainably for an arbitrary deadline? This is the talk for you. I'll be discussing the hidden power of telling people what it is you want. This is all about how to set expectations, to say the things that need saying, and to clarify the path to success. I'm starting this talk with a call to action. By the end of the talk, I'm hoping that each one of you tells someone, and it can be anyone, something that you know is true, but no one else has said it out loud yet. Before you can tell people what you want, you need to know what it is that you want. You should start by writing it down, as this allows you to confidently share it with others, but it also forces you to be specific. I'm going to run through a five whys exercise with an example of something I want. So let's say I am an engineer on a team. We have a feature that is launching at the end of the week and I want to move the deadline out by two more weeks. So instead of at the end of this week, I want to move out the launch to three weeks time. First question, why we need more time? Because we found a security vulnerability. Okay. Why do we need more time to shore up the security vulnerability? Basically, we've been working with the security team to identify a solution to this problem and we need three weeks to implement it. Why? Why do we need three weeks? It will take three weeks because we're interfacing with a system owned by another team. Okay. Why are we interfacing with the system? Why aren't we building or patching this ourselves? We don't want to reinvent the wheel or own and maintain code to handle this use case. Okay. Why? Why don't we want to do that? Why don't we want to own that code? We're not security experts and we want something that's maintainable for our team. So from this exercise, we've gone from this like, very specific, I want a deadline moved out to or a very arbitrary, I want a deadline moved out to something that has a lot more context. Now you're ready to share that with others. So the way you'll do this is you'll take what you've written down from your five whys exercise and essentially go through it in reverse order. You're starting with the deepest context and coming out to the thing that you want. So going through that with the example I gave, we don't have deep security expertise on our team and we are building working maintainable software. We've identified a security vulnerability and we don't want to patch this using only our systems as that same general problem has been solved by another team at HubSpot. It's going to take us three weeks to build, test and deploy this fix and we've already been working with the security team on this solution. So we're fairly confident in that three week sort of extension. So we would like to move out the deadline by two weeks. Now that you written down and you know what you want now it's all about selling it. It's sort of like sharing as much context with others. Here are some things that you should keep in mind. There's I have a bunch of bullet points on the board but I'm actually going to start with the most important thing which is this isn't a game of poker. You don't need to keep your cards sort of like close to your chest and hide anything from everyone else. You should be telling everyone what it is that you want and why. It's important to remember that as you are telling other people what it is that you want, other people are not going to want the same thing as you. This is normal and expected. You are here to bring your own perspective. And this is the big reason why we have diverse teams made up of many different people is we're expecting everyone to bring their own thoughts, motivations and values to these problems so that we end up with a more robust solution. So don't. The thing I want to underline is don't expect other people to want the same thing as you. On the flip side, sometimes you're going to say there's something that you want but it's not like super important to you. You should share that with others. I think there's a tendency to not want to state when something isn't important to you because you don't want to give the impression that that's something that can quickly get cut. But sharing that gives context to everyone else when they're solutioning sort of in a problem space. The worst case scenario is that you don't share that this thing isn't very important to you and someone goes well out of their way to meet this arbitrary constraint and they end up compromising on something that is really important. So really sharing and selling what you want is all about sharing the constraints with everyone else. There's a object oriented programming concept called tell don't ask. It basically boils down to don't query your object's internals and then make decisions based on those queries. An example of this is, let's say you have a user object and you ask whether it is a. You ask your user, are you an admin or. Or are you a standard user? And then you show different welcome messages based on the response. With tell, don't ask. Instead of asking are you an admin or a normal user, you ask what is the welcome message? The same applies to work. Don't ask people unrelated questions or questions that you're then going to infer an action from. Ask directly what it is that you are trying to answer. If you really care about something, you are going to need to repeat yourself. A thing that I find myself repeating over and over again is working at a sustainable pace. A fair warning. If you start doing this, it's going to feel like you have a catchphrase because I. And this is how I feel because I say the phrase working at a sustainable pace so often it starts to feel really weird and like I'm just repeating myself. The reason I do it is because I think we do our best work when we're well rested and there are going to be genuine situations where you need to push through challenges. The whole idea of being high performers or in a high performing culture is that you are able to perform when it matters. So when I'm talking with teams about deadlines and scope, I'm often referencing back to this idea of working at a sustainable pace. One thing you're going to maybe experience this isn't a guarantee, this last bullet point, but sometimes you're going to say all of the things you're going to share, all of the context, you're going to describe what is important to you and you're still going to get pushback. And so I think at this stage it's important to directly ask if someone is pushing for an action that directly contradicts the thing that you're trying to sell. If that's something that they just don't think is important, you need to. The reason you're asking this is not to find out whether they are like a bad person or anything like that. It's really just to understand what are the constraints that they're taking into account versus you. Okay, I'm going to Take a brief moment to share a personal story. So what I have up on the slides is a quote from a book called Never Split the Difference and prior to joining HubSpot, I used to work a product consultancy and I got to a point where I felt like my technical expertise were fairly sharp and that didn't seem to be the thing that was holding me back. I thought about all of the client projects that I had worked on and bucketed them loosely into those that I thought that went well and those that I thought went poorly across the board in both buckets they all had varying levels of technical challenge, but that didn't correlate with whether I felt it was a good project or a bad project. Time and again, the thing that led to failure me thinking about the project as bad was my inability to convince clients to take a particular path or to build the right thing or to cut building the wrong thing. I don't remember who recommended it or why I started reading it, but I started reading Never Split the Difference on a client project where I could practice some of the advice that was being provided. There was a decent amount of negotiation that was happening throughout the project. Since reading this book, it's fundamentally changed the way I think about communication. One key thing that it taught me is I asserted at the beginning of this slide that my challenge was convincing people. But that was only part of the challenge. The other part was I was simply blind to information. Sometimes you are right and you going to need some tools to convince other people to take the path that you're suggesting. But a lot of the time it turns out that you're just going to lack context and the more beneficial tools are finding out what it is that you're missing. So this is the really juicy part. The title of this talk is telling people what you want, but sort of a base of basin switch. It's really about finding out what other people want. If you can cultivate genuine curiosity, you're in for a whole new world of success with your projects. It turns out that humans are weird and wonderful and messy and so the trick is to try and work out what drives people, what do they care about and why. As a brief aside, I mentioned the five whys exercise previously. This is a great exercise whenever you are in that sort of solutioning like defining a problem kind of space. But why is a question that tends to generate a either frustrated or defensive response. And so I mentioned five whys. It's great for running with yourself, but you need a decent amount of psychological safety or to feel like you're all in a very solution based mind sort of zone. Before you can just outright be asking why, you'll tend to want to stick to how's and other questions that don't feel so harsh. That's a nice segue into we talk a lot about empathy at HubSpot. But it's important to remember that your goal isn't to feel what other people are feeling. You're really being the detective. You want to understand what all of the constraints are. It's great if you are aligned and you naturally empathize with what it is that other people want. But you need to stay focused on understanding rather than feeling what it is that everyone else wants. You don't have to agree, you don't have to share the same values. Flipping back and you're going to experience this both ways. We often present to people things that we want with sort of watertight reasoning like how can they say no when we've described all of the context and people continue to say no or choose a path that we're advising against. When you're experiencing that, the chances are that you're missing some information that there's something that you're not accounting for. Think about broader context and you can ask directly if anything in that is a factor. So are you rushing to get, get this done so you can move on to an AI feature? Or are you worried about inbound? Or do you have some big release that you're trying to get this in before, before reaching. Once you understand what other people want in all of the context, you can find a path that is going to satisfy the things that you want and the things that other people want. You may not need to compromise on anything. And, and the goal isn't to compromise, it's to find a solution that works for everyone. Okay, so you've told someone what it is that you want, you found out what they want, and you have some plan for moving forward. State that plan and share what your assumptions are. Some of these are going to feel really silly to say out loud, but it's important that they get said. I think those are the most important things to say out loud. Assumptions like this, this is more important, more important than what I'm currently working on. And so I should put down what I'm currently working on. Saying that explicitly I should put put down what I'm currently working on is important to say because it gives someone the opportunity to correct you if that's not, if that's not a good assumption. Another important thing to say Is it sounds like we don't have a backup plan. Like if we run into some technical constraint, we get blocked by something. It sounds like there's no avenue for if the plan that we currently have fails. It's a great thing to say out loud so that people can start thinking about what taking failure to success might look like. When you're summarizing, you need to state the next steps you know and who you think is going to do it. And you should say if you don't know who's going to do it. An example of this is it sounds like we need to meet with some external teams, say UI components, because you need some additional functionality. First of all, who's scheduling that meeting and when is it going to happen? Because you know for a fact that no action can be taken until that first thing happens. Finally, when you're saying what you've heard during your summary, sort of state whether you agree or disagree with the thing. It's also important that you say all of the things that you've heard so that people can correct you. Summarizing is a really powerful tool for getting alignment and getting everyone on the same page. And you want to know now if your assumptions and summary is wrong, if people have different next steps or you've misheard what someone said. You want to know right now. This is how you get clarity. Okay, so you've summarized, but I think. I think the important thing is to keep it all simple. Humans are natural collaborators. We sort of want to form groups and we achieve way more together than we do divided. We generally want to work with each other, but the reason isn't because we all want the same thing and we're all driven by the same motives. Everyone has their own motivations and incentives and it's up to you to share what is driving you so that together you can find a path forward. This isn't a zero sum game. This is a. When we do things together, we get more than the sum of its parts. And that's an important thing to bear in mind. Okay, I have this. This is my last sort of speaking slide and it's a little bit of a bonus. I kind of wanted to wrap up my talk with just a idea or a tool that you could use with your teams that you may not be familiar with. So this comes from the book Shape up and it's the idea of appetite versus estimation. I'm sure we're all very familiar with estimation, but the quote here is an appetite is completely different from an estimate. Estimates start with a Design and you end with a number. Appetite starts with a number and you end with a design. We use the appetite as a creative constraint on the design process. So I personally do not want to work on the same thing for months on end. I crave change. Estimation presents an idea that we're trying to predict how long it will take to build it right. Appetite is how hungry we are to work on it. Is the problem interesting? Does it deliver value? This sounds like a tip aimed at, specifically at engineers or designers, but this is also so powerful for product managers. When you're building a feature, think about, does it need to be. Does it need to be obvious, easy or possible? This is another sort of bucketing that you can use for thinking about building software. When you're talking to your triad, express your appetite. If something needs to be like obvious, it's really difficult to get wrong. Then you're going to have, you're going to spend a lot of time on it. You're going to have the appetite to make sure that it works really well. If something only needs to be possible, you may have less appetite. You may want to get that done quickly so you can move on to other things. So when you're talking with your triad, say things like, we're talking about feature X. We really shouldn't be spending more than two weeks pulling this together. Like it. It just needs to be possible. It's not going to be leveraged by all our customers. We don't want to spend a ton of our time on it. In other instances you might say, look, this is a data migration. It's hitting some of our biggest core services and we really don't want to cause a crit sit here or risk data loss. So we have a large appetite to work on things like manual testing, regression testing, running it multiple times in QA to make sure we don't miss anything again. On the flip side, you may decide this migration isn't super important. We should take a risk and push this out more quickly so that we can move on to other work. To summarize the idea of appetite versus estimation, you can't always shoot for perfection. Appetite gives you a constraint to work within. Awesome. I wanted to wrap up a few minutes early and so this is my thank you slide. Thank you all for coming to my talk. I started the talk with a call to action, which was, by the end of the talk, I'm hoping that you go and tell someone something you know is true, but no one has said out loud. So please, please, please go and do that. And I'm going to close out with a slide about me. I hope you enjoy the rest of your epic week. Bye. Bye.