A few years later — in 1982 — my close friend Wayne Holder hired me into his nascent software company, Oasis Systems, in part to help with his existing and planned word processing utilities (The Word Plus, Punctuation + Style), but mostly to develop computer games. And we did, developing Sundog: Frozen Legacy on the Apple II, a game for which I still get e-mails (and which Wayne is even now working on resurrecting for modern platforms). In January 1984, a few months before Sundog shipped, we were invited by Guy Kawasaki to come up to Apple to see a preview of the Mac and to talk about what software we could port to the Mac. Through my connections with computer stores in San Diego, I was able to get a personal loan of a Mac for a few days at home prior to the official announcement in Cupertino later that month, which Wayne and I attended as well. That was my first time seeing Steve Jobs in person, and it remains a memorable highlight of my professional life.

When the Mac shipped a few days later, I went down to the one computer store in San Diego that I knew would be getting machines from Apple. I took $3000 in cash with me and managed to convince the store owner — a friend — to let me have one of the three Macs he had to sell. Through a connection with Phil Lemmons — editor-in-chief at BYTE — I ended up writing the official BYTE review of the 128K Macintosh (August 1984 issue). By the end of 1984, I was writing full-time for BYTE, including on-going coverage of the Macintosh, particularly once my BYTE column started in mid-1985. After a few years of writing for BYTE, I switched to writing for Macworld magazine. Steve was now long-gone from Apple, and Apple was having some of its own problems going forward.

But in late 1987, I was contacted by Addison-Wesley. They were interested in having me write a book about Steve Jobs’ new project at NeXT. Folks at NeXT had apparently suggested me to Addison-Wesley, probably due to my writing at BYTE and Macworld. I leapt at the opportunity, particularly since in coincided with our family moving from Utah to just outside Santa Cruz (where I would be doing technical writing for Borland on a consulting basis). Once there, I found myself invited to visit NeXT HQ on Deer Creek Road, sit in on meetings, and attend the 0.3 NeXTstep Dev Camp. And, yes, that meant getting actual face time with Steve Jobs as well — not a lot, but this was a man whose creations had been impacting my personal and professional life for over a decade at this point.

The writing of the book dragged out as I waited to get my hands on an actual NeXT cube, which finally happened (if I recall correctly) at the end of 1988 or early 1989. I wrote the first several drafts of the book on that NeXT cube itself. The book came out in the fall of 1989; it remains the single most successful book I’ve ever written, due to the intense interest in NeXT itself, more than any particular writing skills or technical insight on my part.

The following year, I found myself working with a world-class typographer (Mike Parker) and graphic designer (Vic Spindler) to create a design-oriented desktop publishing system. I was doing all the software prototyping on my NeXT cube, and we made the decision to make the NeXT our first target platform. For five years — 1990 to 1995 — I served as chief architect and CTO at Pages Software Inc, where we developed Pages by Pages and then WebPages, while spending nearly two years just trying to raise venture funding. We closed on funding at the start of 1992 and shipped our first version of Pages in early 1994. We quickly sold all that we were going to in the all-too-small NeXTstep market. My frustrations at seeing larger firm try to leverage off of NeXT’s incredible innovations led to an op-ed piece in the November 1994 issue of BYTE, “Whither NextStep?” The day that issue came out was the last time that Steve Jobs and I spoke — he called me from the back of a car somewhere to ask me what the hell I was doing writing that. I said, telling the truth. Pages would close its door the next year, unable to secure additional funding to move its technology to Windows.

When Steve engineered his brilliant reverse takeover of Apple — getting Apple to buy NeXT for $400 million, then slowly moving himself into the CEO seat — I was not optimistic. I still had unconditional praise for the NextStep technology, but I was dubious about Steve’s ability to sell technology to markets and to compete with Microsoft.

Boy, was I wrong. I was not only wrong about his abilities at Apple, I was wrong in my BYTE article about NextStep being on a downward slope. NextStep, of course, was the foundation of Mac OS X, and Steve transformed Apple into the most-admired, most-imitated, and most-valuable company in the world. And I was tickled that, when Apple brought out its own word processor, it was named “Pages”. Steve had always liked that name when we were developing (and shipping) our own product years before; glad he was able to use it.

