Anecdotes

In this section I have compiled a list of anecdotes and observations gathered over a long career in Silicon Valley. If you like these stories, send me a note at larry@slotnicksystems.com. That might encourage me to write a few more.

a) Imagining the Right Product: Thought Before Action

Hockey great Wayne Gretzkey is often remembered for his famous quote: “A good hockey player plays where the puck is. A great hockey player plays where the puck is going to be”. Building successful software products depends on this adage as much as professional hockey does. Software projects take time. During this time the market moves, just like that puck. You must anticipate where the market will be when you get to your release point. You can focus your efforts analyzing and selecting the right product for the evolved market at the delivery time, or you can focus on working in the most productive and efficient manner, using the best methodologies to streamline the processes and get the most out of everyone. Success often requires that you do both, but if you have to choose, pick the former. Spend more time thinking about what, why and when, and less time on how. In short, more thought and less action, at least up front. There will be plenty of time for action once the strategy is right, and you will be better able to reject unnecessary activity that does not directly enable the strategy along the way.

Over the years I have sometimes seen great engineering teams fail miserably and pedestrian teams succeed. The Computer Science discipline we learn at the university trains us to follow the best principles and practices, but provides little direction on how to select the right things to build or what makes them the right things. Time and again engineers and their managers focus on processes, methods, tools, staffing and product delivery, doing so on poorly selected product choices or on a flawed product strategy. Being successful requires both doing the right things and doing them in the right way.

As a leader of unix application development in the 1980’s I led a team of several dozen highly skilled unix programmers and testers to deliver an elegantly designed and built office application suite for character based unix terminals utilizing very clever character map windowing and graphics. We were proud of our designs and our delivery was nearly flawless. The product suite had truly leading edge application product innovations, and on delivery our word processor and spreadsheet products were way ahead of the unix competition. Regardless, the product failed. Character terminal based products were considered obsolete and the unix competition had moved ahead to graphical systems. The early Macintosh and Sun Workstations had raised the bar and there was no going back. Our business was centered on these multi-user, terminal based unix systems, a business that was then in decline.

Had we spent the extra month or two up front on this project and really thought about the investment we were about to make, we would probably have plotted a different course and saved the company several million dollars in lost R&D. Our divisional sales and marketing drove us forward, incenting us to deliver early. Management wanted it done, and we were all complicit in the final outcome. It is difficult to say what we might have achieved had we done the right thing instead. It was a lost opportunity.

I can provide more recent cases, but would rather not be overly critical of fairly recent product plans that I have seen go awry. However, one case stands out that is definitely worth mentioning and it illustrates the other side of the coin: what happens when the right things are done.

I was a vice president of engineering at Apple Computer in 1997 when Apple purchased NeXT and soon inherited with that acquisition its new and former CEO, Steve Jobs. As a VP I was a member of the so called top 40 team of company leaders which meant that I attended strategic planning offsites and participated in some very crucial decisions designed to control costs and begin rebuilding the business. Three of these decisions come to mind.

The first was a topic that Steve kept pointing out through his use of a slide he had obtained from marketing that was jam packed with product names and numbers in rows and columns. There were product families for business, others for education, and still others for consumer. Each line had its own laptops. Each had low end desktops, each had high end desktops. His position was that we had simply too many computer products. There was overlap between families, there was overlap between models in the same family, there was a marginal need for some, others simply didn’t make sense. He proposed cutting back from some 44 products to 4 basic designs and proceeded to do just that, explaining the logic to the company as he went forward. This came as a sudden change to the plan of record and caused quite a bit of turmoil in the ranks and an unraveling of product commitments. Creating four great products instead of 44 good products that were not clearly positioned became our focus. We then realigned around the new targets. Many people throughout the company thought this was terribly short sighted and destructive. History was to prove otherwise. It was company survival that forced us to identify the essential products and to imagine a new identity.

A second decision area for cost cutting was regarding our quality processes and organization. Over the years I had learned the necessity of staffing up in QA and guaranteeing adequate test time for development projects. I had used a 1:1 ratio earlier in that decade as the proper balance between development engineers and testers for software projects. The new NeXT management team came in and was talking about a 1:2 ratio where there would be half as many testers as engineers. That then led to a fairly hasty decision to reduce several thousand testers worldwide. I thought that this meant that MacOS X quality would be unacceptably bad when it finally shipped and considered the entire exercise a perhaps necessary step (because of company financials), but one we would regret later.

At the same time, in a third effort to drastically cut costs, we opted for a plan to totally shut down the printer division,

Apple Laserwriter II

which represented about 15% of our revenue but little if any profit. Apple had been building its own Macintosh compatible printers for over a decade, consistent in design and simplicity, and many believed that it was a critical part of what defined the end user Macintosh experience. It certainly was an essential element of our former desktop publishing identity. There were debates: “How could we even imagine cutting off 15% of our revenue when our revenue was in a steep decline already?” and “Could we survive without printers?” Many thought we could not. We were leaving behind our desktop publishing identity and moving forward to a new internet in everything identity, but few people realized it at the time.

These were big, bold decisions and my peer managers and I were not at all sure they were the right things to do. They were done on fairly short order. Layoffs ensued as reorganizations began almost immediately. Accommodations and adjustments were made to processes, teams, customers and facilities. Test automation was strengthened to permit more coverage from fewer testers. Partner agreements were put in place to fill the gap in printing systems. We redesigned our development approach to allow for a closer relationship between testers and developers and asked developers to do a lot of the initial testing themselves, a notion which helped enable the trend towards agile development. We also used a more automated approach to testing where we could get more coverage with less headcount. The decision to deliver fewer products brought with it a need for fewer testers. We were betting on the call that the small set of identified products were the right ones. In retrospect, for a variety of reasons, they were. We subsequently shipped MacOS X and a new iMac product line to begin to fuel the amazing Apple turn around story. To this day Apple has achieved amazing success without a printer business, and the company has proven that fewer products (i.e., the right products) with carefully crafted messaging was way more important than lots more products with unclear positioning.

These are big examples, but doing the right thing is a behavior pattern that is applicable down to the decisions and actions taken by first level managers and individual contributors on a daily basis. When a developer begins to think about a new project or piece of functionality, they have learned to think about testability at the very beginning. When a product manager thinks about adding new functionality to the next release, they think about how that functionality enables the strategy for this product or this product line and whether it is more important than any of the other 25 items being considered in parallel.

Being able to make the right decisions, big or small, requires a good understanding of direction and an effort by all levels of management to communicate effectively. As management, we all need to recognize when these things are happening and reward the best enabling behaviors to reinforce them. Sometimes that reward is a simple comment like “great work, Jim!”, or mentioning a person and a behavior at a group communication meeting. This is not a costly activity, it is simply good etiquette, and it goes a long way to motivate team members. Sometimes it is a financial reward, but the most important concept is to visibly recognize the innovators and decision makers.

b) Design vs. Engineering: Which Is Harder?

In early 1997 Apple was nearly dead and losing hundreds of millions of dollars quarterly. As the VP of Internet and Enterprise products, one of my project responsibilities was the initial iMac internet and online user experience, which involved a great many things. It required Microsoft to agree to continue supporting the Macintosh with Internet Explorer and, even more importantly, to continue supporting Office for the Mac. It involved a sequence of initial boot steps to walk the new iMac user through the process necessary to open, enable and begin running on the web through an Earthlink dial up account (remember that this was 1997 and dial up was the standard). Getting Microsoft to agree to support the Mac with MS Office and IE is a long story worthy of its own chapter here (see anecdote below titled “Microsoft ‘Saves’ Apple, 1997”). On the Earthlink side, I had a small team of network and connection engineers, designers and business people focused on making it happen in the most seamless and painless fashion possible. One day all the engineering pieces began to work together from the network manager configuration, the modem connection, through to the Earthlink backend. A backend database lookup was required, a validation step, a few handshakes, an exchange of contact information and a credit card transaction. It was a delicate sequence of steps that had to be foolproof and also had to be unwindable in the event the session was interrupted, or if anything failed on the Earthlink end.

