Back to Part 1

Logic State Analyzer Birthing Pains, by Chuck House

- Part 2 -

* * * * * * * * * * * *

Table of Contents:

Being noticed

Hard to imagine today, but scanners, bar codes, and RFID tags did not exist in 1975; grocery stores had no automation. MSI Data, a tiny Costa Mesa, CA company, had a novel device: a 'portable grocery checker' designed for Alpha Beta, a California grocery store.

The device weighed two pounds with a keypad and a display; it fit roughly into your hand. The idea was that a clerk could carry it up and down aisles, to list items that needed restocking. They intended these units to communicate with the back room, so staff could be loading carts with restocking supplies even as the clerk wandered the aisles. It used Intel's 4004 micro-computer chip; MSI's team said that they were Intel's highest volume purchaser of those chips.

This was in October 1975, three months after the quota dust-up. MSI Data wanted to hire an R&D Vice President, and a recruiter found me - the inducement, besides a handsome salary and bonus, was a hefty stock option and a chance to move back 'home' to Orange County, CA.

I barely knew the terms 'start-up' or 'stock option', and it was intriguing, to say the least. And it was a precursor of increasing notoriety. Executive recruiters - headhunters, a term that I'd not heard before - began to show up. Farnbach and I were the visible targets - we'd bylined the articles and given training seminars. 'Back home' after a quick visit, I met with our HP General Manager Hal Edmondson and described the MSI Data opportunity. Edmondson's quick response was to create a 'Logic Analyzer group', and he promoted me to run it, the first time that I was asked to manage multiple functions (R&D and Marketing). Hal included a moderate raise and modest stock options. I now was a 'general manager' of sorts, and I was very proud of the major R&D program underway that augured to give us unquestioned leadership when it arrived.

Complicating events were swirling, though - innovation was not just happening at our place, but throughout the industry. Along with our efforts to teach seminars and encourage the field force to drive toward a bold "$16.6" sales goal we kept hearing odd comments about a 'new device' - an emulator, whatever that might be. Each microcomputer manufacturer seemed to have one; the two most prominent were the Intellec 8 from Intel, and Motorola's MDS, which stood for Microprocessor Development System (Figure 4).

Our problem, although we didn't yet know it, was that we were focused on 'yesterday's competition'. Tektronix entered the Logic Analyzer business with a combination Logic State and Logic Timing machine, the DAS 9000 (Digital Analysis System), a bulky box not unlike our original D'wuck definitions. Tek, with lots of historic cachet with electronic engineers, got an audience for this machine. Nimble pioneers of Logic Timing Analyzers, start-up Biomation and long-time radio test vendor EH Research, were able to thrive for a time against Tek. We debated whether to change our Logic State thesis and fight the Logic Timing zealots, or to meld the two capabilities. Our field force, struggling with our radical paradigm, helped with that decision.

As the third-generation products made progress during 1976, Hal came back to me with a 'new opportunity.' He wanted me 'back in marketing', but truth be known, he and others were frustrated by my seeming inability to manage a sizable group. His proposal was that I become HP's first Strategic Planning Manager, reporting directly to him, with a couple of people, to redefine the strategy for the whole division. "Whoo-boy, here we go again", I thought. Hal's plan was simple - "John Cardon, a practiced R&D manager who can both motivate people and get the current products finished on time and budget will take over your lab. You and I can define a stronger presence for oscilloscopes and displays, to really wound Tektronix."

November 1st, 1976 launched HP's 1977 fiscal year; John Cardon took over my lab. The products did indeed come to completion; he comported himself well, focusing tightly on schedules. My role, however, struggled. Traction eluded me - we'd tried a million things against Tektronix over the twenty-two years we'd competed. We'd pioneered Sampling Scopes, Displays, Very High Frequency Scopes, Variable Persistence Scopes, and Microprocessor Controlled Scopes as well as Logic Analyzers - and Tektronix had historically answered each initiative within twenty-four months, and taken market leadership within another two years.

My strong fear was that they'd do it again in Logic; that was a big part of the motivation to persist with the third generation equipments so boldly. Edmondson, on the other hand, felt that the game for HP still was to 'beat Tektronix' in the main scope business; ancillary equipment lines could never satisfy Palo Alto, and hence satisfy his own vice-presidential ambitions at HP.

We had a stalemate underway.

And my periodic forays into the Logic lab told me that the team was losing enthusiasm - the drive and the zest for creating and evangelizing these new tools seemed muted. Not good.

And the Winner is!

And then - an incredible surprise. I was selected for a prestigious award - the Award of Achievement, given by Electronics magazine. It was their fourth annual selection of a person for creation of products that revolutionized electronics. Their cover picture showed Bill Moore, CEO of start-up Biomation based in Cupertino, CA, and me - we were jointly selected for the creation of Logic Analyzers - Biomation for Logic Timing and HP for Logic State analyzers. Biomation had created an eight-channel Logic Timing Analyzer the year before the HP 1601L. It was also a 10 MHz machine, which displayed a stylized waveform with time running from left to right on-screen, the same way that oscilloscopes did. Biomation's box was an easier 'sell' to classic analog designers, and they did enjoy considerable success for a time. Biomation's newer designs emphasized faster sampling rates up to 200 MHz, lots faster than our systems.

HP overall revenues reached three billion and Tektronix neared one billion in 1980, each company tripling in size in a mere five years. And Tektronix now had eighty-seven percent of the 'scope business; HP Colorado Springs had declined to eight percent. So the fact that my logic group had a slim lead over Tek - 35% vs 28% - in a market one-seventh as big as 'scopes didn't impress Colorado Springs division management. And the fact that the PDS business was almost three times as big as logic analyzers had been noticed in Palo Alto. No one yet knew that by 2010 HP Logic Analyzers would sell $2.8 billion of Logic Analyzers, half the world's supply. The front end of the innovation "S-curve" is a nascent part of the eventual profile, yet almost all of the decisions about eventual investment and competitive stances are decided by then.

Creating and Sharing the Vision

Doug Chance's words echoed in my ears on the way back to Colorado Springs from Ottawa. We'd become good - incredibly good, in fact - at our Data Domain expertise, and we had done something that eluded our divisional brethren for two decades: whipped our major competitor, Tektronix. We'd become E-stage leaders, with a radical vision and a plan, and we'd executed that plan very successfully. Now, it felt like we were being asked to throw much of that away.

I had long used a simple matrix to describe the difficulties of learning new material - I called it the 'shoelace tying diagram.' Fidgeting on the plane, I found myself sketching the diagram again on the back of a napkin. Although I'd frequently drawn it for new members of the team, additional insights came to me as the plane droned onward.

Most of our daily tasks are performed habitually, which is to say in a semi-conscious or nearly unconscious state of mind. We get up and get ready without 'thinking' - putting on our shoes, cleaning our teeth, pouring milk on the cereal, backing out of the driveway, and so forth. And so it goes throughout the day. We see cars all around us as we drive to work, yet with the possible exception of a new type of vehicle, probably could not describe any of the cars we saw if asked at lunch. Certainly no one could say how many SUVs they passed on the way to work.

These quick examples illustrate two kinds of information - the color of your toothbrush was once learned, but is now unnecessary information unless you share a bathroom sink with others; the number of SUVs along your route as you traveled is latent information, ignored because it is not relevant unless someone asks about it. Latent knowledge is discoverable, if you seek it.

