Recently, I was at the grocery store and searched for edamame, green soybeans (I only vaguely guessed they were some kind of vegetable). I didn’t I knew where to look for this product: in the vegetable section, in the frozen section. products or on the shelves with canned goods? Finally, I gave up and asked a store employee for help. She didn’t know either!
The store employee could have reacted to my request in different ways. She could have made it clear that only a fool doesn’t know where to look for it, or just brushed it off. vague hints, or even just say that they don’t have such a product. But she deemed it possible to find a solution and help the customer. Calling others employees, she took me to the right product in just a couple of minutes. Edamame ended up in the frozen food section.
In this situation, the employee listened to the request and proceeded with the assumption that the problem would be resolved and the request would be fulfilled. She started by saying yes instead of no.
When I first had to take on the position of technical lead, it seemed to me that the main thing in my job was to protect my wonderful programs from the stream of absurd demands coming from product managers and business analysts. In most conversations, I viewed any request as an attack requiring a defensive response rather than a positive answer.
At some point, I had an epiphany and realized that there was another approach to work, which differed from mine only by starting with a yes instead of a no. I came to the conclusion that starting a conversation with a positive answer is the most important part of a technical leader’s job.
This simple change radically transformed my approach to work. It turned out there are many ways to communicate. When you hear, “Listen, this app will be a hundred times cooler if we make all the windows round and transparent!” you might dismiss this suggestion as ridiculous. But usually, it’s better to first ask, “Why?” Often, there is a real and convincing reason why this person insists on round transparent windows. For example, negotiations are underway with a new major client whose standardization committee requires these very round transparent windows.
Usually, after familiarizing yourself with the context of the request, you find that new opportunities arise. Often, the request can be fulfilled within the existing product in some other way, allowing for an easy “yes” response: “Actually, you can upload a skin with round transparent windows in the user settings and activate it.”
Sometimes people come up with ideas that seem incompatible with your vision of the product. I found that in this case, it is usually helpful to ask yourself the question “why.” Sometimes the very attempt to explain the reason to oneself helps to understand the error of the initial reaction. If this is not the case, you can ease the situation by involving other responsible parties in the discussion. Remember that the goal of all this is to say yes to the other person and try to make it work, not just for them, but for yourself and your entire team.
If you can convincingly explain why the proposed feature is not compatible with the existing product, it will provide an opportunity to constructively discuss whether the product you are creating is necessary. Regardless of the discussion results, each participant will have a clearer understanding of what the product is and what it is not. Starting with yes means working together with your colleagues, not against them.