Finally it all worked. Steve had asked to see it, so I invited him to an office of one my team members to get a first glimpse of the engineering functionality, the timing, etc. Once he was there we cold booted the system. The original iMac did not run OSX, but a variant of Mac OS 8. This older MacOS took a long time to boot and put an obsolete but well known small icon of the original mac on the screen while the initial boot progressed. Steve had a fit. “What is that? Why is it there?” (it was in the ROM and not something my team could tinker with), “Get rid of it!” Then we moved through a sequence of rough screens which would eventually be polished to lead the user gracefully and stylishly through the Earthlink account opening process. He had another fit. “What is that? Why isn’t the text antialiased? The graphics stink!” I calmly tried to explain that we were not trying to demonstrate the polished result, only that the engineering steps now worked reliably and that these “finishing” steps could now be undertaken. For me, as an engineering leader, I considered the engineering steps to be the harder, unpredictable ones, and the polish to be easier, more predictable, more manageable pieces.

That day I learned something important. In Steve’s view of the world, the engineering was always the easy part. It was doable, and just a matter of rote execution. He expected it to work flawlessly. For him, the harder, more unpredictable part was always the polish, the design, and the style. As he put it, “Engineers are a dime a dozen. I can find them on any street corner. The only thing that matters is design. Design makes all the difference.” Of course I was aghast that day that he would say such crass things in front of my engineers. I had dedicated my life to engineering. We all had.

It has now been more than 20 years since this episode. I have often thought about it. I really began to understand Steve’s preoccupation with perfection that day. More importantly, I also learned that he was right, although it took me a while to admit it. Apple has moved forward a million light years since then. On August 2, 2018, after a record quarter, it became America’s first trillion-dollar company. It is one of the most successful high tech companies ever. But how did it get there? Was it great engineering or the most compelling design? The answer of course is both (and great sales and marketing, too), but the lesson I learned that day was that attention to design comes first. Everything depends on great engineering execution, but it does not start there.

c) Motivational Leadership: Tapping the Team Nerve Center

What is your management style?

For years I have often answered this ever present interview question with a comment about my belief in positive reinforcement rather than negative. I have formed this opinion throughout many management roles where my product centric engineering teams are busy developing and completing products in alignment with schedule and customer commitments. I have managed products where the actual number sold is relatively small (corporate voice mail systems) and where the number is huge (mass market mobile phones as well as Macintosh and Windows consumer software products).

One thing I have observed is that engineers are always proud to see the result of their long hours used by real people, the more people using them, the prouder they are. I also have observed that the best financial reward to use for retention and motivation is the stock option, particularly, of course, when the options are above water. One thing I do not believe in is using cash compensation to motivate engineers to work harder or to be more dedicated towards a particular goal. Engineers are going to work as hard as they can if they believe their work will be appreciated, if the product is considered cool, or if their piece of the project is fundamental to its working and others are depending on it.

I never have had enough cash available in my budget to provide “motivational cash incentives” such that it could change an employee’s lifestyle the way stock options can if they are in the money. If I or any other leader did have such a budget excess, it would certainly reflect questionably on how the company is being run. This is why I have formulated my positive reinforcement approach. I believe in rewarding engineers and teams for a project well done, a project phase completed ahead of time, a lower bug count than expected, etc. This is not designed to directly encourage harder work, but instead simply to recognize and acknowledge a successful activity. It shows that management sees an individual’s or a group’s focused efforts. Interestingly, though, it does serve to improve motivation in two ways. First, when engineers realize they are receiving a reward, they think about the behavior that got them that reward and tend to try to do it again when the next opportunity arises. Secondly, they feel appreciated, and then their morale improves, and they tend to be more driven for the next phase or project. Even though there is no life style changing event, this effort recognition remains an effective tool for gradually building a motivated work force and a cohesive team dynamic.

In contrast, I have seen many peer engineering leaders try to invent “retention bonuses” or to specify team bonus structures ahead of product delivery if certain project goals are met. These up front “motivational” bonuses are not very useful. They tend to cost a lot of money, and when the retention date arrives, the key individuals walk out the door having mentally checked out months earlier. In the case of up front product bonus plans, they do not tend to extract more intensity or better performance. They might work if all you want is to keep people through a particular date, providing the bonuses are sizable, but mostly these are just efforts by senior managers to convince themselves that they have done their part to pull the schedule in, or to achieve some other goal. In many cases a competitive company will simply match or exceed the retention bonus as a hiring bonus and you still lose the employee early.

Case in point: I once made a bet with our vice president of sales that we would ship a particular mass market product by a particular date. At the time I was the vice president of product development. My pride was at stake. I worked around the clock to make it happen. I was involved in all aspects of decision making that could affect the schedule adversely. Eventually we actually delivered early, before the date. My previously agreed to reward? A $5 company logoed wristwatch. Why did I do it? Pride. It certainly had nothing to do with the reward. They could have added $250,000 to the reward and I would not have been capable of extracting more intensity from the team. Why did the team come together to make it happen? A sense of responsibility and pride in what they were doing and a realization that the company really needed the revenue. Several of my engineers in later years told me that this one project was the one of which they were most proud. It’s all about tapping into the energy of the team. Finding the nerve center. Making people hunger for that success and the appreciation and recognition that it brings.

d) Trust and Loyalty, an HR Partner Saga and a Company PR Fiasco

In my earliest management roles I was very fortunate to have some extremely capable and knowledgable human resources staff support. Early on I began including them at my weekly staff meetings and having them participate in all significant project meetings, team planning activities, all hands meetings, travel to remote sites, etc. That way, they began to know the team dynamics, what motivated certain individuals and people’s attitudes on things in general. Another advantage is that they begin to earn the trust of the team members over time.

I remember working closely with our VP of Human Resources at an Apple company and learning about his “unwritten” 49% / 51% rule. His philosophy was that company HR representatives should be 49% company advocates and 51% employee advocates. This is not such an imbalance as to question loyalty, but just a slight tilt so that employees will feel that when serious issues arise, either personal or company, the HR partner can be expected to provide solid advice and respect confidentiality with a very slight emphasis on supporting the employee, or seeing the employee’s perspective. It is surprising how this subtle sway of orientation can over the long run make a potential adversary feel more like a comrade and friend.

Conversely, in more recent years I have had the less satisfying experience of working in struggling companies, both large and small, where layoffs were sometimes quarterly and bad news was continuous. After a few years of this type of struggle everyone begins to get jaded, a malaise develops, and the reality becomes one of frequent tough decision making where financial considerations always predictably trump personal ones. In many of these situations I began to consistently and accurately anticipate the pro company orientation reflected in the positions HR could be expected to take on any particular matter. Over time a lack of trust develops and employees stop seeking out HR for advice and counsel.

I want my HR partners to be available to my team and me for added insight, individual support and a sensitivity to life issues. I know the business issues. I spend most of my time dealing with them. I don’t necessarily feel the burden others do, perhaps because I am typically engaged trying to solve the tough business decisions. After all, tough decision making is a matter of course in business, but the obligation of senior management to continue to see things from the employee’s point of view is very important. We manage the business, but we lead the people. Leadership requires trust and trust is earned over a very long time.

The need to build trust is not just limited to employee and management relationships. It applies equally well to company and customer relationships. Trust can easily be damaged over a questionable decision or action. Take for example a March 2016 story involving the Microsoft Xbox team at the San Francisco Games Developers Conference. At this conference they put a lot of effort into defining Microsoft as an inclusive, diversity sensitive company. They hosted a Women in Gaming luncheon to discuss how to make the gaming industry even more inclusive to everyone regardless of gender. However a day later they hosted an evening party where they hired scantily clad women to dance in skimpy schoolgirl outfits in front of the ogling nerds in attendance. Oops. There went a lot of hard work on inclusion and diversity. Many angry tweets and comments later, mostly from women, lambasted the inappropriateness of this party and of Microsoft’s real attitudes on diversity in general. Microsoft, to its credit, has done a lot of good work in recent years on diversity, embracing feminism and equality. They have fought for LGBT rights, made an effort to hire autistic applicants and even published stats on their workforce diversity improvements. But one misstep like this does a lot of lingering damage to the reputation and the brand.

e) Is That Altruism or Pragmatism? A Look Behind the Curtain

During a mid spring week in early 1994 I was invited to a human resources group sponsored offsite at a spectacular hillside setting in the Santa Cruz mountains. There was a gorgeous view of the sparkling Pacific Ocean, and the weather was crystal clear. Our HR team had put a lot of work into this offsite with the promise of training us on the importance of creating a truly diverse workforce through innovative hiring processes and other insightful management practices. Of course this was high tech, it was the nineties, and as such there were not many women or minorities to be seen in attendance.