Many of us are familiar with the terms explicit knowledge and tacit knowledge - along with the notion that we can teach explicit knowledge, in a training class for example, while it is tough to teach tacit knowledge even though it can be learned. How do you learn tacit knowledge? By assimilation or emulation once you are in a group which 'has it'. Apprenticeships do this.

The picture above illustrates the shoelace tying diagram. Imagine back to when you did not know how to tie your shoe laces - is it possible to think back that far? Then there came a time when someone pointed out for you that you did not know how to do this task. You might remember the person with some fondness. You have just been changed from an Unconscious Incompetent into a Conscious Incompetent, going from the lower right-hand quadrant to the upper right-hand.

Learning progresses as a counter-clockwise move around this diagram. I suspect you've had experience going to a friend's home and a young child comes running up, saying: "I know how to tie my shoes, watch." Then they proceed to show you that they don't quite have it down yet. Project reviews often have this quality: "I have this neat prototype. Here, let me show you how it works." Two mouse-clicks into the demonstration, you discover that it almost works.

Many lessons might be drawn from such a chart. First, it is fair to observe that Productivity improvements are usually viewed as moving from the upper right-hand quadrant to the lower-left quadrant. The idea is to move your team from learning the initial concepts to practicing them, and then to intuitive easy operational behavior. Many companies prefer to hire new college graduates, wasting no time unlearning a different company's processes and values.

Training departments, schools, and universities exist for the purpose of moving novices, using explicit material, across the top of the matrix - from quadrant 2 (upper-right) to quadrant 3 (upper left), topic by topic for whatever curriculum is deemed relevant. Practice - lots of it - moves a person from quadrant 3 to quadrant 4, from a Conscious Competent to an Unconscious Competent. The practice time routinizes the behavior - in sports, the quarterback learns a host of nuanced things about how much lead time, how to 'read' a defense, knowing when to scramble, and what to do when weather conditions change things. Such skills become ingrained, highly tuned and efficient, and performance improves accordingly.

This works for teams just as much as for individuals - teams that work together for extended time develop understanding, trust, and mutual interactions that are sophisticated, smooth, and effective, almost without trying.

But notice a curious element of this learning, and this positioning on the matrix. If we get a team 'intuitive and efficient' we have basically moved them into the fourth quadrant, an 'unconscious competence' quadrant, which over time can render the group somewhat inarticulate and even inexplicit about what they know and believe. Then, if a structural change comes along - a context-challenging situation - the group may not recognize it for what it is.

Imagine that as events move along, things get harder, profits more elusive, or efficiencies less pertinent. The typical response is to try to figure out 'what happened' or 'what we need to do to recapture what we once did so well.' A classic response, often from higher level management in conjunction with the HR / training department, is to 'go back to the basics', to 'revisit what made us great', to re-instill the 'things we once knew so well.'

But if the lower half of the diagram is "unconscious" - you don't really know whether you do know or you don't know what to do in this situation. Intuition - or the long-ago learned response - might be exactly right, but it could also be tragically wrong. Flight simulators train pilots for a myriad of emergencies, so that their 'intuitive' responses will be good ones. But it works best if the emergency was well enough anticipated that it is built into the simulator to practice.

Being open to new ideas - in effect, willing to stop in the midst of something that has felt comfortable, but has changed character somehow - is not all that easy. Often, it seems that the more expert or powerful someone is or has been, the more they tend to want to stay in that comfort zone rather than admit that they really don't know what to do in this instance.

To some degree, this accounts for why old paradigms die hard. An additional complication is that the new paradigm - the changed situation - is usually cloudy, fuzzy, and inexplicit. The old paradigm - the one that we've come from - has rules, well-established articulated procedures and processes. The new one is at best dimly-viewed, half-conceived, and dichotomous - even for the visionary who senses or even grasps it. Thus someone in that D-stage described earlier - who has the vision, but isn't sure how to realize it - has quite a task to persuade 'the rest of the team' but especially to elicit support from the most influential and powerful of the 'old guard.'

This is the special challenge of the intrapreneur. Interviews with many serial innovators reveal phrases like this: "How can I get my boss (or the engineering council, or . . . ) to support working on my dream if I do not yet understand it very clearly?" Or "How can I persuade ten (or a hundred) people who might help me carry out my concepts if I cannot articulate it well?"

Entrepreneurs usually labor alone through this period, maybe with their own funds, or with funds from one or a few speculative investors; the intrapreneur's special burden is that they are operating in a larger setting, one where quadrant 3 and 4 'conventional wisdom' is all about them, while they "see clearly" that the situation is more like quadrants 1 and 2.

Phrased this way, it is easy to see the plight of the intrapreneur - once they recognize that the situation has been fundamentally altered, they begin their own odyssey - from quadrants 4 to 1, then 2, hopefully to 3 and maybe then back to 4 with new rules. But as they travel this lonely path, they will "look and feel" like A, B, C stage leaders (Table 1-2) until they themselves reach quadrant 3. Then, and only then, will most managers take them seriously.

Once I had drawn the Competence Matrix and compared it to the Leadership Stages, I felt relieved - relieved in the sense that I could now see why it had taken so long to come to grips with the Logic analyzer definitions. The first issue - raised so clearly while standing in the Tektronix booth - was that all of the extant instrumentation no longer met the design needs of customers. What would? Well, I didn't have a clue, but my own team supplied some important elements when they couldn't build our prototype due to a host of new data domain problems.

We didn't know to call them data domain problems, though, until we'd wrestled with some ideas, built a half-dozen prototypes, and taken a couple dozen 'market research' trips. Almost all of this work would be thrown away before we hit upon some definitions that 'stuck'. Even then, the first products that we released failed the economic payback equation pretty seriously, even as we were well embarked on the second investment set.

The second set of products enabled us to get some traction with the sales force, and with the required investment returns, but they weren't enough to generate significant support for keeping the investment momentum going. We only got that third round by essentially taking the division management team through a crash course that toured them from quadrant 4 in their belief system to quadrants 1, 2 and then 3 within a ten week workshop.

The third round turned out so successful that our local management touted us to headquarters - and HQ promptly cannibalized our team for their vision , not ours. Worse, our local managers lacked sufficient perspective to realize that if this were cannibalized, that we'd lose the initiative, and once again be beholden to Tektronix, just as the previous twenty years had done.

Once I had built this perspective for myself, I wrestled with the question of whether we could forestall the incursion of 'directives from above' - and concluded that seemed unlikely at best. At the same time, it seemed worth trying to diagram, in some sort of flow-chart manner, how we'd done all of this. I think I harbored some sense that this might prove useful later.

The chart that emerged is shown in Figure 8. I called it the Strategic Cycle, noting that it takes three Product Cycles to have a complete Strategic Cycle. The diagram includes not just the Strategic Cycle, but the Visioning and the Strategic Planning sections as well.

Contemplating this flow-chart alongside Table 1 and Figure 7 was revealing. Thinking back to standing in the Tektronix booth demo'ing their new 'scope to customers, that day moved me to a Conscious Incompetent person from an Unconscious state. I thought that I was an Unconscious Competent who understood oscillography well, quite suited to managing the Next Gen program as a result. In fact, I was an Unconscious Incompetent about the nature of the new measurement requirements - and the booth visitors served the same purpose for me as that older sibling does for the child who doesn't yet know that they need to learn to tie their shoelaces.

On the Leadership table, I had just moved from what I thought was an E-stage (or F-stage, depending on whom was asked), to an A-stage - completely adrift at sea, no idea where to turn.

