Breaking Silos: How Microsoft Innovates

A live demonstration of a smart highway sounds like a technology story. For Nicholas McQuire, it was also a test of whether people across different technology teams could work together. The Ferrovial scenario he helped demonstrate brought several areas of Microsoft into one customer problem, and he remembers the experience as both nerve-wracking and a major team achievement.

That example gives this Innovation Rockstars conversation its central question: how does a large organization turn separate areas of expertise into something useful together?

Speaking from Microsoft's Strategic Missions and Technologies division, McQuire describes an approach that connects long-term research, emerging businesses and existing products. He also brings the perspective of a former technology analyst who puts unusual emphasis on communication. If he designed an MBA, he says, storytelling would be a significant part of it. Explaining a possible future is part of getting people to build it.

Start with a problem that crosses the organization

McQuire describes technology convergence as a practical organizational challenge. A customer scenario might need capabilities that sit in separate teams, each with established ways of working. Describing the potential of those technologies does not, by itself, connect the people responsible for them.

The intelligent-highway work with Ferrovial provided a concrete reason to collaborate. In his account, the project brought together AI, edge computing, private 5G networks and space technologies. Making the scenario work required changes to existing processes from the beginning.

He sees projects like this as a way to expose and address barriers between teams. The customer problem gives them a shared purpose, while the work reveals which existing processes need to change.

This is a useful distinction for R&D leaders. Cross-functional collaboration becomes more specific when a team has to deliver a scenario that no single department can complete alone. The question becomes what the project needs from each group, rather than whether the organization supports collaboration in principle.

Connect horizons instead of separating portfolios

McQuire calls Microsoft's approach “full spectrum innovation.” In the conversation, he describes work ranging from improvements to the current portfolio through emerging business models to longer-term research with the potential to open new markets.

The important point for him is the connection between those horizons. Research should have routes into nearer-term products, while existing capabilities can become foundations for new businesses.

He uses the language-model work of that period as an illustration. Research could contribute to features in established products, become a platform for customers to build on and inform more distant computing possibilities. These were different uses and stages of related work, rather than three unrelated portfolios.

The episode captures that thinking at a particular point in Microsoft's development. Its longer-term AI and quantum examples are ambitions discussed in the interview, not claims that those future combinations have since been delivered.

For a portfolio review, the implication is to examine the relationships between projects as well as their individual horizons. A promising research effort needs a possible route to application, and an existing product team may have capabilities that another business could use.

Give learning time, resources and consequences

McQuire does not suggest that Microsoft's scale removes the familiar problems of innovation. He explicitly acknowledges the cultural challenges and says the company does not have all the answers.

He describes dedicated hackathon time as one way to make room for experimentation. Teams can work on something broken, explore a product idea or learn something new. The organizational commitment matters because it gives curiosity time and resources within the work schedule.

Learning also appears in his account of reward systems and team development. At an off-site, his team invited the author of Rejection Proof to discuss a series of experiments in dealing with rejection. McQuire connects that experience with the willingness to try something whose reception is uncertain.

The point extends beyond an inspirational talk. If people are expected to learn and experiment, the surrounding working practices need to make those behaviors credible. McQuire describes culture through the things teams are given time to do and the behaviors the organization recognizes.

Make usefulness and responsibility part of the brief

A large research organization can easily become the center of its own innovation story. McQuire repeatedly brings the conversation back to what customers can do with the technology.

“Every company in every industry can innovate.”

He argues that innovations need to be meaningful to customers, applicable in practice and responsible enough to earn trust. Breakthroughs can come from the organizations using a technology for their own needs, rather than only from its provider.

“So it's not just about what technology can do to support innovation, in our case, but also what it should do.”

That places responsibility alongside application from the outset. Technical possibility is one part of the decision; the purpose of the work and the trust it requires belong in the same discussion.

McQuire's customer-engagement work supports that approach. He describes direct workshops where teams can explore future technologies and learn from other organizations' experiences. Storytelling helps make unfamiliar possibilities understandable enough to discuss seriously.

Keep learning across company boundaries

When asked for a career highlight, McQuire chooses a corporate-innovation fellowship alongside the live highway demonstration. The fellowship gave him a way to share ideas with people from other companies and industries, including customers.

It is a revealing choice for someone whose work centers on future technologies. The memorable achievements are also occasions when different people learned or built something together.

For leaders trying to connect research with the rest of the business, his examples suggest a concrete starting point: choose a customer scenario that genuinely requires several capabilities, give the people involved room to learn, and examine which organizational arrangements are preventing them from delivering it together.