Posts Tagged ‘DARPA’

A CTO’s List of New Year’s Resolutions

December 30, 2009

Dilbert.com

There are many ways for Chief Technology Officers to be undone.   Appropriately enough  — in light of  Friday’s  college football bowl fest —  being an effective CTO is  like being a college football coach.  You don’t actually do the blocking and tackling yourself, but you’ll fail if the fundamentals are not done right —  even if your game plan is perfectly constructed.  I will have more to say in an upcoming  post about game plans, but today I want  to recognize the arrival of the  New Year with a short note about the fundamentals.

George Heilmeier, former DARPA Director, Bellcore CEO, and the inspiration for my” Guess Who’s Coming to Dinner?” series[1][2][3] was a mentor to me and to many other  technology leaders .  One day I asked him for a bit of career advice, and he hauled out a Heilmeier list — twelve  rules for CTO’s to follow if they have any hope of navigating the many dangers of the colliding worlds of innovation and execution.  I quickly found out that, true to form,  George had reduced best practices to a few rules of the road because dozens of others had asked for the same advice.  They are fascinating and valuable bits of advice, and they range in scope from broad business fundamentals to technology and culture.   I haven’t come across anyone who thinks that they are not important lessons — not to tuck away for future use, but to internalize and use as a platform for technology management in any setting.  It was December , so I turned George’s list into New Year’s resolutions.

  1. For each “client” establish/conceive a list of technologies and initiatives that drive his business and a list of technologies and initiatives that could change his business.
  2. Use the Catechism to get people to focus on the real “care-abouts” when making investment decisions and establishing priorities.
  3. Establish the physical, economic, and manufacturing limits of the technologies and capabilities that drive the business today.
  4. Establish a good working relationship with your peers
  5. Establish what [insert name(s) of  your CEO and Chairman] real priorities are.
  6. Establish the metrics for success in their eyes.
  7. Don’t shy away from doing some near term problem solving.  It builds credibility and respect.
  8. Never have your peers or clients come to your office for meetings with you.  Go to theirs.
  9. Any display of arrogance will cost you. Don’t do it.
  10. Compile a list of “innovations yet to be made”
  11. Make sure that each program or initiative is output oriented not activity oriented.
  12. Learn the [insert your company name here] culture.  It is unique.

Have a happy and safe New Year, and, by all means, don’t get caught when worlds collide.


[1] http://richde.wordpress.com/2009/09/22/guess-whos-coming-to-dinner/

[2] http://wwc.demillo.com/2009/10/11/guess-whos-coming-to-dinner-part-2/

[3] http://wwc.demillo.com/2009/10/19/guess-whos-coming-to-dinner-part-3/

“Dear Mr. Watson, My employment with IBM has been terminated” (More Loose Cannons)

November 3, 2009

Dilbert.com

There was a birthday celebration of sorts last week.  From the October 29th edition of  ABC News Science & Technology:

While the actual date of the Internet’s birthday is somewhat debated, many say that the Internet was born 40 years ago today at the University of California, Los Angeles, when a computer to computer message was sent for the first time from the UCLA campus to Stanford.

At the time, Leonard Kleinrock and his colleagues were charged with developing the Advanced Research Projects Agency Network (or ARPANET), a government-funded research project in global computer communications that eventually grew into the Internet.

I thought it would be a good occasion to  reflect on how easy it is for Loose Cannons to get smashed by colliding worlds.

In the days before ARPANET, computer-to-computer communications were homogeneous, and computer manufacturers liked it that way. The very idea of not owning every aspect of a technology stack seemed to be ridiculous.  Where’s the value if you can get critical components from anywhere?  What if competitors start using the same suppliers?  Heads of business units hated the idea, but Loose Cannons kept proposing technical architectures that looked, well, open.  The idea was playing out in many ways in many companies.

At IBM, two architectural revolutions were simultaneously  underway. We now know that they were related. In the summer of  1980, IBM executive Bill Lowe prepared to brief  the company’s Management Committee on development plans  for a personal computer:

It was a dangerous place to be.  The Management Committee — or, given IBMers’ fondness for acronyms, the MC — ruled on issues that couldn’t be resolved at lower corporate levels, so going before the committee was, to IBMers, like going before the Supreme Court.  It was actually rougher because the top IBM executives who sat in judgment were known to be brutal, especially if they thought someone was wasting their time.[1]

