<aside> ℹ️ In project management, it's more effective to assign projects rather than tasks to teams, allowing them to maintain a holistic view of the project and encouraging autonomy. This approach results in better project outcomes as the team can adapt to unforeseen changes and challenges. The team is responsible for defining their tasks and approach, and for deploying their work by the end of the cycle. The initial phase of a project often involves orientation and exploration, which should be respected by managers. The tasks that emerge during the actual work often differ from those initially imagined.

• [ ] Assign projects, not tasks
  • [ ] Create a notion project with all the shaping details
    1. Problem — The raw idea, a use case, or something we’ve seen that motivates us to work on this
    2. Appetite — How much time we want to spend and how that constrains the solution
    3. Solution — The core elements we came up with, presented in a form that’s easy for people to immediately understand (breadboard / shaping)
    4. Rabbit holes — Details about the solution worth calling out to avoid problems
    5. No-gos — Anything specifically excluded from the concept: functionality or use cases we intentionally aren’t covering to fit the appetite or make the problem tractable
• [ ] Ensure the project is deployed by the end of the cycle
• [ ] Accommodate testing and QA within the cycle
• [ ] Create a new Notion project and add the team to it
• [ ] Post the shaped concept to the Message Board
• [ ] Arrange a kick-off call with the team
• [ ] Allow the team to get oriented in the first few days
• [ ] Check in if silence doesn't break after three days
• [ ] Encourage the team to discover tasks by doing real work </aside>

Shape Up - Chapter 10: Hand Over Responsability

We’ve made our bets and now it’s time to start the next cycle. How does the team get started?

Assign projects, not tasks

We don’t start by assigning tasks to anyone. Nobody plays the role of the “taskmaster” or the “architect” who splits the project up into pieces for other people to execute.

Splitting the project into tasks up front is like putting the pitch through a paper shredder. Everybody just gets disconnected pieces. We want the project to stay “whole” through the entire process so we never lose sight of the bigger picture.

Instead, we trust the team to take on the entire project and work within the boundaries of the pitch. The team is going to define their own tasks and their own approach to the work. They will have full autonomy and use their judgement to execute the pitch as best as they can.

Teams love being given more freedom to implement an idea the way they think is best. Talented people don’t like being treated like “code monkeys” or ticket takers.

Projects also turn out better when the team is given responsibility to look after the whole. Nobody can predict at the beginning of a project what exactly will need to be done for all the pieces to come together properly. What works on paper almost never works exactly as designed in practice. The designers and programmers doing the real work are in the best position to make changes and adjustments or spot missing pieces.

When teams are assigned individual tasks, each person can execute their little piece without feeling responsible for judging how all the pieces fit together. Planning up front makes you blind to the reality along the way.

Remember: we aren’t giving the teams absolute freedom to invent a solution from scratch. We’ve done the shaping. We’ve set the boundaries. Now we are going to trust the team to fill in the outline from the pitch with real design decisions and implementation.

This is where our efforts to define the project at the right level of abstraction—without too much detail—will pay off. With their talent and knowledge of the particulars, the team is going to arrive at a better finished product than we could have by trying to determine the final form in advance.

Done means deployed

At the end of the cycle, the team will deploy their work. In the case of a Small Batch team with a few small projects for the cycle, they’ll deploy each one as they see fit as long as it happens before the end of the cycle.

This constraint keeps us true to our bets and respects the circuit breaker. The project needs to be done within the time we budgeted; otherwise, our appetite and budget don’t mean anything.

That also means any testing and QA needs to happen within the cycle. The team will accommodate that by scoping off the most essential aspects of the project, finishing them early, and coordinating with QA. (More on that later.)

For most projects we aren’t strict about the timing of help documentation, marketing updates, or announcements to customers and don’t expect those to happen within the cycle. Those are thin-tailed from a risk perspective (they never take 5x as long as we think they will) and are mostly handled by other teams. We’ll often take care of those updates and publish an announcement about the new feature during cool-down after the cycle.

Kick-off

We start the project by creating a new Basecamp project and adding the team to it. Then the first thing we’ll do is post the shaped concept to the Message Board. We’ll either post the original pitch or a distilled version of it.