On the first day of this two day offsite we did breakout sessions that focused on creative ideas for supporting a diverse workforce and we did role playing where we imagined ourselves in situations where an executive decision could swing two ways where one was much more supportive of a minority population. We had group meals where we mixed ourselves up in order to better get to know our peer leaders from other parts of the company and to understand diversity issues in those other areas. During the mid morning session on the second day we had an invited speaker who was a subject matter expert as well as being the author of a recent management book on the topic. This speaker arrived and copies of her book were distributed to all the attendees.

An hour or so later we broke for an outdoor lunch on the sun drenched patio with that intensely blue ocean horizon in the distance. We found ourselves sharing this space with executives from another Silicon Valley company which coincidentally was also there for a similar HR training course. I had my course materials with me and as I sat down I placed them on the table. My book happened to be on top. Then an executive from the other company asked if he could sit at my table and he then set his course materials next to mine. I could not help but notice that his materials included a book as well. His book was titled, “Valuing Diversity”. My book had the much less idealistic title, “Stay Out of Court”. I then realized that this entire exercise was not quite as altruistic as I had thought!

f) Mergers and Acquisitions: A Collision of Cultures

Company mergers and acquisitions tend to put a strain on an entire organization. Two merging companies rarely have anything resembling a common culture. Processes differ, attitudes about the merger differ, communication styles differ, management styles differ, and product lines usually don’t plug and play together. Once the merger deal is done and the lawyers and business development people are out celebrating, there is a lot of tough integration work for everyone else to make it work. Products still must ship, though. Engineers have to keep their focus. Several times in my career I have been a leader in a company that was either being acquired or doing an acquisition and my engineering team was a big piece of the integration effort. I have collected three of those stories here.

Silicon Valley vs. the East Coast: Convergent Technologies and Unisys

Throughout most of the 1980’s I was an engineering manager at a no longer existent computer workstation company, Convergent Technologies, also known as CT. For several years our largest customer had been Burroughs, which later in that decade merged with Sperry Univac to form Unisys Corp. In 1989 Unisys, still our biggest customer, acquired us. They were based in suburban Blue Bell, PA, with walnut paneled executive office suites smelling of stale cigars. We were headquartered in San Jose along the light rail line in a plain, two story building that had barely withstood the Loma Prieta earthquake. The cultural divide between old tech and new tech was huge. Unisys was run by suit wearing bureaucrats who thrived on day long meetings where little was decided. Their product development cycles were painstakingly long. In comparison, CT was a fast paced Silicon Valley company with rapid time to market deliveries, quick prototyping, “can do” attitudes and a “just ship it” mentality. This was truly an oil and vinegar situation and over the course of the next year nearly all of the remaining founding team at Convergent left the company. Unisys was powerless to stop the exodus and only continued shipping these acquired products for a year or two past the acquisition close date. Unisys, as a flagship technology company and onetime member of the illustrious mainframe BUNCH (Burroughs, Univac, NCR, Control Data, and Honeywell), continued its slide into oblivion and never really emerged as a viable product company, certainly not one that had much relevance. This acquisition is best put into the lessons learned/mistakes not to make again column.

Octel and VMX: The Consolidation of Voice Mail Companies

In the mid 1990’s I took a role as Vice President of Engineering at Octel, a leading manufacturer of voice mail systems sold to all sizes of companies from wireless carriers requiring millions of users down to small business systems supporting only dozens of users. In 1995 the company had acquired one of its larger competitors in the midrange corporate campus voicemail market, VMX. VMX had two products in the low and midrange of the corporate campus market. Octel also had two products in this market, one in the midrange and one in the high end. The VMX products dovetailed nicely with their Octel counterparts, at least in terms of their end user support ranges, but that was where the easy part ended. Our creative marketing team proposed that we use a music inspired naming scheme: Serenade and Aria and position them with Serenade at the low and mid-low range and with Aria products at the high midrange and high end.

Before long we had industrial designs that encased the radically different circuitry and software in identical looking beige boxes. Despite the designs and naming, the products from the two companies were entirely different internally, and the problems we faced with vendor management and circuit designs were huge. One task my teams took on was the ambitious effort to clean up the “Telephone User Interface”, or TUI. There were bumps along the way, such as when the “7” key command on one product line did a message erase while it did a message save on the other. Merging the teams was a bit harder. The Octel teams did all prototyping and validations in large centralized test labs, and the VMX teams needed to co-exist in these same labs as sites were consolidated. VMX was a much smaller company and had much lighter weight processes. The VMX engineering team had quite a bit of difficulty adapting to the perceived heavier processes and as the product lines merged it was always a negotiation as to which team’s architecture or approach would be the chosen one for the subsequent generation of products. Overall, the coordination between product marketing and engineering expedited much of this engineering merger. The rest depended on continued engineering diligence, problem solving and details. In retrospect the company culture and people differences: processes, product strategies, working styles, attitudes, team structures, presented most of the challenges. Once we surmounted these people and product issues the Serenade and Aria products emerged as the leading corporate campus voicemail systems throughout the remainder of the decade and enticed Lucent to acquire Octel in late 1997.

The NeXT “Acquisition of Apple” and The Great Apple Turnaround

In early 1997 I had moved to Apple to become a Vice President of Engineering immediately following Apple’s acquisition of NeXT Computer, the company led by Steve Jobs and which held the promise of a new operating system with the potential to replace the then 14 year old original MacOS. NeXT was an energetic, creative place where engineers had no fear of new ideas creeping into everything. Apple at that point was struggling horribly and engineering was quite risk averse in its product decision making. The then CEO, Gil Amelio, had few original ideas and demonstrated minimal leadership skills, although his struggle to find a solution to Apple’s software dilemma led him to NeXT Computer (how that happened is another anecdote). The acquisition of NeXT gave Apple an option for a viable and competitive Mach based OS kernel on which to base its next generation MacOS. It came with an added bonus: the return of Steve Jobs to Apple.

The Macintosh software was getting creaky in its old age. It had been through 8 major releases and the tread was wearing thin. It was a similar story on the hardware side, where there had been few substantive new ideas in industrial design or new product concepts in that decade at Apple with the possible exception of Newton, a product that failed, but was well regarded technically. One notable software success had been the transition from Motorola to PowerPC silicon at the Macintosh operating system core. That had been a very well engineered transition completed about three years earlier. It was an example of doing things right.

As we began to merge the NeXT engineering team into Apple engineering, there was definitely a culture clash. At that time Apple engineers were unaccustomed to trying big new things, certainly nothing as big as a new operating system kernel derived from unix, despite the clear need and the fact that it had been discussed endlessly as a viable option. The NeXT team thought of it as no big deal. For them this was proven technology on which they had based their company’s products for nearly a decade. They had years of experience working with it and had many reasons to be confident. However, we were all anxious about rewriting and reliably hosting the entire Mac Toolbox on top of a Mach kernel and maintaining compatibility with existing applications in the process. Throughout this period I had the challenging responsibility of leading about a fifth of software engineering consisting of a mixed team, about a third from NeXT and two thirds from Apple. The NeXT team was always suggesting new ways of doing things, often from scratch. The Apple team was usually thinking incrementally about how to build on top of what had already been done, to minimize code changes and to avoid breakage.

In the end the great learning experience here was that the two cultures did mix. The Apple teams became quite a bit less risk averse and the NeXT team became a lot more product quality conscious and more regimented in their development approaches and planning. I won’t claim that the great success of OSX was the direct result of these experiences, but it and many other things (the Apple On Line Store, the iMac, the iPod, etc.) were certainly an indirect result of this very successful merger. The biggest challenges in these mergers always seem to involve solving people, culture, and morale issues. Finding and building on the strengths of each team can and will result in the best outcome.

g) Microsoft “Saves” Apple, 1997

In early 1997 one of my responsibilities as Apple’s VP of Engineering for Internet and Enterprise Products was the development and shepherding of Apple’s unique and internally developed web browser, Cyberdog. It was an internet suite of applications including a browser, email and news readers which ran across the Apple product line on Mac OS 7, 8 and later on Mac OS 9. This browser had been very visible within Apple, was being competitively positioned, and it was touted publicly within the Apple universe for being highly innovative. Cyberdog was based on OpenDoc, an Apple sponsored and industry consortium endorsed component technology supporting publishing and reuse of frames in other compatible applications. Microsoft supported and relied on its own somewhat similar component technology, OLE, and was opposed to OpenDoc. We were working towards a Cyberdog release in April of that year but it was delayed by a budget driven layoff affecting many departments. Cyberdog was not as well known as the more dominant browsers then on the market, Microsoft’s Internet Explorer and NetScape’s Navigator, and it only ran on Macintosh computers, where these other browsers were multi-platform. Its future seemed shaky at best despite Apple’s best efforts.

