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..

Now, only two months after the iPad actually started shipping, AT&T is ending that plan as of June 7th, and I find it very hard to believe that Apple didn’t know this would happen, possibly before the iPad started shipping.

I ordered an iPad from the Apple Store back on May 22nd; it still has not shipped, which means that I am unlikely to get it before June 7th, and therefore will not even be able to ‘grandfather’ in under the $30/unlimited plan. There must be at least a few hundred thousand (if not more) people in the same position, all of whom ordered (and paid money) with the expectation of the availability of the $30/month unlimited data plan, but who will find that this data plan is no longer available when their iPads finally arrive. I do consider this classic bait-and-switch (and I’m not the only one);  I would not be surprised to see a ‘race to the courthouse’ from numerous law firms in an effort to establish class action lawsuits against Apple and AT&T.

I think that Apple is underestimating the anger, bad will and litigation that this move is likely to generate; I know I’m pretty appalled.  ..bruce..

Here are what I see as being some of the core classic problems with a system such as this.

The “No Room for the Infrastructure” problem. While the elevated tracks are vastly cheaper and easier to construct than, say, corresponding subway tunnels, they still require above-ground space and a regular footprint at ground level. Most existing urban and even suburban areas simply don’t have the room available, either in the air or above the ground. The political and economic costs of purchasing such room (via eminent domain and other takings) would be prohibitive in most urban/suburban settings.  And while everything in the video looks clean, light, and airy, you simply need to spend a little time around most mass-transit stations to see how they act as magnets for vandalism, graffiti, and litter.

The Last Mile problem. Because of the room problem above, the ULTra network would not likely achieve much network density except in limited and constrained locations (such as an airport or a newly-constructed office park). In actual urban/suburban settings, ULTra would likely end up having a sparse network feeding into existing mass transit systems (subway, buses) or leaving you to walk the rest of the way. As such, it is unlikely to reduce car usage.

The Pay As You Go problem. Mass-transit systems are notorious money pits, heavily subsidized via unrelated taxes and federal subsidies (but I repeat myself), since actual rider fees are not enough to pay for the system’s on-going operations, much less the original cost of construction. My wife and I lived in the DC area for a total of nearly 8 years (six of which were in the District itself), and I was a great fan (and heavy user) of the DC Metro subways. But WMATA is always struggling financially, and that’s true of most mass transit systems. Here in Colorado, where we’ve lived for the last 3 1/2 years, the Denver Light Rail system found itself looking at cutting back services this year — due to reduced sales tax collections and higher fuel costs — even as rider volume was going up as gas prices passed $4/gallon.

The Hidden Costs problem. Somehow, much of the public discourse over (electric) mass transit assumes or implies that electricity is free, or at least carbon neutral. It’s neither. Most electrical generation in the United States comes from burning hydrocarbon-based fuels: coal, natural gas, and a bit of oil. And even if the electricity comes from wind, water, geothermal, solar or (my favorite) nuclear, it still costs money and it still has a carbon footprint.

The Scalability problem. Paul Raven, who blogged about ULTra over at Futurismic, raised this issue himself. The ULTra system shown in the video relies on relatively small cars — four seats each, with some standing/storage room between them — that are spaced apart by the controlling software. Assuming a spacing of 3 seconds between cars, that sets an upper limit of moving 4800 people/hour. This is better than, say, busses on a given route, but it’s less clear how competitive it is over existing train, light rail and subways systems, and it doesn’t begin to approach what the automotive infrastructure can carry.

The Coordination problem. One of the long-standing complaints about the automotive system is its high inefficiency, that is, you have millions of cars on the road, the overwhelming majority of which are carrying one or maybe two individuals. ULTra, by being demand-based, sets itself up for the same problem. If I read the video and website correctly, I can walk up and select an unused ULTra car, punching in my desired stop, and go straight there. By so doing, I may tie up an ULTra car all by myself, going from Point A to Point B. This reduces the overall capacity and efficiency of the system; to overcome that, I must then choose to announce my destination, interact with others (“Who else in going to [Destination X]?”), and decide who else I want getting into that rather small car with me. This leads to…

The Safety problem. Personal safety on mass transit is usually provided by the presence of other people; that is, you are less likely to be mugged or assaulted on a crowded subway car or bus due to the presence of all the other people around you. (Hence the classic drama/horror trope of being on a subway car with just one other, sinister-looking person on it.) Should I let another person into my ULTra car, presumably because that person is going to the same destination, I am then trapped alone with that person in that car all the way to that destination. I suspect there will be a “let me off at the next possible stop” button in the car, but that may not be enough. Likewise, there will likely be an inboard camera, but a second or two of spray paint will take car of that. On a less dramatic note, vandalism of the interior of the cars themselves will likely be increased  for that same reason of isolation (no one around to see what you do to the car).

