Let’s talk about motivation. More specifically let’s talk about what leadership can do to help motivate a team.
Once upon a time, a director of product management and I were butting heads. Let’s call him J (not his real name, or even his real initial).
J was unhappy with the pace at which the developers were delivering. His usual approach to hastening development was to set arbitrary deadlines to create a sense of urgency.
It wasn’t working.
Despite J’s best efforts at inspiring the developers to work harder and faster, progress was moving too slow for his liking.
I was in an engineering leadership role, so J tried pushing on me to push harder on the engineers. Things came to a head when J said to me, in a tone of utter exasperation, “Come on! You know programmers. You have to light a fire under them to get anything done!”
Well, no. I don’t know that. In fact, I don’t think that’s true at all.
Granted, pressure can expedite delivery. However it comes at a cost, and it’s a cost that’s difficult to measure. Pressure and urgency typically lead people to cut corners. That, in turn, can lead to an illusion of speed that comes crashing down later with delays or poor results. But it might not. It could take months or years for problems to arise out of those cut corners. Further, people who operate under pressure for too long burn out. But burnout doesn’t happen right away.
So from J’s point of view, when he was unhappy with the productivity of a team in the past, he ratcheted up the pressure and got the result he wanted. If there was a downside to his approach, he probably never saw it. He was too far away from the work and from the people doing it.
While I don’t know if J left a trail of destruction in his high-pressure-wake before, I have seen the mess that others who used similar tactics to J left behind. In fact, I’ve spent a good part of my career cleaning up after those messes.
What I’ve learned is that if we want things to go fast, a sense of momentum is much more effective than a sense of urgency.
Consider another project with a very different team dynamic.
In 2008 or so, I was a programmer on the BringLight development team at Pivotal Labs. Drew McManus was both a company founder and our product manager.*
We used Pivotal Tracker to manage our work, so we broke the work into bite-sized chunks, tracked as stories. Drew prioritized the stories. When we delivered the work, Drew tried out the new capabilities, and accepted or rejected the story within minutes. Even when he was out of the office for meetings, he would check the tracking tool frequently to see if there was anything for him to accept.
Drew’s responsiveness had a palpable effect on the whole team. We became a delivery machine.
If we were close to delivering a story and had a few minutes before lunch or the end of the day, we’d push through and deliver the story. We knew it made a difference. More often than not, Drew would have done his acceptance before we got back to the keyboard. There were times Drew accepted a story while sitting in a coffee shop, then demoed that new story to a VC just minutes later.
Each acceptance fueled the next delivery. We never rushed. We never cut corners. (Drew was just as good at rejecting stories as accepting them.) Instead, we worked with a sense of focus and purpose. It also helped that Drew had a strong overarching vision of what we were building, so as we broke down stories to bite-sized pieces, we could still connect them to the larger vision.
Drew and I are still in touch, so I know how the story ended. He and his partners eventually sold the company. Before that, the code we wrote ran in production for years with no substantial defects. After go-live Drew hired a solo part time developer to handle routine ongoing maintenance.
BringLight is not the only time I’ve seen a team benefit from a sense of momentum, it just happens to be one of my favorite stories.
Every time I’ve seen a team achieve a sense of momentum, several things are true:
- Everyone on the team has a shared understanding of the big picture and what “good” looks like so they don’t burn cycles on unnecessary or non-useful work.
- The team breaks the work into small pieces (a couple days of work at most) that still represent incremental business value (even if not user-facing features).
- The team embraces the technical practices necessary to ensure that the code they deliver does what they intended it to do.
- There’s an engaged and responsive product manager who is considered part of the team, and who does hands-on acceptance of the work.
- When the work is “accepted,” it’s done. The entire team can stop thinking about it.
- The work, and the status of the work, is visible to everyone.
- The team as a whole has a strong sense of partnership and trust, so the visibility never becomes a mechanism for micromanagement.
There is nothing on that list that’s easy, but it’s worth the effort. Creating a sense of momentum remains the very best way I know to enable long term sustainable delivery. Even improving along a subset of the dimensions in the list can yield huge benefits.
(Oh, and if you’re waiting to hear the end of the story about J, I’m not going to go into details. Suffice it to say that J and I never did figure out how to partner effectively and we didn’t work together for too much longer. In the fullness of time, some time after J left, the team he was trying to pressure did eventually improve their ability to deliver…by developing a sense of momentum.)
* It’s worth noting that I am working with Drew McManus again! I am an advisor for his company 33 Teams.