Mark Adkins writes:

>Meredith Tanner says:

>>i have finished eight guidelines in my time here at Apple. due to unbelievable bureaucracy, not one of them has been approved for use yet.

>I suggest that you draft some guidelines on the implementation timetables for guidelines. I shall be watching your future progress with considerable interest.

There is no humor in any of this. When I was at (insert company name here), the most important planning effort was to create a "plan for a plan." I worked on one product which had more planners than programmers, and heard one planner complain that there were too many programmers, since the programmers were always waiting for the planners to finish their work. I worked in another product area where the primary deliverable--to the customers--was an architecture, but at the time the architecture was announced, all that really existed was a plan for an architecture. No, the plan that was announced wasn't the first all-new plan, nor was it the last. Virtually the whole staff for this "architecture product" consisted of people whose whole career had been in planning. The product eventually evolved into an architecture of architectures, before it fell off the edge of the world.

But what can you say about a company whose planning cycle lasted six months, and where the average time to complete a plan and get it approved was around eight months? You say what I heard more than one planner say: "We know this plan is broken, but we'll fix it in the next plan cycle."

Or you say what the company's jargon dictionary said about planners: "A person whose job is to think about doing real work."

Such a delightful place to work! The company average was for one in eleven new-product projects to reach a point where a product actually shipped. I did work on one of those; after it was completed and ready to ship, it was nearly canceled, and needed another six months of work to get it out the door. During the whole project, we knew that another project in the company was actually the favored project for that particular market, but our project was never killed because the other project changed plans every year. We shipped first, by over a year, but because we were out of favor, our product was virtually unmarketed, and sold something like eight licenses. However, we did develop and complete a second release for these eight customers. That also shipped before our internal competitor.

I should have seen all this coming fairly early, when shortly after I was hired, another project in that group completed development and testing of their product and shipped it to the distribution center, only to see it cancelled. Why? The company couldn't figure out how to market it. Yes, this was a product that customers asked for, knew about, and wanted.

It was a company where a strategic and vital product could be canceled because the manager who owned the product line decided he didn't want to be in that business any more. The people who needed this project to succeed were in a different division, and therefore had no right to raise business issues about the cancellation.

Actually it was good that the project was canceled, because it had been managed into the ground (different manager). Everyone's career suffered except that of the offending manager, who was rewarded with the opportunity to destroy another project. He succeeded.

It was a place that preached empowerment. In a round-table meeting with a third-line manager, someone asked how far down empowerment extended. The third-line said, with a straight face, "It extends down to me."

It is a company that stands behind its commitments to deliver products, once they are announced. One of the worst things that can happen to a manager's career is to withdraw a product after it is announced. The bureaucrazy that is in place to see that this never happens often assures that this embarrassment never happens by preventing product announcement in the first place. Nevertheless, I own a bronzed product announcement letter, nicely mounted on wood, for a product that never shipped. Company- wide, the rule was that a product could not be announced until it was in system test. In my division, the rule was more often interpreted to mean that a product could not be announced until it was ready to ship. This particular product was in several pieces, which had not even been integrated in development at the time of the announcement. Integration never happened, since developers in the various segments weren't allowed to talk to each other. The announcement happened anyway because it was part of a major strategy announcement, and it was necessary to show that the strategy actually had a bit of substance.

It was a company in which developers were so insulated from customers that no one had any real idea what customers needed, or what their minimum requirements were, or what their expectations might be. Marketing was to blame, of course, so our division formed its own marketing team to fix things. The new, enlightened marketing manager was once heard to say, "We have some wonderful technology in this lab; all we need to do is to find a market for it!"

The company Jargon Dictionary equated "Do it right the first time!" with "Let the customers find the bugs." People were often evaluated on the number of errors found in their code. It provided tremendous incentive to deny that anything was a problem.

This company is still in business.

(To its credit, the jargon dictionary also celebrated some of the more obscure forms of debugging. "Organic debugging" was the practice of setting a plant on a program listing; the idea was that bugs would crawl out of the code and into the plant. "Wave a dead chicken over it" was the term for a last, forlorn effort at diagnosing a problem, when the effort is more ritual than reality. There was also a description of hardware running in "casters-up mode.")