Bill Lowe had been beaten up by the MC before, but this time Lowes’ plan to use outside suppliers drew polite questions from MC members who expressed some concern about turning over even partial control of any of their businesses to “outsiders.” What Lowe and the vast majority of IBM engineers didn’t know was that earlier in the year the MC had received a  forecast for global PC sales that showed a peak market of 80,000 units in that began to rapidly decline in 1984 as the specialized customer  need for computers was satiated:

IBM had already been embarrassed by early missteps in the PC market but the corporate culture was focused on mainframes and services.  Problems might be created by opening up the hardware and software architecture of personal computers, but

The general attitude…was that you don’t have big problems in small markets, and we thought the personal computer was a very small market.[1]

The MC might have been more inclined to turn its attention to a market that had real legs.  Like, say, networking.  Ed Hendricks was an engineer at IBM’s Federal Systems Division in San Diego.  Hendricks had helped design VNET, at that time the largest computer network in the world.  VNET was  IBM’s internal corporate network, linking IBM mainframes at scientific data centers.  By 1980, VNET was a global asset with hundreds of  hosts in North America, Europe and Asia.

Meanwhile, ARPANET was growing into the Internet, and Ed Hendricks was interested in how IBM’s technology would continue to prosper when the world started connecting IBM mainframes to large UNIVAC computers, HP mini-computers,  PC’s, and supercomputers from Cray or Control Data.  Hendricks became an industry player in this arena, collaborating with my colleague Larry Landweber at the University of Wisconsin as the expansion of the ARPANET began in earnest. Ed  Hendrick’s IBM Internet Gateway Project was aimed squarely at insuring that IBM mainframes would not be stranded in a world in which they could only talk to each other:

The objective of this project is to begin to bridge the gap between IBM computer systems and network technology predominant among government agencies, conractors and universities.  More specifically, we are working to develop according to DOD standards the technical capacity to interconect networks of IBM computers and systems to similar but different computer networks used by government agencies and their affiliates.

Hendrick’s website preserves the sometimes heated but  thoughtful and deep technical discussions — involving Hendricks,  the legendary Jim Gray, and MIT’s Jerry Saltzer, among others –  that took place througout 1980 about the relative merits of ARPANET and IBM’s networking strategy. For reasons that are still unclear, IBM decided to move the Internet Gateway Project to IBM Research in Yorktown Heights, New York, an effort that Hendricks calls “screwy.”   Hendricks along with team members Gerot “Mike” Engel and Dale Johnson planned to spend a week at Yorktown Heights, getting comfortable with IBM Research’s Systems Laboratory, their proposed  new home:

…the Systems Laboratory was created to focus more directly on perceived business needs. Consequently, Systems Laboratory projects are evaluated and prioritized on the basis “leverage” they exert on the software product line…by design, ninety-five percent of the work carried out in the Systems Laboratory is so closely related to strategic product development that it cannot be discussed outside IBM.

Shocked, the Internet Gateway team concluded:

…a project such as ours which is intended to establish internet communication compatible across differing systems…could not be carried out under such guidelines.  Our overall reaction…was that the ARPANet Internet Gateway project could not have been started within the Systems Laboratory.

They concluded that if the project was to have any chance at all of success, there would need to be a formal review of management decisions, what  IBM called the “Open Door” process.

March 14, 1981

John R. Opel, President IBM Corporation

Dear Mr. Opel,

This letter is intended to invoke the IBM Open Door Policy.  My purpose in requesting this Open Door is to seek clarification of the decisions which led to a situation where a project which is clearly critical to IBM’s future posture in the data communications industry cannot be pursued…Bureaucratic accomodation for only that which is in the strategic plan is a very dangerous posture to be in while the data processing and communication industry is rapidly evolving.

[My team and I] have been working to carry out a project to establish a capacity…to cooperate with the U.S. Government and University Computer Science departments in the evolution of techniques to interconnect dissimilar computer networks…There is essentially unanimous agreement that this activity promises important advances for IBM and for computer technology in general.

In September 0f 1980 we were notified by our management that this work could not be carried out…On each occasion when this qustion [of where the work could be carried out in IBM] was being escalated to the proper level, my management would insist that I leave the management issue to them and to concentrate my own efforts of the technical work.

Last week I was informed verbally that no sponsorship for this project could be found.  My manager asked where hie should look to find me a job. My position was…that inability to find organizational sponsorship for the project is not equivalent to a decision that IBM should not be involved in developing the capacity to interconnect IBM networks to government and university networks…to look for other professional opportunities now and give up attempts to pursue this technology…would be to let the company down….

Sincerely yours,

Gernot Engel