During the later spring and early summer time frame Apple’s financial challenges continued to worsen, it was bleeding cash and was close to insolvency. It became imperative that Apple find some working capital. Steve, in his first quarter back as “acting CEO”, needed to buy some time to assess what we had, what to keep, what to drop and where to focus first. Survival was our first objective. To survive we needed some very basic things. It was apparent that we were going to adopt the guts of the NeXT OS and transform it into what would eventually be called Mac OS X, but that was more than a year out. We needed to do some short term things in order to assure that we would still be there in a year. We absolutely needed Microsoft Office for the Mac to continue and we needed a guarantee of an industry standard browser for the Mac. There was quite a bit of worry that Microsoft would pull the plug on MS Office and that would be the end game for Apple. MS Word and Excel were critical applications and were used everywhere: in Mac businesses, in academia and in government and by most consumers as well.

At the Macworld Expo/Boston keynote that summer, Steve told the crowd about the partnerships we needed to keep and to cultivate.

Bill Gates Saves Apple, 1997

Then, on the huge overhead projector Bill Gates suddenly appeared and made a set of amazing promises that included a $150 million “investment” in Apple and a commitment to continue developing MS Office for the Mac for at least 5 more years. Included in this announcement was also an expanded agreement to cross license current and future patents, and that Apple would make the Microsoft Internet Explorer the default browser on the Mac, with again, a five year support commitment from Microsoft. Why did they do all this? Was this some sort of magnanimous gesture? At the time it seemed miraculous. Why would they choose to save Apple?

It turns out that it was not a magnanimous gesture. In part, it was the result of the settlement of a lawsuit known as Apple Computer v. San Francisco Canyon Co. This suit claimed that this small company, Canyon, had lifted source code owned by Apple and delivered it to Microsoft (and Intel) where it was subsequently reused in what was eventually Microsoft’s Video for Windows. The $150 M, despite being described as an investment, was actually an initial payment on the multiyear settlement. I do not believe it was ever made public what the full dollar amount of the settlement was. Canyon had lifted Apple’s Quicktime for Windows video optimization code and delivered it to enable Video for Windows to perform as well as Quicktime for Windows did. So the “magnanimous gesture” turned out to be a punitive one that was beautified for public consumption and expanded into a multipart agreement. However, expediting the settlement and reaching the agreement rapidly was in the best interest of all parties at that time and the investment did result in Microsoft receiving some Apple stock.

The amazing part of this whole incident is the timing. It all happened at the very moment when Apple needed it the most. As part of the settlement and series of agreements, Microsoft received an allotment of 150,000 shares of Apple preferred stock convertible to common shares at a price of $8.25 and redeemable after 3 years. By 2001 Microsoft had converted it all to 18.1 million shares of common stock which they sold within another year or two for a respectable return of perhaps 3 times their initial investment. However, had they kept that stock it would today be worth in excess of $25 B. Yes, that “B” is not a typo.

Meanwhile, back in Cupertino, this was all good news except that it meant the end for Cyberdog and for OpenDoc. These two technologies had a lot of potential and eliminating them in exchange for our survival was disappointing. However, given our proximity to our own demise, it was a very fortunate set of agreements. From today’s perspective it seems truly insignificant that Cyberdog and OpenDoc had to be eliminated in the process. Internet Explorer then became the default browser on the Mac until Safari replaced it five years later (the term of the agreement).

h) The Search for VC funding: Heart vs. Brain

In the past two decades I have visited dozens of venture capital firms in California and elsewhere in search of funding with varying degrees of success. I have represented both early stage start ups and late round “survivor” private companies. I have learned that different VC firms have different cultures and personalities, for certain. I have also learned that the outcome of these meetings hinges as much if not more on the people, their attitude and the confidence they convey, than it does on the business plan. The rule in the VC world is to believe in the technology, but invest in the people. The VC goal is to identify individuals who are bright, agile and can adapt their budding company’s strategy in anticipation of barriers to success and as an immediate reaction to the unexpected. They hunt for people who are sharp witted, can think on their feet and can articulate a vision as effectively as they can a technical insight. They don’t have to be the most creative or the best engineers, but they need to be able to find that type of talent. They need to have drive and enthusiasm and good common sense. In these meetings much of the questioning and dialog may superficially address some obscure technical or business model issue, but, make no mistake, the team’s answer must come from the heart as much as from the brain. Unbridled confidence goes a very long way in this world.

Just like technologists, individual venture capitalists tend to specialize in a particular business or technical domain. Many of the meetings I have attended are led by the domain expert at the VC firm whose interest area matches your company and who becomes the internal advocate for your investment. This is often the individual who discovered your company and is now, perhaps for the first time, drawing the attention of the full VC firm staff to your company. Often that person has as much at stake in the success of the meeting as your company does. The fact that the attention of several firm members and partners is focused on your company reflects as much on the judgment of your VC advocate as it does on yourself. Often that individual drives the meeting by establishing a rapport with the lead company presenter and assessing the level of personal commitment and drive based on a common understanding of the business direction, the technology or the model. It is important to remember that this individual is likely to be your board member once the funding is completed. You want to have their trust and their full support. Anything less will be a festering problem to your company in the quarters ahead. You need to be thinking about their appropriateness to you as well, although this often gets lost in the excitement of the moment.

I have observed that the VCs I have met engage best with earlier stage companies that have not discovered all their barriers to success or tested the business feasibility of many of their models. These are the ones that don’t know that it “can’t be done”, they simply have a drive and a passion to do it, and often they will find a way to get it done despite all the naysayers. This passion is a difficult thing to quantify, but it is an obvious personality trait becoming apparent when addressing the members of the VC firm. Most VCs connect best with the glimmer in the eye and the contagious enthusiasm in the voice of a budding entrepreneur. The next thing they look for is the availability of either a prototype or a working product. Having captured eyeballs and an established revenue stream are very strong pluses. Often the discussion will turn to an investigation of uniqueness of concept or time to market lead over any known competition.

What to expect and how to prepare:

1. Communicate concisely
Because of the inevitable emphasis on passion and drive, it is extremely important to be able to summarize your vision concisely and your company’s direction should be something that rolls off your tongue with no effort. The shorter and more concise the better. This is sometimes referred to as your elevator pitch. Think of your chance to get funding as limited to what you can convey to the person standing next to you in an elevator in the time you have from when you step in until when you exit, maybe five or ten floors later. You must be able to capture their attention and convey the message extremely efficiently. This is something you will want to practice until it is effortless. You will probably have an hour or more in your VC meetings, but you need to lay the groundwork and get the message out effectively up front.

2. Provide backup materials
Your detailed slides or reports carry the details you need to defend your points later in the meeting. Don’t expect to be able to walk through your presentation in its intended order. You may make your first point, but within moments a question comes and the answer requires you to jump around in your pitch or story. Don’t let this fluster you. Expect it. Politely answer the question or suggest that it be tabled for later. You can do this. Losing control of the story early in a meeting can really throw you off and cost you an important opportunity. In short, be ready to swing at the fast balls, but expect to receive your share of curve balls.

3. Defend your uniqueness
Expect a question about your ability to beat any competition and how you are prepared to keep moving forward. On the web or in your marketplace anyone can copy you and sometimes your sole differentiator might be your confidence and ability to get the product out the door faster than anyone else, giving your team perhaps a six month lead over the competition. A six month lead is an eternity on the web. Think about evolving your concept iteratively and continuously following your first product. Think about how that first product will help formulate your second product concept. Your company must deliver on your first product and then continue scrambling to maintain that lead. Any company can be lapped or leapfrogged. Many times the followers are the ones that succeed simply because they have more staying power, more consistency of direction, more long term focus, and they are less bound by the need to invent the concept and more driven by the lure of a competitive race.

4. Know your needs
Usually an early stage company finds itself presenting to VCs before much of the team is in place, with only the core team and founders. Know the skillsets of the people you need. Be prepared to explain how the funding will enable you to get them. If you have candidates you intend to pursue, be prepared to name them and to accurately describe their background and appropriateness for the project. Know why their skills are right for the job, or if they are just known to be all around super stars, explain that. You also will want to have a good handle on what tangible assets you need to acquire and have a sense of the costs involved. If you need space, have an idea how much, where you would like it to be and how long you expect it to suffice. If you need equipment, the same thought processes apply.

