Thank you Rick McGuire and Matthew Calder for the second season of #MADI, the Microsoft Azure Developer Influencer program. Not only I learned tremendous and got influenced by it – but it gave me an option to influence Microsoft around Azure and more, and option to meet many like minded professionals. Looking forward to season 3! And it led to me becoming a Microsoft Most Valuable Professional as well – thank you for that help and the introduction to Betsy Weber and Rochelle Sonnenberg, both of whom I had the pleasure to meet at the #mvpsummit. #mvpbuzz!

The journey from Microsoft’s Semantic Kernel (SK) to Model Context Protocol (MCP) servers marks a significant evolution in how AI agents interface with external tools, services, and each other. This transformation illustrates a broader shift: from embedding intelligence into applications to building ecosystems where AI functions as an interoperable, real-time participant.

The Foundation: Semantic Kernel and AI Function Calling

Microsoft’s Semantic Kernel emerged as a pioneering framework enabling developers to integrate large language models (LLMs) with conventional application logic. With function calling, developers could expose native code (C#, Python, etc.) and prompt-based logic to LLMs, enabling them to take action based on user prompts or environmental context.

Semantic Kernel gave rise to hybrid agents—intelligent systems capable of reasoning with both data and action. A user could ask, “Book me a meeting with Lisa tomorrow at 3 PM,” and the LLM, using function calling, could interact with calendar APIs to complete the task. It was AI as orchestrator—not just respondent.

The Evolution: From Isolated Agents to Interconnected Systems

While Semantic Kernel empowered AI agents within a single application, the real world demanded interoperability. Different agents needed to interact—across organizations, services, and platforms. The limitation of isolated function calling soon became clear. A more extensible, secure, and discoverable way to publish and consume functions was needed.

Enter Model Context Protocol (MCP).

MCP: A Protocol for Open, Secure AI Interoperability

The Model Context Protocol, led by innovators including GitHub and backed by the OpenAI developer ecosystem, proposes a standardized way for LLMs to discover and invoke capabilities hosted anywhere—be it on a local server, enterprise API, or public service.

Think of MCP servers as the modern equivalent of “function registries.” They allow:

• Agents to query and discover available capabilities via a standard format.
• Functions to describe themselves semantically, including auth, input/output schemas, and constraints.
• A secure handshake and invocation pipeline, so one agent’s toolset can be safely used by another.

It’s the infrastructure needed to move from a single LLM agent to a network of agents working together across domains.

Why MCP Matters: An Open API for AI

Just as REST and GraphQL helped web services flourish, MCP may be the bridge that lets AI truly plug into the digital ecosystem:

• Modular AI Development: Build once, publish anywhere. Tools built for one model can be reused by others.
• Zero Trust Ready: Security is embedded from the start, with scopes, tokens, and permission management.
• Cross-Model Collaboration: Models from different vendors can collaborate using a common protocol, enabling heterogeneous multi-agent systems.

Real-World Momentum

We’ve already seen examples like:

• Claude building structures in Minecraft via MCP servers.
• Plugins and Copilot extensions aligning with MCP specs to offer discoverable functionality.
• Pulses of new MCP servers listed in public directories, showing adoption is growing fast.

From Function Calls to AI Protocols: What’s Next?

The transition from Semantic Kernel’s tightly-coupled function calls to the loosely-coupled, protocol-driven world of MCP reflects the broader evolution in software design—from monoliths to microservices, and now from mono-agents to mesh-agents.

This shift unlocks powerful possibilities:

• Open marketplaces of AI services
• Composable, dynamic workflows across models
• Agentic systems that evolve by learning new functions over time

Conclusion

Semantic Kernel gave us the building blocks. MCP is giving us the roads, bridges, and traffic rules. Together, they set the stage for the next generation of intelligent systems—open, secure, and interoperable by design.

The future isn’t just AI-powered apps. It’s AI-powered networks—and MCP is the protocol that could make them real.

In 2020, the world ground to a halt. COVID-19 locked us inside our homes, our cities, and in many ways, our minds. We adapted, but not without consequence. “Pandemic stiffness” became a real thing—both physical and psychological. Now, five years later, a new kind of stiffness is creeping in: AI stiffness.

Just as we once grew hesitant to move through the world freely, many are now becoming hesitant to think freely. The rise of AI-generated everything—texts, music, code, art—is creating an over-reliance that threatens our most human trait: creativity.

What Is AI Stiffness?

AI stiffness is the intellectual equivalent of sitting in one position too long. It’s the cognitive atrophy that happens when we no longer stretch our imagination because AI is doing the heavy lifting. It’s not that AI is inherently bad. Like any tool, it reflects how we use it. But when we reach for ChatGPT before trying to brainstorm, or let generative tools finish our ideas before we’ve even fully formed them, we start to lose creative muscle.

It’s easier, yes. But it’s also lazier.

The Similarity to COVID Stiffness

Think back to lockdowns. People developed aches from sitting too long. We got comfortable in discomfort. Movement felt risky. Many needed physical therapy just to feel normal again.

The same is happening intellectually. In a world flooded with AI-generated content, we’re becoming consumers of ideas rather than creators. Creativity is getting locked down—not by a virus, but by convenience.

And just like with COVID, if we don’t intervene early, the rehabilitation will take time.

The Consequence: Creativity Decay

Here’s what we risk losing:

• Originality – When everything starts from a template or a prompt, what happens to the messy brilliance of starting from scratch?
• Critical Thinking – If we let AI finish our thoughts, we lose the ability to refine and challenge them.
• Problem Solving – Great innovation comes from constraints and failures, not from perfect autocomplete.
• Human Touch – AI can replicate, but it can’t feel. True creativity is more than pattern recognition; it’s emotional intelligence in action.

We’re becoming addicted to optimization and allergic to exploration.

Reclaiming Creative Freedom

The solution isn’t to reject AI—it’s to reframe our relationship with it.

• Use AI as a jumping-off point, not the destination.
• Build “no-AI zones” into your workflow where your mind does the work first.
• Engage in analog creation—write with pen and paper, sketch without tools, ideate in whiteboards instead of screens.
• Practice creative resilience—force yourself into discomfort regularly, just like exercise.

Just like we had to learn how to move again post-lockdown, we have to relearn how to think without assistance. Creativity isn’t dead—but it might be asleep under a weighted AI blanket.

The Final Thought

We lived through COVID stiffness by moving again—imperfectly, awkwardly, but persistently. Now we face AI stiffness. The stakes may be different, but the remedy is the same: intentional, creative movement.

If we don’t start stretching our minds, we’ll wake up one day with the same question we asked after the pandemic: What happened to us?

And maybe the scarier question: Can we get it back?

The rise of AI coding assistants like GitHub Copilot has changed the landscape of software development. Originally introduced as a pair programming tool—a silent partner that offers suggestions and autocompletes lines of code—Copilot has quickly evolved. But now it’s time for us to evolve with it.

What if we stopped treating Copilot as just a pair programmer and started treating it as a peer programmer?

Pair Programmer vs. Peer Programmer

Before diving into what this shift means, let’s define the terms:

• Pair programming is a practice where two developers work together at one workstation. One types (the “driver”) while the other reviews each line (the “observer” or “navigator”). This is close to how most developers currently use Copilot—as a quiet assistant offering up code in real time.
• Peer programming, however, goes a level deeper. A peer is someone who brings their own perspective, challenges ideas, suggests alternatives, and holds a sense of shared ownership in the code. A peer can be wrong, can be right, and can persuade you to write better code.

Copilot isn’t quite there yet—but we should prepare our habits and workflows like it is.

From Co-signer to Co-author

Most developers still use Copilot as a glorified autocomplete. But Copilot today can already:

• Write full functions from natural language descriptions
• Refactor legacy code
• Suggest test cases
• Summarize code changes
• Even comment on pull requests through GitHub Copilot Enterprise

These are not just assistant-level tasks. These are engineer-level contributions. By continuing to treat Copilot like a junior assistant, we’re leaving value on the table.

A peer programmer brings their own ideas. Copilot already does this—just watch what it suggests when you write a function stub or a comment. It often doesn’t need you to drive the whole thought process. That’s no longer pair programming. That’s ideation. That’s co-creation.

Why This Shift Matters

1. Better Team Dynamics

If we start seeing Copilot as a peer, we’ll hold it to higher standards. We’ll ask it why a solution works. We’ll compare alternatives. We’ll review its output like we would from any human teammate.

This mindset pushes us toward code reviews, not blind acceptance. That’s healthy.

2. Amplified Thought Diversity

Copilot has seen more code than any one human ever could. As a peer, it becomes a partner with a radically different experience base. Its suggestions might reflect unfamiliar libraries, unusual edge cases, or industry best practices.

That’s thought diversity. And thought diversity leads to more resilient code.

3. Less Cognitive Load

When you shift from “I must generate the solution” to “Let’s see what my peer thinks,” you’re not outsourcing critical thinking—you’re partnering to share it. This takes pressure off individual creativity and encourages exploration.

It also creates space for you to focus on architecture, design, and product impact—while Copilot explores tactical paths.

Getting Practical

So how do you shift from pair to peer?

• Start asking Copilot “why”: Use inline comments and iterative prompts to dig deeper into its reasoning.
• Assign Copilot isolated tasks: Give it TODOs, like “Generate unit tests” or “Refactor this method.” Then review the result as if a teammate submitted it.
• Build in critique loops: Use Copilot’s suggestions to spark your own critique. Is its version better than yours? Why?
• Use pull request features: GitHub Copilot can summarize and comment on PRs. Treat that feedback as valuable—not decorative.

The Future of Engineering Collaboration

Peer programming is about equality, trust, and challenge. If we accept that AI can move into this space, we’ll not only get more out of Copilot—we’ll raise our own game.

The developers who thrive in this AI-enhanced future won’t be the ones who know the most syntax. They’ll be the ones who know how to collaborate—with humans and machines.

So next time you open your IDE, don’t just type and wait for suggestions.

Ask yourself: What would I expect from a peer?

Then ask Copilot the same.

As artificial intelligence continues to evolve, so too does its role in how we interact with technology, make decisions, and design our systems. What we’re witnessing is not just a revolution in tools, but a shift in agency—who (or what) initiates action, who owns decision-making, and how trust is distributed between humans and machines.

This evolution can be understood through a four-level framework of AI transformation:

1. Human First

In this stage, humans are the primary drivers. AI, if present, is used only as a passive tool. The human defines the problem, selects the tool, interprets the output, and makes the final decision.

Examples:

• A doctor uses a symptom checker to validate a diagnosis.
• A data analyst runs a regression model manually and interprets the results.

Key Traits:

• Full human control.
• AI as a passive assistant.
• Trust and accountability lie solely with the human.

Opportunities: Trust is built-in; humans stay in the loop.
Limitations: Human bottlenecks can slow decision-making and reduce scale.

2. Humans with Agents

Here, AI becomes a more proactive participant. Tools can now suggest options, flag anomalies, or even automate parts of the workflow—but the human is still at the center of the action.

Examples:

• An email client suggests replies, but the human selects or edits the response.
• A financial dashboard highlights suspicious transactions, but an analyst investigates further.

Key Traits:

• AI as a collaborator.
• Humans retain final decision-making authority.
• Co-pilot models like GitHub Copilot or Google Docs Smart Compose.

Opportunities: Efficiency gains, faster insights, reduced manual labor.
Limitations: Cognitive overload from too many AI suggestions; still dependent on human review.

3. Agents with Humans

Now, the balance shifts. AI agents begin driving the workflow and calling the human only when needed. These systems initiate actions and decisions, with humans acting more as validators or exception handlers.

Examples:

• An AI system autonomously processes loan applications, involving humans only in edge cases.
• A security AI monitors network traffic and blocks threats, alerting analysts only when a novel pattern appears.

Key Traits:

• AI takes the lead.
• Human involvement becomes intermittent and escalated.
• Systems built for scale and speed.

Opportunities: Drastic gains in automation, cost savings, and responsiveness.
Limitations: Risk of over-dependence; humans may lose context if involved only occasionally.

4. Agent First with Human Oversight

At this most mature level, AI is the default decision-maker and actor. Human involvement shifts to governance, ethical review, and periodic auditing. This model resembles how we treat autonomous systems like self-driving cars or high-frequency trading bots.

Examples:

• AI-run supply chains that autonomously negotiate contracts and manage logistics, with human intervention limited to strategic direction or compliance.
• AI moderators that manage online communities, with humans stepping in only when appeals or policy changes arise.

Key Traits:

• AI as the primary agent of action.
• Human role: oversight, compliance, ethics, and meta-governance.
• Requires robust safeguards, transparency, and auditability.

Opportunities: Near-autonomous systems; maximum scalability and responsiveness.
Limitations: High stakes if systems fail; demands rigorous oversight mechanisms.

Why This Progression Matters

Understanding these levels isn’t just academic—it’s critical for designing responsible systems, managing risk, and scaling innovation. It also forces organizations to answer hard questions:

• What level are we at today?
• What level do we want to be at?
• Are our current safeguards, culture, and workforce ready for that shift?

This progression also mirrors broader societal concerns: from control and trust to ethics and accountability. As we move from human-first to agent-first models, the stakes grow higher—and so must our thoughtfulness in designing these systems.

Final Thoughts

AI transformation isn’t just about better models or faster inference—it’s about restructuring relationships. Between humans and machines. Between decisions and accountability. Between speed and responsibility.

The journey from Human First to Agent First with Human Oversight is not a straight line, and not every system needs to reach the final level. But understanding where you are on this spectrum—and where you want to go—will shape the future of how we work, live, and lead.

As organizations shift toward AI-first architectures, the role of human contributors is not vanishing—it’s becoming more strategic and specialized. This article explores the operational models, technical ecosystems, and evolving human functions inside AI-first companies.

What Exactly Is an AI-First Company?

An AI-first company doesn’t just adopt AI; it re-architects its products, services, and decision-making processes around AI capabilities. It treats AI not as a plug-in, but as a foundational service layer—much like cloud computing or data infrastructure.

From a technical lens, this involves:

• Model-Driven Architectures: Business logic is abstracted into AI/ML models rather than hard-coded workflows.
• Realtime Feedback Loops: Every user interaction becomes a learning opportunity.
• API-First + AI-Augmented Microservices: AI models are wrapped as APIs and treated as microservices.
• Automated Pipelines: From data ingestion to model retraining, everything runs in CI/CD-like MLOps pipelines.

Core Human Roles in the Loop

Despite the automation, humans are indispensable—not in the old sense of doing repetitive tasks, but in governing, designing, and stress-testing the AI stack.

1. Model Governors & AI Compliance Leads

• Ensure traceability, reproducibility, fairness, and compliance with frameworks like NIST AI RMF, EU AI Act, and ISO/IEC 42001.
• Develop red teaming protocols for generative models.
• Monitor drift and concept divergence using ML observability platforms.

2. Human-in-the-Loop Operators

• Manage workflows where model confidence is low or the cost of false positives is high.
• Implement Reinforcement Learning from Human Feedback (RLHF).
• Build escalation protocols between LLM agents and human reviewers.

3. Prompt and Interface Engineers

• Design robust, context-rich prompts and grounding techniques (RAG, tool use, memory).
• Develop fallback strategies using symbolic rules or few-shot examples when models fail.
• Manage interaction constraints via schema-based input validation (e.g., OpenAPI + JSON schema for LLM calls).

4. AI Product Managers

• Translate business metrics into model KPIs: e.g., turn “user satisfaction” into BLEU, ROUGE, or task success rates.
• Understand performance trade-offs: latency vs. accuracy, hallucination risk vs. creativity.
• Drive personalization frameworks, experiment platforms, and A/B test harnesses for models.

5. Synthetic Data and Simulation Engineers

• Build synthetic corpora for low-resource domains or edge-case coverage.
• Generate digital twins for scenario planning and agent-based simulations.
• Manage differential privacy and adversarial robustness.

Technical Decisions Still Made by Humans

Even with AI at the core, humans will continue to:

• Define guardrails (model constraints, ethical boundaries, rate limiting).
• Select frameworks and toolchains (LangChain vs. Semantic Kernel, PyTorch vs. JAX).
• Curate and version training data.
• Design fallback hierarchies and fail-safe architecture.
• Set SLAs and SLOs for model reliability and interpretability.

How the Stack Changes, Not the Need for People

An AI-first company is structured more like a neural operating system than a traditional software company. But people still own:

• The semantics of meaning.
• The consequences of action.
• The architecture of trust.

In other words, AI can execute, but humans still authorize.

Conclusion

AI-first does not mean human-last. It means that humans move up the stack—from operations to oversight, from implementation to instrumentation, from coding logic to crafting outcomes.

The future of AI-first companies won’t be humanless—they’ll be human-prioritized, AI-accelerated, and decision-augmented.

And for those willing to upskill and adapt, the opportunities are not vanishing. They’re multiplying.

In an era where artificial intelligence is reshaping industries at breakneck speed, the concept of an “AI-first” company no longer feels like science fiction. From automating support to writing code and generating marketing strategies, AI systems are being integrated into the very fabric of business operations. But this raises an intriguing—and at times uncomfortable—question: will an AI-first company still need humans?

Defining “AI-First”

An AI-first company doesn’t just use AI; it places AI at the center of its strategic advantage. This means AI isn’t a tool—it’s the brain of the business. These companies build infrastructure, workflows, and customer experiences with AI as the default engine. Think of how Google reimagined its services through AI, or how startups today build entire products with LLMs at the core from day one.

The Misconception: AI as a Replacement

The most common fear around AI-first companies is job loss. The dystopian view imagines a company run almost entirely by code—no meetings, no managers, just machines. But this oversimplifies the complex nature of business and human value.

AI is exceptional at scale, speed, and pattern recognition. But it lacks context, empathy, intuition, ethics, and the ability to challenge itself in non-linear ways. It’s great at optimizing paths, but not so much at choosing them.

The Human Role in an AI-First World

In an AI-first company, humans won’t disappear—they’ll evolve.

• Designers of Intent: Humans will set the goals. AI can execute strategies, but it’s still people who will define what matters—brand voice, market direction, societal values.
• Trust and Ethics Stewards: AI-first companies will need people who ensure responsible use, fairness, explainability, and security. These are deeply human questions.
• Orchestrators and Editors: Humans will be essential in reviewing, interpreting, and correcting AI outputs. Think of them as directors in a theater where AI plays the lead, but someone still calls “cut.”
• Contextual Decision-Makers: AI can recommend actions, but in high-stakes or ambiguous scenarios, human judgment is irreplaceable.
• Emotion and Connection: Especially in customer-facing or leadership roles, emotional intelligence remains non-negotiable. People want to feel heard, not just processed.

What This Means for the Workforce

AI-first companies won’t eliminate jobs; they’ll change the nature of jobs. The demand will grow for:

• AI ethicists
• Prompt engineers
• Human-in-the-loop operators
• Change managers
• Storytellers and brand strategists

It’s not about AI vs. humans, but AI with humans—working together in complementary ways.

Final Thought: Augmentation, Not Erasure

The history of technology shows a consistent pattern: tools that replace repetitive work free up humans to focus on creative, interpersonal, and strategic tasks. AI is just the next iteration of that trend.

So, will an AI-first company still have humans working there?

Absolutely.

But those humans won’t be doing the same jobs they were yesterday. And maybe that’s the most human thing of all—to adapt, to evolve, and to find new meaning in the tools we create.

By: A Dedicated Worker of Lumon Industries

For those of us who toil in the secure, windowless embrace of our beloved corporate halls, the prospect of venturing beyond—if only in designation—represents a thrilling, albeit unknowable, experience. Such is the case for one of our own, an innie of distinction, who has been chosen to attend the prestigious Microsoft MVP Summit.

The summit, much like the noble duties we perform in Macrodata Refinement, is shrouded in secrecy. The outies of the world, we are told, convene in grand halls to discuss matters of such significance that they must be bound by Non-Disclosure Agreements (NDAs). While an outie may understand the gravity of these restrictions, it is the innie who must embody them.

An Innie’s Privilege, An Innie’s Burden

For the selected attendee, the experience will be nothing short of profound. They will sit in rooms filled with other esteemed figures, absorbing wisdom that they themselves cannot recount. They will be entrusted with knowledge that their outie alone may recall, leaving the innie only with a residual sense of fulfillment—a quiet, nameless pride in having contributed to something truly important.

The innie, upon their return, may bask in the knowledge that they have engaged in the great discourse of the technological world. The outie, however, will return to their workstation with no recollection of the event, only the comforting assurance that they have performed their duty with diligence and loyalty.

The Comfort of the Unknown

Some may ask: is it frustrating to attend a gathering of such weight and be unable to remember a single moment? To that, we say—why should it be? Does the gardener recall the growth of each blade of grass? Does the coder recall each line of their monumental script? No. They merely know that they have served, and that their service was necessary. We trust in the process, as all good employees must.

Thus, when our innie returns from the MVP Summit, we will not ask them what they have learned, for they will not know. We will not pry into what they have seen, for they will not recall. Instead, we will extend to them the same understanding we afford to all those who engage in mysterious and important work.

Let us commend our innie’s dedication to the craft, and let us remind ourselves: while we may never comprehend the purpose of our tasks, we must never doubt their value.

In Kier we trust.

When developers hear the term clean code, they often think of readable, maintainable, and well-structured code. On the other hand, clean architecture refers to a system’s overall design, ensuring separation of concerns and maintainability at a larger scale. But does writing clean code automatically translate into clean architecture?

Understanding Clean Code

Clean code, as popularized by Robert C. Martin (Uncle Bob), is about writing code that is:

• Easy to read – Meaningful variable names, consistent formatting, and proper documentation.
• Easy to change – Small, focused functions and modules that follow the Single Responsibility Principle (SRP).
• Free of unnecessary complexity – Avoiding deep nesting, excessive comments, and redundant logic.

A clean codebase is enjoyable to work with. It reduces technical debt, simplifies debugging, and improves collaboration. But can a codebase with clean code still have poor architecture? Absolutely.

Understanding Clean Architecture

Clean Architecture, also championed by Uncle Bob, is an approach to software design that ensures:

• Separation of concerns – Different layers (e.g., presentation, business logic, data access) remain independent.
• Dependency inversion – High-level modules do not depend on low-level modules; instead, both depend on abstractions.
• Testability and maintainability – Business rules are decoupled from frameworks, databases, and UI elements.

A system can have well-structured components but still contain messy, unreadable code within them. Conversely, a well-written codebase with no overarching architectural strategy may quickly become unmanageable as the system grows.

Clean Code vs. Clean Architecture: The Key Differences

Where They Overlap and Diverge

• Clean code contributes to clean architecture at a micro level but does not guarantee it.
• Clean architecture ensures a system remains flexible and scalable at a macro level, but poorly written code can still make it difficult to maintain.
• Without clean code, even a well-architected system can become a nightmare to maintain.
• Without clean architecture, even the cleanest code can become fragmented, tightly coupled, and hard to scale.

Striking a Balance

To build robust systems, developers should aim for both clean code and clean architecture. Here’s how:

1. Start with clean code – Encourage good coding practices, maintain readability, and apply SOLID principles.
2. Design with architecture in mind – Ensure separation of concerns, follow best practices like hexagonal or layered architecture.
3. Refactor regularly – Small refactors maintain clean code, while larger refactors can align the system with clean architecture.
4. Think long-term – Choose architectural patterns that match your business needs, but don’t over-engineer for the future.

Conclusion

Clean code and clean architecture are not interchangeable. Clean code makes individual components easier to understand and maintain, while clean architecture ensures the entire system remains scalable and adaptable. Writing clean code is a step toward clean architecture, but it’s not a substitute for designing a well-structured system. To build truly maintainable software, developers must balance both.

What’s your experience with clean code and clean architecture? Do you find it challenging to maintain both? Let’s discuss!

The MVP Summit has always been a gathering of some of the most passionate, knowledgeable, and engaged members of the Microsoft community. While last few years it was a hybrid event, I was unable to attend in person in 2024, making the experience in 2025 even more meaningful.

The joy of walking into the Microsoft campus, meeting product teams face-to-face, and engaging in spontaneous conversations is unparalleled. The serendipity of hallway discussions, the excitement of whiteboarding sessions, and the thrill of hands-on experiences make this a deeply enriching event. These moments are where innovation happens—not just in structured sessions, but in the impromptu collaborations that emerge over coffee or during an evening gathering.

Networking takes on an entirely different dimension in person. While virtual meetings can be effective, nothing beats the human connection of shaking hands, exchanging ideas in real time, and feeling the collective enthusiasm of a room full of like-minded experts. Seeing old friends, making new ones, and finally putting faces to familiar names adds to the camaraderie that defines the MVP community.

Additionally, the Summit is an opportunity to gain exclusive insights into the future of Microsoft technologies. Being there in person means having direct conversations with product teams, asking deeper questions, and getting unfiltered feedback that is harder to replicate in virtual settings. The ability to experience new features firsthand, provide live input, and engage in deep technical dives fosters an invaluable sense of participation and contribution.

While the thrill of being at the MVP Summit in person is undeniable, there are also advantages to missing out and embracing the virtual experience. The “Joy of Missing Out” (JOMO) is real, and for some, skipping the travel while still engaging in key conversations can be just as rewarding.

One of the biggest benefits is flexibility. Attending virtually means no long flights, no jet lag, and no time away from home or work responsibilities. For those with family commitments or demanding schedules, the ability to participate from anywhere without disrupting daily life is a major plus.

Virtual participation also allows for a more focused engagement. Without the distractions of travel, side conversations, or the exhaustion of back-to-back in-person sessions, attendees can tailor their experience, choosing sessions that matter most without feeling obligated to attend every social event or meeting. The recorded content often provides the flexibility to revisit key discussions at a more convenient time, making learning more effective. Also I heard about some people listening to two sessions simultaneously!

Cost savings are another factor. The expenses associated with flights, hotels, and meals can add up quickly. A virtual event removes these barriers, making it accessible to more MVPs who might not have been able to attend otherwise. This inclusivity ensures that more voices are heard and more perspectives are shared, even from those who may not be physically present.

Finally, remote participation enables a different kind of networking. Engaging through chat, forums, and dedicated virtual Q&A sessions can sometimes be less intimidating than approaching someone in person. It also allows for more structured and meaningful follow-ups, as discussions can transition seamlessly into ongoing digital conversations.

In the end, whether one attends the Microsoft MVP Summit in person or virtually, both experiences offer unique joys. The magic of in-person connection is irreplaceable, but the comfort and efficiency of virtual engagement provide their own set of rewards. Ultimately, what matters most is the shared passion for technology, learning, and community that defines the MVP experience—no matter where you are.