How will we arrange for integration across product lines?
There is no simple answer to the problems of improving integration across product lines. Actually, there are reasons to believe that such integration might work better in the new structure than in the old one, in contradiction to the appearance of a stronger split between the products. Before attempting to prove that the new structure will work better, however, it is worth reflecting for a moment on how well integration works across products now, to see how difficult it will be to at least maintain this level of quality in integration.
In the current structure, Autosketch, Autoshade, and AutoCAD programmers all sit very close together, all tied organizationally through a VP of Software Development. Surely, this is an environment that would foster tight integration if any could. Yet even the most generous spectator would have to say that the integration among these products is weak. It would seem that organizational boundaries are not the problems most fundamentally responsible for poor integration; the difficulties lie elsewhere.
The new structure has a number of incentives for improved integration: simplest is the profit motive for the GMs of being able to cross-penetrate the customer bases built by the other product families. The part of the new structure that may produce the most interesting results is the creation of a body of people whose major focus is on product integration: the Executive Review Board. The members of the Review Board will focus more attention on these matters than ever before, simply because so many other responsibilities have been removed from their shoulders in the new organization.
How do we straddle the line between Research and Development?
A classical question for all high-technology companies is: What is the relationship between research and development? Here the question can be phrased: What avenues does the new structure offer for different kinds of research to support different kinds of development?
The new organization has at least three different ways research and development can cross. There is the Advanced Technology organization: in addition to developing wholly new technologies, the Advanced Technology group also plays a role in developing technologies that need to be shared among product families, as described earlier.
A GM can also start an in-house R&D effort in support of the milestones and goals agreed upon with the Executive Review Board.
Also, Developer Services can undertake short experiments which can be singled out for further development when they bear interesting fruit.
One of the problems in our current organization is that, to start something new and different, you need a massive level of consensus, including in principle the VP of Tech and the VP of Marketing. In the new structure there will be fewer people you need to get consensus from, and in some cases there may be alternative routes to achieving the same goal because there may be several different GMs you can interest in the idea. For example, you could initiate a pen-oriented development effort by convincing either the PM of AutoSketch (who could include a pen-oriented enhancement in his/her next release), or by convincing the GM of the Retail business unit (who could start a new project, perhaps by splitting the AutoSketch line into two lines), or by convincing the GM of the Information business unit, or by convincing the sequence of people needed to start the project in Advanced Tech. All of these organizations become centers of action, rather than centers of veto power.
How do we improve communication between groups?
No matter what structure you build, there are groups between which communication is difficult: you can't put everyone in the same building, and you can't put everyone in the same room for every meeting.
The new organization will improve communication between marketing and technical people who are working on the same product. This communication has been in disrepair for such a long time, it seems like a most urgent need in the company. It may well be that, in another eight years, it will be time to reorganize again to repair the communications which are less effective in the new organization (which at that time will be ``the old organization'').
Doesn't this company already have too many rules and regulations inhibiting operations? Isn't the idea of having yet another bunch of guideline documents the antithesis of a successful company?
Actually, it is difficult to tell whether the company has too many rules and regulations. They aren't written down, and as a consequence, not only is it easy to make up new ones on a regular basis, it is impossible to tell how much the new ones have complicated the system--you can't even see how thick the stack of pages is to ascertain how much pruning we need.
Guidelines can give people power as well as taking it away, particularly when the guidelines explain why one approach is better than another. There are companies in the world that have policy manuals and are still dynamic. There is risk in writing guidelines; but there is risk in leaving it all unwritten, as well.
What if the number of policies (as opposed to guidelines) begins to grow and become an impediment? Doesn't this always happen eventually?
Since the policies will require Executive Review Board approval, they are not likely to grow in number very quickly. Indeed, by the time they grow to the point of being an impediment, it will probably be time to restructure the company again anyway.
If they grow faster than expected, we'll be aware of it because the policy book will get thick. At that point we can implement additional impediments to the growth of policies, things such as sunset laws, and requirements that at least two members of the Executive Review Board be able to quote all the policies from memory, and that any policies forgotten in quotation are stricken from the books.
If one product family has a down quarter, what effect does that have on other product families?
It must not have any effect on other product families. One could construct a scenario in which it would be best for a company to restrain the product families that are on plan when a key product family has trouble; but not Autodesk, not now.
Editor: John Walker