Through a few twists of fate, I had the opportunity to work at both Microsoft and Meta, and I noticed an interesting difference between the two companies that I probably would not have paid much attention to from the outside: does a company want people to see it as reliable and trustworthy, or as innovative and always willing to try something new?
Of course, these two qualities are not mutually exclusive. A company can be reliable and innovative at the same time, and nearly every technology company would probably like to be both. Still, I have come to feel that as a company grows, there is inevitably some degree of trade-off between them. The more an organization wants to preserve its ability to change quickly, the more uncertainty it has to accept. Conversely, the more it wants its products, direction, and commitments to remain stable and predictable, the harder it becomes to operate like a startup that can act on a new idea immediately. Of the companies where I have worked, Microsoft and Meta seem to represent two very different approaches to this problem.
When Reliability Becomes Part of the Product
If I had to describe the culture I experienced at Microsoft, I would say it is a relatively conservative technology company. By conservative, I do not mean that Microsoft does not build new things. From Azure and AI to all kinds of developer tools, the company continues to develop plenty of new products and technologies. Compared with many consumer Internet companies, however, Microsoft clearly places security, stability, compatibility, and long-term reliability higher in its priorities. This has a great deal to do with its business model. Many people may still associate Microsoft primarily with Windows and Office, but today a large part of its business comes from enterprise customers, including Azure, Microsoft 365, and its various security offerings. Many government agencies and large companies have also built their infrastructure on Microsoft products. When those are your customers, their expectations are very different from those of ordinary consumers. If I redesign or remove a feature from a mobile app, users may complain or decide to use another app. But if a bank has hundreds of internal systems built on my platform, or if a company has moved its entire infrastructure to my cloud, then suddenly changing an API, discontinuing a feature, or introducing an unexpected breaking change can become a very serious problem.
For these organizations, what they are buying is not merely a set of product features, but a form of commitment. When I choose your product, I am trusting that three, five, or even ten years from now, you will not suddenly tell me that it no longer works. Technology will continue to change, but I expect you to provide sufficient backward compatibility, a migration path, or long-term support so that I do not have to rebuild my entire system every few years. This is why, when I worked at Microsoft, I often felt how much the company cared about trust. From an engineer’s point of view, things could certainly feel slow. A feature might go through many reviews, and something that could technically have been replaced long ago might still need to be supported because customers continued to rely on it. Even a seemingly simple change could involve more work around security, compliance, and compatibility than around writing the code itself.
I used to see this as big-company bureaucracy, but from another perspective, some of that bureaucracy is simply the cost of reliability. When other companies are willing to build their businesses on top of your products, they are not necessarily trusting Microsoft to introduce the coolest new feature every year. They are trusting it to be a company that will not act recklessly. For Microsoft, being trustworthy is itself part of the product’s value.
The Other Side of Compatibility Is Ever-Growing Complexity
Good compatibility does not necessarily make a product easy to use. When old features cannot simply be removed, old workflows must remain supported, and new requirements keep being added, products naturally accumulate layer upon layer. Every addition may have made sense in its original context, but after several years, what users see is a growing number of options, more entry points, and several ways to do things that look similar but are not quite the same. Power BI is an obvious example from my own experience. It has a wide range of features and must support customers with different use cases from different periods, but that also makes its interface and concepts increasingly complex. Some things remain not because they are still the best design today, but because people already depend on them and they cannot simply be removed.
The cost of Microsoft’s approach, then, is usually not that a feature suddenly disappears, but that historical baggage slowly accumulates. Users can be more confident that what works today will still exist tomorrow, but the product can also become increasingly layered and take more time to understand.
Still Trying to Move Fast, Even as a Big Company
At Meta, I encountered a very different culture. Meta is obviously no longer a startup. It is a huge company with a large workforce and products used by billions of people, yet it still works very hard to preserve a startup mentality. The clearest example is the well-known phrase Move Fast. Before joining the company, I assumed it might simply be a corporate slogan. Once inside, however, I found that it genuinely shapes how many things are done. When the company decides that a direction matters, organizations and resources can move toward it very quickly. A project can begin quickly, change direction quickly, and, if it later appears no longer worth pursuing, have its resources moved elsewhere just as quickly. The benefit of this culture is clear: becoming large does not automatically mean losing the ability to change course. Technology moves quickly, and if a company waits until it is completely certain before acting, the market may have already moved on by the time that certainty arrives.
Facebook’s decision to rename itself Meta is a particularly striking example. Regardless of whether the metaverse ultimately proves to have been the right direction, it was an extraordinary decision for a company of that size. The Facebook name had accumulated enormous brand value, yet when leadership believed the next computing platform might take a different form, the company was willing to change its name and commit tremendous resources to VR, AR, and related technologies. At a more traditional large corporation, the discussion alone might have taken a very long time, let alone moving the direction of the entire company. What makes Meta unusual is that even at its current scale, it still tries not to become a company that is too successful to change. That culture, however, inevitably comes with another side.
The Other Side of Rapid Change Is Constant Readjustment
If part of Microsoft’s difficulty comes from historical baggage, Meta can be difficult in a completely different way: not because too many old things remain, but because things change too quickly. A feature that works today and has already become familiar may disappear after a while or move somewhere else. Internal tools, interfaces, and processes may also continue to change. Each change may have a reasonable goal, such as making the system better, more consistent, or better aligned with a new direction, but the people who actually use it still have to keep readjusting. This approach prevents too much historical baggage from accumulating and allows teams to replace designs that no longer fit, but it also reduces predictability. Users may not need to understand ten years of old options, but they have to accept that something they learn today may not work the same way tomorrow.
From the perspective of usability, therefore, it is not that one company is easy to use and the other is difficult. They impose two different kinds of cost: complexity accumulated in the name of compatibility, and instability introduced in the name of rapid iteration.
What Looks Like Speed Inside the Company Can Feel Like Uncertainty Outside It
The same characteristic can feel completely different depending on whether it is viewed from inside or outside a company. From Meta’s perspective, being able to change direction quickly when something is not working is unquestionably an advantage, because resources do not remain trapped in a project that no longer has a future. But if you are a partner working with Meta and have already committed a team to building something together, the question you care about most may be, “Will you still be working on this next year?” In other words, the ability to change is flexibility for the company itself, but it can become risk for those who depend on the company. This applies not only to business partners, but also to employees, developers, and investors.
A company that is willing to try new things may give its engineers opportunities to work on many new technologies and products, but it may also mean that organizations and projects can change easily, or even be shut down without much warning. Likewise, a company’s willingness to commit significant resources to an unproven market may look excellent from the perspective of innovation, while investors may instead ask when those resources will turn into revenue. This is not simply a question of which culture is better. Different people care about different things, and ultimately, they may also place their trust in different kinds of companies.
Innovation and Reliability Are Two Sides of the Same Coin
Innovation and reliability are both positive ideas, but in some situations they are two sides of the same coin. Innovation, by its nature, means doing something that has not been done before, and anything genuinely new contains some degree of uncertainty. You do not know whether the market will accept it, whether the technology will ultimately work, or whether the resources invested today will ever produce a return. If a company cannot tolerate this uncertainty, it will have difficulty creating anything truly new, because every discussion will end with the same questions: “Has this succeeded before? Is there enough data to prove that it will work?” The problem is that if enough data already exists to guarantee success, the idea may no longer be particularly innovative.
Reliability, on the other hand, derives much of its value from reducing uncertainty. A company signs a long-term contract or moves its infrastructure onto your platform because it believes the future will remain predictable to some degree. From this perspective, the difference between Microsoft and Meta is not that one is better than the other, but that they make different trade-offs in different places. Microsoft has a large enterprise customer base, so it needs customers to believe, “If I entrust something important to you today, you will not suddenly change the rules tomorrow.” Much of Meta’s business still serves the consumer market, where the question is instead, “When the next platform arrives, will I still be able to keep up?” Those two questions naturally create very different company cultures.
A Company Somewhere in Between
If I were to add another company to the comparison, Google would be an interesting case because it seems to sit somewhere between Microsoft and Meta. Earlier Google was widely seen as a highly innovative company, one that often built the technology first and only then figured out what it could be used for. It had a strong engineering culture and created many experimental products, which in that respect made it feel closer to Meta. In recent years, however, Google has expanded further into the enterprise market through products such as Google Cloud and Google Workspace. Those customers have very different expectations from ordinary users of Search or YouTube. If a company moves its infrastructure to Google Cloud, it will naturally begin asking the same questions as an Azure customer: Will this service still exist five years from now? Will the API change? Will you someday decide that the product is no longer worth maintaining and shut it down?
This may explain why, as a technology company grows and its enterprise business becomes more important, the way it operates often begins to move closer to Microsoft’s side of the spectrum. This does not necessarily mean that it has lost the ability to innovate. It simply means that when more people depend on your products, the freedom to change them at will naturally becomes smaller. To some extent, this is difficult to avoid when a startup becomes a large enterprise.
Why Do Big Companies Eventually Slow Down?
Looking back, what people call “big-company disease” may not be caused only by having more employees or a more bureaucratic management structure. Another important reason is that as a company succeeds, the number of people and organizations to whom it is responsible also grows. A startup’s greatest fear is failing to change. If nobody uses its product, changing direction tomorrow may be the most reasonable decision because few people depend on what already exists. But once a product has hundreds of millions or billions of users, along with enterprise customers, developers, partners, and even government agencies building on it, a change in product direction no longer affects only the company itself.
This is why large companies gradually introduce more processes, reviews, compliance procedures, and security requirements. Some of that bureaucracy is certainly unnecessary, but it would be wrong to say that all of it is meaningless. Part of it simply reflects the fact that the cost of making a mistake is no longer what it used to be.
The Hardest Part Is Keeping Both After Growing Up
The comparison is not as simple as saying that Microsoft is conservative while Meta is innovative. The more interesting question is how a company can preserve both innovation and reliability as it grows. If it leans too far toward reliability and requires every decision to be proven risk-free, it may gradually become stable but unable to create anything new. But if it pursues speed above everything else and constantly changes direction, customers, partners, and employees may eventually stop trusting the direction it presents today. The difficult but essential task is to distinguish between the things that can be tested and changed quickly and the commitments that should not be changed casually once they have been made. A new product direction can be explored quickly, but an API already offered to customers cannot necessarily change without warning. An internal project can be stopped quickly, but if partners have already invested substantial resources in it, the company’s external commitments require a different level of consideration.
If a company can draw that boundary clearly, perhaps it can become more reliable without losing its original ability to change. I think this is a question that highly successful technology companies such as Microsoft, Meta, and Google will continue to face: Once a company has grown large enough that many people depend on it, can it remain worthy of their trust while preserving its willingness to take risks and change?
To me, that question is far more interesting than simply asking which company is “more innovative.”