Getting out of the way
There’s no shortage of advice that tells managers to “get out of the way” of their teams. I tried to apply this concept when I arrived at Managed By Q and I was surprised by how well it worked. Along the way, we’ve learned some things about how to get out of the way effectively.
Our initial situation was demoralizing. Several projects had run months late. We were just about to start work on our dispatching system, a system that we’d promised a year earlier. We were having trouble deciding what we’d build, though we anticipated that the scope would be huge. It was enormously important to the business, but we were doubtful that we’d succeed.
I was new and I didn’t have any insight into building a dispatching system. The only card I could play was to get distractions — including me and other managers — out of the team’s way.
Getting out of the team’s way meant removing several mechanisms of control. We killed estimation, then sprint planning meetings, and finally we killed sprints altogether. We stopped exhaustive documentation of stories in JIRA and switched to lightweight self-service project management in Trello. The team would succeed if they made good decisions and not through tight, controlling management.
Getting out of the team’s way also meant that the team needed the ability to focus. We eliminated a bunch of projects and whittled the team’s focus down to two priorities, one of which was the dispatching system. I was new on the job and feared that the company would rebel. Instead, to my great surprise and happiness, they supported us.
Finally, getting out of the team’s way meant that they needed the authority to choose any approach that would lead to success. That meant that we needed to agree on the goals of the project. The initial goal of our dispatching system was to reduce the time that it took for anyone to find, contact, and confirm the right person to staff a cleaning session. In retrospect, that goal is pretty obvious. At the time, we had several competing goals to choose from.
With processes gutted, competing projects slashed, and goals clear, I waited. Others asked me whether I had a plan. Did I know what we’d deliver? Did I know when we’d deliver it? I had to admit that I had no plan, only goals. Everyone was skeptical.
The turning point arrived suddenly. Matt Madurski, a customer-focused and well-liked engineer, had a hunch for how to simplify the dispatching problem. He went to a bar, ordered a beer, and wrote the first, most minimal dispatching API that he could think of. It wasn’t that complicated. There wasn’t even a UI. But, days later, he was dispatching people. In the very first iteration, someone would send him a request over Slack, he’d query his own API, and then he’d send back a list of people to staff sessions.
It was working. Matt had made some good simplifying assumptions and we had the core of a system that could do what we wanted. We spent several months improving the core of what Matt built. We built a UI, added in flexible searching features, and added in SMS integration. Matt rewrote all of the initial code so that it would actually perform well under realistic circumstances. In terms of our goal, the time to find, contact, and confirm the right person sharply plummeted, from the better part of an hour to mere minutes.
Not everything worked out as perfectly. Because we’d scrapped so many processes, we’d hit a few stumbling blocks:
- We had no clarity on our timeline. Would we be working on the dispatching system for another month or for another six months?
- The team occasionally got frustrated with a high level of rework. As developers were finishing work on a part of the system, a design would change.
- We struggled with reactive work such as bug fixes outside of dispatch.
The team, sometimes with my involvement, came up with answers to each of these issues. JT White, a designer, sketched out a high level vision of our future dispatching system. This vision helped the team reason about what they needed to build and about how long it would take. JT also agreed with developers to start doing more work at low fidelity, so that major scope changes would get worked out sooner. Although we didn’t return to sprints, we did establish a lightweight weekly review meeting, led by John Cockrell, our product manager. In that meeting, we review what we’ve learned, we review our bug status, and we restate our plan both for the coming week and for the coming few months.
Getting out of the way was a learning experience for me personally. When we hit stumbling blocks I was tempted to peel back on the freedom I’d granted the team. They resisted strongly and, each time, they were right. I learned to handle stumbling blocks by explaining what concerned me and, only sometimes, by suggesting a solution. The right things would inevitably happen.
There’s a corollary to the doctrine of getting out of the way. If our managing principle is trust and not control, then our people matter more than our processes do. We need to hire people we can trust. As we’ve started to build out the team at Q, we’ve developed a detailed set of criteria to assist us in evaluating candidates. But, for each candidate, we ask a defining question: “Does this person make us better?” Only when the answer is yes can we trust that the team can continue to succeed when managers get out of the way.
The team made great decisions — decisions that were formerly considered to be “management” decisions. We ran into some stumbling blocks but, all told, getting out of the way has changed our development culture for the better, and it’s raised the standard for who we bring onto the team.
