Finding your footing while everything around you keeps changing.
One of the more interesting things about organizational change is that it rarely feels like a single dramatic event while you are living through it. The ground usually moves first, a little at a time, and only later do you look around and realize that the landscape is different.
A leader moves into a new role. A priority gets renamed. A program that felt central last quarter becomes maintenance work. Two teams begin solving adjacent versions of the same problem. Someone you have relied on for years leaves, while someone new arrives with useful questions and none of the historical scar tissue that made the old answers seem inevitable. The org chart eventually catches up, but by then the practical organization—the network of relationships, decisions, dependencies, and unwritten agreements through which work actually happens—has already changed.
The past six months have given me plenty of opportunities to think about this. I have watched priorities move, roles evolve, teams absorb new responsibilities, and familiar operating assumptions get challenged. I have also watched friends and colleagues navigate reductions in force, voluntary retirement decisions, internal moves, and the quieter uncertainty that comes from wondering what the next change will ask of them.
This is not unique to Microsoft. The technology industry is still reconciling the post-COVID hiring expansion with a different economic and strategic environment. At the same time, artificial intelligence has moved from an interesting capability to an enormous investment priority. Companies are shifting capital, flattening layers, reconsidering how work is organized, and asking teams to increase both speed and accountability.
Microsoft has described its own changes directly. In July 2026, the company announced approximately 4,800 role eliminations, or about 2.1 percent of its global workforce, alongside thousands of internal redeployments and a voluntary retirement program. The explanation was not that every affected role had been replaced by AI, but that customer needs, business models, priorities, and the work itself were changing quickly enough that the organization had to change with them.
That combination creates an uncomfortable paradox: organizations must keep delivering today’s commitments while redesigning themselves for tomorrow. Microsoft’s 2026 Work Trend Index described a similar tension as the pressure to perform colliding with the pressure to transform. It is easy to celebrate reinvention in a keynote. It is much harder to make room for it while customer commitments, scorecards, and operational escalations remain very real.
I do not have a clever method for making that tension disappear. I do have a few lessons from spending much of the last six months in the middle of it.
Do not wait for the blueprint
The natural instinct during a reorganization is to wait for stability. We tell ourselves that we will improve the process once ownership is clear, document the work after the new model settles, or make the difficult decision when leadership has finished defining the strategy.
The problem is that large organizations rarely stop changing long enough to hand anyone a finished blueprint. By the time every box and arrow has been agreed upon, the people closest to the work have usually created a provisional operating model already. Some of those choices become durable. Others become sources of confusion that last much longer than anyone intended.
One recurring theme in my work this year has been the choice between redesigning a system and getting people to use the system we already have. Redesign is more intellectually satisfying. Adoption is usually more important. A technically elegant model with no shared understanding is less useful than an imperfect model that helps people coordinate, make decisions, and see the same version of reality.
I was reminded of this during a conversation about changing the structure of a program that was still struggling to gain consistent adoption. The proposed changes were thoughtful and, in several cases, probably right. My concern was sequencing. If we changed the vocabulary, hierarchy, and process before people had learned to use the existing model, we would lose the chance to learn whether the problem was the design or simply the absence of shared habits.
That does not mean accepting weak systems forever. It means first creating enough clarity for people to move together, then improving the structure with the benefit of usage, feedback, and evidence. In periods of change, a usable bridge is often more valuable than a beautiful plan for a bridge that has not been built.
Adoption is not the less ambitious alternative to redesign. Sometimes it is the evidence required to redesign responsibly.
People rarely resist change in the abstract
We often say that people resist change, but I am not convinced that is the most useful diagnosis. Most people I know have adapted to extraordinary changes in technology, customer expectations, tools, leaders, and work environments. What drains them is not change itself; it is uncertainty without context.
Ambiguity has a tax. When ownership is unclear, every small decision requires negotiation. When priorities are vague, people hedge their effort across too many possibilities. When the reason for a change is missing, even sensible actions can feel arbitrary. A short gap in leadership clarity can become hundreds of hours of distributed guessing across an organization.
This is why I have become increasingly interested in the unglamorous infrastructure of work: operating models, decision rights, governance, common definitions, portfolio views, knowledge bases, and an operator’s manual that explains how the organization intends to work. These things can become bureaucracy when they are designed to protect the process from people. At their best, however, they are a form of empathy. They reduce the number of questions each person must answer alone.
A recent discussion about knowledge management made the distinction clearer for me. We began by talking about one repository and ended up identifying three different needs: an authoritative operator’s manual, a faster-moving knowledge base, and a place for tools, queries, code, and reusable assets. Combining all three might have been simpler on a diagram, but it would have made each one less useful. Authority, contribution speed, and executable tooling require different forms of governance.
Good governance does not create more meetings. It makes more meetings unnecessary. Good documentation does not replace judgment. It preserves context so judgment can begin from a better starting point. Good standards do not eliminate local creativity. They prevent every team from spending its creative energy rebuilding the same basic machinery.
The goal of governance is not control. It is enough shared understanding for people to exercise judgment without constantly colliding with one another.
Build things that can survive you
Earlier in my career, I found a great deal of satisfaction in solving difficult problems myself. I still enjoy that, but the work that feels most valuable now is different. I am more interested in making recurring problems easier for everyone who comes after me.
That shift has changed what I notice. I notice when the same question is answered in five separate meetings, when a report depends on one person’s memory, when a workflow works only because someone quietly repairs it every week, or when teams use the same words to mean different things. I notice when a person has become the integration layer for a system that should not require a human integration layer.
This is not an argument against expertise. Deep expertise is essential. It is an argument against treating dependence on hidden expertise as a sign of organizational health. Being indispensable can feel reassuring during uncertain times, but it is a fragile form of security. Creating a system that makes many people more capable is both more scalable and, ultimately, more influential.
Over the last several months, some of the work I have valued most has involved consolidating fragmented information, clarifying stages and ownership, improving the relationship between operational data and reporting, and reducing the number of places where people have to reconcile competing versions of reality. None of those efforts produces a dramatic launch moment. Their value appears gradually as fewer people need to ask where something lives, what a status means, or who has the authority to make the next decision.
That is the strange thing about strong operational work: its success is often measured by what stops happening. Meetings become shorter. Escalations become less frequent. New teammates gain context faster. Leaders spend less time reconciling contradictory reports. The organization becomes a little easier to understand.
This builds on something I wrote in Fifteen Years at Microsoft: the thread connecting much of my work is no longer an individual technology or customer problem, but the human systems through which those problems get solved.
Influence travels better than authority
One of the most durable lessons of organizational change is that authority is attached to structure, while influence is attached to trust. Structure can change overnight. Trust usually moves with the person.
Titles matter because they establish accountability and decision rights, but titles are poor substitutes for relationships. People remember who shared context instead of hoarding it, who made their work easier without demanding credit, who told them the truth when the answer was uncomfortable, and who helped them succeed when there was no obvious personal benefit.
This does not mean becoming agreeable or avoiding conflict. Some of the most useful relationships in my career have included direct disagreement. Healthy organizations need people willing to challenge assumptions, especially when a familiar process has become disconnected from the outcome it was created to support. The key is whether disagreement serves the work or merely advertises the person disagreeing.
Amy Edmondson’s work on psychological safety is useful here because it is often misunderstood as simply making people feel comfortable. The stronger idea is that teams need enough trust to surface risk, admit uncertainty, ask for help, and challenge a plan before reality challenges it more forcefully. That becomes even more important when roles and priorities are moving, because the cost of silent confusion increases with the pace of change.
The AI opportunity is an operating-model problem
The most visible AI conversations are still about individual productivity: drafting text, summarizing meetings, generating code, creating images, or automating a task. Those capabilities matter, and they are improving quickly. I suspect, however, that the larger opportunity is organizational rather than individual.
Microsoft’s recent framing is that AI pilots do not become enterprise impact through technology alone. They require adoption, governance, repeatability, measurement, and a system for running real work. That matches what I have seen. The hard part is rarely producing an impressive demonstration. The hard part is connecting it to identity, permissions, policy, reliable data, human oversight, and a workflow people will actually use.
The same is true for knowledge. An AI assistant cannot rescue an organization whose important context exists only in private notebooks, disconnected chats, aging slide decks, and the memories of a few experienced employees. AI can make knowledge easier to find and connect, but first the organization must decide what is authoritative, what is provisional, who can contribute, how conflicts are resolved, and when an emerging practice becomes an official one.
This is why I am more excited about AI reducing organizational entropy than about AI simply producing more output. Imagine a system that can explain why a decision was made, connect a current issue to three earlier workstreams, flag when two teams are building overlapping solutions, identify a policy that contradicts a newer standard, or give a new employee a reliable map of the organization in an afternoon instead of six months. Those are not merely productivity gains. They change the organization’s capacity to learn.
Donella Meadows’ Thinking in Systems remains one of the most useful lenses for this moment because it reminds us that improving one visible component may do little if incentives, information flows, delays, and feedback loops continue producing the same outcome. AI inserted into a weak system can help the weak system move faster. The harder and more valuable work is redesigning the system.
The most interesting promise of AI may not be helping individuals produce more. It may be helping organizations forget less.
Be quick, but do not hurry
There is understandable urgency around AI. The opportunity is enormous, the competitive pressure is real, and no large company can assume that yesterday’s strengths guarantee tomorrow’s relevance. Microsoft has used the language of moving with greater pace and intensity, and the broader industry is making similarly aggressive choices about investment and organization.
Urgency, however, is not the same as panic. Brad Smith recently borrowed John Wooden’s advice to “be quick, but don’t hurry” when discussing AI and jobs. I like the distinction. Being quick means reducing avoidable delay, making decisions with the available evidence, learning rapidly, and changing course when the facts change. Hurrying means confusing activity with progress, skipping the work of alignment, and creating preventable problems that someone else will have to absorb later.
Stanley McChrystal makes a related point in his TED talk about leading through complexity. Shared purpose and the ability to learn across boundaries become more important as the environment becomes less predictable. An organization cannot centralize every decision and still move at the speed of local reality. Leaders must provide context, create connections, and trust people close to the work to exercise judgment.
That describes the kind of organization I want to help build: not one where every answer travels up and down a hierarchy, but one where people share enough context to make good decisions across it.
A small field guide for moving ground
I am still learning how to navigate organizational change, and I am suspicious of anyone who presents a universal formula for it. Still, a few practices have proven useful enough to keep:
- Name what is stable. Customer needs, professional values, trusted relationships, and the purpose behind the work often remain more durable than the current structure.
- Separate facts, decisions, assumptions, and open questions. A clearly stated unknown is more useful than a confident rumor.
- Optimize for adoption before elegance. A shared, understandable process can be improved. A perfect model that nobody uses cannot.
- Document the why, not only the what. Procedures age quickly. Decision context helps future teams understand when a procedure should change.
- Make ownership visible. Shared work without explicit ownership tends to become either duplicated work or abandoned work.
- Build bridges before empires. The most useful solution may connect existing teams and systems rather than create another center everyone must navigate.
- Leave room for local judgment. Standards should remove recurring friction, not prevent people from responding intelligently to reality.
- Measure friction as well as output. Repeated clarification, manual reconciliation, excessive escalation, and meeting load are signals about the health of the system.
- Invest in relationships before you need them. Trust created during calm periods becomes operating capacity during difficult ones.
- Know what is yours to carry. Caring about an organization does not require absorbing every ambiguity, disappointment, or decision as a personal verdict.
The last point may be the hardest. Organizational change is personal because work is personal. It affects colleagues we care about, plans we have made, identities we have built, and the sense of progress we use to orient our careers. Reductions in force and voluntary retirement programs may be described through percentages, eligibility rules, and strategy, but they are experienced one person and one family at a time.
Any honest discussion of organizational transformation has to hold both truths: companies must change, and change has a human cost even when the strategic rationale is sound.
Maybe this is the real work
I do not know what the next organizational chart will look like, and I have stopped pretending that predicting it is the best use of my energy. Technology will continue evolving. AI will reshape roles, workflows, and organizational boundaries. Companies will continue adjusting their structures as investment moves and strategies mature.
What I can do is help create clarity while the answers are incomplete. I can build systems that preserve context, make ownership visible, reduce repeated effort, and help more people act with confidence. I can challenge a process without dismissing the people who created it, support adoption without treating the current design as permanent, and invest in relationships that remain useful after reporting lines change.
Titles are temporary, programs end, and strategies evolve. The work of reducing friction, sharing knowledge, improving the system, and helping other people succeed seems to survive every reorganization I have experienced.
Maybe that is the real work after all.
The rabbit hole
A few resources that influenced the thinking behind this post:
- Microsoft: The latest in our company transformation — a direct explanation of the company’s July 2026 role reductions, redeployments, and prioritization.
- Microsoft: How Frontier Firms are rebuilding the operating model for the age of AI — especially the tension between delivering current results and reinventing work.
- Microsoft: AI alone won’t change your business. The system running it will. — a useful argument that enterprise AI requires a governed system, not a collection of demos.
- Microsoft: AI, jobs, and the next generation — includes the helpful reminder to be quick without hurrying.
- Thinking in Systems by Donella Meadows — the clearest introduction I know to feedback loops, leverage points, and why isolated fixes often fail.
- Team of Teams by Stanley McChrystal — on shared consciousness, empowered execution, and adapting structures built for a more predictable world.
- The Fearless Organization by Amy Edmondson — on creating the conditions for people to surface risk, uncertainty, and disagreement.
- Turn the Ship Around! by L. David Marquet — a practical case for distributing control by increasing competence and clarity.
- WorkLife with Adam Grant: Is It Safe to Speak Up at Work? — a useful podcast episode about building a culture of voice rather than silence.
For the earlier chapters of this story, see My First Year at Microsoft, Five Years in the Crystal, Ten Years at Microsoft, and Fifteen Years at Microsoft.
The inevitable meme
The familiar “This is fine” scene works because most of us recognize the temptation to normalize chaos while waiting for someone else to acknowledge it. The healthier lesson is not to sit calmly and insist that everything is fine. It is to notice the fire, help people find the exits, create enough clarity for coordinated action, and improve the wiring before the next spark.
These reflections are personal and do not represent Microsoft.
