Identified the Bottleneck

I’m pretty sure I’ve identified the bottleneck for CS. It was done by going through some case studies and thought exercises. Of course, this is my own opinion and CS is a big beast. So I should get some other opinions. Before going into the bottleneck, let’s discuss some things left out in the original post.

First off: Bugs are inventory. That may seem counter-intuitive in some sense since the defect itself isn’t a net positive resource for the project. However, consider the fact that bugs are work items that need to be addressed prior to shipping the product. They are one of two outputs of testing (the other being a certified build) and feed into the rework process. So bugs are inventory. Given the fact that many projects find themselves in months of rework to address bugs, it seems pretty clear that rework to address bugs (or BRCs to defer them) are another possible bottleneck. They could be one of the biggest. In our case, I think that bugs are one of the issues that will eventually become a constraint; but, there are tighter constraints right now than bugs.

Secondly: Yet another bottleneck could be outside the software engineering process per se. The bottleneck could be (indeed, on further contemplation I believe it is) outside the engineering group. Earlier I dismissed the idea of using unit sales as a way of measuring throughput since I wanted to focus on engineering issues. However, focusing on engineering issues only is really a detriment to the system as a whole. Let’s take another look at throughput.

According to the definition given by Goldratt, throughput is the “rate at which the system generates money through sales.” The emphasis comes from the author and he stresses that the definition is worded precisely. So let’s rethink our throughput as money generated from selling software.

After going through numerous case studies and a couple of thought experiments I believe that the biggest bottleneck is really the business model that Adobe uses for its Creative Suite. A second bottleneck is the deployment cost of new releases for our customers. Luckily, in both cases Adobe is trying to address these bottlenecks. I don’t believe the bottlenecks have been elevated appropriately, though.

The fact that the business model is the biggest bottleneck was really staring me in the face. I’m embarrassed for not seeing it immediately. There’s so many data points or case studies that point to this fact. By business model in this case I mean the terms of our licenses, the technology used for licensing and the deployment methodology. Deployment is included here because it is an implicit component of our license agreement. Without getting into confidential information, here’s some salient points:

- Our highest call volume generators are related to the business model. Licensing (and in some cases deployment) is the bane of our customers. I’ve spent significant time in the last year advocating putting in place an engineering team (led by me, of course) that would focus solely on the business model needs. I’ve got that team now and its taken almost 15% of my time this entire year (yes, I keep careful records) just to get them started. It will be my biggest effort in the coming two years. This is the OOBE-1 project, for those interested and familiar with some details of how Adobe does business.
- Many large sales are blocked by our licensing model. Lots of examples can be given here, though in the interests of confidentiality I’ll only mention that education sales have been limited frequently in the last two months because of our business model. The perpetual license or inflexible expiring license is costing us sales.
- Enterprise sales are blocked by our business model in two ways. Cost of purchase must be justified before the enterprise customers will actually purchase a new version. Even more important, the cost to deploy our software is much too high for enterprise customers.
- Many software releases are ready to ship but blocked due to business constraints. Although the business model isn’t the cause for every piece of completed software that we don’t ship, it is the most common case. In other cases the constraint is still on the business side; but, not necessarily easily traced to our business model. Examples just from the last three months on just my engineering teams include CSXS SDK, new Extension Manager versions, and new Configurator versions. I’ve heard complaints from other engineering managers for years along the same lines. Revenue recognition rules based on our business model legally block us from making releases of valuable solutions to customers and it sucks. This is one of the primary reasons why I think engineering is not the most important bottleneck for CS.
- It is entirely possible to shorten release cycles for our products, including the Suite itself. We could easily shift gears and release the entire Suite every six months from an engineering perspective; but, the business organization isn’t prepared for such a change. Nor do our customers want major releases every six months. Its too expensive for the customers. However, if we did release the Suite every six months each release would have far fewer features; but, over time there would be more features and more appropriate features within the products than you see today.
- Projects are killed because they don’t easily fit our business model. The project could make money and they could be implemented at a reasonable cost. In some cases, that cost in so incredibly low that its quite clear it isn’t the additional cost of engineering that is the bottleneck.

The good news is that we’re already putting some attention on the business model. I don’t think its recognized as the largest constraint for CS from a TOC point of view. That’s my next evangelism task – which can hopefully be done well before I return from sabbatical.

Another good thing is that the entire organization is set up to work at the pace of the business model constraint. We can clearly do better. For example, we don’t have extra capacity in non-bottleneck areas. And as you can see above, we are most definitely not optimizing our bottleneck.

One thing I really like about this sabbatical is that it allows me to really walk away from the day-to-day concerns of leading engineering teams and do some work at a more conceptual level.