OK, that’s what I came up with on the top of my head. Can you think of others, or do you have counter-arguments to what I’ve listed above?

Again, I’m a great fan of usable mass transit systems. When I lived in Washington DC, I regularly went to New York City on business without once climbing into a car or a plane; I’d walk down to the nearest Metro stop (Cleveland Park, Red Line), take the subway to Union Station, take an Amtrak train to Penn Station in NYC, then walk crosstown to my hotel or business destination. I’d then reverse the whole process to go home again. But I was also quite aware all that time of the financial struggles and subsidies of both WMATA and Amtrak.

Likewise, ULTra will only succeed in small, constrained settings, such as airports and office parks. The video itself references those two settings, but the ULTra website references grander uses. I just don’t think they’ll happen, at least not without massive government spending, and even then they won’t make a real impact in automotive use.

As always, your mileage may vary.  ..bruce..

And so, from hour to hour, we ripe and ripe,
And then, from hour to hour, we rot and rot;
And thereby hangs a tale.

– William Shakespeare, As You Like It, Act II, Scene vii.

I have observed a pattern (or anti-pattern) in IT engineering that looks something like this:

Let’s call this the arc of engineering, since that’s more compact and elegant than the strangely shaped curve with what appears to be a single inflection point of engineering. “Arc” in any case conveys the essential sense: that system quality (however you wish to define that) rises over time to a peak value and then starts to decline.

This came to mind because I recently put a new hard drive in my laptop and have been going through the tedious drill of reinstalling all the various applications and utilities that I am used to using. With some software, I want — or have to use — the latest versions. So, for example, my versions of Firefox, Thunderbird, Quicken, and so on are all current, not to mention my anti-virus/firewall software.

For others, however, I either don’t need — or specifically don’t want — the newest versions. The laptop’s restore disks installed Windows XP, for which I’m grateful; I have no plans whatsoever to upgrade to Vista. Similarly, I installed MS Office 2003; I don’t own and don’t plan to buy Office 2007. As far as I can tell, Microsoft pretty much hit the top of its engineering arc for both Windows and Office a few years ago. In fact, the early to mid-2000s may well represent the peak of quality, features, and user acceptability for these product lines. Given the on-going end-user unhappiness with Vista and Office 2007 — and the corporate resistance to upgrades to either — Microsoft’s user base may never again be as happy with these product lines as they were a few years ago.

This is not an anti-Microsoft screed, because I have observed a similar effect in other companies and product lines. For example, I was a very early Macintosh adopter and champion, though I also was quite critical of its initial limitations. Apple continued to make improvements and changes to the Macintosh product line and finally reached what I considered at the time to be a close-to-perfect Mac: the Macintosh IIcx. It was solid, reliable, and very stable. Apple followed up with the Macintosh IIci, which used the same form factor, but offered several improvements over the IIcx, though there were some software stability problems due to the rewritten ROM and related hardware changes.

And then came the Macintosh IIfx, which was supposed to be even better — but the IIfx soon became well known for its hardware problems, in particular its tendency to blow out power supplies. Other Mac II models — the IIvi, IIsi, and IIvx — each had their own problems and limitations. From there, Apple descended into the product-line chaos known as Quadra/Centris/Performa, a marketing disaster from which Apple would not recover completely until Steve Jobs came back to Apple and introduced the iMac.

In this same time period, Apple had to deal with the fact that its operating system — System 7, introduced in 1991 — was under-featured, underwhelming, and built on aging technology. System 7 would lose its graphical UI edge with the introduction in 1992 of MS Windows 3.1 and would pretty much lose the operating systems wars completely a few years later with the introduction of MS Windows 95. It would not be until Apple’s introduction in 2002 of the Jaguar (10.2) version of Mac OS X — a heavily updated and retooled version of the NeXTstep OS — that Apple would regain technical and UI leadership in operating systems.

This same pattern can appear in internal IT projects. The system under development goes into production and continues to improve over time. Then at some point, the system’s overall quality (functionality, performance, reliability) starts to decline and maintenance costs begin to go up. At some point the organization decides to replace or re-engineer the system, sometimes successfully, sometimes not.

So, why does this happen? I believe several factors are or can be involved. (To simply the discussion, I’ll use “system” to mean the software, IT system, product, or product line under discussion; likewise, I’ll use “developer” to mean the company and/or IT development group responsible for creating, enhancing, and maintaining the system.)