To quote John Perry Barlow over on FB, “The world is suddenly a less interesting place.” ..bruce w..

[1] The first was an HP-67 card-reading programmable calculator.

[Cross-posted from And Still I Persist]

I’ve joined Google fairly recently after spending nearly a decade at MSFT, and I’m having to unlearn a ton of things I’ve learned at MSFT.

First, I had to unlearn that my opinion doesn’t mean shit. Engineers do, in fact, run Google, and I’m an engineer. A LOT depends on engineers here. Barely anything depends on the management or PMs. The comfortable, asphyxating bureaucracy of Microsoft simply does not exist. It is up to you to define the direction, and execute on it. If you’re good, you will also get other people to execute on it, by means of which you will establish yourself as a leader.

Second, I had to unlearn that my teammates are plotting something behind my back. As far as I can tell a few months in, they aren’t. Or they’re so skilled at it that I don’t see the plot (which after 10 years at MSFT is unlikely). They’re just building a product.

Third, there’s no “jihad” against anyone. Not even Microsoft. People are discouraged from thinking in those terms. No one is trying to “kill the fucking Microsoft”. No one is throwing chairs or calling Ballmer a pussy. People just build their products and services the best they can.

Fourth, there are very few people who can say “no” without motivating their answer with data. The first answer you will hear from anyone (including Legal!) is “yes”. It’s not blind acceptance or anarchy either, it is expected that you will motivate your changes, with data, if necessary. Want to change the way Google runs ads? If your change makes sense and you can demonstrate it, it will be accepted. Search? The same. This one is particularly hard to unlearn – after burying so many great (or at least I thought they were great) ideas because they weren’t _politically_ feasible, sometimes within the same extended team.

And so on and so forth. I wasn’t a bad performer at MS by any means (left the company 5 levels up from where I joined), and as a matter of fact I admire bits and pieces of Microsoft to this day, but Google made me realize just how miserable I was there. I don’t yet feel Google is the ideal place for me either, but one thing is clear – it’s much easier to breathe here, if you know what I mean.

When I wrote The Art of ‘Ware back in 1994, I came away from it with a greater appreciation of why Microsoft had achieved the success that it had. It appears that Microsoft has lost its way. ..bruce..

What is interesting about Holmgren’s hire is that it is modeled after Bill Parcells role at Miami – The Football Czar.  He’s not the head coach and he’s not the GM (who usually handles personnel).  Instead, he is something else.  It is a role that leverages his expertise as a position coach, a head coach and a GM.  One that sees the bigger picture and is able to evaluate players AND coaches from a fresh and more independent perspective.  It is a position created to drive the “rebuilding” of a program – something Miami and Cleveland badly need.  In Parcells’ case, he took an 1-15 team and got it into the playoffs the next year with an 11-5 record.  Part of the Parcells formula is to bring in a core of coaches and players that he trusts and who know his systems, both offensively and defensively.

Be sure to read Curran’s entire post, plus the robust debate in the comments that follow it.

Of course, Ruby and I also used the football analogy a few years ago in suggesting a radically different approach to IT organization and leadership. As we wrote:

The bad news is that, unlike in football, the business and IT sides of a firm don’t always agree on what constitutes a ‘victory’ (even though both sides can usually agree on what a ‘loss’ is, at least in cases of total or significant project failure). Indeed, sometimes they cannot fully agree on what the game is.

Curran’s IT Czar role could in theory solve that; I like his proposals and approach, and, of course, I like the sports team analogy.

The problem is, it’s hard to see how upper management would treat or perceive it as being any different from the current CIO role. Both as a consultant and as an expert witness, I’ve had lots of opportunity to see just how  constrained the CIO slot can be in large organizations. A lot of the blame for that rests squarely upon the CEO and other CxO leaders, both in terms of whom they select for the CIO job and how they define/constrain that job. CIOs tend to be selected from business-types with some technical background, as opposed to technical types with some business background. Curran’s analogy (e.g., Bill Parcells) suggests that the czar be someone who has been down in the trenches (e.g., position and head coach) and knows what day-to-day IT development requires, but that’s not who usually gets picked.