So what do you do in such situations? In somewhat pell-mell fashion, we followed the flow-chart. Specifically, we traveled and listened - from multiple viewpoints, to many problems, with lots of boundary conditions. And we formed a tentative thesis - the d'wuck.

The d'wuck was good enough to test the thesis on 'a very small audience' - and with help from Bert Forbes, it found a very credible audience at IBM. That was enough to convince Dar Howard that we were at the B-stage of leadership, and moving to the C-stage - certainly we had done some useful things, and it now appeared that we were doing a few right things. It earned us the chance to build a larger group, which in trying to validate the thesis, reshaped it sizably, and led eventually to a couple of tentative products. The HP 1601L and the HP 1645 thus were the initial salvos of Phase 1. We could now be said to have reached the D-stage and to a degree the F-stage of the Leadership chart. By the time that we defined the HP 1600S with asynchronous latching, and the next round of equipments - ala the HP 1610 and the HP 1615 - and then we defined and codified the data domain principles, we clearly fit an E-stage leadership situation. And we were now Conscious Competents, aware of and becoming good at what we were doing.

When I drew the flow-chart, however, and as I have described the evolution in these pages so far, I was still operating at a lower level than these tables and charts might suggest. I had been viewing the HP-1601L as Phase1, the HP-1600S as Phase 2, and the HP-1610 as Phase 3. In this view, PDS systems were alien forces, something being foisted upon us against our wishes.

A different perspective occurred to me as we neared our destination airport. Actually, all of the technology and approach of the HP-1600S was virtually unchanged from the HP-1601L - to us, it seemed different because of: (a) being almost two years later, (b) new cabinetry, with connections back to true 'scopes; and (c) it was much more capable in terms of specific features. But in terms of circuit technology, user-interface, display nomenclature, and signal connections, it was essentially identical. To the customer, it was refinement, not break-through. All Phase 1.

By contrast, the HP-1610 and HP-1615 (plus the others in the family) were radically novel by comparison - new displays, new circuitry approach, new user-interface, completely new look-and-feel cabinetry, totally different signal probing methodology - everything had changed.

Thought about this way, we had just completed the entry products for Phase II, and we hadn't given much thought at all to Phase III. No one looks very far ahead if they feel behind the power curve, giving all of their attention to gaining traction in the tough environment of the moment.

So, instead of feeling depressed about not having done much with respect to Phase III, I had an opportunity to accept the proferred prize, the PDS challenge, and declare victory. Why didn't I feel victorious? Again, it came back to 'control' - I liked being in charge of creating change, and I bridled when someone else told me what to do. How much this related to long-simmering issues with my father is hard to say, but on many days, this has felt quite emotional for me.

It would be wonderful to report that this all became clear, and I objectively sat down and decided to be grateful for the guidance and support as we broadened our perspective. It didn't happen that way - once again, many sleepless nights went by, as I wrestled with myself over this conundrum. Eventually, though, I came to grips with it, agreeing that the 'right answer' to have total leadership in the data domain would mean to have leading-edge products for both design and analysis of systems being built with integrated circuits and microprocessor controllers. To date, Tektronix had only ventured weakly into the data domain, trying to tie it back to time domain analysis tools. Intel had done only data domain design tools for microcontroller designers, without thought of providing real-time analysis tools for a total range of IC designs. HP Logic Systems Division (we loved the acronym) would be the integrating force, the overall provider, of data domain tools, if we could master the PDS challenge.

The Third Generation - PISCES

We were, however, very late to the party. And, in effect, we were almost back to A-stage leadership - no idea quite where to go or what to do to get started. All we knew was that we didn't want to copy the answers that already existed. So we began afresh - with a new visioning exercise - with a team that was firmly in the synchronous digital design world at least.

PISCES (HP Code Name for the HP 64000 Program Development System)

(PISCES = Practically Intelligent Structured Computer Emulation System or a Zodiac sign)

I was late that morning, very frustrated when traffic was tied up at the Garden of the Gods Road off-ramp from Interstate 25 in Colorado Springs. Police lights were flashing - a person on a gurney was being loaded into an ambulance. I was instantly sick - the motorcycle looked like that of George Haag, our pugnacious program manager for PISCES.

The HP logic analyzer sales team was in town for two days. We were scheduled that Monday morning - September 11, 1978 - to share the functionality, status and progress rate of our new Program Development System (PDS). Intended to compete with Intel's Intellec series and similar products from Motorola and others, our PDS ( with the Zodiac code-name PISCES ) was a bold step into a much more competitive, sophisticated arena than traditional HP instrumentation.

My walk along the Ottawa River with Doug Chance in October 1977 indeed presaged HP executive 'help' from Palo Alto and Cupertino, California. This new product sector purported to be a much larger and more important product contribution than logic analyzers - in a market that HP couldn't duck. The California opinion was that our Colorado Springs team was the most skilled and able to take on this challenge; they were insistent that we take the resources from our recently updated Logic Analyzer program and apply them to this code generation / emulation world of microprocessor development rather than competing more strongly against Tektronix.

George Haag, the obvious choice to lead this challenge, was fresh from leading HP's 1610A flagship for our third generation logic analyzers, with relevant design experience in two HP computer divisions. Pulling together a crackerjack team, Haag seized the opportunity to define an elegant networked computer system unlike anything within the computer industry at the time.

Six months later, HP's new CEO, John Young, taking over from founder Bill Hewlett, visited our division to review the program. We invited twenty key HP R&D leaders to solicit their advice and support. It was a fractious meeting. HP R&D divisional managers had a notorious NIH (Not Invented Here) reputation - and these visitors lived up to expectations. George and his key lieutenant, Tom Saponas, did a yeoman job of explaining, debating, and combating the various factions represented. In the aftermath, the program was validated for Young, and additional resources were granted to accelerate PISCES on a fast-track development.

During quota setting in July, rumors of this altered strategic direction befuddled the instrument sales force - unnerving them as they were grappling with how best to sell our new third-generation logic analyzer tools. They fretted - was our Logic Analyzer operation headed into computers, and if so, would sales responsibility shift to the separate computer sales force? Logic analyzer sales were up sixty-five percent for the year; no other instrumentation product line had growth even half this rate. At the same time, it had become clear that microprocessors and microcontrollers were emerging as important design elements, and this Logic Analyzer product line was their entrée into this emerging design arena. They didn't want to lose it.

At the July meeting, we invited the field sales team to Colorado Springs for two days in September, both to give them deeper training on the third generation analyzers and to assure them that PISCES would be theirs to sell. We confidently anticipated that the logic analyzer line could grow by another fifty percent in 1979, and they accepted quotas accordingly; we also told them that PISCES would be available a year later, for the 1980 quota setting timeframe.

Unfortunately, we had not made as much progress on PISCES during the summer as we had hoped, and much anxiety surrounded this Monday meeting. Getting through the tangled traffic scene, I learned to my dismay upon arrival at HP that it was George's motorcycle that I'd seen. Saponas had just talked to the hospital - George was in ICU, with critical head trauma.

Walking to the front of the room to launch this event was one of the hardest jobs I ever faced.

The group appropriately shared a quiet moment, but by the end of the day, much angst floated through the audience. They voiced their belief that we were struggling to invent an incredibly complex system, on a relatively short time schedule, and now we'd lost the charismatic, driving leader - there was no way that we could get home on schedule, if at all. The group, dispirited, broke for dinner - Tom and I meanwhile had been twice to the hospital where it was clear that George had sustained major injuries.

