Yes, No is also an option!
“The difference between successful people and really successful people is that really successful people say no to almost everything.” [Warren Buffet]
Saying NO is a challenge in our crafting days. Especially when we as software developers find ourselves in situations where we are supposed to make commitments. Why do we have a problem with that? We at Codementors had a small discussion about different reasons behind saying a "yes" even when its not appropriate. In this blog we will share some of the reasons we experienced. Each decision has its implications. How to deal with that as a software crafter especially if the decision is not yours!
After this small discussion, we decided to gather the reasons behind such decisions made by software developers. In this part we will concentrate only about situations, where an explicit “no” is relevant.
Types of YES
To make it simple we differentiate between:
- an unsaid no becomes a yes.
- accepting a yes after saying no.
- saying yes and meaning it.
Let us start with the last one. I will call it a real and committed yes. The person saying this sort of yes is motivated and believe in their commitment. I experienced that people accept the responsibility after such commitment even if they fail. And this is the only “YES” which exists.
Reason No. 1: Consequences
“I need to do it! Otherwise I am out of the game!” Sounds familiar, right?
For example a team developing a system get an invitation from management:
Manager: "We have to deliver the system with all the functionalities until a specific date."
Team: It sounds impossible. We need to cut some of the functionalities.
Manager: …
Team: …
Manager: If your team cannot do it, we will hire a team from another vendor, which can do it.
Team (in most cases the account manager): If another team can do it, why couldn’t we?
Sounds like the only option that team has is saying a yes at this moment. Here we are talking about a yes after saying a no. The reason behind this behavior are the Consequences: The developers could loose their job, if they does not hit the goal. And they won't because the root cause of their no will not be discussed or solved.
How to deal with it?
Developers in team say no because of the concerns they have. I experienced a similar situation years back. We sat together and listed all the risks and concerns we had. We made them transparent to stakeholders including management. We checked weekly, if a new risk should be added to our list and if any of the risk probability has risen. Management received the updated list regularly and took actions to mitigate the risks. We also discuss the scope of system regularly with our product owner. We had new requirements and some of the old requirements became obsolete. Also these changes were brought to managements knowledge regularly. The system was not operational on given date with all functionalities. Management understood the reasons and nobody lost their job. On the contrary the team was appreciated for the way they worked.
Reason No. 2: Psychological Safety
Amy Admondson wrote about a nurse in her book The Fearless Organization. Once while assisting a medical doctor, she was pretty sure, that the doctor is making a mistake while treating a patient. She didn’t say anything. Psychological Safety was the reason behind her silence.
If employees feel psychological unsafe in a team or organization, they wouldn't say a no to anything. In this case we talk about "an unsaid no becomes a yes". This is a hell for a software crafter. Management/seniors expect that employees/juniors are only there to follow their commands. Because nobody contradict any of their decisions, everybody is committed, according to management/seniors point of view.
After some time employees leave such teams or organizations. The quality of the software becomes worse. Customers become unsatisfied. These are some of the symptoms we noticed in such cases. If nothing get done against this attitude, this becomes the new culture. And that my dear is hell of a job to change! :-)
How to deal with it?
In such a situation a significant change is needed on both, management's and developers' side. One of the most important instrument a software crafter should have are communication skills and specially the art of giving and accepting feedback. We don't need to attack our seniors or management because of the decisions. Try to understand and figure out the motivation behind such decisions or commands. E.g. the medical doctor in above example is honest about saving his patient.
The nurse could have told the doctor:
- "Excuse me but what you are doing right now appears like a mistake to me because ..." OR
- "Thank God, you are here doctor. Otherwise, I could have done xyz instead of what you are doing."
The first option seems difficult in an psychological unsafe environment. The nurse may doesn't want to tell her boss that he is making a mistake.
In the second option a feedback is given without stepping on anyone's toes. Staying silent forever is not a solution but a time passing strategy. Which is not going to help anybody!
I also believe that software crafters also welcome feedback even if it hurts.
In case of a team, my interpretation for a similar example by Patrick M. Lencioni given in his classic book The Five Dysfunctions of a Team is to get rid of such seniors. This is a decision which should be made by higher management. Make sure you make it transparent. As i said earlier: "Staying silent is not a solution."
Conclusion
Our yes without thinking about any reasons to say no may hurt us in a near future. It doesn't mean to start with no. But not to start with yes as well. We experienced that making our reasons and following risks transparent helped us a lot. Sometimes those risks are only in our imagination. Talking to teammates and stakeholders help us figure out the reality. The same is true for a team, where before communicating concerns with management, team members should discuss these thoroughly amongst themselves. It is not easy all the time. It helped us live in a comfortable state of mind after making our concerns transparent. Which, in turn, directly increases productivity.
List some decisions for yourself from last couple of years you regret. To which category they belong? YES or NO