5. Ask for suggestions and advice
Don’t overlook this last step. Often there will be a tremendous experienced resource pool in the room. Pump them for information on talent, companies doing anything similar, larger companies with an interest in this type of technology, etc. Asking for advice is an important step. It shows you are constantly thinking, are open to suggestions, and that you respect and appreciate their opinions. You are not obligated to follow the advice. Remember, at this point advice is free and free advice often has questionable value, but considering the source of this free advice, you might actually get an insight or a compelling suggestion that you might otherwise have overlooked.

i) Taking Your Company Public: Be Careful What You Wish For!

Palm Computer was a very experimental company at the forefront of mobile systems and PDAs at a time when devices were getting smaller (palm sized), but no one had yet successfully presented a small form factor with a touch screen to a large population of users. Palm did so with a stylus based screen interface and demonstrated just how effective such a touch system could be.

Palm’s history was quite tumultuous as it was bought and sold many times. Palm was founded in 1992. It was sold to US Robotics in 1995. 3Com acquired US Robotics in 1997 and then Palm spun out of 3Com and went public in 2000. As third parties began licensing the Palm software, Palm formed PalmSource as a software subsidiary to establish separation between its devices and software businesses. In 2003 Palm spun out PalmSource and acquired Handspring, Palm bought back full rights to the Palm brand from PalmSource in 2005 as PalmSource was acquired by Access. In 2007 Apple launched the iPhone. By 2010 Palm was reporting sizable losses and put the company on the market. Finally, HP acquired Palm in 2010.

I joined Palm during the time it was independent from 3Com and stayed for several years through its split into two companies: PalmOne (the hardware company) and PalmSource (the software company). I had been intrigued by the company for many years and nearly went there in the mid 90’s when they were much smaller. I thought they were an extremely creative, productive and cohesive team and saw many opportunities for their continued leadership in a mobile device space that was growing exponentially. I wanted to be part of that excitement and in early 2003 I became the Chief Product Officer at PalmSource. I led the software engineering development teams, the support organization, the product marketing organization and the user Interface design groups. As I joined the company our focus was on getting the next PalmOS release development cycle on track and delivered to our key customers.

Palm’s software products were widely used and the software was licensed to a host of third parties doing all sorts of things with it: Barcode readers and Sensors (Symbol), PDAs (IBM, Lenovo, PalmOne, Tapwave), phones (Samsung, PalmOne, QualComm, Kyocera), entertainment and multimedia systems (Sony CLIÉ), GPS integration (Garmin), wristwatches (Abacus/Fossil), etc.

One of our larger PalmOS licensees, Sony, had become a 6% investor in Palm in 2002. Sony wanted this next PalmOS release for a new generation of multimedia devices in development that delivered photo, video and audio playback that they branded as their “CLIÉ” line of handheld devices. This was quite an ambitious set of features for a handheld in that time frame.

The Sony CLIÉ

My job was to jump in several months after the departure of the previous engineering leader and to determine where in the development cycle each of the project components was and what it would take to complete it. In some cases there was confusion about the final feature set. In others there were instability issues, and in still others there were incompatibilities or poorly defined dependencies. The software development tools also required revisions and had to be prepared for delivery in sync with the associated PalmOS release.

It was a messy project like any large engineering effort tends to be when its team is in disarray and its product is not well defined. I did my best to nail down the open ended feature set, to assure myself that the engineering teams were all working collaboratively, to assess the development tools from the point of view of a customer, to evaluate the testing procedures and tune them, to validate the accuracy of the documentation, to guarantee support would be ready for this large new release, and to communicate the project status throughout the company. I also took the lead in providing release status to our key strategic customer and primary driver for this release, Sony, through multiple face to face meetings in Tokyo. This was challenging and a bit intimidating, but became fun as the project began to show progress and the bug counts began to trend in the right direction.

During this period Palm kept moving towards the separation of the hardware and software companies, which was considered essential because PalmSource had been quite successful at licensing PalmOS and had nearly 20 active licensees at that time. Unless the hardware and software companies (Palm and PalmSource) were independent from each other, Palm the hardware company, would be considered by the other licensees to have inside leverage with PalmSource and an unfair advantage at getting its requirements prioritized. As a result, PalmSource had its IPO in November of 2003 and was done simultaneously with Palm’s acquisition of Handspring to form PalmOne. We were then

The PalmSource IPO in 2003

two companies with different strategic agendas, bound together by the shared ownership of the Palm brand, which was managed by a holding company. We had been granted our wish: independence and we could now operate without limitations, or so we thought. It felt both invigorating and a bit intimidating.

As the PalmOS project was nearing completion, we began to hear rumblings from within Sony that their own house was not entirely in order. Regardless, I kept driving the teams forward and continued my monthly presentations to our key licensees. During the summer of 2004 when the product was stable and our release date was approaching, Sony informed us that the strategic plan for their CLIÉ products had been nixed by their senior management. This meant that they were going to pull the plug on the entire project. This they proceeded to do over the next year by first cutting headcount, then limiting availability of CLIÉ products only to Japan, and then cutting back support and drivers which ultimately led to the demise of the Sony CLIÉ line altogether. This hit those of us at PalmSource hard because Sony represented more than 20% of our licensing revenue, and no other customer could fill that revenue gap. At this time embedded open source Linux systems were making strides in the mobile device space and this new competition undermined our arguments for a proprietary PalmOS. PalmSource, as a newly independent company did not have much time to repair the revenue drop. Over the course of the next ten months we struggled to make our numbers and eventually found an exit strategy with Access acquiring PalmSource in September of 2005.

This experience reinforced the notion that I should be careful what I wish for, because it could happen with unexpected consequences!

j) Platform vs. Product: Maximizing Reuse and Minimizing Redundancy

Software development is expensive. To minimize specific product development costs, software must be general purpose, customizable and reusable. More often than not, too much customization results in too little reusability. This is the dilemma. The majority of the code must be reusable across the broadest application space. The reusable portion needs to be thought of as the platform on which nearly everything else is built. It needs to have characteristics like consistency, compatibility, uniformity, stability and it must deliver well defined runtime performance metrics on one or more target hardware platforms. This is very sensible, except in real companies with revenue sensitive product roadmaps, product delivery priorities tend to take precedence over platform sensibility. Both are needed in order to build a sustainable business.

For many years I have been responsible for developing generic software intended for use in a variety of product applications, to serve as the foundational software for many products most of which have yet to be defined. At PalmSource we designed and delivered PalmOS for our many licensees who used it to build a variety of products well beyond our vision, but all had common attributes around mobility, wireless, touch interface and handheld. PalmOS was a closed source platform but was designed to be extensible and our customers routinely extended it to build smart phones, gaming devices, field research products, inventory scanning devices, GPS products, cameras, datebooks, music libraries, memory enhancers, etc. Some wanted to emphasize multimedia storage and playback, others wanted it to be transaction centric and yet others wanted it to be data collection centric.

The common denominator was customizability. There were so many product concepts that it became our objective to deliver as much flexibility and tunability as possible. We would freeze, stabilize and release the platform more or less annually with a set of new features, a release number, and a name. The licensees would then design, manufacture and release the end user products. We evolved the platform with new feature releases and maintenance releases and we had numbering schemes and support models to enable us to manage the changes, keep release levels consistent and assure compatibility. Customizable software must be managed in this manner to avoid divergence and to enable a single evolutionary path for all.

At MontaVista Software where I was Vice President of Engineering we used a similar approach to releasing what we called “editions” of our software, all based on open source projects. Open source software is no different from closed source in that it must be stabilized and customized. The open source development tools we also packaged, delivered and supported required formal releases to guarantee full compatibility and consistency with any particular MontaVista edition release level. The primary difference between MontaVista’s open source platforms and PalmSource’s closed source software was that at MontaVista we pulled the software from the parent open source projects. To do so required making decisions about which versions in which to invest our development, support and QA resources. We then not only delivered the software in a final binary form but also in source code form enabling maximum modification by the customer.