The next morning, things came to a head; the PDS team rallied, and Saponas stood up and took command of the meeting. He solemnly vowed that the schedule would be met - the product would introduce September 11, 1979. I was impressed by the dedication and motivation of the PDS team - everyone on the team seemed fully committed to meeting this high-profile goal.

The unorthodox definition of the product was part of the problem. This was a computer-based system, in every sense of the word. Each 'development seat' looked to a user like a big stand-alone terminal, not unlike the medium-sized terminals HP was already supplying for computer users on HP's minicomputer-based time-shared systems. The term 'work-station' was not yet used in the computing world, but it was an apt descriptor for each of these development stations. Both in terms of the internal architecture and technology, and the inherent 'stand-alone' computing power, these seats were much more like the Engineering Desktop Calculators from HP Fort Collins than 'smart terminals' available from most computer vendors.

Even more innovative, the system had no 'master controller' - it was the first peer-network system the world would see, running as a set of totally shared stations on a high-speed local area network - a very early "cloud computing" configuration. The 'secret sauce' was a shared disc drive, the first HP version of the novel Winchester disc drive invented not long before at IBM Almaden, abetted by our own logic analyzers. This architecture was a total inversion of the extant computer systems of the day, which all used a master CPU or central processing unit to control many data-entry terminals, with several disc drives for lots of data storage. Our design, with no CPU, used one disc drive to synchronize the set of powerful terminals (Figure 9).

Competing PDS systems used a very simple architecture by comparison, where each developer had a full CPU-like terminal with its own on-board floppy disc drive. No connection existed to other developer seats; each developer worked independently on their own code. Synchronization was a tedious, manual process after code development of a segment was complete. Floppy drives, while cheaper than a Winchester drive, lacked memory size and speed.

Additionally, borrowing heavily from other HP divisions which built computer peripherals, PISCES was designed to be 'plug-compatible' with many devices - other disc drives if more memory was needed, printers, and remote displays, along with computer diagnostics and disc-resident maintenance manuals. No other PDS vendor allowed this type of resource sharing.

Thus, our system was designed from the beginning for development teams, rather than individual developers - teams writing hundreds of thousands of lines of embedded code. It arrived coincident with the shift from eight-bit microprocessors most useful for small tasks such as gas pump controllers and grocery store checkout 'cash registers' to the new sixteen-bit micros that were emerging for true computer-like tasks - including soon-to-emerge personal computers, although none of us appreciated just yet how revolutionary those PCs would become.

Moreover, PISCES was designed for engineers rather than computer programmers. "Guided syntax soft keys" allowed easy construction of commands in engineering terms, providing a significantly faster learning curve for designers new to microprocessors. This functionality, and a large-screen display for the developer, allowed much more rapid development of code bases.

The coup de grace was that the machine featured 'universal emulation' which meant that a developer could develop microcode for a microprocessor from one vendor, and then cross-target it so that it could run on a different microprocessor from another vendor. This feature, universally praised by developers, was despised by the microprocessor vendors. Until PISCES, microprocessor vendors built PDS systems dedicated only to their own chips. If you wrote code on an Intel Intellec, that code only ran on an Intel microprocessor. Motorola, AMD, and Zilog built their own PDS systems - all fractious and non-standard.

We painfully learned many lessons. One key finding: disc drives of that era were not very reliable, so two coping strategies existed. One was 'consistent back-up' so that data would be preserved if a head crash occurred; the other used multiple discs to provide data redundancy. Our system, using just one disc per system, inverted the failure risk factor. It was an architectural marvel - getting a much higher speed, larger memory system with synchronized code-streams from multiple developers, but it made the integrity of the whole system dependent on the least reliable component. Fortunately, Winchester disc drive failure rates improved substantially; we lucked out rather than really understood this nuance.

In order to create PISCES, our team took advantage of an historic HP strength. HP had a wildly decentralized divisional organization, a legacy of Hewlett's belief that contribution, creativity, and market success were dependent on small nimble teams unhampered by corporate strategic plans and rules. A big part of Hewlett's genius for this decentralized organization was a long-standing culture of sharing technology between divisions. If you knew that someone in another division had a device, a component, or a process that could help you, you could ask for their help - and it was expected that they would grant it. Parts in production could be transferred at factory cost to be used in your new design, and products under development might even be done jointly, if both parties agreed. And for the most part, they did agree.

This collegial concept dated back over twenty years, to the first divisions created in the late 1950's; it worked well as the corporation spawned new divisions, usually in remote geographies.

'Groups' had emerged to cluster the rapid proliferation of divisions, as the company entered new markets - so by 1978 there were groups for Electronic, Medical, and Chemical Instruments, plus Devices, and Computing Systems. As groups emerged, rules changed somewhat - you were collegial within your own group, but maybe not so much with other groups. No division 'crossed the boundaries' between groups to link unrelated technologies. No one explained this shift in rules; importantly, this situation hadn't been tested very hard since pertinent technologies were increasingly differentiated between groups. Until PISCES. To meet our aggressive development schedule, we sought to borrow rather than invent wherever possible.

George Haag and Tom Saponas had each spent several years in computer divisions, so they knew many designers and technologies well. Moreover, the computer divisions knew our logic analyzer products well - they were the chief users of such tools. The PISCES team borrowed technology, components, and processes from fourteen divisions around the company - not always smoothly. In particular, we became a thorn in the side of the disc drive division. At first we thought this due to our stiff requirement for a reliable Winchester drive, but when our volume requirements appeared to tax their own plans, they became concerned about profit margins, delivery schedules, and logistical issues. The collegiality capsized.

After several frustrating meetings in Boise, Idaho, we decided to build disc drives ourselves - the hell with them! This, while not expressly ruled out by HP's lax business organization, was confrontive, earning us interviews in Palo Alto to discuss just what we were trying to do, and why 'we weren't able to get along' with our sister division. I was incensed - the problem was them, not us. Here was a division deciding to disbar another from buying its products, and then asking that the other be precluded from finding alternatives. Much discussion ensued; they grudgingly agreed to sell us drives to our requirements - we agreed to drop our plans to compete.

Our PISCES team had burgeoned, by now comprising most of the Logic Analyzer R&D operations, which meant that new Logic Analyzer product design took a three year hiatus. Sales did grow by another fifty percent in fiscal 1979, but Tektronix's new Digital Analysis System in 1980 would shortly blunt our sales growth. This was a major mistake - you never abandon a hard-fought win just as the momentum builds. But - we did. The philosophy that allowed this error was also a legacy of Hewlett's decentralization belief - that each division can autonomously choose its R&D programs. Thus, even though Palo Alto management forced us to get into the PDS arena, we weren't able to persuade our own group management to use R&D funds from stodgier analog instrumentation lines to keep logic analyzer R&D momentum.

My response was to try to find help from some of HP's international divisions. HP had expanded overseas early in its corporate history, with operations in Germany, Japan, and England. Those operations all sought to replicate HP's classic division model of autonomous R&D teams and product lines. When Dar Howard restructured the Colorado Springs lab to accommodate the digital 'scope ideas in 1970, he had offered segments of his lab to these teams. Germany had seized the bait for both low-frequency 'scopes and pulse generators; Japan had done the same for sampling oscilloscopes.