19 March 1981

Mr. Thomas J. Watson, Jr., Chairman Emeritus

Dear Mr. Watson,

My employment with IBM has been terminated as a consequence of recent management decision which are incompatible with my professional goals…I believe I am justified in requesting more thorough and explicit responses to the following questions:

  1. What “business needs required the termination of our ARPANET Interconnection Gatweway Project and the abandonment of the…professionals we had been dealing with?
  2. What factors prevented alternative organizational arrangements that would have allowed our group to continue its work within IBM?
  3. What is IBM’s posture regarding professional cooperation with the computer scientists working in association with DARPA…to establish mutual techniques for interconnection of dissimilar computer networks?…

Sincerely yours,

Gernot Engel

May 15, 1981

John R. Opel, President IBM Corp.

Dear Mr. Opel,

On March 4, 1981 I sent a letter to your office requesting clarification of a decision which cancelled the internet gateway project…Your office’s attempt to analyze the internet decision appears to be stalled because it was handed back to middle management….I can only conclude in this instance the Open Door Policy has failed. My recommendation to salvage the situation is that you give fifteen minutes of your time to receive a presentation on the internet project and attempt to evaluation for yourself the value of this project to IBM’s future.”

Sincerely yours,

Gernot Engel

May 19, 1981

Dear Mr. Engel,

I have reviewed the results of [the] investigation into your concerns.  Your disappointment with the decision to terminate the VNET/ARPANET project is understandable; however, I conclude the decision was properly based on the need to fund other Ad Tech projects with greater business potential…

I understand you are currently considering a return to IBM, and I hope you choose to do so.

Siuncerely,

John R. Opel

Number 1-81: September 11, 1981 MANAGEMENT BRIEFING

TO ALL IBM MANAGERS:

Organizations seem to have an irresistable tendency to codify successful practices in rules, instructions and controls which soon begin to take the place of judgement. When that happens, the result is bureaucracy.

IBM is not immune.  Earlier this year, reports from many sources indicated to me that a growing bureaucracy is affecting the performance of our business…corporate staff heads, group executives, and the division presidents are exploring ways to reduce unnecessary controls, rules and approvals in their areas of responsibility…We will succeed in that effort only if you managers, at every level of the business,k are willing to stand up and fight bureaucracy wherever you find it…If you have all the information to make a decision, make it…

[signed by John Opel, president]

John Opel stepped down as IBM president in January 1985 and chairman in May 1986.  He was succeed by John Akers, and he was succeeded by Lou Gerstner in 1993. Gerstner, the former CEO of RJR Nabisco, described his transformation of IBM in “Who Says Elephants Can’t Dance?”[2].  Most observers agree that critical to IBM’s turnaround that took it from a free fall in the early 1980′s to unquestioned market  leadership in computers, software and services was the dismantling of a remote, hierarchical management culture that squeezed innovation in political pincers.  By the time I took over the computing research directorship at the National Science Foundation in the late 1980′s, IBM had become a major player in the growth of the Internet [3]:

In the mid-1980s, NSF decided the time was right to try to link its regional university networks and its supercomputer centers together. This initial effort was called NSFNET.
By 1987, participation in the new NSFNET project grew so rapidly that NSF knew it had to expand the capacity of this new network. In November of that year, it awarded a grant to a consortium of IBM, MCI, and a center at the University of Michigan called Merit to create a network of networks—or inter-net—capable of carrying data at speeds up to 56 kilobits a second. By July, 1987, this new system was up and running. The modern Internet was born.

REFERENCES

1. Paul Carroll, Big Blues: The Unmaking of IBM, Crown Trade Paperbacks, 1994

2. Louis V. Gerstner, Who Says Elephants Can’t Dance? Inside IBM’s Historic Turnaround, Collins, 2002

3. National Science Foundation, NSF and the Birth of the Internet, http://www.nsf.gov/news/special_reports/nsf-net/textonly/index.jsp

Guess Who’s Coming to Dinner, Part 3

October 19, 2009

Note: This is a continuation of my Guess Who’s Coming to Dinner posts about the power of including innovators in strategic decision-making.

It took George Heilmeier an afternoon to convince Secretary of Defense James Schlesinger of the value of DARPA’s six “silver bullets”, capability-changing technologies that could guide system designers for the next decade:

  • Create an “invisible aircraft”.
  • Make the oceans “transparent”.
  • Create an agile, lightweight tank armed with a tank killer “machine gun”.
  • Develop new space based surveillance and warning systems based on infrared focal plane arrays.
  • Create command and control systems that adapted to the commander instead of forcing the commander to adapt to them.
  • Increase the reliability of our vehicles by creating onboard diagnostics and prognostics.