Open source is a world where software components and projects have life cycles of their own and are periodically declared ready for mass use by their lead architects, known as “project maintainers”. At MontaVista our goal was to select the best Linux kerrnel, development tools and application products to productize, a process that required anticipation of feature completeness and overall stability well before a version was declared ready, or “final”. We did this on an annual basis and recognized that since the Linux kernel was released about every 11-13 weeks, there are about 4 or 5 new versions a year to choose from. We would have to skip several Linux kernel releases and select the right one for our customers to use. A bad choice could cost delays in stabilization or supportability or it might contain partially implemented functionality that is not ready for general use, but selecting an older, more “proven” release would be viewed as being less current and less competitive. True open source champions advocate pulling and using the very tip of the tree, the most current, and most unproven, code.

One problem my customers at PalmSource and MontaVista faced was that when they used our software platforms to build products, their essential customizations to the software became a set of proprietary features and modifications that they would need to maintain and integrate into our releases whenever they received them from us. Over time these code deltas could and often did become a substantial chunk of additional software and the reintegration time with each new release became an unwanted but necessary delay in getting their products out the door. Sometimes we would help them contribute some of those features back to the open source community in order to limit the need for future maintenance and integration, but most features were simply too product specific to be of interest in the open source community. I watched a few of my MontaVista customers grapple with their internal modifications in 2007 and thought quite a bit about it from both their and our points of view.

One of our new Linux edition customers that year was Cisco. Cisco had for years been successfully building and delivering their immense product families of routers and switches based on an internally designed and developed embedded operating system called IOS. It had served them well for over a decade through many releases, but product engineers had so extensively modified it for specific product lines that the code itself was no longer sharable between internal company product teams. Modifications needed by one team might also be needed by another, but the source code had diverged to the point that lifting a feature from one version to another was more work than simply rewriting it in the second version.

The Cisco management complained to us that there were some 150 or more variants of IOS in use around the company, the effort to reintegrate them all was insurmountable and could not be cost justified. As a result, they came to us with a strategic plan to phase out IOS and adopt MV Linux in its place and to not allow the code divergence to begin all over again on this new foundation. They would enforce this by creating a centralized platform team to centrally manage code modifications to their core platform and to do a one time only custom feature reintegration with each new release of MontaVista Linux before distributing it internally to product teams and business units. It was a necessary step to invent a set of processes allowing contained customization and to enable broader reuse of the platform code.

Another one of MontaVista’s customers at that time was Motorola Mobile Devices. By 2007 Motorola had made quite a large investment in building Linux phones for the Chinese market. This code base was known internally as Linux Java, or LJ, and was based on an early edition of MontaVista Linux that was some 2 or more years old at the time. There had been many releases of LJ and it was then nearing release level 7. A variant of this code served as the foundation of a very popular brand of Chinese phones, known as the Ming phones. Other variants were shipping elsewhere in China using different form factors and LJ release levels. The LJ 7 focus was to deliver a new generation of Chinese phones utilizing a greatly customized version of LJ, but it continued to be based on this much earlier version of MontaVista Linux. Motorola had begun to recognize the need for a platform team of the sort Cisco had devised and I was asked to join Motorola in order to take on that responsibility once this new line of phones was completed. I really liked the notion of doing that and decided to accept the offer to lead the LJ 7 platform team and project. I inherited a large team of around 1,000 engineers distributed in China, Silicon Valley and Chicago, and a sizable annual budget of about $75M. I also inherited a set of features in development and a scheduled delivery date that at that point was only ten months out, a very ambitious schedule.

The Mobile Devices business unit of Motorola was driven by a set of quite independent product teams, each building lead devices for a particular carrier and then expanding that device’s footprint after it shipped to include as many similar carriers and geographies as possible. There were product teams developing devices based on Symbian, Windows Mobile, Linux and P2K. P2K was an internally developed embedded system that was used in the majority of phones positioned in the lower half of Motorola’s mobile phone price range. P2K was not unlike Cisco’s IOS in the sense that many product teams had used it, there were many variants of the code by region, carrier, technology, etc., and it had reached the point where, like IOS, it was difficult to adopt changes developed in one divergent code base in another. For the Linux Java work, it became my goal to platform-ize it and to avoid the code divergence and fragmentation seen with the P2K code lines. This required stabilizing it, revising it to include a much more current Linux kernel, and then centralizing the management of subsequent changes through adoption of a set of architectural and code review processes that assured high reusability of these changes.

Over the course of the next 2 quarters my Motorola LJ team was able to complete over 140 new LJ 7 release features and then to successfully stabilize and tune the code. However there were additional features being developed by our partner product teams and those required the help and supervision of my team to enable their timely completion and to retain the aggressive delivery date commitments. We restructured ourselves as two teams, a platform team and a product support team. The platform team then innovated around several new development and problem resolution processes to establish the separate notion of platform. My Chinese teams invented the concept of a platform health team manned by hands-on architects who could rapidly identify, reproduce, prioritize and resolve problems found in each new build or in the current code base as a whole. We had a performance team responsible for driving towards a set of elapsed time performance targets tied to around 100 typical end user usage scenarios. We struggled to maintain full platform team staffing through the targeted delivery date for the target products. There was constant pressure to drop platform work in order to expedite product shipments. This delayed some of our planned LJ platforming work designed to branch the code into an actively modified development branch and a stabilized product support branch. The initially released LJ 7 phones for the China market did ship on time in the fall of 2008 at some cost to the platform goals. The delays to completing the supporting platform work are typical of the tradeoffs necessary in achieving aggressive product delivery commitments.

As all of this development was underway Motorola was grappling with a much bigger question: how to maximize the return on R&D investment and select the best software base to use as the foundation for future smart phone development. This strategic planning was initiated by the arrival of our new CEO in mid 2008. The outcome of this extensive planning resulted in Motorola’s well known strategic decision to adopt Android as its primary smart phone platform, which led to the eventual demise of LJ (along with Symbian, Windows Mobile and P2K). The platform planning concepts, processes and tools preparatory work we had done for LJ was further developed on Android, and enabled a very rapid definition and adoption of Android platform processes, tools and methodologies.

Android as delivered by Google is by definition a base platform. Google determines how much of the functionality must be present to call a product an Android product and to permit applications developed for it to be deployed through the Android Marketplace. Google software releases vary in stability and completeness. There is usually a lead device with each Android release, called the “Google Experience” device. The Motorola Droid for Verizon was the Google Experience device for Android 2.2. This release also highlighted Android’s support of a new silicon family, the Texas Instruments OMAP 3430. Much of the stability and performance seen with this release can be attributed to the preceding 2+ years of effort invested by both TI and Motorola on doing the complete Linux Java bring up on this chip set. Google accepted many of our combined LJ platform improvements in the BSP. Post release, my internal platform team engaged with the many product teams and managed the life cycle of product specific changes, to enforce development guidelines, architectural consistency, and feature appropriateness for a general internal release. We also managed a pipeline of features queued up for submission to Google for adoption in the next mainstream Android release. The benefits of platform development had become central to the Motorola Android development mentality, the benefits to be gained in future product development cycles through increased code reuse and minimal redundant development between product teams.

What is the bottom line?

A platform oriented engineering team is essential to manage the code base. They must be authorized and encouraged to enforce rules: rules of conduct, rules of architecture, and rules of process. Without this your software will diverge into multiple code bases, leverage between teams will be lost, redundant coding will ensue, and eventually will become unmanageable. This gets very costly very quickly.

k) Leading the Parade

One of the many business leadership lessons I learned from Steve Jobs was his “parading businesses” metaphor. He would often say that we do not have to invent the next new thing, but we need to be certain that we pick the right next things and then out execute all of the other players who are already there. He would go on to say that we need to pick the parade we want to be in and then get in front of it. Once you pick your parade you need to decide how to establish the right leadership to enable you to get in front of it and then continue to innovate so that you can steer the direction the parade is headed. In 2008 Steve was quoted in Fortune on this topic.

“Things happen fairly slowly, you know. They do. These waves of technology, you can see them way before they happen, and you just have to choose wisely which ones you’re going to surf. If you choose unwisely, then you can waste a lot of energy, but if you choose wisely it actually unfolds fairly slowly. It takes years. One of our biggest insights [years ago] was that we didn’t want to get into any business where we didn’t own or control the primary technology because you’ll get your head handed to you.” Source: Fortune, Mar. 7 2008

Apple’s brilliance has been its ability to pick the right parades and do the follow through execution to be the parade leader. Looking back over the last 18 years, here are some of them:

- Multicolored integrated iMacs. Established leadership in consumer oriented computers at a time when most computers were beige and bland.