The closest model to an IT Czar that I’ve seen that has worked were the various corporate Y2K ‘czars’ who were appointed 10+ years ago to save the officers and directors from any Y2K liability, and thus were given lots of power and pretty free rein. (A joke from those times — Q: What’s the difference between a terrorist and a corporate Y2K director? A: You can negotiate with the terrorist.) An IT czar appointed to ‘turn around’ an organization’s IT efforts would have to be given that same power and freedom. That is not likely to happen unless, as with Y2K, the corporate officers and directors see themselves at risk — professionally, legally, financially and/or personally. Otherwise, as noted above, the “IT Czar” would be just another CIO.  ..bruce..

When funds are exhausted, then money is raised under pressure. Control is lost and equity surrendered to supply the needed resources.

One of life’s great ironies is that the worst time to raise money is when you really need it, because that’s when you agree to the most unfavorable terms. The logical conclusion, then, is to start working raising money well before you need it. If you end up not needing it, so be it; but if you do, you will have done the work in advance. That’s also important, because it takes time to raise money.

Try to gain resources from the competition. Each dollar gained from or spent by the competition is worth two dollars raised and spent by yourself.

You can leverage off your competition by learning from their market research, analyzing their plans and products, and buying their technology. Chapter 13 (”Gathering Intelligence”) will have more details and ideas.

Reward employees who recruit from competitors. Merge those recruits with your own and win their loyalty. This is called weakening the competition while increasing your own strength.

If your developers had wanted to work long hours just for lots of money, they would have become lawyers. They do it for bragging rights — for the right to say, “Yeah, I helped create that product” — and for a chance to change the industry and maybe the world. It may be hubris, but then again, the world really has changed because of products created by technology developers over the last fifty years — and the most dramatic changes are yet to come.

==========================

Compare suntzu pingfa (Chapter 2: “Doing Battle”):

Take equipment from home but take provisions from the enemy.

Then the army will be sufficient in both equipment and provisions.

When all strength has been exhausted and resources depleted, all houses in the central plains utterly impoverished, seven-tenths of the citizens’ wealth dissipated, the government’s expenses from damaged chariots, worn-out horses, armor, helmets, arrows and crossbows, halberds and shields, draft oxen, and heavy supply wagons, will be six-tenths of its reserves.

Therefore, a wise general will strive to feed off the enemy.

One bushel of the enemy’s provisions is worth twenty of our own, one picul of fodder is worth twenty of our own.

Killing the enemy is a matter of arousing anger in men; taking the enemy’s wealth is a matter of reward.

This is called defeating the enemy and increasing our strength. (Sonshi translation)

=============================================

[From The Art of ‘Ware (Version 2.0) by Bruce F. Webster (forthcoming), Chapter 2, “Supporting Development”]

In key areas of technology development, talent is scarce and salaries are high, limiting resources for other employees.

As new technologies become hot markets, the number of skilled developers is small, and they command high salaries. For example, in the software industry this has been true at various times for 8086 assembly, Windows, C++, OLE 2.0, object-oriented development, Java, .NET, Python, and subsequent technologies. Each area fills in with time as sustained demand and high salaries draw more engineers into it. But, curiously enough, the absolute number of excellent developers in a given area of technology remains pretty much the same.

When I was teaching computer science at Brigham Young University in 1985-87, the number of students enrolled as computer science majors had increased dramatically — by a factor of five or so — from when I had been a student there a decade earlier. One of the professors, who had been around since the early 70’s, observed to me that the number of really good students in the department was still pretty much the same; the five-fold growth of enrollment hadn’t brought a five fold, or even a two-fold, increase in excellent CS majors. Why? Because those students with interest, aptitude, and native talent has been signing up all along; the surge in enrollment had come from students who saw computers as a way to get a great paying job, much as my friends during my undergraduate days had signed up for pre-law or pre-med.

When a new area of technology opens up, it quickly draws to it those developers with the interest, talents and desire to become really good in it. More excellent developers do come along with time, but as they do, some of the current ones start moving on to new areas, so the absolute number stays more or less constant.

Because of this, I’d like to propose a minor addition to the vast assortment of laws and rules governing technology and engineering:

