People do things because someone else told them to or because they are convinced and accept the reason behind what needs to be done. If you’re a leader, I’m sure you know that the first scenario is short-lived, and people will get demotivated and abandon you.
But if you employ the 2nd method and get your team’s buy-in, you will substantially increase your chance of success in any project.
A prerequisite of getting your people’s buy-in is to clarify WHY.
Why? is often the first question we, humans, verbalize after learning to speak. Why is the sky blue? Why do birds fly? Why I can’t binge sweets all day long? As we grow older, we don’t verbalize the question that much, but we never stop asking it in our minds. We need reason and understanding because it gives us meaning.
“He who has a WHY to live can bear almost any how.”
— Friedrich Nietzsche
Life is hard, and Nietzsche’s saying reflects that meaning can give us the resilience to endure those challenges we inevitably face. Work is also complicated and part of life. To be motivated and engaged and to have resilience in work, you need to understand the reason behind it because everything must be done for the right reason.
“People are problem-solving machines”
— Jordan B. Peterson
I believe the above statement is accurate, and if you specify the Why and not just What needs to be done, you will tap into this incredible ability of humans to solve problems. With the reason clearly understood and accepted, whoever works on the task might devise innovative ways of implementing the What. You could also discover that there is a better What or, even better, the What is no longer needed.
Why helps you in decision-making
Explaining why something must be done will force you to think more deeply about the task. It will validate (or invalidate) the path you chose and if what needs to be done is correct. This is the most significant advantage for you.
How do you put this into practice?
When you write a task, describe a feature, or verbally ask someone to do something, start with the Why. Explain the reasons behind what needs to be done. The Why should always come before the What. Do this even for trivial tasks or features, even if the reason is evident. This way, it will become a habit and eventually could become part of your ethos.
Let’s take a software engineering example. Imagine you are the one who writes a task for engineers to implement a login page. The task is about implementing a form to collect the username and the password, authenticate the credentials, and redirect the user to the private section if the credentials are valid. Else, display an error message. It’s a simple task, and you might be tempted to write just the title and nothing more.
Is it self-explanatory? I don’t think so.
Let’s explore a few questions I might have as an engineer: Why authenticate with a username and password and not with Google? Why use a username and password and not the email and password? Why not ditch the password and email a one-time link to the user? Why do we need to do this now? These are all valid questions an engineer might ask.
To clarify those questions, you need to reserve time to discuss them with the engineer tasked with the implementation. You wrote the task, and then you need to discuss the task again. This is inefficient; if it happens a lot, it demotivates everybody.
Maybe you clarified the details verbally in a previous meeting. Then why not write it down in the task as well? Scripta manent, verba volant. Maybe you described the reasons in a separate document. Then why not say that in the task and link the document? Maybe you already implemented the authentication with Google, but you also want to offer the possibility to authenticate with a username and password. Then why not mention this in the task and add a link to previous tasks to give more context?
It is effortless to start your tasks with the Why. I've written thousands of tasks with the Why up front, and I can tell you that it is easy. The engineers working on those tasks find it valuable. The feedback I received from them was very positive. Many took this habit to other projects after they left my teams.
I also find it very valuable in the decision-making process. It happened to me many times that I realized what the What should be only when I wrote the Why.
The bottom line is Why drives our motivation and engagement. It gives us purpose and meaning. It taps into humans' natural ability to solve problems creatively and help you make the right decisions.