The developer loses conceptual control of the system. In other words, no person or group of people understands the overall architecture, design, and operating constraints of the system. Thus the developer can no longer ensure that on-going changes to the system are consistent and compatible with existing aspects of the system or with other changes being made. This in turn can come about for several reasons:

• The system grows too large and complex. Sheer code size is not necessarily a problem (though it doesn’t help); on the other hand, the degree of fragmentation and interdependencies can be. (See this Vista post-mortem for some examples.)
• Those who really understand the system have left or moved on to other projects. The best and brightest IT engineers — particularly architects and designers — usually prefer to work on new systems. That means once this system has shipped (or gone into production), the people who created the system in the first place and who understand it best may well want to move on to other things, inside or outside of the company. Those who replace them — and those who stay behind — may be quite talented but may not understand all the system’s nuances and requirements. Eventually, they may decide to move on as well. With each generation of turnover, more institutional memory is lost.
• The development organization no long meshes with the system. Conway’s law states that “any piece of software reflects the organizational structure that produced it.” Since the IT group responsible for the system often changes once the system ships or goes into production, the organization of the new group responsible for the system may not match the system’s structure, causing gaps in knowledge and responsibility, plus a tendency — conscious or not — to reshape the system to match the new organization.

Software rot sets in. Software rot is a real term of art within software engineering, referring to the well-known tendency of systems in production to become less reliable over time for a variety of reasons having mostly to do with piecemeal and uncoordinated changes to the system, or growing incompatibilities with external systems.

The enhanced system finally outgrows its original foundation. When the developer seeks to expand or improve the system, it often does so without properly rearchitecting and redesigning the system first. As a result, the original system eventually may be stressed beyond its original intent and begins to suffer from functionality, reliability and/or performance problems. Mike Parker, one of the co-founders of Pages Software Inc. (read the 3rd paragraph), once described this syndrome as “trying to build a castle on the foundation of an outhouse.”

Market or business needs shift beyond the product’s fundamental design. A developer creates and enhances a system to meet a specific set of business/market requirements. However, there often comes a time when new or expanded requirements exceed the capabilities of the system’s original architecture and design. This can lead to the “outgrowing the foundation” situation described above, with the resulting problems. Or it can lead to a true re-engineering or replacement effort, which may well lead to the final two problems below.

The developer begins to add “blue sky”/”kitchen sink” enhancements. Once the “door is open” on changes to the system — or features for the new/re-engineered system — the requests pour in from all directions. Without rigorous control over these enhancements, the development effort can quickly bloat in every aspect: architecture, design, code size, schedule, staff, and defects.

Backward compatibility is maintained at all costs. Supporting backwards compatibility in a system can be a bit like trying to drive a car while pedaling a wheel at the same time. Apple abandoned its old arc of engineering and created a new one under Mac OS X by first forcing binary backwards compatibility into a separate mode (the “Classic” environment) and then dropping the Classic environment altogether for Intel-based Macs running Mac OS X. Microsoft — which has struggled with the backwards compatibility issue for almost its entire OS life — has announced that for “Windows 7″, it will in effect follow Apple’s lead by not supporting binary (and to a certain extent source) backwards compatibility in Windows 7 but instead using virtualization technology (switching to a backwards-compatible OS) for older application.

I’m sure there are other reasons I haven’t listed here, but it does show why the arc of engineering exists. Comments? ..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)

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)

These factors govern the success of the company: Tao; the economy; the marketplace; leadership; management.

Tao means running the company so that all the employees share the same vision of success.¹

“Tao” (literally, “the Way”) is probably the most difficult concept — and task — introduced in this book. Why? Because it is hard to achieve success for a diverse group of people, and the more people involved, the harder it gets. Universal stock options help, but they are not by themselves sufficient.

It is also difficult because there is a moral element involved. For Tao to be achieved there has to be an outstanding level of reciprocal dedication, loyalty, and trust between the employees of the company at all levels. This does not mean that employees are not accountable to their managers or vice versa; quite the contrary. But there is a Taoist paradox at the heart of this: the manager must focus on the needs of the employee, while the employee must focus on the needs of the company. This is a powerful situation, since each acts as the other’s advocate, each helps the other to succeed, and each (in theory, at least) trusts the intentions of the other.

