BONUS: Innovation in the Context of Success (An Essay)
Concepts, Tools, Culture, and Change: Challenges of Innovating at Scale
No numbered post this week due to the US holiday. As we transition to Windows 8, I wanted to offer this essay on innovation in the context of success.
Thank you for reading along on my journey of the PC in Hardcore Software. There are two chapters (about a dozen posts) remaining and both are about the development of Windows 8. If I were writing a traditional book and not Substack then most certainly a decade ago I would have just written the story of Windows 8, what went wrong and even a bit of what went right. Instead, I wanted to bring the full context of the product with the events that led up to it a rich foundation that shows how much of a part of the arc of the entire PC computing revolution Windows 8 turned out to be. By waiting for the story to settle so to speak, readers can also bring perspective that was not available even five years ago.
Microsoft and by extension the PC have always been about tools—tools to enhance creativity, increase productivity, empower individuals and teams. Placing a computer on every desktop and in every home was the ultimate expression of the breadth of the tool, and then the company actually achieved that. Let that sink in. A company arrives at a corporate mission in the mid 1970s and then actually achieves it sometime around 2005. Incredible.
The computer wasn’t always a practical tool. For many years it remained an elusive concept. By that I mean, computers were wonderful in theory but as a practical matter there were so few of them and they were so expensive and impossible to use that few benefitted. It wasn’t until IBM and the mid-1960s that the computer moved from a concept to a tool or said another way from a theory to a product. Once computing was a product, it was just a matter of time before the paradigm shift that followed would take hold. Soon, within the span of a generation, the computerization of everything took place.
Looked at through this perspective, the personal computer is a natural part of the story of the technology dispersion of the computing paradigm. Making computers cheaper, smaller, faster, and thus available to more people and teams followed naturally, even if many along the way thought it foolish. The entire mindset of computing changed at several points along this journey. In other words, a new concept of computing emerged and then what followed was a paradigm shift populated with new products. Those new products, of most interest to us in this context, came with new leaders in a business and technology sense. Bill Gates would often point out that major shifts were also a time when there was opportunity for new companies and peril for existing leaders.
By now we are all familiar with the march of various paradigms of computing: calculating machines, mainframes for databases, mini-computers, networked workstations, stand-alone personal computers, graphical interface computing, internetworked endpoints, and servers. We arrive at today with mobile computing and cloud computing. Each paradigm building, and often rebuilding, on the ideas of the previous paradigm. Followed by a period of refinement. Each with an accompanying change in technical and business leadership.
It is often these changes in leadership that surprise people the most. As many know I am a huge fan of the series Halt and Catch Fire. The series takes place in the 1980s just as one of these paradigm shifts began, specifically the change to personal computing. One of the key moments, both fictionally and in real life, was the creation of the first BIOS, the basic input output system which is the most primitive software of a computer. Once the fictional startup created the BIOS they were met with a cadre of lawyers from IBM, International Business Machines, who used the hardest of hardball tactics of the day in an attempt to stifle this innovation. The entrepreneurs succeeded and the fictionalized Compaq computer was born. The takeaway from this scene is the awesome and terrifying power displayed by IBM. I shared a similar experience in the mid-1980s when some IBM lawyers visited the computer science lab I worked in. Then the lawyers, who outnumbered us two to one, aimed to assert ownership of our work simply because we used IBM hardware as part of a research grant. Incidentally, we used IBM RS/6000 RISC workstations running Unix. They failed then.
I reflect on this often as I consider both how awe-inspiring powerful IBM appeared in the early days of the PC. IBM was not a brand but the definition of computing. I recall the first time I ventured into a “computer system retailer” to buy floppy discs from a salesman in a suit and tie (they didn’t even accept cash, I needed to open an account and receive invoices) where the IBM logos were displayed as though they were the flags of country. Then a few years later at Microsoft, the power and secrecy around how IBM worked was told to me through those that took an uncountable number of trips to Boca Raton while working on OS/2.
Those stories were more complex though. IBM wasn’t scary for technology reasons. In fact, IBM had clearly lost its way. At the time, Bill Gates shared with me his story of battling with IBM over engineering productivity, a story I had heard a dozen times already. IBM measured productivity in KLOC—thousands of lines of code—which was literally the opposite of how Microsoft achieved productivity. Microsoft, BillG and Paul Allen, cut their teeth on writing as few lines of code consuming as little memory as possible (4K over the weekend to be specific) and not on showing off thousands of lines of PL/1. IBM was the old paradigm. Microsoft created a new paradigm. IBM still felt and acted as though they were powerful and dominant like they had been just a few years earlier. They were not. In fact, the reason Bill shared that story with me at the time he did was because Microsoft had finally broken free of the OS/2 joint development agreement. Bill felt it was a bet the company move. To those of us that grew up with PCs and only PCs, it was not just natural but actually puzzling why IBM was still so feared.
What had happened, at least in my view, was that IBM lost sight of building great tools. Sure they built the best tools for running a bank from an underground bunker of million-dollar servers. There was no doubt about that. The world saw new opportunity. It saw the spreadsheet, the word processor, desktop publishing, and more. These tools were a new paradigm too. The paradigm of individual empowerment.
IBM was trapped in a creation of its own making. For almost three decades the IBM mainframe had been so busy solving problems of IBM mainframes that the company could not look up or out to see that the problems that were solved with each successive new product were no longer worth the cost of change or adoption. A favorite childhood book of mine was Mike Mulligan and His Steam Shovel. In the story, quoting the Wikipedia summary:
After many years working together, Mike and his coal-powered steam shovel Mary Anne (whose name is a reference to the Marion Power Shovel Company) face competition from more modern gasoline, electric, and diesel shovels. Searching for work, they find a small town about to build a new town hall. Mike offers that if he and Mary Anne can't do the job in a single day, the town won't have to pay them. The town's selectmen – who believe the work would take a hundred men a week – hire Mike and Mary Anne, expecting to get their new cellar at no cost. Privately, even Mike has some doubts.
At sunup the next day Mike and Mary Anne begin work. When sundown comes they have just finished the job, but realize they have neglected to leave a ramp by which Mary Anne can get out of the cellar. A child suggests that Mary Anne be converted to a boiler for the new building's heating system, and that Mike become its janitor. Mike and Mary Anne settle contentedly into their new jobs.1
While just a metaphor, it always made me think that it is ironic that IBM continued to push mainframes right up until they are quite literally sitting in the basement and the operators settle contentedly into jobs operating those basement computers. A key part of the metaphor is that new technologies arise, and it doesn’t mean old ones go away, but rather they settle into a more content mode of delivering on the old promise in some way, perhaps inefficiently. It is a bit harsh, but I was in my early 20s when I adopted this childhood story for one of my ongoing metaphors of technology shifts.
This metaphor repeats itself at every generational shift in paradigms followed by improved and brand new tools—like clockwork. The ingredients and even the timing for these shifts becomes readily apparent as one benefits from seeing the changeover happen multiple times, even as a participant.
It is helpful to start with why a specific tool can take hold and spread so quickly. Each time new tools appear they have some combination of the following attributes:
Immediately does what it claims to do, no matter how trivial it might seem to some
Easily understood by a single or very small group of motivated people
Straightforwardly mutable into doing tasks beyond those originally intended
Effortlessly acquired with little friction by those with an affinity for technology
Seamlessly fits the profile of a hobby or side project
Organically attracts partners and third parties creating an ecosystem
Rarely competes directly with current offerings
And so on. Many people reading this were products (so to speak) of the first wave or paradigm (yes it is tricky to define these waves, but it isn’t critical to make the point) of internet computing. The speed bumps of setting up TCP/IP, using FTP to find a browser, and so on were exactly what I’m talking about. These were not insurmountable, yet they were enough of a hobby to make the investment worthwhile. The payoff was immediate access to a new world—almost a metaverse—of ideas, images, and capabilities. The steps there to setting up a private web server, programming CGI, and building a site were achievable without much, if any, infrastructure, formal training, or investment beyond that of a hobby or side project.
The personal computer was of course just like this. The first hobbyists of a personal computer obtained a printout of a BASIC interpreter and keyed that in. It required little by way of skill. It required access to an early computer. I shared the story of how my first programming was done on my best friend’s family Atari. It had no tape drive, so every afternoon I went over to his house and typed the same program to compute sales tax, shipping, and total cost for an order of mythical products from a store. I was trying to solve the classic point-of-sale solution for our family retail business. It was thrilling and productive beyond words.
Along the way these exact tools change in character. They mature. The companies around them solidify. They improve markedly from what the first experiences were. By Windows 95 everything one needed to access the internet, sans an analog dial up account, was ready to go as soon as a PC was unboxed. A short time after retyping the sales program in BASIC, my father bought an Osborne I for the business and now I had a floppy disk and dBase and he had a fully operational inventory and accounts payable system that computed the right sales tax.
This characteristic of increasing abstraction and iteration on what started off as a paradigm shift is exactly what is so incredibly valuable. For many years I had the following quote hanging on the relite of my office, as I moved from office to office it moved with me:
What I love so much about this quote from two of the most eminent thinkers and contemporaries of the 20th century is how they appear to be debating, but, at least to me, they are answering two sides of the same question. The question is “What is innovation?” The answer is that it is really a whole new idea followed by an amazing tool that brings the idea to practice. They are both right. Besides, who am I to get in the middle of these two whose thoughts and writings will certainly outlast anything I contribute.
This question of “What is innovation?” matters to a business because with great success it seems to become increasingly difficult to innovate. In fact, what I think has become clear in writing Hardcore Software is how much time is spent even debating whether something is innovative or incremental, solves a hard problem or addresses customer pain, or value-add or value-negative for the business. Such questions tend to consume all the oxygen in a successful company. It is also why the later-stage products from a mature and successful company take on an entirely different character than the early products from a company.
Much has been written about founder-led companies or even just nostalgic views of the good old days of a company, referring to the time of maximal innovation or when products were released at what seemed to be an incredible pace. There is no doubt truth in longing for those past days. One of my favorite books on technology product history of Emerson Pugh’s IBM’s 360 and Early 370 Systems. This book details the absolutely mind-boggling number of inventions that were productized in what today we’d consider a single product cycle: operating systems, disk drives, memory, virtualization, device drivers, programming languages and more. One would be hard-pressed to find a modern comparison of raw inventive engineering that took place in a single cycle. Yet at the same time it would be enormously unfair to discount the innovations that IBM subsequently brought to computing in databases, networking, reliability, and operating scale. Those innovations, however, only make sense and have impact within that IBM context, which of course was everything for that decade.
My view, as a technologist, is that the first paradigm of computing innovation was the ultimate in tool creation—the literal creation of the mainframe computer. Following that is further creation of tools, though perhaps more clearly purpose-built or focused on solving specific problems versus a universe of capabilities. The next wave of tools moved up the stack of the mainframe to create a platform more people could use and do more with. The creation of the mainframe database and associated transaction processing capabilities is an incredible example of such a tool-driven and paradigm-shifting revolution, especially because it was Oracle and not IBM that perhaps benefitted the most.
It is what comes after that second wave that I find most interesting. The pace slows, but something else changes. The characteristics of what is brought to market change. In essence, what seems to happen is that the products that are released fail both to be interesting in theory or practice, they are neither paradigm shifting nor tool-centric revolutions. Technologists or product-centric thinkers always often look for such a demarcation in time when a company makes such a shift. Too often it is ascribed to a change in leadership, a particular failed product, or a poor response to a competitor. To me these are circumstantial and not causal. What we can identify in failing to lead a revolution are the attributes of products that are released in this third wave that create the opportunity for a paradigm shift:
Awkward to solve problems that were not quite a good fit for the product
Difficult to comprehend the system end-to-end
Inflexible to tinkering due to aging and complex architecture and constraints imposed
Challenged to find ideas that don’t conflict with existing tools and products
Afraid to change too much or break with the past due to commitment to an ecosystem
Shrewd towards competition by crafting competitive frameworks versus competing head-on or replacing your own product
Let me offer some critiques of Windows as we got through building Windows 7 in this regard. My hope is that one can see that what the company tried was not successful in changing enough to create or join a paradigm shift. I write this in the context that Windows 7 was enormously successful relative to what we set out to accomplish and in how the market ultimately received it.
Much of what went on from the late 1990s through 2007 (when Vista shipped) was an attempt to scale Windows from the smallest devices to the largest devices and to branch off to special purpose devices as well. “It’s just software” and “Using Windows is efficient” are the rallying cries for the era.
As a result, something like TabletPC emerged where it was clear Windows was an entirely awkward base upon which to build the product. Yet one could not fault the team at the time not just for internal reasons but for external reasons as well. The Newton failed. Palm Pilot was nice but severely limited. What customers wanted was a “full PC” not a gadget. At the same time, the product was awkward because it also tried to meet the needs of or maintain compatibility with existing investments. Using the above list of attributes, one could see how it regretfully met almost all of these tests:
Using a TabletPC was awkward when using a pen and stylus and also awkward when using a keyboard.
Architecturally the attempt to insert pen/stylus user interface into the existing Win32 API was done in a complex manner few could entirely understand.
The cost of building even trivial TabletPC apps was high and there was little one could do to experiment. Other than a simple drawing program, even motivated developers were challenged to make a leap to solving bigger problems.
Almost by definition TabletPC was constantly trying to thread the needle between being new and innovative while also fitting in with an existing strategy. I shared the story of how the TabletPC team wanted the “killer app”, Excel, to be on the TabletPC and were mostly disappointed when we built a special, purpose-built TabletPC app.
Managing the ecosystem around Windows by offering TabletPC was enormously difficult to impossible. The existing ecosystem had no experience with pen/stylus and yet wanted to apply the same standards and approaches, all of which led to an array of substandard, or arguably just plain poor, devices.
Competitively the TabletPC viewed competition not as replacing a PC (in other words redefining the market we were in) but as a special case to expand the market.
This is but one example of many that I think can fit this framework. I previously described one of the Longhorn pillars, WPF or Avalon, in this context. Windows Media Center was another. As we will talk about, Windows Phone had some (not all) of these characteristics primarily in terms of the ecosystem and platform capabilities. There are many smaller products from InfoPath to AutoPC that match the challenges above.
The shorthand for all of this was sometimes referred to as “a solution in search of a problem” but that would be entirely unfair. Such a categorization would have eliminated the rise of the graphical interface, client/server, or internet computing products from a roadmap. Rather, at a more core level one could simply describe the resulting technology in the context of the above attributes as being sufficient to explain the inability for the product to break through or define a new paradigm.
To those who have read Innovator’s Dilemma it might seem as though what I described is basically the classic problem faced by innovators. A company with massive success is facing a paradigm shift in their core market and needs to respond. The classic response to this problem is to, as Clay Christensen told me back in the late 1990s, create a team, rent a building, give them their own card keys, and ask nothing of them but to compete. It sounds easy. In fact, that is exactly what Microsoft did for Xbox that yielded that product—despite all the efforts by Bill and others (well documented from first-person accounts) to drag Xbox back to Windows and leverage it more. The product followed the Christensen model quite literally, as Xbox people had their own email domain to go with secured facilities. The reason Microsoft could do this was because it had little to lose. Whether a game console succeeded or failed, had no impact on the main businesses of Windows, Office, Server and even if it was wildly successful the result would not require those big products to reconcile or adapt.
At the same time, this exact strategy was followed for Zune, Kin (phone), Bing, by and large Great Plains/Dynamics, and quite a few others. Among those and even including Xbox, there have been stunning failures and moderate at best successes. I shared the story of trying build SharePoint this way and ultimately it was dragged into the strategic initiative world where it in fact lost much of the utility and charm, though in exchange for that it was bundled with the enterprise go to market and heavily sold.
These are just Microsoft examples. There are untold examples from across the technology industry occurring at any given moment. In other words, anyone who says there is an easy answer to coping with a paradigm shift is, for lack of a better word, a charlatan. Business is a social science and that means there are no algorithmic answers to the problem of paradigm shifts.
I would ultimately argue is that Windows 7 was the very best of innovation for the second wave of innovations that followed the initial creation of Windows and certainly with the baseline of Vista to compare it looked extraordinarily good. I would also argue that the decade before Windows 7 was spent in efforts to manufacture, synthesize, or conjure the third wave of innovation and those all fell victim to resulting in characteristics of solutions above.
For that success, it is worth noting that inside of Microsoft (ok, BillG specifically) Windows 7 was not viewed as innovative or paradigm shifting. It wasn’t. That was by design. It was not meant to take us from zero to one (to borrow a phrase) but rather from, say, five to seven making up for six.
The debate over whether a product is a conceptual paradigm shift, or a tool-centric revolution is classic Microsoft. Microsoft loved this debate. I loved this debate. To me, whether something is a concept, or a tool has always been critical to reframe as a theory or a product. Once a problem is framed as a theory or a product, then you can shortcut many of the most significant ways big companies can mess up or ossify. The best thing to do is reframe what needs to be done as a product—get clarity on what would be built. Then build it. Shipping wins. Otherwise, the debates are left best in the classroom—that’s where I always diverged from the “boxes and BS” style of debate.
But getting a product built that changes things is vastly more difficult or even, arguably, impossible. Change for any organization is difficult. Change for a successful organization is even more difficult. Change for the most successful business in the history of business is, at least by my account, the ultimate degree of difficulty.
That brings me to the second clipping that occupied the rarified space of my relite for much of my management career, and that is a series of quotes about change. While I worked in a constant state of trying to change so many things, change was indeed at the core of nearly everything I worked on and worked towards. I don’t know why I thought and acted that way. I just did. As I reflect today, I am certain that participating in those early days of computing cemented the idea of change as I watched how our family business changed from analog to digital. This feeling of finding and embracing change was so clearly what enabled me to have the chutzpah as an under-30 person at Microsoft to assert the whole company would need to change to embrace the internet. We are a product of our experiences.
Change is very easy to write about. Resisting change is super easy to disparage. Yet every corporate and innovation failure is rooted in a failure to change. Maybe people on the team would not change. Maybe the organization would not change. Sometimes salespeople refused to embrace change. It might be that the distribution channel rejected change. Perhaps even customers or partners refused to consider change. For change to work requires overcoming a good deal of resistance and basic human nature. Too often, engineers just throw up their arms at the first resistance. Sometimes that’s all one can do in a big and successful organization.
Why is change so difficult in such an organization? It is important to define some of the reasons or attributes that cause change to be so difficult.
Change is hard. Business is a social science and is made up of people. By and large, people resist change and embrace the status quo. One example of this discussed quite a bit throughout this work has been the role of enterprise customers and how they embrace the choices they previously made to the detriment of new products. Another common theme has been the tech enthusiast and how change upends their own personal sense of mastery and control, making change difficult even for the most ardent fans.
Business becomes a tool. As a successful product transcends technology and product it is elevated to a business. It is from that point that the product is no longer simply technology, but it is the means to an end for the business. Rather than merely looking at the technology aspects of a product, the business sees the product itself os a component that includes other tools such as distribution, pricing, packaging. Innovation is no longer the sole province of technologists but now the business can feel innovative by changes in other aspects. In a commodity market these other factors often lead to new innovations in product, but in the technology world the vast number of innovations that became big businesses led with product, and hence product-centric founders.
Sustaining innovation consumes everything. What used to be viewed as incremental begins to take on a whole new meaning and essentially transforms into innovation. Sustaining the existing business comes to define innovation and consumes everything that can be thought of or made. The ability for small incremental improvements to look, and often feel, like big changes to the product can happen because the cost of getting anything, even something small, done is so high.
Business leverage is the key to growth. Having won the initial market, feelings of inevitable saturation begin to take hold. A close cousin to sustaining innovation is business leverage as a means to grow the business. Where thoughts of growth used to be consumed with thinking up new products, the focus shifts from thinking about new products to thinking about entering new markets leveraging the strength of existing products. While it is easy, especially in the context I am writing, to think of this as monopoly leverage it is far less sinister than that. Leverage simply means that the innovations dreamed up are viewed through the lens of bringing them to market in the context of an existing business. It is easier for Nabisco to find ways to add Oreo cookies to another existing market than to dream up another cookie as wildly successful as Oreo. This struggle has been described in many sections herein as attempts to build new businesses versus bringing something to market as part of the Office or Windows bundle. The sinister side of this leverage is how it stifles new thinking because if something cannot leverage the existing business it is viewed as an expensive and often small distraction.
Risk is viewed entirely differently. When a new product is starting risk is existential. Will the project come to exist? Will it get cancelled? Will it get distributed? We’ve talked about many such examples, such as the precarious birth of Outlook. In a successful company, risk takes on a whole new meaning, but a much narrower one. The main view of risk that occupies most discussion is not will something come into being but will something new break or undermine the existing business. This relatively narrow view of risk comes to dominate decision-making and is often the leading force that can stifle new products. Risk is much less about existence and much more about causing trouble. The creation of SharePoint and the friction with Windows Server for files was such an example. While I did not write enough about this, Hotmail, SkyDrive (now OneDrive), and Live identity all ran into the idea of doing more damage than good or said another way they were risky endeavors.
Perspectives on new technologies change. When you’re just getting started, new technologies are viewed as exciting and are rapidly embraced and absorbed. The way Microsoft approached the graphical interface was one of excitement and opportunity. Just a few short years later with the arrival of the internet that broad (though not universal) enthusiasm was replaced with a significant effort to marshal the company to embrace (and extend) internet technologies. The cloud was met with even more resistance and literally took the CEO to give an external speech2 declaring “We’re all in” to overcome the resistance both internally and from customers.
Experience enables the buzzsaw. While experience is often viewed as an asset, in a large organization experience can quickly become a tool for ossification. Experience enables an ominous combination of pattern-matching and questioning. Pattern-matching is the ability to quickly conclude something new is a repeat of something that previously failed, so is bound to fail again. In fact, the broad history of technology can be seen through a series of innovations attempted many times and failed all but the last time. How many different microcomputer systems existed in small numbers before the PC? During the lead-up and even after the PC a good many experienced computer industry leaders continued to claim the microcomputer was an underpowered fad. Experience also enables one to ask so many questions under the guise of learning, coaching, or helping but in practice designed to prove the technology or idea won’t work. As we saw, many of the most important leaders in technology saw the internet as having too many questions—who pays for it, how will you know how much internet you can get, who runs the software, who wrote the software? Even inside a company questions can be used to thwart any idea: Which budget is this from? How does this relate to X, Y, or Z? Will this version 1.0 have the proper security reviews, accessibility reviews, geopolitical reviews, and more? Previous sections offered many examples of this technology and business buzzsaw that became a tool of the company.
Success has different meanings. When you take the business as a tool and a different view of risk, success starts to look rather different. Much of this is the difference between zero to one versus one to ten. The biggest curse of a wildly successful company is that everything that could be new—that is everything the company isn’t working on but might have potential—looks incredibly small relative to the existing success. This type of thinking only takes old as a company is mature and has time to wallow in the new definition of risk. Until then, everything small looks like an incredible threat and success looks like entering the market. The reason Microsoft entered the markets for applications, consumer software, CD-ROM, and more was as much about simply pushing limits of technology as it was defining success to mean participating in all the exciting technology opportunities. Later in life, participating in everything tends to look less like success and more like waste.
Quick fixes to make some problem go away are valued. A successful company with a large footprint in the market is battling a sea of small competitors. Windows faced competitors in networking, file storage, cross-platform APIs, development tools, and more. No one of those could upend the platform and by and large the company knew that. As a result, the company starts to value less the potential-paradigm shifting nature of those competitors and values more the clever hack, tactical bundle, or easy M&A, that can just make some problem go away. I’ve discussed this previously as a “tie is a win” when it came to Exchange competing with Lotus Notes.
The company is the paradigm. Ultimately, the most significant barrier to change is that the company is no longer a participant in a paradigm shift, but rather it is the paradigm shift. This can be symbolic in the sense that Google came to symbolize the internet era but of course did not command or control the internet itself. Or it can be a bit more literal as Microsoft experienced which is that the company was the Windows paradigm, one and the same. It goes deeper than that as it is not just the single product, but the business model. In the case of Microsoft, as discussed and will be discussed further, the key assumptions about WinTel and the OEM business model, are as much part of the paradigm as the Start menu. The paradigm that is the company is a bubble that surrounds everything and escaping that to gain perspective is almost impossible. Competition ceases to be an outside force and is primarily other parts of the same organization, and if something outside is a competitor it is invariably another enormous company competing head-to-head. IBM famously created the PC but the rest of the company could only see the PC through the context of the mainframe bubble. In fact even the PC group planned on trying to turn the PC into a mainframe-like proprietary platform with MicroChannel, which failed for many of the reasons described above. Once a company is a paradigm then change is not about doing something new or changing a product, it is literally changing the DNA or makeup of a company. Changing when everything looks like it could be negative or weaken the paradigm is quite literally impossible for most to fathom.
Some might suggest that embracing new paradigms, running towards change, and building are the characteristics of a healthy company—the cultural attributes that a successful company requires. Folding these all under the umbrella of culture is far too easy an answer. Find me a successful large company and I will show you somewhere they have written down how much they value innovation (3M) or change (HP) or thinking deeply about technology (IBM). It simply isn’t that easy. In fact, most successful companies are also models of corporate culture—except it was the culture of the past that created the present that enables them to take time to articulate the quality of what got them there.
What man has made, man can change.
-Frederick Moore Vinson (1890-1953)
That's why it's time for change.
-Thomas Edmund Dewey (1902-1971)
The above quotes on change are a way to bypass any culture. Essentially once a company achieves success and has the foundation, it is time to change. There’s nothing about nature that says work must continue on the path that got the company there. The success was not an act of nature but one of foresight, luck, and circumstance. That means it is time for change.
What to build and how to change a company and organization to build it are the questions of a product-delivery organization and business. The search for answers that yield stellar results is the driving force behind entrepreneurship, whether practiced inside a company, in a self-funded business, or a venture-funded business. For the past one hundred posts and twitter threads in Hardcore Software I have tried to offer the context for where success comes from and what it takes to change in order to achieve it.
The real question is what happens after success when the paradigms around you have upended everything that got you there?
From Wikipedia, https://en.wikipedia.org/wiki/Mike_Mulligan_and_His_Steam_Shovel retrieved August 16, 2022
“Email: Ballmer tells Microsoft employees to embrace cloud“ by Todd Bishop, Pugent Sound Business Journal, March 4, 2010. https://www.bizjournals.com/seattle/blog/techflash/2010/03/e-mail_ballmer_tells_microsoft_employees_to_embrace_the_cloud.html