- Think(ing) Different(ly) Campaign. Associated Apple with the essence of creative spirit at a time when Apple was struggling to survive.

- MacOS X. Adopted unix and unix derivatives for mass market consumer use at a time when Windows was the unqualified desktop leader.

- MacOS X. Evolved the traditional MacOS user experience into a much more consumer oriented and friendly MacOS X.

- iPod. Established leadership in handheld electronic music players at a time when MP3 players were geeky and everywhere, but trends in digital music management distribution were not settled.

- iTunes. Established leadership in digital media management, sales and distribution at a time when the record industry firmly controlled music distribution.

- iPhone. Established a truly successful touch oriented smartphone at a time when keypad oriented smart phone products were prevalent and touch was considered burdensome (because of the stylus requirement) and unnecessary.

- AppStore. Enabled a simplified process for obtaining applications for your iPhone, iPad or computer, and providing a clear, open process for app developers to obtain broad distribution. This level playing field is the key ingredient in creating a successful app ecosystem.

- iPad. Made tablet computing compelling at a time when many others had built unsuccessful tablets.

iWatch. Placed many digital world imperatives on your wrist making them instantly available (voice control, wallet, activity tracking, notifications)

This list goes on.

Steve was also fond of saying, “Good artists copy, great artists steal”. He not only believed this, but this very quote he stole from Picasso, which further illustrates the point. This is all especially relevant with increased litigation around patents and intellectual property protection. In 2012 Apple sued Samsung for copying its designs in a widely publicized litigation. It is not just Samsung that copies. Steve’s entire notion of getting in front of the parade starts with an instance of a copied product or concept and then building on that.

l) Eating Your Own Dog Food

Delivering a new software product is a prolonged, painstaking undertaking that requires commitment, vigilance and perseverence. Is the design right? Is the implementation robust? Will it withstand the necessary load and stress? Is it usable? Does it provide the correct interfaces? These are a few of the thousands of questions that must be asked and investigated as a product plan is executed. As the first prototypes take form the initial users are typically the engineering developers themselves.

For a new product or build, the initial question is always: does it work correctly? Determining the answer to that question is often the domain of the Quality Assurance engineering team. Their job is to determine if the prototype works correctly according to the specification. Often much of this testing can be automated, since the information on how the product should be used was documented at a very early stage in the development cycle. The bigger question is whether it is bullet proof. Does it do only those things it was designed to do? What happens when unexpected or even malicious input is submitted? Does its performance scale properly as its usage peaks? Eventually the QA team will provide an assessment and if the product is deemed ready, it can be put into broader use.

At some companies this broader use is called a beta program. Betas can be an internal and/or an external. It is always recommended to do an internal beta first. There must be a plan. How many users can be properly managed? How will support work? What mechanisms will be used to report feedback? How frequently will the beta site software be updated? How long should the beta program last? Will users use this instead of the more established OTHER software that is in common usage for this purpose? If so it becomes critical that it be ready and properly supported.

Now eating your own dog food begins to have meaning. You are eating your own dog food if

- your beta software is being used instead of the normal software for everyday, mission critical, usage

- the daily functioning of your beta users depends on it

- real users are using it continuously

- - problems are being identified and tracked efficiently
- new versions containing fixes are rapidly being put into service

It is simply the best way to prove the stability and usability of the product, but only if the beta management team is in place to support users, to process problems efficiently, and to update users’ software quickly. In short, you want to learn as much as you can as quickly as you can, to enable the product to move to a potentially much larger external beta program with many fewer surprises.

m) Becoming a First Time Engineering Manager

In the late 70’s, as a brash newbie software engineer fresh from Berkeley I landed in Silicon Valley as a member of the technical staff in the Data Systems Division of Hewlett Packard. I had a big ego and a fairly hard boiled anti-management attitude. Perhaps this stemmed from my heavily ingrained Berkeley anti establishment mentality. Coming from the university environment I simply could not see what possible value managers were adding to the talent mix and I resented having them speak on my behalf. I recall lunches with friends where managers would sometimes attend and on one occasion I recall grilling a manager for the entire lunch to explain to me what he actually did while I made snide comments. It was actually rather immature on my part, of course. As it turns out this particular manager did not work for my company and he was not particularly adept at describing his role. This further reinforced my negative attitudes.

Several years later on a spring day in 1984 I learned that my manager had resigned. He was actually a guy I liked a lot, and he was more of a hands on contributor than a manager, or at least that is how I saw him (or maybe I had matured a bit). Within an hour his manager suddenly appeared in my office and informed me that I was to be his replacement and that he would not take no for an answer. This situation presented me with a real career dilemma. Should I remain true to my belief that the only virtuous work was coding and anyone not coding at 100% capacity was dragging down everyone else? I eventually acquiesced and took on this first level management role. I defined my new role with my former peers to be collaborative and directive and soon discovered that despite doing less actual hands on development, I was doing more product direction setting and even making decisions impacting the company results. I participated in engineering wide product and resource planning and began to understand how our product offerings directly supported the company strategy. I learned over the next few years why management is relevant and why good management is essential.

Over the years since this episode I have moved up the management ranks. On several occasions I have found myself in the position of my manager’s manager back in 1984. I have made some good choices and some not so good ones. I have learned that one can teach good management practices, but cannot teach technological skills, at least not in a useful enough timeframe to make it worthwhile. The most important criteria for selecting a candidate for engineering management are technical competence and basic interpersonal skills. A person without both of these traits will usually fail. A non-technical manager will usually fail to earn the respect of the team, and a technical manager with clumsy interpersonal skills will alienate team members through (probably unintended) social misques, inadequate verbal communication, ambiguous directions, or indirect criticism. I have also observed that a person possessing reasonable interpersonal skills can be taught better behaviors, and will often learn through example provided their technical acumen enables them to make good decisions as well. The person with minimal technical competence will usually lose team respect before they can learn the technical ropes, regardless of their polished demeanor, style and communication skills.

n) Another Take on Management Style…Are You a Consensus Manager?

I have never settled on a preferred answer to the question about my management style and philosopy, and often make it up on the fly. Sometimes I explain my drive to be consistent, to be as predictable as possible, to demonstrate desired behaviors, to be fair, to be demanding but reasonable, and to listen carefully to candid feedback. Once in the mid-2000’s I was interviewing for an executive role at a very large European phone manufacturer in their upstate New York offices. This site housed, amongst other things, an arm of their prolific and omnipresent HR organization. I found myself interviewing with several of these HR people on this particular visit. One of them asked some flavor of the question about my management style, to which I began answering using one of the arbitrary responses mentioned above. This time, however, I got into a discussion of decision making as part of my style, probably in the context of being fair or consistent. In making the point that group consensus was desirable but not always achievable, I said that I am not a consensus manager. I continued to explain that I strive for consensus, but if it cannot be achieved, I said that I do not hesitate to make a tough decision but will always explain my logic so that the individuals present will understand a bit more about how I think in order to make my future responses a little more predictable.

I went on to give a few examples of decisions I have made in lieu of consensus and why. This particular company was in fact very much a consensus oriented decision making company where nearly all decisions were vetted by a host of participants and anyone was capable of rejecting or altering it. This was apparently part of their company DNA. I found that my HR interviewers had stopped listening when I had said, “I am not a consensus manager…” and had already mentally walked me out the door. They had not listened to the explanation or to the examples. It was simply black and white to them. I was not going to fit into their culture of which these HR people were the self proclaimed guardians.

This question of management style seems to be coming up more frequently in recent years, perhaps coinciding with my decision to stop dying my beard black and to let my whole head turn grey. At least I am not bald, but I must appear a lot more hard boiled and set in my ways now that I am visibly and obviously “older”. I still do not use a standard answer to this work style question and try to work the answer into the previous context of the conversation. A few months ago it came immediately following my description of how my previous executive positions had evolved to reflect market directions, industry conditions and company strategies. I began by describing the realization that in the world of open source, agile/lean development and ultra competitive mobile product landscapes, a product plan might need to be revisited many times during its development cycle giving the impression that the plan is always in flux and is never set. Feature or content additions become more about opportunity cost where it is necessary to exercise good judgment and to really know the team’s capacity in order to make reliable product affecting decisions. Having clarity around the overall strategy and direction is necessary for good judgment to be exercisable not just by senior management, but by everyone on the team.

