I started working with a team as their dev manager sometimes back. At the time I joined, they were working on a several months project and were fairly behind schedule. I was informed about the challenge awaiting me: the team was lacking ownership and sense of urgency.
There is a quote that I love, unfortunately I can’t recall whom it’s from1:
Everyone is doing their best given their context. If you think they’re not doing their best, then you don’t understand their context
It’s a matter of understanding the team’s context.
Hoping it would make more of a difference than the 2 intangible orthodox references of ownership and urgency, we started fixing what was obviously broken: restoring focus, setting up a process that makes sense, reducing WIP and cycle time, limiting interruptions, etc., while trying to make sense out of what we were working on. This team, composed of 4 developers, a QA automation specialist and a product manager, had already spent 2 months refactoring the website’s header…
Having a process that works is a necessity. But it took a transformation way beyond the team itself to fix things. And this team is now the most self-driven I’ve ever worked with. being in one of their planning meetings is a truly inspiring thing: the product manager puts out the numbers and makes sense out of them. They review what’s being worked on and question its usefulness. They review what’s supposed to be next, and discuss about whether it makes sense as per the goal and if it can be made smaller and more to the point. Potentially the PM brings up new things that could help enhance the goal. Then it’s done, usually packed in less than half an hour. You can touch the focus, feel the motivation. It’s organic, it doesn’t need guidance. Things happen because they make sense.
According to Daniel H. Pink2 the three elements that drive motivation are autonomy, mastery, and purpose.
Needless to say, feeling autonomy and sense of purpose is hardly possible when you spend your day untangling legacy code to rebuild a header. So what changed?
- This team used to have a poorly defined applicative scope. It now doesn’t have any. Instead, it has a business goal: increase revenue.
- This team used to deliver features. It now targets a metric, and measure its improvement.
- This team used to receive a quarterly roadmap with arbitrary deadlines they needed to deliver3. Instead, they decide the features they will work on to achieve their business goal. The features they work on are prioritized based on value rather than HIPO’s gut feeling.
- The team used to work on full fetched features that took months to release. They keep focus and don’t diverge. They iterate on a very short period: a few days or a couple of weeks. Then measure and pivot or persevere.
- The team used to be judged on deadlines and number of features. Instead it evaluates itself on achieving a goal.
More than anything, they used to have no connection between their work and the success of the company. Today, the connection between their day to day job, and the money the company makes out of it is direct, short-termed, very visible.
I’m not gonna lie: this is not perfect yet. It needs fine tuning, and a very reduced amount of control. But it’s more optimal and comfortable than anything I’ve experienced up to now. We’re transitioning the other development teams to that model. This is not a frictionless process, but it’s definitely worth the move.
Motivation is not a quality. Motivation is a feeling. Motivation is organic. It cannot be force-fed to a team.
Almost sure it’s Gerry Weinberg. Can’t prove it though. ↩
They were also asked to post-rationalize the roadmap with business goals during a “tech offsite”. We actually once spent an hour debating what the goal was for a roadmap already decided for. Life is fantastic. ↩