Three of us - product marketing manager Don Wilkins, hawking the new microprocessor-based HP 1722A, me with the HP 1600S, and the Colorado Springs Quality Assurance manager, Ron Given, had spent a product launch week in northern Europe in spring 1975. It was a heady time for my wife and I - neither of us had traveled to Europe previously, and it was stimulating for widening my perspective. I was pleasantly surprised by how many designers and technicians spoke English, but in common with many American travelers, I also found that spending some time trying to communicate in their tongue, and showing interest and some prior knowledge about local history and culture worked wonders to build collegiality.

In early 1978, I took our Logic Analyzer executives - Chuck Gustafson (R&D), Erik Lessing (Marketing), and Jeff Kalin (Manufacturing) - to Germany for the purpose of asking them to manufacture, sell, and even co-develop logic analyzers, since the PISCES program occupied us. The Germans were receptive. Looking back now, it is hard to explain why I felt I had the power to make such a request, let alone agree to move part of the program. In corporations today, such moves would have to be proposed, vetted, and approved by a long chain of managers and committees - in HP then, you just took the initiative. 'Local folk' either praised it or said "no."

In December, 1978, I took a similar trip to Asia with product marketing manager Norm Hall. The goal here was two-fold: first, to get HP's partner, Y/HP, more excited about the Logic Analyzer products, and second, to stimulate interest in other countries such as Korea, Taiwan, and even India. Though familiar with Europe, I was scarcely prepared for the masses of Asia, especially the poverty so evident in India. Characters seemed illegible, faces were inscrutable, mannerisms less understood. We took a short orientation / protocol course that helped a bit.

I needn't have worried. Norm Hall had pre-arranged the trip in such a way that everywhere I was feted as 'America's Engineer of the Year', playing off the year-old Electronics cover story, and the fact that I had just been elected to the IEEE Spectrum Board, IEEE's leading magazine. In each country, our hosts found the local 'Engineer of the Year', whether named by their IEEE chapter, some magazine, or whatever means. And that led inevitably to a 'state dinner' of sorts, with English as the lingua franca and logic analyzers a favorite topical issue. It was alternately heady and intimidating - the latter especially when a local favorite food specialty was prepared. I was always served first, which wasn't as big a treat as one might think. For example, we had whale blubber and fugu, the well-known poisonous puffer fish, in Japan. In Taipei, I was invited to pluck a fresh eyeball from a flopping flounder at the table. In Hyderabad, India, I almost became ill when a monkey was beheaded and I was offered the warm brains as a delicacy.

Admittedly, we had our hands full with PISCES. The magic date of September 11, 1979 was fast approaching - and the sales team was certain that we would not fulfill our promise. George Haag, surviving his horrific accident, entered a long rehabilitation program. Saponas, along with Chuck Gustafson and Mike Davis, supplied superb leadership. As we neared the deadline, we were able to cobble together enough of a system to announce it to the world.

Our goal was to introduce PISCES in grand fashion. We announced simultaneously in Japan, Europe, and America - a feat never before tried by HP. Saponas and I launched at a major press conference in Paris, while Gustafson and our product marketing maven John Marshall did so simultaneously in Munich, Germany. We held press conferences in New York and Palo Alto the same day, as well as in Tokyo Product marketing manager John Marshall would later tally that we got fifty-seven magazine and newspaper stories around the globe that week!

The introduction was a bit premature, in the sense that our 'universal emulation' capability only had one microprocessor target available at launch. But within a year, PISCES - now called the HP 64000S - had targeted most of the major microprocessors of the day, and sales were brisk. Which brought about the next problem - how to service and support these equipments, quite unlike anything our instrument sales force and service technicians understood.

Service required both the instrument and the computer support teams. Servicing printers, for example, or disc drives, was an unknown for the instrument group and yet these products were fundamental to PISCES system performance. And the computer service teams had no comprehension about logic analyzers or emulators, or even the smart terminals that we were supplying. So it took a melding of the strengths of each to satisfy customers. Unfortunately, this became a bit of a political nightmare, since we were proposing to build a 'merged team' across two increasingly separated groups within the larger Hewlett-Packard.

A bigger surprise awaited, which surfaced as we started getting field failures. Our system was failing at prodigious rates compared to historic instruments of the company - rates three to four times higher than anything in anyone's memory. When we'd talk to the computer divisions, though, PISCES failure rates were two, three or even four times better than anything they knew about - mostly due to our more conservative instrument design approaches with components.

My bosses, both at the division and the group level, barked, "What the hell is going on?" The answer was that each group had evolved - from a common history of acceptable failure rates in the 1960s, the computer group found that speed of development was far more important than quality in order to compete. Their failure rates crept up, and in some places even leapt up. But they consistently produced the highest quality computer equipment in the industry nonetheless. Within a decade, the computer group average failure rate was more than ten times worse than that of the instrument group - unnoticed by anyone in corporate, or by customers.

But now we had joined the two in an unholy alliance - and we were simultaneously the worst instruments ever produced by HP, and the best computer systems ever built. I now had three problems. First, the computer group divisions were sore at us for exposing their crappy quality, and bringing them into the corporate spotlight. Second, my bosses were in the instrument group, and so was my sales force. And they were beyond upset with our flawed PISCES system. If your sales team is sore at you, this is not good; if your bosses chime in, that can be even worse. Third, we had chosen an architecture - the expensive shared disc drive - that put the weakest quality link at the heart of the system. And when this failed, a whole team of developers were stranded. Some of our customers were incensed when this situation happened to them.

Engineers are trained to believe that there is indeed a 'best solution' for every problem; other disciplines - philosophy, political science, or business school - teach about dilemmas and compromise. Unwittingly, we had exposed a dilemma in HP's historic organizational model - how do you bridge two autonomous groups when they have each pursued appropriate goals with classic HP values, and arrived at fundamentally dichotomous value propositions? I scarcely perceived at the time that this challenge would soon pre-occupy the next phase of my career.

Break-throughs versus Incrementalism - Lessons Learned

All of the problems described above were largely internal issues - the external world presented its own set of challenges. When Palo Alto management tasked us with the goal of producing a PDS in short order, we began a systematic assessment of our erstwhile competition. For the meeting in autumn 1978, we'd compiled a list of more than thirty competitors who had announced product. Twenty had delivered machines, and eight were outspending us. I decided that it'd be worth understanding who was managing those eight companies, and we put together a list of names for the top four managers (president or general manager, and three vice-presidents or equivalent for engineering, marketing, and manufacturing) for those eight. The forty-third company to announce a PDS, we were really late in a crowded field.

Tektronix, upon learning that HP planned to enter the PDS market, rushed a "poor man's development system" to market, essentially copying the first generation Intellec approach. This enabled them to beat us to market by a year, and their brand name gave them beginning impetus. Unfortunately for Tek, their solution didn't scale to larger code generation requirements of the newer sixteen-bit microprocessor chips. Nor did most of the other competitors.

At the end of our first year of sales, we had 7% of the PDS market, Tektronix had 10%, and Intel had 47%. Within another year, we passed Tektronix, and, except for Intel, trounced the rest - many folded their operations within that year. HP became the "universal emulator" company; the other semiconductor companies approached us to build an emulator for their current best microprocessor, giving designers a choice to cross-target, avoiding the "Intel lock".

Four years later (1984), Intel marketshare had 'shrunk' to 34%, HP was now 21%, firmly in second place, and Tektronix still had 10%. Tek's revenue peaked at $63 million that year. Intel also peaked that year, at $205 million; the 1985 memory chip crisis for Intel was nearly catastrophic. Surprisingly, HP's PDS program surpassed Intel in 1986, with 25% total share.