“Invisible aircraft” refers to the stealth technology that led directly to the F-111A Nighthawk and is good illustration of how innovators can influence events by focusing on business objectives.  In those days, half of the aircraft in a strike mission were there, not to fire weapons, but to detect and disrupt enemy radar.  Reducing aircraft radar cross-sections by a factor of 10,000 would lead to a ten-fold reduction in radar detection range and a corresponding increase in mission effectiveness.  Classified research in stealth technologies – mainly materials science – had been under way since the 1950’s, but DARPA’s idea was to use stealth as the primary criterion for aircraft design.  Performance and stability are the first casualties in this kind of design, so George knew that, not only would he have to integrate all of the component technologies it would take to produce a flyable, battle-worthy airplane, he would also have to convince the Air Force – run by and for pilots – of the usefulness of this way of designing an airplane.  Pilots understandably wanted to think that aerodynamics would be uppermost in the minds of designers, but DARPA wanted to turn that principle upside down.

The world changed after that.  By the 1980’s many high-performance military planes operated so close to the their performance envelopes that they were difficult or impossible to control without computerized assistance.  There was, in fact, a sort of dark  murmur among military pilots who understood both avionics and computers.  I was directing software test and evaluation oversight projects for the Director of Defense Test and Evaluation at that time.  One of our systems was an advanced fighter aircraft that was being retrofitted with computerized flight controls.  Some of the test pilots had done graduate work in computer science, and were clearly comfortable shifting between flying jet fighters and thinking about computer software.  One of them had a poster taped to the wall of his cubicle.  It showed a mocked-up  pilot’s eye view from the cockpit of a military  airplane that was clearly spiraling into the ground.  On the heads-up display was a graphic that looked something like this:

>>ATTENTION. FATAL ABORT.

>>GENERAL EXCEPTION FAULT 1080XX.

>>PROGRAM ABEND AT LOCATION 001001010111011.

>>RESTART PROGRAM? Y/N

We were talking about an operational test that he would be flying the next day, but all I could do was stare at the poster. I was a software tester.  I knew that fatal error messages like this were common. They came bundled with the price of the software. Most graduate students knew it, too. I thought to myself “This is the bravest guy I have ever met.”

In approving the silver bullets Schlesinger had promised to keep Pentagon staff off  Heilmeier’s back, but the Air Force resisted DARPA every step of the way:

During this period, the Air Force was not at all supportive of DARPA designing and building aircraft and would not cooperate with us.  We needed their help but received none.  As a last resort, I went to see AF Chief of Staff, Gen. David Jones to plead the case. When I entered his office, I was shocked to see that the general, who had refused to help us in no uncertain terms, was present.  I thought that the program was dead and me with it.[1]

Jones listened to George’s pitch, turned to his reluctant General and said, “We’re going to help these guys.” It was not a question.  Whether this was a directive from Schlesinger or a result George’s powerful presentation is not really important.  The Air Force cooperated from that point on, and on the morning of December 1, 1977, George watched from the end of a runway at Edward Air Force Base as the first prototype of a stealth aircraft took off.

Tying a technology agenda to business goals empowers both sides, and it puts both the passive and active resistors in an organization in a bind.   The cost of resisting change is to put their own goals at risk, often with unpleasant career consequences.  It also allows technology leaders to form new agendas that bypass an unmovable bureaucracy.  Here is how Heilmeier summarizes these lessons:

  1. When you really believe in a concept and the people involved, practice “no excuses” management.  The meaning of this is that you must remove all of the bureaucratic impediments to success.
  2. “Breaking glass” and going around the bureaucracy can be done if you believe in your cause and refuse to quit.
  3. In a game changing initiative, a small group must take on a larger group who won’t always “play fair”.

The danger in this approach is  that success depends almost entirely upon personal commitments, and those commitments can easily be undermined by a change in leadership.  When that happens — as I know from personal experience –  entrenched interests  come roaring back, hell-bent on toppling whatever was achieved.  The time frame for achieving goals has to fit within the tenure of the “small group” because worlds will inevitably come crashing together.

I will have more about this is a later post.


[1]George H. Heilmeier,  “A Moveable Feast – Kyoto Prize Lecture (SD Version)” 2005

Guess Who’s Coming to Dinner, Part 2

October 11, 2009

Dilbert.com

