The Power Of No

“No” is a rough word to say. It’s hard to say it to strangers, so imagine how hard it is to say to your manager or a client. Let’s contemplate why is important to let loose this two-letter word.

Stage

Last year we had a project for a big health care system based in Phoenix, Arizona. They wanted to perform evaluations on their staff. This project was the biggest single sale of all time in the company I work for. It involved a big six figure number.

The main goal of the project was to perform yearly performance evaluations. And they had a strong requirement: they didn’t want employees to have open access to these evaluations unless they had the right privilege. Sometimes those evaluations could contain sensitive feedback meant to be seen only by the recipient.

That was the pitch. That was all. Nothing more, nothing less.

So POs and PMs started their dance. They started gathering requirements and thinking of ways to tackle this problem. And solutions started to pop up.

Bonus

When the requirements came down to the engineering team there was one important thing mentioned that I think every company should try doing: managers told us that for every week we delivered ahead of schedule, we as a company, were going to make an extra 20k.

Those words were like a highly pressured injection of fuel into a V8 engine. The project had a fixed budget, so it’s not particularly difficult to realize that the sooner we delivered, the better for the project’s profitability. But due to the way it was phrased, it became very appealing for the engineering team. We took it as a sort of “bet”: hell yeah we were going to be able to deliver it ahead of schedule.

A small parentheses to express how important it is to be clever when picking your words.

The Dance

We started to get proposals from POs and PMs on how to tackle this project. One proposal being pushed for was: “we need to build the client’s organization hierarchy within our system.”

So the PO came with this idea of building a hierarchical view to show the whole organization. A hierarchical view that was represented in terms of teams: “Accounting” team, “Nurses” team, etc. Something like a file and folders tree-view where every manager had a number of team members.

So we started sketching the idea, we did many back and forth meetings with the PO until we realized that our client didn’t have this “Teams” information to provide to us. They wanted to have that data in the system, but didn’t have a way to give it to us automatically. And of course, they didn’t want to introduce this data manually. This was the first wall we smashed our faces with. We didn’t want to add this data ourselves manually as it would mean getting a support case every time they wanted to change the structure of their organization. So we said “No, keep digging”.

In a conversation with the PO, we realized that they did have the information about who was the manager of whom within the organization and they could send it to us in an automated way. That was an instant “aha!”. We could now build the organization hierarchy automatically. We were going to use the hierarchical relation between people, not the teams they belonged to. First win.

Now the PO comes back to us asking for the initial requirement: “we need to build this hierarchical view of the org, something like a tree view”. So I asked: “what do they need this for?”, and he said “well, we need a way to find someone in the org to perform an evaluation”. Alright, engines back on full speed. After some exchanging some ideas and mockups with the designer the result was something like this:

But this whole concept started to itch on me. I couldn’t find its real usefulness. After asking some questions to the PO I realized that this was more like a personal idea and not something the client requested. This tree-view concept was a whim from the PO to try to make the contract money worth it. But was this going to be useful for the client? No. What they needed wasa way of knowing who was reporting to whom in a simple way. So I said “No” once again. I suggested that we should ditch that tree-view concept and target the actual client’s need. So we implemented a table list that allowed the user to filter by “Manager”. Simple and easy, no gleamy feature, but hits right on the spot. Another win for the “No”:

After this we were ready to move to the next step of the implementation, we needed to build a way to “hide” evaluations from users. Something like a privacy setting. As a simple example: If I was a staff member being evaluated, only my manager and I could see the evaluation. My team mates wouldn’t be able to see it and I wouldn’t be able to see theirs. So we started the PO / engineer dance again.

This is right when my idea bulb sparked: “Why not doing something like what Facebook does to customize sharing permissions of photos?”. This was an instant hit, the trust I earned due to challenging established ideas made this particular idea to get accepted instantly. After some back and forth with the designer, we pulled our sleeves back up and started coding. We finally implemented the “evaluation sharing” feature, and it looked as simple as this:

That was it. These simple changes hit right on target with our client. They were so happy with our implementation that decided to explore other development options with us.

Windup

The intention of this story is to show you how you should consider this powerful word more often. It doesn’t mean that your first response needs to be “No”. That’s not how you leverage the power of “No”. The main idea is that before saying “Yes”, you take time to consider what’s being asked, analyze, deep think and challenge the establishment. Let the fear go away. Almost everything you interact with is a creation of one or more humans, and humans do make mistakes. Have that in mind always considering that you yourself are also a human.

An interesting takeaway is that if we didn’t challenge what the PO was suggesting, there was a high chance that we weren’t going to hit the self-imposed deadline. The risk of having a shiny complex feature to offer was too high compared to the benefits being brought to the table. As an engineer, you’re also part of the direction of a product. You’re not just a code typing machine. Make yourself heard.

Oh, and in case you are wondering, we delivered the project 4 weeks ahead of schedule.