|
|
The first four recommendations I made for turning around Autodesk in Information Letter 14 implied reorganising the company around product line profit centres rather than overhead functions such as Development, Marketing, and Sales (see page
). The management response to Information Letter 14 began with a top-to-bottom reorganisation of the company into “business units” focused around principal product lines. Unfortunately, management's response to Information Letter 14 basically ended with the reorganisation. On June 16, 1991, Marc Stiegler, who had served as the chief architect of the reorganisation, laid it all out in a paper titled “The New Autodesk,” accompanied by a 39 page booklet of organisation charts. Reading between the lines with the benefit of hindsight, one can see how this plan contained the seeds of its undoing. The U.S. domestic sales department and all the overseas territories remained independent of the product organisations (due to intense lobbying by the managers affected). The product organisations still could not, therefore, shift the attention of the sales organisation away from easy AutoCAD revenue onto emerging products and markets. The structure also reinforced the passivity of senior management, removing it one level further from a position of overall leadership and instituting an “Executive Review Board,” whose major function was to adjudicate squabbles between subordinate organisations, not to plot the grand strategy of the company and see that it was implemented, as senior executives are supposed to do.
Overall, the organisation Marc proposed was not inherently flawed and was certainly an improvement over the “Old Autodesk.” The reality was, though few people had yet realised it—certainly not me—that no structural change in the company could turn Autodesk around without a change in the way senior management led the company, or a change in personnel at the top. With the right people, it could have worked. With the wrong people, it was foredoomed.
The creation of the Americas territory in December 1991 returned many of the marketing functions to a central overhead organisation, effectively undoing the essence of this reorganisation.
by Marc Stiegler
June 16, 1991
Now it's time to consider whether Autodesk has become stuck in the past; whether it's time for Autodesk to change and how. The changes may be unpleasant to contemplate and difficult to carry out, but they may be just as necessary and, if successfully made, as rewarding.
— John Walker, Information Letter #14
There never has been, and probably never will be, a “best” organization for a company with hundreds of employees. There are only organizations which are better for a particular company for a particular period of time. The restructuring along product lines proposed here is intended to serve Autodesk better during the coming decade would simple growth-by-accretion on the current structure.
This document describes a framework for product line oriented structures, as well as a proposal for how the framework could accommodate the new Autodesk. It starts by discussing four problems that the new structure might solve; continues with the goals of the restructuring; and then goes on to discuss the organizational components of the new structure and the functions of the people in it. The document ends with a set of questions and answers; some of the answers duplicate material in the document, but they also help explain why the proposed restructuring might successfully solve additional problems.
Some people may agree with the idea of moving to a product-line structure simply because John Walker proposed it in Information Letter #14. Some people may agree simply because this organizational structure has served other companies, such as Microsoft, so well. Some people may never agree with it until it proves that it works. For most people, however, the key question may well be, “Why does a product-line structure work so well for companies like Microsoft, and why would it be better for Autodesk?”
To partially answer this complex question, I list here several current and near-term corporate problems that a product-line structure could solve.
Currently, virtually every department in the company is an overhead center, from programming to technical writing to marketing to manufacturing. Eventually, all such arrangements breed inefficiency. When swift shipment and low cost are of secondary importance, as they are in overhead centers, the entire department's focus slowly shifts from doing the job quickly and effectively to doing it perfectly, with decreasing regard for how long it takes or how much it costs. Worse yet, the meaning of “perfectly” also shifts, away from a customer's definition to one that reflects the priorities of the overhead center.
This is not an indictment of the people who make sincere efforts to make the system work—it is an indictment of the system itself. The Federal Government is the shining example of this: there are many excellent people who work grueling hours in the government yet cannot point to any worthwhile national achievement. Over the long run, such an overhead operation is the breeding ground for slowly deteriorating effectiveness.
At Autodesk, the Tech budget for FY 92 is 43% larger than Tech costs were in FY 91. Yet it is difficult to determine where the money went. No one can look at Tech and identify a 43% growth in productivity or effectiveness. On the contrary, almost every product seems to take longer to deliver than ever. One can look at each project and explain why it's having problems; one can also look at each expenditure and say why it hasn't paid off with more products yet. But if one does this for every project and every expenditure, one winds up suspecting that there may be a forest behind all those trees.
By moving more activities from overhead centers into product lines with direct profit-and-loss responsibility, we redefine success and failure in customers' terms—the most effective way of consistently leading and winning in any marketplace. Even if we believe that such a redefinition is not needed today, it seems likely that it will be critical to our success in coming years.
With the current structure, neither the success nor failure of any product can be credited to anyone. This has peculiar ramifications in the case of failure: suppose the manager of a software development project hires such a large staff for a project that, when the product ships, it does not generate enough revenue to pay for the staff. The marketing people are not to blame: they sold the product well and brought in lots of money. From their point of view, they succeeded. Meanwhile, from the software manager's point of view, he/she also succeeded: the product shipped on time, with all the features customers could want.
Certainly, the software manager and the marketing people wanted the product to succeed overall; they are sincerely interested in the company's success. But when push comes to shove, they also must consider first that part of the puzzle for which they are responsible. Here, every individual was a success, yet the company failed.
By moving responsibility for profit and loss into the hands of a product manager whose total focus is the total success of the product, we ensure that someone takes credit for its success…or its failure.
Arranging to do an AutoCAD port to a new platform (even to “just another UNIX Box”) requires a tremendous amount of consensus-building. The VP of Marketing cannot initiate a port on his own—he needs the support of the VP of Tech. Similarly, the VP of Tech cannot initiate this action on his own either—if the VP of Marketing won't support selling it, it hardly makes sense. The lowest level person in the company with all the authority needed to do a simple port is the President.
By giving the AutoCAD family a general manager with authority to initiate marketing and development, we eliminate one or two levels of management overhead. Achieving a consensus of many participants will remain important, but giving GMs authority eliminates many potential decision-making bottlenecks.
This is a very important improvement, since decisions need to be responsive to rapidly changing market conditions. Breaking out the AutoCAD family into multiple products, each with individual profit-and-loss responsibility, could reduce even more management overhead for many decisions. By making product managers responsible for profit and loss, we give them a better yardstick for success than any higher manager could supply. (And, at the same time, we get higher management out of the role of trying to act like market forces themselves).
Microsoft's multi-year product plans have been lauded for their excellence. What does it take to do this kind of planning?
First, it takes both marketing and technical people, standing toe to toe, figuring out what the product means. It takes a leader who is totally focused on the long-term, overall success of the product. And it takes incentives for the leader and the marketing and technical people to put it all together into a plan. The product manager is the leader: in the product-line structure, he or she has the resources needed to develop a plan; the negotiation with the Executive Review Board over development and profitability targets (described below) is one of the incentives to develop it.
At the highest level, the goals of this restructuring are: Making the company more responsive to opportunities in the marketplace.
Making the company more effective in strategic planning.
Giving diversification efforts the level of attention they deserve.
These goals are achieved through the following supporting goals of the restructuring:
Moving authority and accountability closer to the actual work. This makes the company more responsive to the needs of customers.
Shifting the company's focus from technical or marketing success to the life-cycle success of a product. This facilitates strategic planning for the product, and improves responsiveness by boosting the chances that the response will be effective. By focusing on the life-cycle success for new products from their inception, we also improve the chances for the success of new products, which is critical to diversification.
Guaranteeing that there is at least one person who is dedicated to the comprehensive success of each individual product. Again, this improves planning, responsiveness and the chances for the success of new products.
Removing upper management from the details of product planning, freeing them to focus on corporate strategic planning and selecting opportunities for diversification.
Improving communication between technical and marketing people on individual products; this improves responsiveness.
Giving people the authority to succeed, which again improves responsiveness.
This proposal identifies the following three types of organizations which can comprise most parts of a product-line oriented company:
Business Units
Service Centers
Corporate Functions
Business units generate revenue; the individuals responsible for the business unit are accountable for its long-term profitability. In a homogeneous environment like the U.S., the product lines are the most obvious examples of business units, although there are other organizational units, such as foreign subsidiaries, which are business units as well.
Service centers supply services to the business units and bill back the costs. There are at least three reasons for having a function provided by a service center rather than by the business unit itself.
First, the level of service a business unit needs may vary significantly over the course of its work cycle. It would be inefficient to have the business unit hire a full-time staff capable of handling a peak load; it makes more sense to staff the service center with people who can move from project to project as needs change.
Second, providing the service may entail special equipment. If the equipment is expensive and is not used to full capacity by any one business unit, it doesn't make sense to have other business units duplicate its purchase.
Third, the service may maintain a corporate standard. The reliability with which the standard is maintained could be increased by having all the business units share the same service center, which would specialize in completing the work in a way that maintains the standard. If a service center exists to maintain a standard, it should publish a guideline document which describes how business units that cannot use the service center (for example, physically remote business units) can maintain the standard.
In each case, the advantages of having a business unit use a service center must be traded off against the advantages of having dedicated members of the business unit do the work.
Service centers and business units would usually interact as follows. The business unit needs a service. The service center estimates how much it will cost. If appropriate, the two organizations negotiate exactly what service is actually provided and what it actually costs. The business unit gets billed for actual costs accrued by the service center.
One attractive aspect of a service center is that the agreed-on costs negotiated with each business unit justify the service center's budget to acquire additional resources. As a result, questions attempting to justify percentages of budget on a macro scale (e.g., “What percentage of the R&D budget should go to QA?”) are replaced by smaller, simpler questions. In addition, the direct billing gives the business unit the incentive to use the service center wisely.
The person in charge of a service enter may, in practice, hold a title such as manager, director, or VP; in this document the generic term functional manager, or FM, is used regardless.
The corporation as a whole picks up those functions which cannot be provided by business units or service centers. For these functions, it's either difficult to make billing a meaningful incentive to use the service (as with finance and accounting—it's not clear how to meet legal requirements for accounting if every business unit contracts an outside accounting firm), or so dangerous to the company if business units don't use the service that there's a need to eliminate all disincentives for using it (as with legal, as discussed later).
The number of corporate functions should be minimized. This is where bureaucracy grows, since the incentives for keeping lean and mean are so weak. If someone comes up with an interesting idea for how to turn a corporate function meaningfully into a service center, we should go for it.
A product line includes most people who work full-time on a product, including that product's programmers and marketing people. Since there are quite a few projects at Autodesk that could conceivably become separate product lines, it makes sense to group them into product families. Each product family would have a General Manager (GM) and a General Management team. Each product within the product family would have a Product Management team, with the Product Manager (PM) reporting to the General Manager. The General Manager would report directly to the President of Autodesk.
In the simplest case, the General Manager would have the following responsibilities and authorities vis-à-vis product managers:
The General Manager negotiates with the Product Manager on the product's target profitability, taking into account the development needed to position the product and the family for long term success.
The General Manager may break a single product into multiple products, or merge multiple products into a single product, as he/she deems appropriate for strategic reasons.
In this simple case, the GM and the PM do not need daily contact, as most of the authority resides with the PM. In practice, this relationship will often be built on a product-by-product basis. For example, if a product is allowed to run at a loss, because the GM sees a strategic advantage to the product family, the GM and PM probably need to work out a relationship which very clearly guarantees that the GM's strategic purpose is being fulfilled.
Also, because in the simple case the GM does not have much work to do, GMs would frequently double as PM for one of the products in the family. As a rule, no one should act as PM for more than one product—the purpose of the product-line structure is to guarantee that the total success of each product gets the total dedication of at least one person, and having one person act as PM for multiple products defeats that purpose.
The following are proposed assignments of products to families:
The AutoCAD family could include the following products:AutoCAD itself
AME
AutoshadeThis is only one possible breakout: the General Management team for the AutoCAD family has the authority to make the final breakout decision. At this time, the breakout of AutoCAD into products is so undecided that the breakout listed above does not match in any recognizable way the functional chart which accompanies this document.
In creating product lines, one usually wants to break a family into as many independently profitable products, with individual accountability, as possible. However, just because a product can have a separate price tag doesn't make it an independent product. A good example would be an ADS application that generates IGES files. Such an application could be priced separately—but its profitability is irrelevant to its success because IGES's main purpose is strategic, to help AutoCAD penetrate markets where IGES is required.
One could also make a case that Autodesk sells AME and/or Autoshade for strategic reasons. If these products get bundled with AutoCAD, their profitability no longer matters, and they should cease to be independent product lines.
In the end, the General Management team will make these decisions.
Multimedia is already broken out, at least at the GM level, like a product family. It would include Animator, Animator Pro, and 3D Studio. One interesting question is which product family the Science Series product line should belong to; this is one candidate.
This would include Generic CADD, GenCADD, and AutoSketch. This family is also a candidate as the home for the Science Series.
This would include all the Hypercube products, including Hyperchem, HyperNewton and HyperNDO.
This would include Xanadu and AMIX.
The only other organizations that clearly should be business units are Autodesk's foreign subsidiaries. Other organizations that could become business units are noted in later sections.
There are several new types of service centers needed with a product-line structure, and there are interesting questions as to which current Autodesk departments become service centers, which remain as corporate functions, and which get incorporated into product families. Before answering these questions however, there are additional features of service centers that deserve discussion.
Exactly what does the business unit get billed for when it uses a service center? There are parts of a service center that might reasonably be left as overhead, i.e., not billed to the product lines.
Before running through the possible distinctions between billable and nonbillable items, we should review the purposes of making a service billable. One purpose is to encourage the service center to be more efficient in its handling of business unit requirements; the other purpose is to encourage the business units to use the services efficiently, for example by preparing materials in a way that the service (whether it is an in-house service or an outside service) can cost-effectively digest.
Given these purposes, an exact accounting suitable for the SEC is clearly overkill.
Should the cost of the computers and other capital equipment used by the people in the service center be billed back to the product lines? In this proposal, the answer is yes: this becomes the basis on which the functional manager justifies his/her capital equipment budget.
Should the basic facilities costs be distributed across the employees of the service center and then billed to the product line? The proposed answer is no: it is not clear that it adds to the effectiveness of the incentives, and is easier for accounting to track if left out.
Many of the service centers have a certification aspect to their activities, including as a minimum the development of guidelines for product lines that are unable to use the service center. Should the cost to develop such guidelines and certification activities be billed? The proposed answer is no: this is geared toward a corporate goal. The organizations that most use the service center are the ones that least need the guideline document; it would be very distorting to the incentives to bill the users of the service to support the nonusers of the service.
If we create a team inside the service center to improve the operation of the service center, should this cost be distributed and billed? The proposed answer is no: once again, such work contributes to corporate long-term goals, not immediate product line goals. The success of such efforts should be measured based on milestones and end results, as with other development projects.
Should the cost of the manager of the service center, be distributed across the employees for billing? The proposed answer is that this be decided on a case-by-case basis, depending on the extent to which the manager of the service center works on corporate goals versus individual product goals (i.e., what percentage of the time does the manager spend worrying about guideline documents and facilities as opposed to nurturing specific relationships with product lines?).
Every service center has a number of odd cases which should be reviewed for operation as overhead or as a billable service. The functional managers should develop proposals for the Executive Review Board (described later) for deciding on the exact breakout.
How do we determine if the service centers are doing a good job? The answer may cause a moment's anxiety for members of service centers who have come to believe that bitter adversarial roles are a necessary part of their lives. The good news is that there are examples in the corporate world of places where such relationships are rare exceptions: it is possible to run companies larger than Autodesk with less friction and fury.
Product lines and business units will be measured according to how well they serve their customers, by measuring profitability. It is appropriate for service centers to be measured according to how well they serve their customers as well. Consequently, this proposal recommends a yearly review of the service centers by the GMs and PMs.
This does not necessarily portend disaster for the service center. Just because one GM or PM is disgruntled with a service center, that is not the end of life for the center, because there are five other business units involved in the review. If all the PMs and GMs do not have a common perspective on a service center, then what is indicated is not the censure of the center, but rather a more detailed analysis. Furthermore, if the vast majority of PMs and GMs are unable to tell whether they're getting good service or not, the company has a much more fundamental problem than the breakdown of communication between product lines and service centers.
There are additional aspects to the review of a service center, including how well the service center maintains corporate standards and how well the service center maintains guideline documents.
Meanwhile, this is not the only forum for communication between a service center and a business unit on how work is progressing. In general, if the GM or PM has a problem with a service center's service, the GM or PM should seek out its director/manager to discuss it. This works the other way, too: the functional manager can seek out a GM or PM if he/she perceives a strained relationship.
If, after the GM has talked with the FM, there is a business reason why the service center cannot effectively meet the needs of the GM, the GM should present his/her alternative plan to the Executive Review Board for acceptance. The plan should include the GM's strategy for maintaining any relevant corporate standards.
As noted earlier, service center should create guideline documents for business units that cannot use their services directly. With the coming of guidelines, an obvious question arises: who has to get permission from whom to disregard a guideline?
The FM of a service center can alter or break the guideline without permission: he/she is, after all, the expert.
The more interesting question is, does a GM or PM need to get permission from someone to disregard a guideline? Here, we should probably define a new term to distinguish between two concepts: a “guideline” is a recommendation which a GM can disregard, accepting the consequences of the action, without consultation; while a “policy” is a rule which a GM must get authorization from the Executive Review Board to disregard.
The purpose of the restructuring is to grant the “authority to succeed” to PMs and GMs; therefore, guidelines are, by and large, the more appropriate mechanism for the company.
Does Autodesk have issues which require policies to resolve? Just in case there are, it makes sense to define a mechanism for creating policies.
Guidelines are created by the service centers. Policies, however, should be created by the Executive Review Board. People in service centers can propose policies to the Executive Review Board—but the Board must make the decision. Before anyone creates a policy, the Board should scrutinize it to make sure that it states the underpinning requirement in the broadest possible terms, rather than as a particular implementation strategy, to maximize the policy's flexibility.
Since a GM can disregard a guideline, it behooves the maintainers of a guideline to list the reasons why the guideline is a good idea. The strength of these explanations will often determine whether the guideline is followed or disregarded.
When a GM disregards a guideline, he/she should be aware that the service center may no longer be able to assist the GM with matters related to the disregarded guideline, i.e., once the process expressed by the set of guidelines is broken, the director/manager of the service center may not be able to support other pieces of the now-broken process.
This organization will be responsible for coordinating marketing between product groups and with our international subsidiaries. They will have responsibility for market intelligence and analysis. Most important, they will have responsibility for correctly positioning Autodesk as a broad-based software company through advertising, public relations, development of collateral, trade shows and other promotional events. They will be responsible for coordinating consistency and worldwide standardization of corporate style and packaging.
This would be a service center of programmers who work on different projects at different times for different product lines. In our current organization, there are times when Dev Test and Build groups act in this capacity, building components for products whose programming staffs are overcommitted and have some tasks which can be done with relatively little spin-up by an extra person.
This service center would also serve a load-balancing function during a product's long-term life-cycle. Because individual products are managed by their own profitability, and funded by their own revenue streams, it is possible to imagine “quiet times” in the development of a product. For example, when a product is released, it may make sense to shift expenditures from development to marketing and shrink the development team during this period. Rather than lay off people who have just achieved a great success, or attempt to hastily find new homes for them, these people can join the developer services center and explore projects with a variety of product lines.
This service center would not be expected to be 100% committed to product lines all the time. As a result, Developer Services could, in its spare time, undertake short projects that might become new products. There seems to be a boundless supply of ideas at Autodesk for objects that could go on bonus disks, or into the Science Series, or into new market areas. Developer Services could develop into a place where these ideas get explored.
Developer Services would be expected to have most of its people employed with the product lines most of the time.
Where should Developer Services report? There are at least three interesting possibilities: 1) the VP of Technology; 2) the same organization as training and support, since short projects are also undertaken by training and support when time permits; or 3) Advanced Technology, which should, in principle, be where the largest number of radically new ideas crops up. This proposal puts Developer Services into the Advanced Technology organization, for the potential synergy with radical ideas worthy of exploration.
There are some challenging questions regarding the operation of Developer Services. For example, once an exploratory project has gotten under way, if a product line needs the services of a person working on the exploration, who gets priority? Clearly, at some point in its evolution, an exploratory project becomes important enough to be worth completing, at least in comparison with some lower priority projects in the product lines. One of the first tasks of the FM for Developer Services will be to come up with a set of guidelines for making this tradeoff.
In this proposal, technical publications would become a service center. Though some of the product lines may employ a number of writers full time, the requirement for writers and for publication production varies over the course of the product life cycle. The publications group also supplies a level of format standardization that gets regular praise from our foreign subsidiaries.
The Build group could conceivably become a service center. If the GMs were to decide to continue to use the Build group as it stands, it would continue in its current form, with the addition of a bill-back process so the GMs and PMs account for how much money they've spent on builds. If most of the build work were to move inside the product lines, it would make more sense for the people remaining in the build group to move to Developer Services, from which they could sell build services along with other software-related services. Even if the Build group were to be completely dismantled, it would be necessary to develop a guideline document for the build process, and to maintain a “certifying agency” that checks to make sure that source and object files track one another, for QA purposes. This certification agency could be independent, run from Developer Services, or what could be more appropriate, the certifying action could be performed by the QA organization, since QA is the group for which the certification is being performed. This proposal suggests putting the build certification process with QA.
Dev Test has a similar relationship to becoming a service center: if the PMs wish to use Dev Test services through a service center, it would continue in its current form. Otherwise, some Dev Test people will go with the products that they work on full time, and the others will join Developer Services.
This proposal assumes that many of the people of Dev Test and Build will go into product lines, in which case the rest would be merged together into the Developer Services organization.
QA is a most difficult case. One can argue that QA should be an overhead function, not a service center: if a product goes out the door with serious flaws, it reflects on the whole company, not just on an individual product. Therefore, it is in the best interest of the company to eliminate any disincentive for using this service, such as direct costing to the product line. On the other hand, such a quality black mark is not as damaging to the company as some kinds of legal problems: as the Microsoft Word 3.0 fiasco demonstrated, you can ship an utterly vile product and still retain your reputation for being the superstar of the industry, indeed without even noticeably impairing your premier status in the market.
It is also possible to argue cogently that QA should be a part of the individual product line. The General Manager's incentives with respect to individual product are essentially identical to those of the President of the company: they are focused on the long-term welfare of the product, and suffer from neither a technical team's natural inclination to ship sooner rather than later, nor a QA team's natural inclination to ship later rather than sooner.
On the other hand, breaking up the QA process would reduce the application of QA standards across the company; and on the third hand, breaking up the QA process might result in some interesting innovations in QA methodology.
The middle course is to keep QA as a service center while we see how the rest of the restructuring plays out. This proposal recommends keeping QA as a service center. Our current QA department supports a number of processes other than software testing, which is the service center part of QA; these other activities may be more appropriately operated as overhead operations. The FM of QA should come up with a proposal on this matter, as discussed as a general need for FMs earlier in this paper.
Technical support would become a service center as it is already divided into product lines.
Training could conceivably become a business unit. This, however, would involve making a change in the corporate strategy, since a profit-motivated training center would want to compete, in some sense, with our distributors. For the moment, this proposal recommends making training a service center as well.
Sales could fit any of the three categories of organizations.
Whether thought of as a corporate function, or viewed as a business unit. the underlying dynamic for the sales group is the commission structure. Commissions take sales outside the breakout into business units, service centers, and corporate functions.
Sales could also be made part of individual product lines. Not having sales as part of the product lines could disenfranchise the PM and GM from a very important part of the process of getting the product into the customer's hands. On the other hand, sales is also the critical point at which the company and all its products are presented to the distributors and customers as a unified family. Certainly, even though sales is kept together as a single organization, it would make sense to have a structure internal to sales that can parallel the product families (i.e., have people in sales devoted to selling each product family).
This proposal recommends making sales a service center. This would allow the PM to trade off marketing expenditures with sales expenditures. Having a structure inside sales that parallels the product families would facilitate its setup as a service center.
This proposal further recommends keeping the retail sales organization at Generic separate from the sales organization in Sausalito, although this situation warrants further review.
For some people, there may be multiple, functionally similar locations in the new structure for them to move to. An author who works nearly full time on AutoCAD, for example, could reasonably continue in that role either as a part of the tech pubs service center, or as a member of the AutoCAD product family.
Here's a proposal for how these negotiations should be carried out:
The product manager chooses whether to make an offer to the individual to join his/her product full time. The individual then has the choice of joining the product line, or staying with the service center. There is one point the individual should be aware of if he/she chooses to stay with the service center: the product manager has the authority to hire a full-time person to undertake the individual's existing tasks inside that product line. If the PM does this, then the individual will of course find his job altered, since the PM will have effectively hired a replacement for the existing job.
We are not going to be able to eliminate all overhead activities, at least not without new innovation, beyond all known organizational strategies. The remaining corporate organizations at Autodesk would include all activities which clearly have an important purpose, but for which there is no clear way to make the accounting either effective or useful.
Accounting and Finance
MIS
New Business Development
Advanced Technology
UNIX Network System Administration
Personnel
Operations
Legal
It might be possible to make our legal department a service center. However, a legal error by a single product line can have such terrifying consequences for the entire company, it makes sense to eliminate any hint of incentive to avoid using these services. So, the legal department sneaks in as a corporate function.
Later, it might be worthwhile for us to explore splitting legal functions into corporate requirements which serve as corporate functions, and other functions which could become billable services. However, this proposal makes all of Legal a corporate function.
It would also be possible, because of its anti-piracy efforts, to treat legal as a business unit. However, this also creates a number of odd incentives on the participants, so this alternative has been rejected until someone makes a really cogent case for it.
The maintenance of the UNIX network by one group, and the 3Com network by another, will get more exciting as we move marketing and technical people together. This relationship will require review as we move into the restructuring. For the moment, however, this proposal leaves MIS and the UNIX Network System Administration groups alone.
The Executive Review Board is composed of all the executive officers of the company. This board negotiates with GMs the mix of profitability and development activities required to maximize long-term success.
When a product family misses its targets, either for profitability or for long-term development, the Executive Review Board reviews the product family to ascertain the cause of the problem. Outcomes may include changes as simple as lowering profitability expectations, and as significant as terminating the product family or replacing the general manager.
The Executive Review Board will have quarterly reviews with GMs; ideally, these meetings would be held just before the quarterly Board of Directors meetings.
Guideline for Product Line Goals and Milestones Negotiation
The normal process for setting product family goals would be:
The GM team prepares a plan that includes key development milestones, U.S. profitability targets, and worldwide unit sales targets. This plan is presented to a group which includes the Executive Review board, the other GMs, and the FMs. The other GMs have as an explicit review purpose the task of identifying opportunities for powerful integration across product families.
If a GM identifies an opportunity for powerful integration, a team is established to assess the cost/benefit of that integration (in the simple case, this team is just the GM who identifies the opportunity and the GM who is presenting the plan). If the Executive Review Board decides the benefits to the company are great enough, the profitability targets will be lowered to accommodate the additional development cost needed for the integration.
The Executive Review Board and the GMs also have an explicit purpose to identify efforts which are being duplicated across product lines. When such duplication is identified, the GMs and the Review Board must resolve the duplication. In complex cases, the resolution will require the development a corporate strategy; the team to create the strategy would include participants from each interested product family.
Often, the seeming duplication of effort across product lines may be appropriate, due to real differences in needs and goals. At other times, it could be appropriate to cancel one of the efforts, levying upon the surviving project the requirement to meet the needs of the other product families: this solution is really viable only when the requirements for the product families are very similar. Finally, a combined team may be brought together to build a solution viable for all the product families. When R&D is required, such a combined team could as a default be placed in the Advanced Technology organization for the duration of the development effort, though other reporting structures are possible. There would be a good incentive on the GMs to use such a shared solution, since the development costs would not come out of their budgets.
There will be a weekly meeting of Al's staff, which includes the GMs among others, to work on conflicts, discuss processes, and identify strategic issues. Each week one GM will give a more complete review of activities and changes in his/her organization.
Surprising as this may be to some people, concepts of tact were invented to increase the clarity of communication: by using tact, one can avoid arousing defensive emotions which inhibit successful understanding and agreement.
I would like to present two examples of communication between a product line and a service organization, since this is where communication is most at risk. And, I would like to look at both tactful speaking, and tactful listening—there is art to tact, at both ends of the communication.
Example 1:
The GM or the PM runs into the service organization and says, “I must do X,” where X is a significant change from the plan as of the day before.
Often the truth is a bit more subtle. A statement that is both more truthful and more tactful at the same time is, “We have a set of requirements which, if we do X, will be fulfilled.” It is probably worth a thousand misunderstandings for the GM to take two seconds to consider whether the second phrasing is more effective.
Communication is a two-way street: if the GM uses the first phrasing (perhaps because he/she has been working too hard and is not quite up to par), it will often be to the advantage of the team for the person in the service center to ask about, or perhaps even assume, the second phrasing.
Example 2:
The FM of the service center runs into the product line offices and says, “You can't do Y,” where Y is the thing the GM or PM most desperately wants to do. Often a more correct and more tactful statement would be along the lines of, “Here are some issues with doing Y. I am interested in working out the issues with you.” It is worth a few seconds for the FM to choose a clear and correct, but perhaps ever so slightly tactful, phrasing.
Once again, the listening GM has the latitude to understand a poorly phrased comment by a harassed FM in a way that does not need a strong emotive reply. The GMs really will have the authority to do what they really need to do; assertions that they can't do Y will not succeed as vetos; they need not fear someone will prevent them from succeeding. They can afford to respond with politeness and tact, since they won't need baseball bats to be effective.
A general management team must have expertise in each of the following areas: technical development, marketing, organizational behavior, personnel and financial responsibility. It will be rare to find a single individual with all these forms of expertise; as a consequence, the General Management team may include individuals in addition to the General Manager him/herself.
A reasonable analogy here may be made to the Release Management teams used at Autodesk and other software companies with great success. An AutoCAD release has both a manager and a chief engineer, working largely as coequals. The manager and the chief engineer are able to work effectively as a team not only because they get along well with each other, but also because there are reasonably natural lines of demarcation for deciding which partner should have final authority over each issue. Also, each manager/chief engineer pair works out the lines of demarcation in a customized way, depending on the exact set of strengths and weaknesses of the individuals.
In a similar way, General Management teams would work out lines of demarcation of the total authority that fit well with the complementary forms of expertise supplied by the team members.
Two styles of team seem natural: A General Manager accompanied by a Chief Marketing Officer, and a General Manager accompanied by a Chief Technical Officer. We may wind up with other combinations too, focusing on combinations that achieve all the objectives with a minimal number of team members.
Did the GM achieve the development goals set at the beginning of the year, whose purpose was to position the product family for successful growth in later years?
Did the GM's products work effectively as components in meeting corporate goals, i.e., did the products work well with other products, did the marketing and documentation and quality augment the public's awareness of Autodesk as an excellent software company?
Did the GM meet the profitability targets in the US?
Did the GM meet the unit sales targets worldwide?
For signing checks, the GM should have the same authority as a Vice President. The GM should be able to sign contracts for services whose cost is as great as the GM's check signing authority can pay for.
The product manager controls the development and marketing budget for the product. Except in special cases as noted with respect to the GM, this individual has the authority to hire, fire, promote, and generally do anything necessary to get a product into the hands of the customer.
A particularly challenging question is: To what extent does the PM have the authority to disregard the service centers of the company, to perform those services either inside his/her product line, or to go outside the company for that service? This question has a multiple part answer. First, the corporate service centers are effectively subsidized, simply because their space, heat, and electricity are all paid for out of overhead, so the PM has a real profitability incentive to use the internal service. Second, the PM does have an obligation to make his/her product complement other Autodesk products in terms of marketing, documentation, quality and integration. Hence, using a service center which is set up to maintain corporate standards will usually make life easier in achieving that goal. On the other hand, the PM really does need the authority to succeed, not the excuse to fail. Consequently, the PM can get released from the need to use corporate services with an articulate explanation of the reasons for the GM and the Executive Review Board.
The criteria for assessing a PM are essentially identical to those of a GM, with one addition: because a PM has many people working directly for him/her, there is an additional question with respect to the management effectiveness: How positive and enthusiastic is the morale of the employees? Since most GMs act as PMs for one of the products in their product family, this will typically be a part of the review of the GM as well.
Review the plans developed by the GMs for strategic growth, to facilitate the negotiations between the Executive Review Board and the GMs on profitability targets (for example, if the VPs concur with the GM on major development efforts needed for long-term success, they would recommend to the Executive Review Board that they relax the profitability needed from the GM to offset the costs of the development).
Seek out opportunities for strengthening the corporation by integrating products across product families (i.e., they would do for the independent families what the GM does for the products within the family).
Seek out opportunities to reduce duplication of effort by business units by initiating corporate development efforts.
Seek out holes in the product family mix which should be filled with new products or product families.
Oversee projects still under development that have not yet been assigned to a GM.
Identify new strategic directions for diversification.
Seek out ways to improve the overall structure of Autodesk.
Employees of service centers spend much of their time working for other people in other organizations. To perform a review of such an employee, the line manager in the service center should talk with every manager for whom the employee has worked since the last review, and use that input in the evaluation. As with the annual review of the service center as a whole, if a single manager is disgruntled with the work of the employee, that should not spell disaster for the employee; indeed, if there are widely conflicting opinions about the employee's performance, this is an indication that something more complex is happening that needs to be investigated.
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.
The entire new structure should be watched carefully for opportunities for improvement; however, there are some specific areas that have already been identified which are worth watching closely to see whether change is appropriate. These areas include:
Coordination of the UNIX network system administration with the MIS 3Com network system administration. This will get more complicated during the time of the move, since these networks will need to get even more deeply intertwined. Hopefully better technology can resolve some of these problems.
Coordination of corporate marketing and technical publications. Each of these organizations create material for the product; it needs a coordinated look and feel.
Coordination of the retail sales group at Generic and the dealer channel sales group in Sausalito.
Keeping all of Legal as overhead, or identifying components of the legal activity which should be charged back to business units, service center style.
Making training a business unit.
In a completely free market, if a business unit went to an outside service and demanded extremely short-notice turnaround, the outside service might well charge a premium price for the extra effort. Since our internal service centers are nonprofit organizations, this kind of “premium charge” does not make sense. Yet the absence of such a premium charge mechanism distorts the incentive system: to the PM or GM, it looks no more expensive to demand service on an hour's notice than on a week's notice, even though it may very well be more expensive—such sudden requirements cost us in terms of scheduling conflicts and angry frustration. What would be an appropriate mechanism for repairing this distortion?
Many, many people have been involved, in various degrees at various times, in the development of this proposal. Below is a listing of all the people the author can still identify at the end of the process, who had specific unique suggestions and insights that caused the author to add or improve specific passages of the final draft. All ambiguities, omissions, and errors, are solely the responsibility of the author.
David Ang
Carolyn Aver
Moonhie Chin
Ruth Connolly
Malcolm Davies
Scott Davis
Al Green
Scott Heath
David Kalish
Volker Kleinn
John Lynch
Tom Mahood
Sandra Marin
Pete O'Dell
Kern Sibbald
John Walker
Below are listed the major changes, additions, and clarifications in the June 28, 1991 version of “The New Autodesk”:
There was a graphic which depicted some organizations as service centers, some as corporate functions, and others as a mix of service center and corporate function. In fact, under close inspection, every “service center” has corporate functions as well as service functions. As noted in the text, the Functional Manager for each service center should present a proposal to the Executive Review Board breaking out which activities should be handled as a service, and which should be handled as a corporate function.
There are 2 kinds of guidelines that service centers may—or may not—need to do. One kind of guideline is the guideline describing the service center's process, so that remote organizations can use the same process even if they can't use the service center. Only organizations that have a certifying function need to prepare such a guideline. Those are the centers that uphold a corporate standard of some type.
The other kind of guideline is a submissions guideline, i.e., what should materials look like that the PMs bring for service? If a PM wants to break such a guideline, the appropriate response is not to tell him he can't do it, but rather to tell him how horridly expensive it will be to him if he does it that way.
There are organizations for which it really doesn't make sense to do either of these kinds of guidelines, such as the sales group, as an example.
Organizations other than business units may use service centers; once again, the costs get billed back, and the organization which plans to use a service center should allocate money in their budget for using such services. An example is Advanced Tech, which needs the service centers in much the same way the product lines need them.
Not all employees of service centers are “matrixed” to product lines. A “matrixed” employee is one who conceptually joins the product group, usually to the extent of sitting in their office space, while working with the product team. Sales is again an example of a service organization wherein the employees are not matrixed.
Problems with service centers that do not matrix employees are conceptually problems with the service center as a whole, and should be addressed to the FM.
In the New Autodesk, the way the sales department budgets changes only slightly. To understand the change, first let's review very briefly how sales did their budgeting in the Old Autodesk:
Two changes occur. First, the revenue targets are broken out by product line. Second, for each product line, the Product Manager plays the role of “upper management” in the discussion of targets and in the review process.
The Autodesk Tech Library does a lot of important activities that are atypical of a library, such as database searches. The Library changes its name to Information Resources, and becomes a part of Advanced Technology. It operates as a service center (with some corporate functions).
The Japan group will become a part of the AutoCAD product family. Today, this is where the vast bulk of their work resides. In the long run, it may be more appropriate to have a separate service center for the Japanese ports of our software, to ensure that emphasis is not skewed by the organizational structure. This arrangement will be under continuous scrutiny to assure that it works.
The Science Series will remain with Advanced Tech until we have
identified a Product Manager and fully reviewed the choice of business
unit where it should be placed.![[Footnote]](i/footnote.png){kind=small}
The goals of the corporate marketing group are to:
Corporate Marketing will include both Marcom implementation, and a strategic focus on planning.
Where “The New Autodesk” discusses training, the particular kind of training being discussed is dealer training.
GMs do not need check-signing authority, which is the mechanical part of the purchasing process. What they need is expenditure authority. The General managers will have the authority to approve expenditures for their business unit at the same level as an Autodesk Vice President.
How do customer requirements make it into products? This was a most popular question. The document “The New Autodesk” does not address it directly.
Indirectly, the new structure creates an environment even more conducive to incorporating user feedback than the Old Autodesk. Because of the closer ties that the PMs and GMs have to profit and loss, they have a stronger incentive to care even more about the customer's desires. This in turn means stronger incentives to establish strong lines of communication with those who are close to the customer (notably, the sales people). Meanwhile, the sales organization will have a dedicated point of contact for each product line, and that person will have a strong incentive to communicate as well. Finally, the sales people themselves will retain the strong incentives to communicate that they already have (namely, to have a product they can sell more of more quickly). Consequently, any successful GM/PM will establish forms of communication well suited to the needs of that product, both with our own sales people and with other sources of good customer information.
The 2 areas of most active concern in the discussions have been the coordination of the sales groups and the coordination of the 3COM and Unix mail systems. We will continue to assess these areas for improvement during the transition and beyond.
|
|