Working around process bandwidth bottlenecks

For most of my first year at Cozy, the engineering team was rebuilding the application. The UX and code we had was, hmmm, not good. It wasn’t serving our customers and wasn’t maintainable in any way. We were working as fast as we could to add enough functionality to a new app/codebase so we could turn off the old one.† This led to a logjam of design and product “priorities” that simply weren’t going to get worked on.

I was asked by one of our designers how he could be most helpful to the rebuilding effort.

Oh, that was simple. Stop working.

It’s harsh, but think about it. Everything that was designed would need input and review. Worst of all, it would end up on a shelf, because we weren’t going to build it. The additional design put stress on the overall system. You can imagine the antagonistic environment created by explaining, over and over, how maybe that is a good idea, but in any case we are not going to do it, maybe in 6-12 months, and I really need to get back to solving critical problems.

When we looked at the entire product value stream, it was clear that the most productive thing for design and product to do was to be as responsive as possible to the engineering team, not design new work. They could also be very valuable by doing strategic work like product research, or supporting functions like QA.

Later on, we had the inverse situation, where we had one designer for an entire engineering team. We had three main ways of coping:

First, I tried to make sure the designer is focusing on one or maybe two things at a time. Avoid the cost of context switching!

Second, I focused engineers on non-feature tasks that appealed to them, especially performance, cleanup, stability, and building new capabilities.

Finally, I asked engineers with a strong visual eye and product sense take some liberties with their solutions. They would consult with the designer at the beginning, and then had to just make it work. Usually what they made was ‘good enough’ after some polish. Sometimes it required a do-over. It was never efficient for the engineers, but they weren’t the bottleneck.

In both these cases, there was pressure to “solve” problems by introducing process. In the case of an engineering bottleneck, there was an effort to “button up” designs more before they reached engineers. This led to extra features being designed. It also led to engineers being involved less in the design process (“let them focus”) or more (“validate designs earlier”). Any of this would have slowed down engineering.

In the case of the design bottleneck, frustration with rework led to engineers requesting requirements documents. Frustration with the way things looked caused some folks to ask for pre-launch design reviews. Any of this would have slowed down design.

I’ll pull a dangerous maneuver and use some formulas to explain how I see the slowdown working, and why it is so alluring.

Let’s say that we have 5 “units” of design production but only 3 “units” of engineering bandwidth to implement them, resulting in 2 “units” of wasted design due to the engineering bottleneck: 5 design units - 3 engineering units = 2 bottleneck units

If the additional process introduces, say, 20% slowdown to design and 10% slowdown to engineering, you end up with a smaller bottleneck: (5 * 0.8) design units - (3 * 0.9) engineering units = 1.3 bottleneck units.

Well, great, you’ve halved your bottleneck. I guess this is why I see so many companies add process and call it a success. It seems better from your position on either side of the equation- less bottleneck is less stress!

But taken at a higher level- looking at the overall value stream- you’ve reduced throughput from 3 units to 2.7 units! You are much better off going down to 3 design units and not introducing any more process. Are you prepared to reduce utilization to increase throughput?

Remember, if you have a bottleneck, the way to fix it is to fix the bottleneck! You can add resources, or take them away. You cannot introduce process that will change reality.‡