The Empire Long Divided Must Unite

Chinese children are familiar with the opening lines of Romance of the Three Kingdoms:

The empire, long divided, must unite; long united, it must divide. Thus it has ever been.

As Ben Horowitz (of Andreesen-Horowitz) says in his new book, The Hard Thing About Hard Things:

The first rule of organizational design is that all organizational designs are bad.

In my limited experience of management organization, which includes taking courses on it during my unfinished MBA, any organization achieves some things and omits others. One way to handle this is not to keep it static forever. Unite what is divided, and divide what is united.

The Corporate CAD Cycle

This reminded me of something that I wrote years ago that somebody reminded me of just recently, something I called 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 7nm 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.

Functional vs. Product Divisions

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 (for sure 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, on my last tour of duty here, we had six or seven full-page ads in EE times from different groups, all product-oriented but with a different look and feel and brand image. I think the logo was about the only thing common. However, if engineering, marketing, and so on are all functionally managed, then they can be very unresponsive to urgent needs in the product groups. I went through an era like that at Cadence where corporate marketing controlled the entire advertising budget and wasn't interested in products at all. That was the era of Cadence advertising in in-flight magazines with things like the "curfew key" and other futuristic electronic devices. But you could barely discover what Cadence did from those ads.

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. The empire, long divided, must unite; long united, it must divide.

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.

Three Envelopes

Which reminds me of an old CEO joke. That's like a "dad joke", just not as funny.

The CEO of a company gets fired. The incoming CEO finds a note from the fired CEO, and three sealed envelopes. The note says that when the board is getting restless, to open the next envelope. Well, the old CEO didn't leave the company in great shape so almost immediately things are not going well. The new CEO opens the first envelope. "Blame the previous CEO." Of course, at the next board meeting, the new CEO blames the mess he inherited from the prior CEO, and since the board had fired him, they have to agree. Things start to improve, but a year or two later, there is a bad quarter. The CEO opens the second envelope. "Centralize everything that is distributed and vice-versa". So there is a big re-org, and the functional organizations are all blown up and replaced with product divisions. This buys some time. but after a few more years, things are not looking so good. The now-not-so-new CEO opens the third envelope and reads the card: “Prepare three envelopes”.

Sign up for Sunday Brunch, the weekly Breakfast Bytes email.