Want to motivate workers? Just ask, "any blocks?"

A manager can make a different when it comes to progress and can control it. As a manager, there are moments when the team makes great strides and everything seems to be humming. These are moments when our constituencies and business owners are happy that we are making progress. Most important, these are the moments when the team is extremely motivated. For over three years, I thought that these moments were out of my control. It all started three years ago when I worked with a team of ThoughtWorks. One of the project manager said,

...when you are a high level manager, you don't make a big difference at work.

Later at a bar we dissected that sentence. When you are a manager, progress is mostly made by people under you, but you are not doing the work per-se. You can measure, forecast, but you really can't increase the speed/velocity of the project.

On December, I read the article What Really Motivates Workes by Teresa M Amabile and Steven J. Krammer on HBR and found out that the top motivator for workers is progress. They based a research purely on understanding the power of progress. The authors found out that

on days when workers have the sense they're making headway in their jobs, or when they receive support that helps them overcome obstacles, their emotions are most positive and their drive to succeed is at its peak.

As a manager the key motivation turns out to be largely within my control. Manager have a large influence over events that facilitate or undermine progress. This enforces the Scrum methodology of having the daily 15-20 minute meetings and asking the three questions:

1. What'd you do yesterday?
2. What you gonna do today?
3. Do you have any blocks?

I have to admit, I always focused on the first two questions. I did pay attention to the "blocks", but I didn't prioritized them as I should've been. I was under the impression that if we finished/burned tasks yesterday, and we were committed to burning some points today, we were making progress. Now, it's the opposite. The authors suggest to

Scrupulously avoid impeding progress by changing goals autocratically, being indecisive, or holding up resources.

I take a great care of dealing with this blockages ASAP. I don't just focus on the blockages. I take a great care to clarify overall goals, ensure that people's effort are properly supported, and reframe from exerting time pressure to intense that minor glitches are perceived as crises rather than learning opportunities. The other item that I need to focus is on cultivating a culture of helpfulness.

I was pretty impressed with this article and I made adequate changes after I read it. After a few weeks, I noticed some pretty good outcomes specially on my junior programmers. Not so much with my senior developers. One of the reasons is "changing context". When one of the junior developer/engineers gets stuck they would jump to ask the questions to the senior developers. As everyone knows, context changing is very expensive. I'm trying to put some type of threshold for the junior developers to ask a question (20-30 minutes). I was also thinking of making some new rules so that the senior developers don't get bother when they are focused on a particular tasks. One of the ideas was using headphones. If someone is wearing headphones that means that he's focusing on some type of task. I'm still trying to figure out how I can make this balance work, but so far it is good to know that I'm on control of it.