How successful was our program? Measured in terms of revenues and profits, quite so. It was a rollicking ride. Figure 10 shows revenue evolution of the first fifteen years of this field, a period that cumulatively amassed over four billion in PDS sales. The five years from 1981-1985, the peak competitive years, had sixty percent ($2.4 billion) of those sales.

Intel, with cumulative sales of $1.6 billion by 1987, had clearly defined the category, and used it to superb advantage to sell microprocessor chips. It is hard to imagine today, but in 1981 - the first serious year for HP's PDS in the marketplace - the Intellec was twenty-two percent of Intel's sales, and more than two hundred percent of their profits. At Intel, there were serious discussions about whether Intel should go into the equipment business, but HP and Tektronix entrees by 1982 were blunting both the growth and enthusiasm at Intel for this product sector.

But factoring in the lost momentum for Logic Analyzers, it was a painful experience. I was wedded, emotionally and philosophically, to the logic line. We'd introduced our first Logic State Analyzer in 1973, contemporaneous with the first Intel PDS system. Singlehandedly. we'd defined the sharp distinction between logic timing and logic state analyzers.

HP's pioneering Logic Analyzer line cumulatively sold $150 million, besting our old nemesis Tektronix ($99 million) in the first seven years, through the end of 1980. Those were satisfying years, especially given the doormat status that our 'scopes always suffered (Fig. 11).

We weren't yet familiar with the concept of 'opportunity costs', but events surrounding the choice to shift R&D resources from Logic to the PDS program would demonstrate it beautifully. Tektronix, by deciding to build a "me too" offering for the PDS market, kept the heat on for logic analyzers. Affirming my fears, HP's next five years of logic analyzer sales flattened - in fact, they dropped for several years as Tek's new products took a toll. Once momentum is lost, it is very hard to regain. This was one of the key learnings of the period, and a hard pill to swallow for the HP Colorado Springs team. It would be four years before significant R&D resources were again applied to Logic Analyzers; HP didn't regain the leadership mantle for eight years.

Interestingly, by the time that HP caught Tektronix in Logic Analyzers, the PDS business was ebbing away. Even though forty competitors announced, within five years of entering, Biomation disappeared, and within ten years, Tektronix pulled the plug. HP stayed in for twenty, outlasting even Intel, but it was a relatively brief, if exciting, product arena.

Figure 12 illustrates thirty-three years of sales fortunes ($M/year) of the three key Logic Analyzer vendors - Biomation, Tek, and HP. Intel never produced or sold logic analyzers.

Several clear decision points stand out in Figure 12 Biomation, the original logic timing pioneer, competed successfully for a decade, before enduring a decade-long slow decline. Tektronix, with a strong merged 'scope/logic timing/logic state analyzer (DAS 9100) debuting in 1981, was able to double sales in four years, asserting domain leadership. A bold logic state/timing analyzer, the HP 16500A, answered the charge in 1988 with a significantly improved user interface, high performance, and attractive pricing. This product family doubled HP sales overnight, and cut Tek sales in half as they enduring revenue slide for a decade.

The early 1990's revealed an interesting pattern - both Tek and HP enjoyed healthy growth, each growing more than sixty percent during a period when many more microcontroller designs emerged for both consumer and industrial markets. In effect, the data domain revolution - from an analysis standpoint - had to await the demise of PDS systems before classical analytic tools were widely adopted. The final chapter - Tek overtaking Agilent in 2002 - resulted from the disruptive activities at Agilent after the defocusing divestiture from HP.

All told, Hewlett-Packard and its spin-out test company, Agilent, have sold nearly five billion dollars of data domain equipment, which in turn have fueled incredible designs of almost every digital electronic product that our society uses. Intel Intellecs sold $2.3 billion - but despite what textbooks say about 'first mover advantage' HP was able to surmount the early Intel lead, not to mention all of the other forty competitors. Overall, HP managed to hold and extend its lead over its traditional foe in data domain tools versus Tektronix's long hegemony in oscilloscopes.

What happened to the leadership for this PDS arena? Forty entrees is a lot of competition. Statistics about such a group are seldom collected - it is quite rare that anyone would assemble them. Because I felt like a 'fish out of water' at the time, I'd compiled a list of the leaders at the eight top companies, plus our own team. When I left the Logic program in the spring of 1982, moving to a 'corporate job' in Palo Alto, I found the original list that I'd composed in the spring of 1978. It was an interesting quest to find out 'what happened' to this group of managers.

Of the top four managers for the top nine PDS companies, after two years of PISCES sales, an astounding thirty-one of thirty-six original managers (including ours) had lost their jobs. Several (five) were promoted; one became a multi-millionaire. All lived, though one died of a heart attack a year later. Seventeen lost their wives, a stunning and deeply troubling statistic.

For a number of years, I would tell audiences that such sociology was typical of companies who got caught up in the Silicon Valley feeding frenzy, abetted by too much venture capital and too little time for analysis. And I'd observe that entering a field in a 23^rd or 43^rd position wasn't a very good idea, in terms of putting a marriage 'at risk'. Later, I've come to realize that it doesn't really matter whether your group is first or 43^rd, it will essentially be a brutal competitive tussle for the leadership at every one of these companies.

Yes, it is easier to prevail in a top position if you're among the 'first movers' but it is inescapable that if the venture world considers this field to be able to 'coin money', investment funds will flow for many competitors. Such investments necessarily drive a mind-numbing pace and momentum for virtually all competitors. This clearly is one of those situations akin to what President Harry Truman said: "if you can't stand the heat, get out of the kitchen."

Many studies in recent years have averred that ready access to venture capital fuels Silicon Valley innovation and leadership; this case history reveals a different pattern. Yes, Biomation was a Silicon Valley start-up, funded by angels more than venture capitalists, but Tektronix was a Portland, Oregon company, and HP's operation was in Colorado Springs. Motorola had a sizable group, in Austin, Texas, and Intel's team was half in Silicon Valley, half near Portland. Virtually all of these were funded by corporate investment rather than start-up VC monies, and almost without exception they were not really Silicon Valley companies or divisions. It is true that many of the other forty companies were fashioned by venture capital seed money; it is likewise true that none of them survived. So, this was in effect just solid corporate renewal.

Whether innovation occurs because of opportunity, funding agents, or inspired thought, one thing that stands out in these cases is the fact that no program stands in isolation. These are competitive scenes that have a context, a historical cast, and a feeling that these are marathons rather than sprint races. Nonetheless, each individual project will feel "stand-alone" to the team working on it. Figure 13 portrays an investment scenario (R&D, manufacturing tooling, and market research plus product launch material), and sales revenue on a timeline. The intrapreneur task is to shorten the time and investment 'burn rate' between t -½ and t 1 ½ while lengthening t 1 to t 6 and raising the mature sales rate.

Building on the Strategic Cycle concepts of Figure 8, Figure 13 illustrates successive development phases. In order to build sales momentum, a second product set must be available for sale not long after sales for the first product set mature. Thus, between t 2 and t 3 , a new program needs to be introduced.

Assume for the moment that R&D time will be roughly constant. This means that concept planning and R&D for the second generation (Phase 2) has to start long before the Phase 1 products are introduced. Ditto for Phase 3, where R&D for the third phase must start at the same time Phase 1 goes to market. For relatively slow-moving markets, these requirements are tough enough - for dynamic technologies, they can be daunting indeed.

