...I think it was in Shape Up that the idea of delegating projects rather than tasks came up. And I'm trying to move this way, of working with my own team. I just wonder if you guys have any tips or help for making that transition, helping team members take ownership for their areas of work, maybe obstacles I can watch out for leading my team in this way as we move in this direction. We have a small team, just a handful of people. But I would love to move in this direction where they're taking more ownership and I can delegate whole projects rather than, um, me kind of owning the project and then delegating tasks...
We're likely going to address this question out loud on an upcoming podcast AMA, but I wanted to write up a response as well. So here goes.
When we ultimately decide what to work on over the next 6-week cycle, we assign specific projects to specific teams of two. And that's the last assigning, or delegating, we do on that project. Once a team of two (one programmer and one designer) is assigned to a project, they determine how to approach it, they determine the steps they're going to take, they determine the tasks they need to complete to get it done. They fill up the Card Table or To-Do Lists in their respective Basecamp project. They, they, they.
Projects start with a name, the people involved, and, typically, a kickoff message describing the project in a few hundred words. But that's it. The rest starts blank and its on them to fill it in as they go. That's the other thing — a project may start with a small handful of tasks on day one, two, or three. Work is added as the project progresses, as more discoveries about the work are made. Things make the list as they need to, not in anticipation of being needed.
No one defines all the work up front. That's a fools errand. Assuming you know too much up front is the best way to find out you're wrong in the end. Instead we define the direction, the purpose, the reason, and a few specific "must haves" up front. The rest — all the rest, which is mostly everything — is determined during the project, by the people on the project. Day three may have 12 open to-dos. But by day 14, there might be 20. And by day 15, there may be 30. Eventually that number begins to dwindle as scopes are completed, and work wraps up.
As that team thinks things through, sometimes they'll make to-dos for each other since they know who will be responsible for which parts of the project. They're on the ground, they know best. But there's no one outside the project making to-dos for them, assigning them work, or otherwise telling them what to do. In other words, you don't show up waiting to be told what to do, you do what you determine needs to be done. That's how they own the outcome. They aren't responsible for determining if the feature was a good idea to build in the first place, but they do own if it works as-built.
This can come to a shock to some people — especially new employees that come from more traditional organizations where their manager effectively gives them a list of tasks or goals or whatever every day. "Here's your 12 things to get done today." That's not how we work. Here it's "Here's the stuff I've decided to work on today to make progress on the project we're working on together."
Along the way other people can check in, or be pulled in for advice, review, a second opinion, etc. But that demand is primarily driven by the teams themselves. Sometimes if we haven't noticed enough progress, or sensed something's stuck in the mud, we'll jump in, poke around, and see if we can help, but most of the time, outside assistance is purely demand driven from the inside, not the outside.
QA is one minor exception. As a project moves on, QA floats in. And when they spot issues, they may assign those issues directly to either the designer or the programmer, depending on their determination of responsibility. Other times they just add them to the triage section of the Card Table and the team divvies them up depending on how they see the responsibility.
As for tips, I don't have many other than try this on something small and relatively inconsequential to start. But real. Don't practice real work on fake projects. Chunk off something, put a couple of people on it, define the concept you're after, and let them loose on it. You may need to try this a few times to get the hang of it. Your job, as the manager or team lead, is to let go. Resist the urge to define, the urge to lay out the path ahead of them. That's their job, and they'll only get better at it if you let them do it.
You can do this.
-Jason