Ryan Singer

April 9, 2021

8. Team Integrated and Team Modular

A Shape Up reader wrote an email asking:

1) I work for a company building custom software for different clients. Many times our clients don't have the budget to pay for full-time programmers and designers for six weeks  . . .  the cost is kind of high for a small business.

2) How do the roles of frontend and backend work? What if a project needs only 2 programmers and design isn't so important?

At first I recoiled with assumptions: How could it be that design "isn't so important?" Isn't integrating design and programming at every step the One True Way to make great software?

After I paused to think, a surprising fact came to mind. I'm actually in the same boat on my own side projects. Budget is low in time and money. I end up doing most of the design up front. The programmers work without a designer (me) during cycles, because I have a day job and can't be there to collaborate.

I've been thinking a lot about integration vs. modularity lately (see the previous newsletter). And using Tailwind on a side project has made me reflect on the modularization of design. A light bulb went off. This is exactly what Clay Christensen was talking about in Innovator's Solution. Whether to integrate design and programming on a given piece of work depends on the outcome and performance you're trying to achieve.

Here's what I wrote:

My instinct is to work backward from what you are trying to sell.

Suppose we define two ways of working:

Let's call the first one "Team Integrated." One designer and one programmer work full-time on a single project for six weeks. They collaborate intensely as they go.

The second one is "Team Modular." One designer creates a concept for one programmer to build. The designer gives it to the programmer and walks away. The programmer implements the concept alone using a UI component library like Tailwind within a time budget.

These are both valid. They have different trade-offs.

On the cost side, Team Integrated is way more expensive. On the outcome side, they can do two unique things:

1. Team Integrated can change a concept mid-flight as they encounter problems. They aren't dependent on just the initial concept at kick-off. This gives them more chances to find the right solution the first time around. They don't have to wait until after the work is built to say "Hm that didn't work, let's design something different."

2. Team Integrated can build new things that off-the-shelf components can't do. We couldn't build something like the Hill Chart feature in Basecamp without close back and forth between a designer and programmer.

Team Modular has very different trade-offs. It's far cheaper. The designer is free to do other things while the programmer builds. In response to (1) above, Team Modular can say "yeah the concept might not be right ... but we can afford to rethink it and do another cycle in the future to improve it." In response to (2) above, Team Modular might say "Who needs that? There is so much prior art on this problem. And Tailwind does everything we need."

At Basecamp, we chose Team Integrated because (a) we want to sell novel never-done-before things. Component libraries won't cut it. And (b) we differentiate on UX and we can't get all the details right unless a designer is involved at every step.

I have a side project right now where I chose Team Modular. I don't have another designer and my time is limited. I'm shaping projects with a lot of intent up front — and more concretely than I would do at Basecamp — and the programmers do their best to implement in the six weeks. I end up having to sometimes re-do an entire feature with a whole separate cycle, but that's fine because I just don't have the time to be involved and catch problems like that earlier.

Does that framing give you any ideas?

The questioner replied: 

Wow this is really helpful! Thank you so much!!

I asked:

Can you tell me what's helpful?

And he replied:

The modular concept. I think it will work for us and bring the cost down.

Framing this question as an explicit trade-off, with different costs and benefits in different circumstances, is far more helpful than my former stance — claiming that the type of work I like to do most is the best way. I'm energized by the realization that Shape Up is also applicable in places where design isn't integrated throughout the cycle like it is at Basecamp.