Agile development teams are typically making product decisions like these in weekly scrum meetings. They feel they must be able to adjust the plan as either internal or external opportunities arise. When an engineering organization changes to agile/lean development they often simultaneously eliminate most of the project definition phases: up-front planning, document preparation, requirements gathering and product specifications. This scenario leaves a scrum team with no context or framework for using good judgment to make good decisions, in effect, no real plan. Transitioning to agile development does not mean throwing the baby out with the bath water. Planning is still required. The scrum teams must keep an eye on the overall deliverables, despite being tempted to accept code contributions from respected team members simply because they describe them as ready to be submitted and not factoring in the strategic value of including that contribution for the upcoming release.

A key element of my management style has been to “right-size” the development processes as they are streamlined for agile/lean team development. Your team may no longer need an immense MRD (Market Requirements Document) with justification, market analysis and use cases, but they do need clarity around who the target customers are, what they need in the product and why they need it. If the scrum teams are left to make decisions without this guidance, they will opt for feature acceptance when the code is available and ready, independent of the feature’s value to the release. Senior management must be very active in its leadership and shepherding of the development teams and show them how to make decisions in the correct product delivery context, how to engage the product marketing folks in the scrum processes and overrule some submissions favoring strategy over readiness. I like to call this management style “management by demonstration”, and I have found teams learn how to do it quite rapidly as they see it. Additionally, they prefer understanding and following a framework for making these decisions rather than being left to simply make the call in a relative vacuum using common sense as their only guide.

This returns us to the previous discussion of rewards and recognition and provides us as managers with another opportunity to demonstrate the importance of recognizing when these daily decisions as they are made, using recognition to illustrate the right set of tradeoffs in making product decisions.

o) The Answer Is Yes, What Was the Question?

As a start up you need customers. You never know where the next one will come from or what new business segment they will represent. At one of my start up companies we had a brash CTO who was constantly on the road teaming with either marketing or sales to make us known, to demonstrate our product concept, and to reel in the next customer candidates. I knew from attending several that these customer meeting trips were quite grueling and the customers always had ideas for how our product concept could better satisfy their specific needs. Our CTO had a philosophy that regardless of what they ask, it is already built into the product. If their question is, “Does the product have a certain feature?”, the answer was always yes. If they want that feature, it is there. This may be dishonest on the surface, but his thinking was that by the time the business agreement was likely to be in completed, the engineering team will have enough time to implement the feature.

Needless to say, as the VP of Engineering, this practice used to drive me nuts. We had fast paced two or three week product update cycles. These cycles were overcommitted and understaffed. There was a feature list a mile long already in place. I felt that the work kept backing up and having a couple new features added following each customer visit did not help. I came from a development environment where we wrote a requirements document, a functional spec, a design document, a Gantt charted development plan, a test plan document and then we performed rigorous testing cycles to drive the defect count down to an acceptable threshold. In other words, it was a waterfall world. I learned that developing for the web can’t work that way. For one thing, 18 month release cycles are unacceptable. In many cases even an 18 day release cycle is considered too long.

I learned how to pare back on the planning and preparation and adjust the plan as we went. In effect, to create an agile environment, before the term agile was in general usage. I insisted that the developers test their features before they check them in and then provide their test tools and results to the QA team as part of the code check in process. It became possible to hand pick features from anywhere in the pipeline and move them up in delivery timeframe depending on their stated dependencies, something that ultimately allowed us to adapt the features coming in “over the transom” from sales and CTO customer meetings.

These were the early days of learning how to be flexible and timely in the web space. Those are also two traits you cannot live without in a start up and they are generally useful in life as well. If the customer wants it, yes it is there. Then go off and make it so!

p) Joining a Start Up Means Sometimes Mopping the Floors

In 1999 I left my executive engineering position at Apple to join a fledgling start up as the VP of Engineering. At the time our company was a 5 person team with an idea, a PowerPoint deck, and lots of energy and enthusiasm. We had a CEO who had been the founder and CTO at his previous, successful company leading to an acquisition by Sun, which was then on an company buying spree. We had a youthful, charismatic dynamo of a CTO overflowing with confidence and can do attitude and an industry expert and a former company CEO as our VP of Marketing. We also had a couple of very capable engineers working on a prototype. The team had just received its Series A funding and was ready to make it happen.

In my role leading engineering I knew that I needed to build the team, define and create the development processes, oversee the product design, support sales and synchronize with marketing on specific initial feature requirements and timeframes, and of course, deliver and support the product. I considered all of these things as the standard responsibility of an engineering leader and they were typical for the roles I had held previously. I did not anticipate the many other things that would come up over the course of that first year that also became my engineering responsibility simply because someone had to do it. A lot of stuff gets done in start ups that way…

Hire and set up the internal IT team (we had no “IT department”)
Select a colocation facility to host our fledgling site
Decide on data center equipment and software
Obtain licenses for software and hardware
Build out the internal data center
Build out the external data center
Set up the external web site
Establish processes for updating company website
Set up and support internal website
Build out the internal office data network
Select phone system (we had no IT department)
Set up break room, buy refrigerator, utensils, supplies
Keep break room stocked with snacks and energy treats for the entire company (since most of the headcount was engineering this became my job)
Purchase office furniture at IKEA
Construct IKEA office furniture (the parts come in a box)
Buy office computers at Fry’s, charged to my personal credit card (we had no IT department)
Give motivational talks to the company
Lead strategic debates in exec staff meetings
Do product demonstrations
Meet and greet prospective customers and investors
Attend board meetings and present engineering progress reports
Support and participate in the effort to obtain subsequent rounds of funding
Select a new building (we had no facilities department)
Make company culture decisions for new building floor plan (we had no HR department)
Define a company culture, determine our company culture priorities and terminology (we had no HR department)
Get tee shirts and coffee mugs printed
Hire electrical contractor to lay fiber for high speed data connection at new building
Hire construction contractor to dig trench to frontage road for above mentioned fiber link
Get city permit to dig above mentioned trench

…and sometimes mop the floors and take out the garbage

Was it worth it? Absolutely! This position was one of the most satisfying, highest energy, most fast paced roles I have held throughout my career. We went from almost nothing to a full engineering team of 65 people, a working product, a dozen top tier customers, and our first real revenue all within a six month period. Along the way we needed to figure out how to deploy our product on the web, how to maintain it, update it and support it. There were no standard tools for these things in 1999. It was so unlike my previous role at Apple where we had a partitioning of responsibilities, a lot of support, all the company functions, and there were processes and procedures for everything that needed to be done. In our start up we did it all ourselves. No one was too elite to take on a mundane task if it needed to be done.

q) Putting “Good” Money after “Bad”, the Late Stage Start Up Dilemma

Late stage survivor companies searching for a D or even an E round of funding are intriguing beasts. I have represented a few of those as well. These are typically companies that have been around for five to ten years, have a revenue stream, have probably had some good quarters, but have not achieved a consistent degree of business performance. There have been break even quarters and losses as well. Management has come and gone. The remaining management team tends to be scrappy with struggling leaders who have seen bad times and good. The teams have worked and reworked their presentation materials to such a degree that they can make their points from rote memory. Their responses to the typical repartee in a VC conference room reflect hard boiled pragmatism intertwined with a glimmer of hope that they can still pull perfume from the pig.

Often the dialog in these meetings will go into why a particular strategy or sales approach failed to deliver anticipated results. These discussions can drag out, and the team members can get defensive. You must avoid this natural reaction to defensively explain your actions. That is a no win situation guaranteed to disappoint. Sometimes the conversation will turn to why a particular new approach might succeed. This is the key to a successful meeting outcome, because this is where the leadership has a chance to demonstrate that they continue to have drive and initiative, and gives the VC an opportunity to reassess the people.

Occasionally it leads to a new funding round, typically led by the new VC. This changes a lot of things. First, the board of directors will no doubt shift in character and membership to reflect the new VC. Often a change in company management is demanded. A new CEO or CFO is not uncommon. Overall this might be a good thing, since the old team was clearly challenged to make the business work. A new leader might see things differently and find a new angle. That is the optimistic perspective, of course.

I have also seen meetings like this end inconclusively without clear next steps. Typically a VC firm that has not found a path to success with a team like this within the first 5 years will have lost interest in it in favor of the many more exciting opportunities with larger potential upsides. There is a saying in the VC world: “Don’t put good money after bad”. Sometimes a decision to provide additional funding comes at a high cost to the company: a required layoff, a mandatory change of management or a painful cost cutting exercise.

Slotnick Systems

Recent Posts

Browse by Tags

Anecdotes