Figure 14 can be interpreted several ways. Successive phases might be no more than 'line rounding' - relatively simple modifications or additions to an existing technology base - or they might be significant redefinitions of the extant technology or functionality. If the former, the presumption is that continual fast refinement is adequate to remain competitive, whereas the latter is more appropriate where market evolution is fast-paced and requirements are fluid.

Either way, the closely coupled investment requirements are not intuitive to most managers, since the challenges of today's issues often feel quite full-time, precluding any sense of ability to view today's programs in a larger time-context. In my experience, the need to begin investments for tomorrow's phases and even phases for the day after tomorrow determines a group's eventual ability to lead a market. Perhaps the toughest challenge that the intrapreneur faces is to illumine this requirement for nested successive investments to his or her management team.

The difference in the two approaches - breakthrough vs. refinement - can be shown with two parallel programs in the oscilloscope division during the 1970's.

Figure 15 shows evolution from the HP 1700 portable 'scope, HP's first entrée into mobile 'scopes for field support on computer systems, to the HP 1722 portable 'scope with digital readouts, to the substantially higher quality, lower cost HP 1740 that combined some digital and analog measurements. All look similar, and they clearly use similar technology.

By contrast, Figure 16 shows three phases of data domain products from the Logic Analyzer team in the same HP Colorado Springs 'scope division. Each family looks substantially different and they obviously are based on rapidly evolving technologies. Competitors late to the party would have (and did have) a hard time matching these evolutionary leaps.

SEVEN RULES

The stories described herein represent a wandering personal odyssey. There were no books or coaching, nor courses to take in school. I was fortunate to work for Hewlett-Packard, a company led by two engineers whose instincts were to create, to innovate, and to base those innovations on contribution to the customer. Their intuition led them to fashion unique guidelines, 'rules' which insisted that designers, indeed employees in every level and function of the company, innovate. Without knowing the word intrapreneur, they asked each of us to be one.

Here's an HP recruiting advertisement from Electronics magazine, October, 2, 1967:

How could you not learn that contribution was expected of you? As I traveled this path, some supportive 'rules' emerged. Much later, I appreciated just how empowering and unique these ideas and concepts still are for modern corporations. They are an Intrapreneur's Rulebook.

The seven rules describe important leadership choices by which an intrapreneur operates - heavy emphasis rests on rapid-fire exploratory activity, always testing a thesis on a desired audience, perpetually asking "why" of your team, clients, and company approach. But more fundamentally, the rules require a clear focus on the goal - the contribution to be made - and on specific things that are crucial to success: using your team, honoring your supporters, knowing the territory deeply, very thoroughly, in terms of features, needs, and competition.

Since intrapreneurs reside inside a corporation with abundant resources all about compared to an entrepreneurial start-up, they have a decided advantage of being able to tap the best ideas, brainpower and creativity of multiple people - if they will only do so. But to some degree, this requires skill that intrapreneurs and entrepreneurs sometimes lack.

To really empower other folk, you have to allow them space and time to make their own mistakes, learn their own lessons, but especially to imbue their own passion into the tasks at hand. Similarly with your bosses, many of whom will seem recalcitrant, unenthusiastic, or downright hostile to some or many of your best ideas. The secret is to bring them along, to empower them to become part of the success rather than fight them at every turn. These two capabilities - constructing and leading a true team, and encouraging and in effect creating supportive bosses - are well outside the normative prescriptions for 'how intrapreneurs operate'.

There is this pernicious belief that intrapreneurs must be combative, fighting for what should be obvious but isn't, daring the company to fire them almost with regularity. Yes, those elements go with the territory, but only episodically. There will be no long-term success if these fundamental teamwork ingredients are missing. Let's take each rule in turn, and examine it in light of the case studies presented to date:

HP designers used the phrase "Smaller, Faster, Cheaper, Lighter" to connote the classic improvement categories. But the distinctions usually were that it had to be significantly so - ten times improvement rather than ten percent incremental gain. One thousand percent requires thinking about the problem and its possible solution in very different terms than ten, twenty or even thirty percent improvement. A thousand percent? Re-think, restructure the entire problem.

To be sure, not every project did a thousand percent increase, but the idea fundamentally was to make a dramatic, unexpected contribution - easily a 'game-changer' which could then be followed by a rapid succession of refinements. The set might be composed perhaps of something that was a four-to-one improvement, followed by three thirty percenters. This, taken together over four quick-succession projects, would yield nearly a thousand percent improvement - essentially without heroics once the initial breakthrough project was defined.

Such a cluster of projects could be thought of as a Phase in Figure 2-8. For the Logic team, the first Phase was the HP 1601L, followed by the 1600A, 1607A, and 1600S. These four projects, for example, changed the parallel channel tracking from two to twelve, then sixteen, and finally thirty-two while simultaneously changing memory depth from one to sixteen to two hundred fifty-six. All this, plus numerous indexing features and other contributions - each one with the same technology thrust, essentially as one Phase, completed in less than two years.

Phase II was the microprocessor-based suite of products, starting with the HP 1611A, then the 1610A, followed by the 1615A, 1602A and 1640A. With expanded channel count, memory depth, and 'look-and-feel,' the really important contributions were different: on-board calculation, displays in higher-level coded form including mnemonics, ASCII characters, and embedded logic state and timing diagrams. The first of this group was marketed twenty-two months after the last Phase I project; the suite took twenty-seven months for four key projects.

Clearly the original X-Y display was a breakthrough contribution, as were the follow-on projects in both the industrial control market and the medical monitoring arenas. So, as specific projects, these all met the test.

The biggest challenge, in retrospect, was the PDS business. All of the others were inventions, differentiated by the fact that no company was building anything remotely like them. The PDS business, on the other hand, was characterized by a slew of competitors - forty of them announced by the time we decided to enter that warzone. How do you define 'contribution' in that space? And if you don't define a breakthrough contribution, how will you possibly be noticed, let alone prevail? The facts speak for themselves - we really did in fact deliver major new contributions, and we did 'win' in the marketplace with them. How, you might fairly ask, was that done? And that, of course, leads to the next several rules.

As I drove to the airport in Albuquerque with the only extant demonstration X-Y Display box in the world, I mused about the irony of the excitement at the customer site versus the tepid view at my home division. By the time the trip was complete, more than twenty enthusiasts surfaced; I was primed and ready to conquer! I probably should have told someone more forcefully back home, because the marketing department almost scuttled the project when David Packard came by for a project review.

I learned from that one. And I made sure for the d'wuck tour that several people went, and that we got an audience back home. And when the digital 'scope team was assembled, my belief was that each of the designers needed to get 'infected' with customer religion. In terms of passion for what we were embarking on, it paid handsome dividends. You name it - in terms of knowledge, perspective, and desire - the trips built engagement, enthusiasm, and judgment.

When tough questions surfaced, such as the asynchronous trigger issue, we could turn again to our 'customers' and do on-the-ground market research. Very efficient and very accurate. Why more designers don't 'go ask' is beyond me, frankly. Same holds true for CEO's, I think.

The PISCES program coalesced our perspective. Here, a presumptive answer existed in the marketplace - was it good enough? Our team, by now practiced in market 'sleuthing' found that the parameters had in fact changed since the current equipments had been defined. The problem had morphed - into a tougher, more systems-oriented team requirement.

