Why focus on why

Around 2 years ago, I started a new management gig. it wasn’t the first, but it was the first with a relatively large team. One of the most basic things I needed to do as a manager was to bind the team to its mission, and in simple terms: get them super motivated to do their day to day tasks.

I’m a strong preacher for freedom, it gives people a sense of ownership.

Let’s tackle the two edges of freedom:

No freedom at all

Someone tells you what to do, how to do it, and when to do it.

” You need to remove some logs related to the checkout process, so please delete lines x and y from file z, make a PR and send it to me “

Well, this is straight forward, anyone can probably do it, you might think it’s a good task for a newcomer. Another perspective is: what message am I sending to this person? This is how it might look from an employee perspective:

“I don’t trust your judgment and capabilities, so I’m telling you exactly what needs to be done, I don’t even bother to give you the bigger context. You probably won’t learn anything from this task, but that’s the job, and this is what the future looks in this team. I trust you so little I must personally make sure you did it right, so I must review your code.”

So, as you can see I took it to the extreme, but even if 5% of this thoughts will pop in the employee’s mind, it’s bad.

Complete freedom

” We’re paying too much to our logging storage service “

This approach is wide open. no what, when or how, only why. This can go down in one or 2 ways:

when it’s a junior developer:

“Ohh sh*t I’m clueless, I have no idea what needs to be done, I’m too shy to ask anyone anything, this is scary. Why is there no one to guide me?”

when it’s a senior developer:

“Alright, we’ve got a problem, let’s solve it. I feel trusted and empowered by my manager to solve problems on my own”

*There’s an even higher degree of freedom, one where you don’t focus the employee on a specific problem, and let them choose it on their own. This is not an industry standard so I’m ignoring it.

So, to the point, freedom is awesome, not for everyone and should be dosed right. You’re optimizing for independent team members who can do everything. in order to get there, you need to trust them and have high expectations from each team member.

With experienced developers it should be relatively easy, just focus on the “why” and they’ll figure out the rest, or ask nudging questions to get more of the ‘what’. if it’s a feature, a product manager will provide the what. When you focus on the why, you create a strong ownership of the problem. This is good because you never want to get attached to a particular solution, the solution might change tomorrow, it’s a fast moving world. However, the problem probably won’t change so quickly. When you focus on the why, you give a wider perspective, allowing people to be more creative when it comes to proposing creative solutions. They need to think, and this is exactly why they came to work, and that’s why it’s so motivating.

With less experienced developers, it might be a bit trickier: you want to do the same without getting their frustration level above the tipping point where they feel incapable. You’ll need to do some sensing for each task to understand the proper level of freedom that can be given.

My recommendation is to start with the why, and start an open discussion about the next steps. Uf things don’t evolve, you can push some of the what and how as needed.