• Webster’s Constant: the number of excellent developers in a new area of technology quickly reaches a constant value, which is sustained through the period during which the technology is vital.

This may seem a bit silly or fatuous, but it’s actually critical to understand if you need to build a development team that will be working with key technologies. It’s going to be tough finding really good people, and you’ll find yourself running into the same names over and over again. The trick is getting them to come to work for you.

==========================

Compare suntzu pingfa (Chapter 2: “Doing Battle”):

A nation can be impoverished by the army when it has to supply the army at great distances. (Sonshi translation)

When a company is drained by competition, it is because product development and marketing have taken too long. Prolonged development cripples the company.

Developers can typically sustain a high level of energy for 18 to 36 months, depending on how hard they’re being pressed. After that, they start looking around for something new to work on. A project that takes too long getting out the door runs the danger of never shipping, because key developers keep leaving to work on something else, either within the company or outside of it.

There are other significant internal and external problems caused by prolonged development. People within the company begin to lose heart, bicker, and find fault with each other. Customers question the company’s ability to deliver products in a timely fashion. Competitors use your delays against you to win customers and sow doubt about you.

Even allies begin to doubt and may seek to distance themselves from you. During the very long year between our original ship date at Pages Software Inc. and and the date when our product (Pages by Pages) actually went out the door, someone at NeXT swore we’d never ship and said he’d eat a can of worms if we ever did. We did ship, on March 7th, 1994. We never heard if this person carried out his promise; we certainly kept our end of the bargain.

==========================

Compare suntzu pingfa (Chapter 2: “Doing Battle”):

No nation has ever benefited from protracted warfare. (Sonshi translation)

Those who handle product development skillfully don’t build engineering teams twice, nor raise capital three times.

Building product development teams twice means having to replace the original engineers with new ones in the order to complete the product. There can be any number of reasons for having to do this: the engineers get burned out; the engineers get disgusted with upper management and leave; the engineers lose faith in the company and its directions, particularly if they view the product as being “hijacked” and taken in a different direction by latecomers to the company, or the engineers are replaced and/or fired, either because of insubordination or because they weren’t the right ones for the job in the first place.

Raising capital three times before product release indicates that development and launch have taken too long. (Believe me, I know.) The first round is usually essential to get the company off the ground. The second round may be necessary because of changes in product direction or the all-too-common delays in production development. But you’re in trouble if you raise a third round of capital for anything but product launch, and possibly even then. Not only does that mean that you’re late in shipping, it also means that you’re surrendering equity — thus reducing equity incentives for existing employees — and that you do not have sufficient cash reserves to keep the company going once the product does finally ship.

Focus on creating your own development resources, and recruit from your competition. This way, you can be sufficient in both tools and personnel.

Invest in development resources, that is, the tools needed to actually create the product. All the money you can think of possibly spending on those resources probably won’t equal what you’ll lose each and every month if your product is late. Likewise, be willing to devote people and resources to creating custom in-house development resources. It’s easy to chose not to do this, because you can often “get by” without such tools and you may be concerned about the return on investment. But the right tools can make significant difference in product quality and time to completion.

Some of the best people to do your product development are at other companies and are probably at your competitors. Recruit aggressively and hire the best, strengthening yourself and weakening your competition.

=====================

Compare suntzu pingfa (Chapter 2: “Doing Battle”):

Those skilled in doing battle do not raise troops twice, or transport provisions three times. ?

Then the army will be sufficient in both equipment and provisions. (Sonshi translation)

When you release a product, if success is slow in coming, you’ll face diminishing returns on product development and exhaustion among your engineers and marketers.

It is enough of a challenge to sustain energy and excitement through the process of actually getting the product out the door. If returns are slow and small, people can get discouraged and start looking for the door themselves.

When your developers are burned out, your technology aging, your resources diminished, and your advantages gone, then others will take advantage of your weaknesses and cut into your market. Even expensive consultants and new CEOs won’t be able to turn things around.

