Handing over responsibility and instilling a sense of ownership

In Shape Up, one of the key elements that seem central to the success of a project is how much the team own it and feel responsible for it.

I’d love to dig into this a little bit and explore some of the challenges and hopefully solutions that other teams are experiencing. I’ve shared below some areas that have been floating around in my mind but would be good to hear other challenges too.


Changing patterned behaviour can be difficult. Teams have grown to expect projects to go through the paper shredder even though they don’t like it and it’s clear it doesn’t quite work.

There are many different ways to compose and structure the team. Is there a point person? A team lead? Who are they? Are they the same person every time? Equally, how large are the teams? Basecamp is able to do small 2 person teams but other companies have more of a separation between design, frontend and backend. So they’ll have 3 at minimum.

What’s the best way to hand over the responsibility that gives the best chance of success for the project? We have a kick off meeting at the moment but it’s difficult to know what the structure of that should be. What should and shouldn’t be discussed in these meetings?

I would love to hear what some of the ways that you are using to instil ownership over projects?

2 Likes

@JoshAntBrown Man, this is such a great question. I think it’s the thing I wrestle with the most.

To your point about changing patterned behavior being hard, I think the people who struggle the most with feeling invested are the folks who were hired before we piloted the Shape Up process.

During my shaping work, I’ve found it helpful to float a fat marker sketch to a designer or engineer, or walk them through a breadboard and ask for their take on it. I don’t circulate whole pitches for their reactions (I did that once at it was a mistake :slightly_frowning_face:), but rather show them something closer to a raw idea and try and get their perspective. My main goal is to broaden my own perspective, but it has absolutely created room for them to feel more invested in the resulting pitch.

The other thing I do is invite people are vocal about wanting more strategic involvement to pitch something. One of our execs has this wonderfully cheesy mantra – “if you’re going to oppose, you need to propose.”

There are many different ways to compose and structure the team

Boy are there ever :slight_smile:

I’ve found that the person who is best a defining scopes usually makes the best team lead. Keeping the design development work super closely tied to shipping individual scopes is, in my opinion, the most important aspect of succeeding in the execution portion of Shape Up. I don’t actually think it matters whether that person is a designer or an engineer, but I haven’t been working this way that long either, so I could totally be wrong.

Basecamp is able to do small 2 person teams but other companies have more of a separation between design, frontend and backend. So they’ll have 3 at minimum.

I think Basecamp’s default is 1 designer and 2 devs. If, in your case, one of those devs is a UI engineer that’s probably fine, isn’t it?

I strongly encourage you to keep your teams to no more than 3 people, if for no other reason than it seriously simplifies communication. A 3 person team means there is only ever one conversation happening at a time. Just adding one more person creates a lot more complexity.

What’s the best way to hand over the responsibility that gives the best chance of success for the project?

I don’t know if this is the best way, but it has proven to be a pretty good way for our teams. We announce the next projects and team assignments sometime the week before the cycle starts.

On the first day of the project cycle the teams assemble, chat about their project, and schedule a kick-off with the Pitch Author and any other relevant stake-holders to ask questions and express any concerns. We give them 2 or 3 days before the kick-off to get oriented and figure out what questions they have.

The goal of the kick-off is to try to identify the first scope. If that’s not reasonable or possible (though hopefully it is!), we identify what they need to figure out in order to define the first scope and schedule a follow-up to discuss before they get off to the races.

We don’t discuss solutions in detail in this meeting. If questions start to circle around asking for prescriptive direction, we tell them that’s up to them to determine.

We don’t make adjustments to the pitch in these meetings. Sometimes it gets very tempting to do so – especially if there are project team members who don’t like the pitch for one reason or another.

3 Likes