I'm struggling to give our design team enough work

1

Our team recently started using Shape Up and things are generally going well, however, our design team has reported that they tend to be very busy at the beginning of a project (when they are actively whipping up deliverables in coordination with the engineering team) and the end of a project, (when they are reviewing all of the project scopes as they come together), but there is a noticeable lull in the middle of a project.

Whereas pre-Shape Up our design team would often be occupied with design work on features under consideration, Shape Up has eliminated that (often wasted) effort by only bringing in design when a project has been greenlit (i.e. bet on).

I now find myself assigning these underutilized designers small projects that could get picked up during a cool-down period (or never), which feels wrong.

So my question is, is our team “doing it wrong” WRT Shape Up? Or is this expected? And if it’s the latter, what is the best use of our design team’s time when they have extra capacity mid-cycle? Also, consider that there could be projects that don’t require design at all (e.g. API work).

Appreciate your feedback!

4 Likes
2

Hello samsles! Welcome to Shape Up. I’m a designer myself, so I hope my perspective will help.

What if that “noticeable lull” actually contributes to your team’s success? If your designers are super busy at the ends of your cycle, maybe that lull is actually a “well-deserved break” that allows them to recharge and reorient. Maybe the break prepares them to do better work at the end of the cycle, and makes them super responsive to developer questions/requests.

In addition, if you’ve just started Shape Up, perhaps that lull is the exception and not the rule. Maybe after two or three more cycles, you can have better data to measure.

Regarding the assignment of small projects … I guess that really depends on your company’s situation and how designers are positioned on delivery teams. At our company, our designers have work both inside a cycle as well as outside of it (e.g. customer research, sales support, continuing education, design standards, etc.) We set clear boundaries and priorities for those work streams.

Another idea is to cross-train your designers to support other roles on your delivery team, such as QA, so they can still contribute to the team if there’s not specific design work needed.

For shaped work that doesn’t require design (e.g. API work), I think the easiest fix is to not include a designer for that work, and rebalance the team’s composition in the next cycle to reflect that. (That said, our team is considering some weird experiments, such as teaming a developer and designer to write a spec draft of web services for a key feature in our product.)

I believe the nature of variable scope is always going to create natural ebbs and flows in work, and I personally would try to live in that flow rather than try to boost utilization levels. I know some see underutilization as a bad thing, but running at 100% all the time can also be just as (if not more) harmful. Sometimes designers need time and space to do their best work.

Best of luck! Happy to answer any other questions.

2 Likes
3

Hey Nelson,

First off, thanks for the thoughtful response! You might be right that I’m overreacting to the initial feedback, which isn’t necessarily representative of how the team will operate on future projects.

Re-reading my post, I might’ve given the wrong impression that my goal is to fill the design team’s capacity with specific tasks. By contrast, my goal is to be able to provide direction for designers who are explicitly requesting more work during the cycle. To this end, your suggestions of having them focus on research to support/discover the need for future pitches, or playing a part in QA are both great ideas.

Perhaps we have a bigger problem at our organization in that we don’t have a dedicated Head of Design (I’m the Director of Product) to define and oversee these other “work streams”, but I could certainly make time to put a framework in place that the design team can work within when they do find themselves with extra time on their hands.

Thanks again!

1 Like
4

Hey @samsles,

There’s nothing wrong with “assigning small projects” when people don’t have enough work and they are asking for more. That falls neatly within the framework of shaping and betting. The key thing is to be strategic about it rather than reactive.

1 Like
5

Hey Ryan, thanks for the response! To provide a bit more color, the reason I’m wary of assigning small projects to the design team mid-cycle is that the dev team seems to be occupied with their projects, so there wouldn’t be anyone to handle development on the small projects until cool-down or as part of a small-batch team’s workload in the next cycle. Maybe that’s not a problem, but on the surface, it feels like we’re either circumventing the betting process and pre-committing to future work or creating a backlog. Am I overthinking this?

6

Hey Samsles,

Two things stood out to me that may be responsible for your design team’s work bulking at the start and end of a cycle.

Perhaps they’re designing too much up front, causing a gap in the middle where dev is building everything. And then they’re only able to review at the end when it all comes together.

What if, instead they only design just enough at the start for a dev to begin. For example, they can inform engineering of the affordances a user would need on a page, but not the styling or exactly how it would work. E.g. a user will need to toggle something, but I haven’t decided yet if it’ll be a radio button, a checkbox or something else.

That way front-end devs can begin working and design still has more decisions to make while that’s happening. So instead of design the whole scope->build the whole scope->review, follow the same process but broken up into smaller iterative chunks.

Design enough for dev to start a scope -> start building that -> review so far -> design more -> build more -> etc

Hope that makes sense and helps! :sweat_smile:

7

Ah, I understand. Yes I can see why you wouldn’t want to commit to building out the front end of something when you haven’t bet time for the back end. No, that’s not overthinking.

We can’t get into the fact pattern for your situation here, but I would suggest looking into why the work is lopsided. Eg: is it more like an iceberg, where there is very little UI complexity but lots of back-end work? And look into whether that is persistently true or if it’s a temporary situation.

Shape Up as presented in the book works better when you are in a more “layer cake” situation where the surface area of the UI and the surface area of the back-end work are closer to each other. If you have a consistent imbalance in the type of work for each project, it may be that dedicating a designer to the cycle team doesn’t make sense. In that case you may want to design a different structure where the designers roam across teams or work outside of the bets.

2 Likes
8

Hey Aylon, thanks for your response! I think what you describe is at least partially a factor. Pre-Shape Up, our design team’s process could best be described as “waterfall-like”. They are used to handing over high-fidelity work all at once. While they have naturally moved away from this model now that we’re using Shape Up (we’re sharing a lot more wireframes these days), we could certainly stand to move farther in the direction you describe.

9

Thanks, Ryan. Honestly, this is our first cycle where the entire design and engineering teams are participating (we ran a pilot with one team last quarter). We’re still figuring things out. We’ll probably experiment with a few approaches, e.g. a roaming design team, assigning designers to research that informs future pitches, emphasizing delivery of low-fidelity designs so that the team is continuously engaged in a deliver-review-iterate cycle, etc. At least I have plenty of options to play with :slight_smile:

1 Like