Being “technology driven” is often not the best path to real innovation.  Part 1 of this post was distilled from a conversation with George H. Heilmeier, former director of DARPA, CEO of Bellcore, inventor of the liquid crystal display and winner of the 2005 Kyoto prize. It was based in part on the “Heilmeier Catechism”, an approach to technology strategy that begins, not with the technology but with the business problem to be solved.  It was shared widely with the many younger managers who came under George’s influence over the years, and I have heard from a fair number of them in recent weeks.  All had their own stories to tell about why the approach of “selling to investment bankers” was exactly the right way to think about positioning R&D in a larger organization.  In all of our discussions, George has always been insistent about two things: the negative power of vested interests and the failure of  technology transfer by “throwing technology over the transom”.  Out of this came his notion of an “interdisciplinary team” with representation from R&D, product engineering and manufacturing, where leadership and balance shift as time goes on. This is the dinner table.   As important as these ideas are for day-to-day management of R&D, they are critical when it comes to initiating projects that are transformative, where commitment to change comes from handshakes at the top of the organization.

Shortly after the Regional Bell Operating Companies began divesting themselves of Bellcore, but before George stepped down as CEO, the appetite for applied research began to change.  To some extent, this was part of a natural evolution of the company from a captive R&D Lab to a stand-alone corporation whose owners – eventually the employee-owned defense systems integrator, Science Applications International or SAIC — demanded not only profitability but also growth in a market that was already growing at 15% per year.   The “30/30 Frontier” (30% revenue growth with 30% operating margins) was a wake-up call for all R&D managers in the company and it was a personal lesson for me in how to engage corporate management with initiatives that were tied to  bet-your-job objectives.

I was in charge of computing research at the time,  and three things were important to me.  First, was Heilmeier’s  commitment to funding forward-looking work at the corporate level, which meant that annual spending goals had to be set by reaching a consensus among product, research,  sales, and marketing teams.   Second was the freedom that Bob Lucky  — Bellcore’s senior VP of Research –  gave to his senior leaders to push the boundaries of the business. Third, was the collaborative but demanding relationship that I had with Chief Operating Officer Sanjiv Ajuha, who was himself a veteran software development manager.

Sanjiv was in turn looking for three business advantages that at first blush seem to be mutually contradictory.  The first two were obvious: near-term competitive advantage for the company’s large software systems and  game-changing inventions that would shake up the marketplace in the long run.  The third was revenue against which corporate R&D investments could be scored.  Near-term objectives were rolled up into product R&D costs while long-term objectives were used in 3-5 year investment planning.  Scoring R&D spending against revenue hardly seems like a competitive advantage but in my view it was the critical piece of the puzzle because it forced us to run a business.  It forced us to operate a business unit with profit and loss goals, not just another corporate cost center (which tend to develop unhealthy  entitlement cultures).   It also forced us to be very hard-nosed about tracking research contributions that led to revenue in existing product lines.  I would like to think this is a classical WWC strategy because it made us  focus externally on business objectives that affected the entire company.

I’ll have a lot more to say in later posts about some of the tools we used to do this, but the example that Heilmeier kept in front of us – because it took some convincing to make sure the lessons stuck – is for me the most compelling part of this story and the one I returned to time and again as I found myself inventing new frameworks in other organizations.

As DARPA Director, George reported to Nixon’s Secretary of Defense James Schlesinger.  Schlesinger himself had impressive academic and technology credentials.  He had served as head of the Atomic Energy Commission and Director Central Intelligence. Schlesinger’s DARPA operated like a technology incubator full of “technology entrepreneurs” as Heilmeier called his staff.  Under Heilmeier, DARPA settled on six over-arching themes, all of them aimed at somehow changing the nation’s military posture in ways that would be understandable not only to the Secretary but also to the staff and line officers who were frequently unhappy with DARPA’s “help”:

  • Create an “invisible aircraft”.
  • Make the oceans “transparent”.
  • Create an agile, lightweight tank armed with a tank killer “machine gun”.
  • Develop new space based surveillance and warning systems based on infrared focal plane arrays.
  • Create command and control systems that adapted to the commander instead of forcing the commander to adapt to them.
  • Increase the reliability of our vehicles by creating onboard diagnostics and prognostics.

Each of these “silver bullets” was so directly tied to a military objective that it took only a single meeting with Schlesinger to get his buy-in on the entire agenda.  In my next post I will describe how these technology challenges were turned into military capabilities and why it’s an important lesson for today’s climate where innovation and execution often seem to be at odds.