Many things in business go in cycles. One in EDA is what I call the “corporate CAD cycle”. It goes like this. I’m sure a similar dynamic plays out in other industries too.
A large multidivisional semiconductor company has dozens of products in development. They have management who decide that the best way to hold groups responsible is to give them complete control of their destiny. Each group decides what its design methodology is going to be, purchases tools and is generally pretty successful at getting their products out. Life is good. Then one day someone in finance or corporate CAD notices two things: the amount of money that the company is spending on tools is very high, and secondly the various groups have made different tool/methodology decisions and so it is much more difficult than it should be to move around people (need re-training) and pieces of designs (wrong formats, wrong standards). The first phase of the cycle has ended.
A decree goes out. Corporate CAD will make corporate-wide volume tool purchase and decide what should be the standard flow. The standard flow will be mandated throughout the corporation, no exceptions. In a fairly short time the big problems are fixed: the tool budget is slashed now that experienced purchasing agents are negotiating very large deals with just a few EDA vendors; moving people and blocks around is simpler since everyone has the same base knowledge. Life is good. The second phase of the cycle has ended.
But management notices that many product groups are being a lot less successful at getting their products out than they used to be. This is a huge multi-million dollar problem. Management takes a look at the most important bet-the-company product. The product group says they are forced to use the wrong tools, that they are spending too much time getting blocks into corporate formats that they don’t use themselves, that they have too few licenses. But this chip is critical, so just this once, since the group is really expert, they are allowed to buy whatever tools they need to get the job done. Of course when corporate CAD said there were no exceptions to the standard flow, they weren’t that stupid. Of course there were exceptions for RF. And the advanced group over there that is doing a pilot project in 45nm obviously needs some tools that are different. Oh, and we just acquired a little fabless semiconductor company who uses something non-standard, we’d better let them at least get their chip out before we force them to use the standard flow, it’s hard enough for them switching to our process. Gradually the iron grip of corporate CAD relaxes. Corporate CAD makes big purchases, but a lot of those tools are sitting on shelves. Design groups are largely making their own decisions about tools. Chips are coming out successfully again. Life is good. Then someone in finance…
This cycle seems to re-play itself in many areas where two contradictory goals collide. In the CAD case above it is the need to have a standard flow, but also allow exceptions when the standard flow is not enough. Of course I exaggerated the story a bit, but the basic cycle between giving too much freedom and not enough seems to be real and I’ve seen a version of the cycle play out in many semiconductor companies.
One other area with this sort of cycle is whether to manage functionally or along product lines. Should a large semiconductor or EDA company (or anyone else for that matter) run engineering as an organization, and then have project managers for each product? Or should a product be responsible for all its own groups? Engineering, marketing, finance (probably not), sales (maybe). There are problems with both structures. If product groups are self-contained (even if they don’t have dedicated salesforces) then there is no control of corporate brand image, little standardization of development processes and so on. At once point when I was in Cadence years ago, we had 6 or 7 full-page ads in EE times from different groups, all product-oriented but with a different look and feel and brand image. However, if engineering, marketing and so on are all functionally managed then they can be very unresponsive to urgent needs in the product groups.
The way this seems to play out is to be functionally organized for a few years, then when that seems ossified, become structured into business units or product groups for a few years. One reason that I think that this can actually be effective, not just management churning, is that the relationships from the previous era endure, at least for a couple of years. If you were previously in marketing for a product group, and now you are in the company-wide marketing organization, you still know all the engineers that work on the products you care most about; after all, only a year ago you were all in the same organization. When eventually you get blown part back into product groups, you still know everyone in marketing, you know in your bones the corporate look-and-feel, branding and so on, and it takes a couple of years to gradually forget (as an organization, with people coming and going, more than individuals actually forgetting).
So there really is something to the old management canard that, when you don’t know what to do, centralize everything that is distributed and distribute everything that is centralized.