Few technology companies manage to keep themselves in a lead position for more than five years. At that point, they usually become victims of their own success. The visionaries who founded the company are either gone or given emeritus status. Market focus is on adding yet more features to old, bloated products; no one is willing to risk coming up with new products and technologies that might cannibalize existing ones. And so they start on the long (or, sometimes, not so long) glide downwards, shedding products and people, sometimes merging with other firms on the downward slope. Some companies manage to level off, or at least to slow the rate of descent, but they rarely regain their former status; their place in the market has been filled by other companies with newer products and technologies.

There have been product releases that were poorly done but quickly successful, but there have been few that were well executed and that took a long time to succeed. No company has benefited from a prolonged competition.

There are three dangers in a prolonged competition. First, it consumes resources that could be applied to new markets and products. Second, it narrows your profit margin, further limiting resources that could be applied elsewhere. Third, it tends to lock you in on your current products, blocking development of new ones and leaving you vulnerable to new competitors.

Note, though, that success is relative. In established markets, there are typically two to four major players who between them own 90% of the market. In such a case, gaining even a few percentage points of market share is cause for celebration; witness the fierce battles between Pepsi and Coca-Cola for mere fractions of a point of market share.

=================================

Compare suntzu pingfa (Chapter 2: “Doing Battle”):

When doing battle, seek a quick victory.

A protracted battle will blunt weapons and dampen ardor.

If troops lay siege to a walled city, their strength will be exhausted.

If the army is exposed to a prolonged campaign, the nation’s resources will not suffice.

When weapons are blunted, and ardor dampened, strength exhausted, and resources depleted, the neighboring rulers will take advantage of these complications.

Then even the wisest of counsels would not be able to avert the consequences that must ensue.

Therefore, I have heard of military campaigns that were clumsy but swift, but I have never seen military campaigns that were skilled but protracted.

Therefore, if one is not fully cognizant of the dangers inherent in doing battle, one cannot fully know the benefits of doing battle. (Sonshi translation)

A parable in the Bible talks about counting the cost of something before you start to build. That truth is ancient and obvious, yet I’ve seen too many companies ignore it. Once you know what you want to do, you have to figure out how to do it — and particularly how much it’s going to cost. Resources required include people, money, time, mindshare, technology, and information. They are all expended as development proceeds, and not all are renewable.

Sun Tzu talks in his second chapter about the resource issues of mobilizing troops, and waging war. What’s important, he says, is to succeed as soon as possible; the longer things drag out, the worse the results, regardless of how much “better” the product. If you don’t believe me just ask anyone (else) who has shipped a product a year late.

Product development requires a core development team, support, and quality engineers, and the necessary resources from production and marketing.

It is still possible for an outstanding concept, technology, or product to originate with a few people working in a garage or cheap office; just look at Google. What is almost impossible is for those same few people to bring the product to market on their own. Customer expectations of quality — in marketing, packaging, documentation, customer support, and, or course, the product itself — are at a very high level, and there are a lot of fiercely competitive companies that can provide that level of quality.

The cost of supporting these employees for 18-24 months, including salary, training, travel, marketing, and money spent on equipment, office space, utilities, and supplies, will amount to roughly $15,000 per month per person. Such is the price of new product development.

This figure is less in some places with lower wages and cost of living. And, of course, things can be done a bit cheaper in a start-up, particularly if the developers are fresh out of college. But that $15,000/month figure — about $180,000 per year– is a good, conservative rule of thumb, especially for business planning. The general rule is to take the annual salary of that employee and double it. IT salaries, after booming in the late 1990s, were hard hit by the tech collapse of the early 2000s. However, they are on the rise again. Plus, not all your salaries are going to be IT-related; there will be non-IT employees as well.

=========================

Compare suntzu pingfa (Chapter 2: “Doing Battle”):

Generally, the requirements of warfare are this way:

One thousand quick four-horse chariots,

one thousand leather rideable chariots,

one hundred thousand belted armor,

transporting provisions one thousand li,

the distribution of internal and on the field spending,

the efforts of having guests, materials such as glue and lacquer,

tributes in chariots and armor,

will amount to expenses of a thousand gold pieces a day.

Only then can one hundred thousand troops be raised. (Sonshi translation)

Successful product development required stealth and misdirection. Hide your strengths at first and appear to be weak; when actively developing, show no signs.