It breaks down, of course, if that mutual advocacy isn’t there. When both manager and employee place the needs of the company as paramount, the stage is set for burnout, declining quality of results, and turnover. When both place the needs of the employee as paramount, then the company suffers and, eventually, so does the employee. And the last situation — where the manager places the needs of the company first, while the employee places his or her needs first — is the classic adversarial management-vs.-labor relationship that has been the source of tremendous conflict, inefficiency, fraud, violence, corruption, waste, and suffering since the start of the Industrial Revolution.

Does Tao guarantee success? No. Does lack of Tao guarantee failure? No. But as market forces continue to dismantle or reorganize the large corporate structures that have dominated the last century (and the mentalities that go with them), firms that seek to achieve and maintain Tao will have a decided advantage.

The economy means buying and selling, lending and borrowing, growth and decay.

Technology-based industries go through waves of prosperity that aren’t always related to the nation or global economy. This still fuels the basic dream of a small group of developers making a fortune, even though cost to market has risen tremendously, and the technical economy now tracks the national economy more closely. Even so, new opportunities can turn things upside down; witness the mad, intense scramble into the original dot.com boom (and bust), as well as the current “Web 2.0″ boomlet.

The economic aspect of product development has to do with cash flow for the company itself: how much money (or credit) is on hand, what monthly “burn rate” of resources is, what additional sources exist, what additional expenses are required or anticipated, what the bottom line is each and every month, and how well future income and expenses can be predicted.

New companies typically must raise sufficient capital to complete an initial product and then successfully bring it to market. That capital may be from sweat equity, personal savings, contract work, advance royalties, private investment, corporate partnerships, or venture firms. Each of these sources has its advantages and its costs; failure to understand these trade-offs can lead a bright young company to the point where it carries the heavy burden of development and marketing without much in the way of rewards.

The marketplace means time to market, ease of development, potential demand, customer requirements, competition, and return on investment.

Success depends on how quickly and cheaply you can bring to market a product that people are willing to buy in sufficient quantities. This means you’ve got to understand both what it is you’re trying to build and who is going to choose to spend their money on it instead of on something else, including equivalent products from other firms. Beyond that, you have to be able to sell your products for a price at which you can make a profit — not just pay back what you spent coming to market, but actually show a return on that original investment. And you have to do this in an arena filled with companies that are better staffed, better funded, better known than yours.

Leadership means the qualities of wisdom, integrity, humanity, vision, and fairness.

Wisdom means knowing the right thing to do, and the right reason for doing it. Integrity represents the ethical and moral dimensions of business that are sometimes neglected in executive offices, particularly those of sales and marketing. Humanity involves remembering that every decision made affects people’s lives — including those in competing firms. Vision is the quality of seeing beyond the next quarter’s results and into the future. Fairness mixes compassion, justice, and evenhandedness appropriately.

These qualities are uncommon, and are seldom found in equal and sufficient proportions in a single person. But that does not excuse their absence, nor does it relieve us of the effort to achieve them. They must reside in those who lead the company, and they must be expected of employees at all levels.

Management means organization, communication, acquisition of resources, and budgeting.

Many start-ups are run by technical or visionary individuals who do not fully understand or appreciate the role of management in a successful company. This can lead to failure to recognize or reward contributions, exhaustion of resources, inefficient use of time, and even legal problems. Management skills should be as important in a company, division, or product group as technical skills.

Every CEO will have heard of these five factors, but success depends upon truly understanding them.

When you examine companies for success or failure, you will usually find that the successful ones understand and deal with all five factors — Tao, the economy, the marketplace, leadership, and management — while the unsuccessful ones have misunderstood or neglected one or more of these factors.

================
1 Compare Suntzu pingfa (Chapter 1, “Calculations”): Therefore, go through it by means of five factors; compare them by means of calculation, and determine their statuses: one, Way, two, Heaven, three, Ground, four, General, five, Law.

The Way is what causes the people to have the same thinking as their superiors; they may be given death, or they may be given life, but there is no fear of danger and betrayal.

Heaven is dark and light, cold and hot, and the seasonal constraints.

Ground is high and low, far and near, obstructed and easy, wide and narrow, and dangerous and safe.

General is wisdom, credibility, benevolence, courage, and discipline.

Law is organization, the chain of command, logistics, and the control of expenses.

All these five no general has not heard;

one who knows them is victorious, one who does not know them is not victorious. (Sonshi online translation)

• Sun Tzu (Chapter 2, ‘Doing Battle’, Sonshi.com translation): 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.
• The Art of ‘Ware (Chapter 2, ‘Supporting Development’, 1995 edition): 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.

I have recently done a draft revision of the book, though I have more work to do before publication. But you are free to browse the HTML version at the link just give, or download a printable PDF version of the current draft. Feedback and comments are always welcome. ..bruce..