Our team, within limits, had design strengths to step up to a much more complicated solution than anything we'd ever done, or anything available from competitors. More importantly, we had access to superb computer subsystem components from other HP divisions, so if we could 'team-play', we had deep reserves upon which to draw. But because it was a different 'reading' of the marketplace, the naysayers lined up - "too expensive, too late to market, too grand, too much software overhead, etc..." Naysayers often have a lot of fun at these parties.

Through all of this political fog, abetted by the fact that we'd been ordered into this space instead of us being in charge of our own destiny, the meaningful constant was the voice of the intended customer. Know that voice, hear it clearly, and you cannot go too far wrong.

This is a tricky point to make, because you have to do it ethically - I'm not talking about how to hire pretexting specialists or spies, but intelligence gathering of a very different kind. First of all, you should know your true competitors. The fact that we misunderstood the PDS impact for several years is mute testimony to the blinders we wore in that respect re the data domain. We, after all, had defined the domain - "what do you mean, we don't know the key players?" But, factually, we only understood our corner of the data domain world. Big problem!

How to know your competitor? You cannot really call and invite them to lunch, can you? For one thing, there are legal sanctions about collusion with intent to price-fix or otherwise do nefarious things, and who's to know what you talk about in a clandestine meeting. For another, most competitors, upon receiving such an invitation, would say "no" or something more pithy.

So how did I get to meet the Tektronix folk? For Next Gen, it was at a public Trade Show. For the logic analyzer discussions, I was in 'their town' for personal reasons, and they sought me out - I don't know to this day whether they were trying to 'pump' me for competitive G-2 or if instead it was just top designers discussing issues that none of us understood very well. It felt more like a professional society meeting - an IEEE or ACM meeting - which of course is a great way for designers to get together legally, to debate current issues in front of an audience. For all of the PISCES competitors, it was either attending and participating in panels at IEEE meetings or actually being beseeched by several companies to have us include their capability in our new, more generalized approach so that they could concentrate on making chips rather than tools for designers to be able to program their chips. Tools thus were a means to an end, and they were (or at least some managers at their company were) willing to open up with us. By the way, be of no mind that there will be multiple meetings with such folk - it is imperative to use any chance meeting as a great opportunity to learn all that you can about 'the other guy'.

Everyone is familiar with the four-year-old child who constantly asks, "Why?" If you answer, "Well, that is because...", the quick comeback is the same question: "Why?" Such behavior, oft thought cute in children, becomes maddening behavior in business, especially for managers. But for the creative team, the intrapreneuring team, this question needs to be constantly refreshed. New paradigms are unknown, unmapped, with barely discernable patterns. "Why?" matters.

Precisely because asking "Why?" yields multiple answers, it makes sense to build multiple prototypes to test those wide-ranging possible answers. Some will stick, many will not. Those that stick will evolve or morph into something different still; market testing will warp features and even functionality. The speed of evolution is the key here. The game is not to get the first product right so much as it is to get the first product shipped; then, fast turn-around to the next product is much more valuable than extra time to get the definition 'right'.

For engineers, who constantly love tinkering, this might seem an easy point. But engineers like to tinker upfront, to iterate the specifications before completing a prototype rather than buttoning it up and shipping the erstwhile product to a real customer. The process I found much more effective was to imagine that the shipped products - versions 1, 2, 3 and so forth - were the tinkering experiments. And that, for perfectionist engineers, is psychologically a struggle. But I would urge you - iterate like crazy, with products 'on the market', or at least, 'out of your lab'.

Teams come in many sizes - and they may or may not be collocated. For the X-Y Displays, our team was quite small, but each member contributed heavily to the definitions, possible users, and specific skills and tasks. For the d'wuck , different members of the small team contributed features - features that the next team, the digital 'scope team, spent time validating and refining, before dismissing some ideas and pursuing new ones. As the various logic products were first introduced, the learning from each experiment informed the group for the next set of definitions.

Until Phase II of Logic Analyzers, our 'team' was our local team. But in discovering that we needed to educate the HP sales force and some key faculty at universities teaching logic concepts, we began to understand the idea of 'extended teams'. Building a working team requires several things - a shared goal is imperative, and balanced rewards are important. But we found that mutual trust was perhaps the most important element - trust that every member will be respected, nurtured, and valued. Such a phrase is easy to write, and easy to say. It is profoundly difficult when things aren't going well and stress levels are rising - which is precisely when it is most crucial to maintain trust.

PISCES presented special challenge for our notion of teamwork. For the logic lines, it was relatively easy to establish collegial relationships between us and the sales force - they were paid well if they could sell our products. Ditto for the university professors - their co-operation was rewarded with equipment grants. For PISCES, the major reward for collaborators at other HP divisions was psychic - Hewlett's personal legacy with the company was an expectation that any group would help another when it was possible to do so, but there were no monetary or direct rewards for being a good corporate citizen.

Thus, our requests - especially for modifications to some key technical material - were above and beyond the normal call of co-operative teamwork, especially because we had no 'tradebait' of consequence for any of them. Relationship management - teamwork supported by friendship and shared 'higher-level' psychic reward 'for the good of HP' - was the only rationale available.

Teamwork built on such threads can work in a strongly collegial culture; these bonds become tenuous as people move around or leave the company, or the personal touch becomes infrequent as the company grows larger. Groups that have learned to develop and maintain such ties for key partnerships enjoy much better productivity and effectiveness as a rule - but often the root reasons, which themselves take time and effort, are obscured from management understanding.

This often gets stated - particularly in Intrapreneurship courses - as "honor your sponsors". Which in itself is both appropriate and affirming. Many intrapreneur sponsors have had to 'go out on a limb' to back an unpopular idea and/or person - counsel to honor them is well-placed, and this rule can be interpreted to include them. But here I am trying to get at something deeper, to get at the core sometimes of the real problem - honoring your most active opposition, almost precisely if they are your bosses. Find ways to understand their concerns - treat this as a market research question: "what would it take to have them understand and support you?" The best example to illustrate this was the conclusion that we had to create a workshop to teach the Colorado Springs executive team about microprocessors and the needed measurements in order to fund our Phase 2 program. The course was revealing to them in a relatively objective manner, giving them personal insight into the design issues of these new chips, and the value of our programmatic solutions. They still had lots of resource constraints, and some personal prejudices to boot, but the ambiguity or even obscurity of what we were trying to accomplish had been stripped away. Future discussions had the characteristic of reasoned negotiations rather than dictatorial fiats. In short, by honoring our bosses' comprehension needs, we reduced antagonism greatly and moved toward support.

A second example, more profound in some ways, was honoring the Palo Alto leadership who had forced us to go into the Product Development System business. They were not high on our list of favorite folk, and we had spent considerable time debating how to bring our own brand of insouciance to the table with the bold PISCES definitions, so the requested review augured to be acrimonious. The solution - to honor our Palo Alto bosses by inviting a wide coterie of their trusted lieutenants, and creatively and actively engaging with those visitors on 'the merits' of our program rather than spending time on charter fights, territorial imperatives, or past history of various divisional slights. Not only did this win points for our openness and candor, winning a chance to continue, but it surprisingly led to an infusion of more investment when the visitors urged 'go faster, this is terrific.' We couldn't have made the case as well as they did for us.

Menlo Park C.A.
January 17, 2012

Charles H. House

References:

Click here to download the"Logic State Analyzer Birthing Pains" - The 58 pages document is a 1.5 Mb PDF file.