Any concept, once viewed, can be imitated, in appearance if not in fact. There is a real danger in exposing product concepts too quickly, though it is a risk that sometimes must be taken to raise capital. Likewise, you don’t want to tip off your competition as to what you’re doing, unless there’s an advantage in doing so.

Managing external perceptions and expectations while developing a new product is a difficult task. Revealing too much too soon can raise expectations too high while giving your competition a clear view as to what you are doing.

If product release will be soon, make it appear to be far away; if product release is far in the future, make it appear to be imminent.

With the first approach, you can lull competitors into complacency and lower the expectations of consumers. In both areas, the advantage of a soon-than-expected release can be tremendous.

The second approach is the classic FUD strategy: fear, uncertainty, and doubt. This tactic was honed to a fine art by IBM and then was adopted with success by Microsoft, at least until the Vista development effort. The danger is in loss of credibility, particularly with customers and the press, but it may work to freeze or misdirect the competition.

Entice the competition into a market segment, and then confuse them by your response. Where they are focused, strengthen yourself. Where they are successful, avoid them.

It helps to have a market niche that you are prepared to grant your competitors, particularly one that they would be interested in anyway. Talk it up, lure them in, then go elsewhere where your real strengths are.

Build strong walls where your competitors might intrude on your market share. Don’t waste resources attempting to win committed customers away from them.

Annoy their leaders to irritate and distract them. Hide your advantages to make them take you lightly.

Feuding CEOs are a time-honored tradition in the technology industry; large egos have often prevented what might have otherwise been successful partnerships and mergers. If you can get your competitors on the defensive, or at least really ticked with you, you may be able to tempt them into doing something rash.

There’s an art to making your customers (and investors) love you while having your competitors not take you seriously, but it can be done. Many successful, established companies started out as small and/or declining ones that weren’t taken too seriously; witness, for example, the Apple renaissance since 1996.

Wear the competition out by faster development.

Invest in your engineers. Take the time to give them proper training, resources, and tools. Discover the secrets of rapid product development, and when you do, keep them to yourself. In the process, be sure you wear out the competition and not your own developers.

Break up competing alliances and sow internal dissensions.

Alliances between convergence companies are constantly forming and shifting. Mergers are announced almost monthly; some actually go through. “Strategic alliances” are more common, but are less significant unless resources are actually committed. Even so, if those mergers and alliances threaten your company, you should find ways to undermine them.

Likewise, when it is your interest, look for ways to cause disagreements within a competing firm over a product and market direction. This will slow them down and may even misdirect them.

Release products at a time and in a market which they don’t expect. Do not freeze product specs and marketing approach too far in advance.

The competition will base a lot of their plans, consciously or unconsciously, on what they expect you to do. The more you surprise them, the less effective their plans will be and the less confidence they’ll have in those plans.

To compete, you need a product technology that allows you for last-minute shifting of the final specification and target market without the months of delay such changed usually entail. Companies that achieve this will have a better chance of surviving the rapid technology turnover in the industry.

Those who create an honest and well-thought-out business plan will likely succeed. Those who don’t will likely fail.

Too many business plans are an exercise in creative writing. This is often done to convince others to invest in a company, an effort of dubious ethical and practical results. The greatest danger, though, is when you believe the fantasy yourself.

Beyond that, your plan for business must be something far beyond the traditional written business plan. You must systematically address the issues raised in this chapter at the very start and lay the groundwork for success from the beginning. Otherwise, you risk wasting the time and/or money of all involved.

While success may depend part upon luck — that is, upon events and circumstances outside your control — it remains a truism that fortune favors the prepared. This chapter covered the ways in which you can prepare for success. Any resistance you and the others feel towards considering these issues and questions in detail should be a warning flag.

=========================

Compare suntzu pingfa (Chapter 1: “Calculations”): Warfare is the Way of deception.

Therefore, if able, appear unable, if active, appear not active, if near, appear far, if far, appear near.

If they have advantage, entice them; if they are confused, take them, if they are substantial, prepare for them, if they are strong, avoid them,if they are angry, disturb them,if they are humble, make them haughty,if they are relaxed, toil them,if they are united, separate them.

Attack where they are not prepared, go out to where they do not expect. (Sonshi online translation)