M365.FM - Modern work, security, and productivity with Microsoft 365

Mirko Peters (Microsoft 365 consultant and trainer)
  • 5.0 (3)
  • TECH NEWS
  • UPDATED DAILY

Welcome to the M365.FM — your essential podcast for everything Microsoft 365, Azure, and beyond. Join us as we explore the latest developments across Power BI, Power Platform, Microsoft Teams, Viva, Fabric, Purview, Security, and the entire Microsoft ecosystem. Each episode delivers expert insights, real-world use cases, best practices, and interviews with industry leaders to help you stay ahead in the fast-moving world of cloud, collaboration, and data innovation. Whether you're an IT professional, business leader, developer, or data enthusiast, the M365.FM brings the knowledge, trends, and strategies you need to thrive in the modern digital workplace. Tune in, level up, and make the most of everything Microsoft has to offer. M365.FM is part of the M365-Show Network. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support.

  1. The Architect’s Confession: Why Technical People Build the Worst Tenants

    18H AGO

    The Architect’s Confession: Why Technical People Build the Worst Tenants

    Mirko Peters shares a blunt truth: Microsoft 365 problems are rarely technical—they’re governance failures. From automation chaos to security overreach and AI rollouts that stall, this episode breaks down why technically brilliant architectures often collapse in real organizations—and what to do instead. ⚡ Opening Insight“I’m not the most technical person in the room… but I see the failures.”Microsoft 365 isn’t a toolset—it’s an operating system for your businessMost failures = organizational design problems, not technical ones🧩 Core Idea Technology rarely fails. Organizations fail to structure it. 🏗️ Section 1: Microsoft 365 = Operating SystemNot apps → organizational infrastructureTeams = communication layerSharePoint = institutional memoryPower Platform = process automation layer👉 If you treat it like tools → chaos 👉 If you treat it like an OS → architecture matters ⚠️ Section 2: When Technical Excellence Becomes a LiabilityEngineers optimize for:CapabilityPerfectionOrganizations need:SustainabilityMaintainabilityProblem: Perfect systems on day one → collapse by year three 🧠 Key Shift From: Can we build this? To: Should we build this—and who runs it later? 🧱 Section 3: The 3 Governance Zones 1. Personal Work (Low Control)OneDrive, personal chatsMinimal governance2. Collaborative Work (Moderate Control)Teams, projectsOwnership + lifecycle3. Enterprise Records (High Control)HR, Finance, ComplianceStrict governance👉 One model for all = failure 💥 Failure Patterns (Real-World Cases) 🐍 1. Automation HydraHundreds of flowsHidden dependenciesNo ownershipResult: Small change → system-wide failure 🏰 2. Security FortressPerfect Zero Trust setupToo restrictiveResult: Users bypass → shadow IT explodes 🤖 3. Copilot StallAI rollout starts strongThen stopsWhy: Copilot exposes:Permission chaosOversharingGovernance debt🧨 4. Identity CollapseToo many Global AdminsNo delegation modelResult: One breach = total compromise 🔍 Root Cause Technical people optimize for:PrecisionControlCapabilityBut miss:Human behaviorOrganizational realityLong-term sustainability🧠 The Big Shift: Intent-Based Governance ❌ Configuration Thinking“Enable MFA”“Restrict sharing”✅ Intent-Based Thinking“Authenticate based on risk”“Enable collaboration safely”👉 Intent survives change 👉 Configurations don’t ⚙️ What Durable Architecture RequiresClear ownershipLifecycle managementContinuous monitoringAdaptable governance📊 Governance Debt (What to Check)Too many Global AdminsOrphaned Teams & sitesUnknown Power Automate flowsUnlabeled sensitive dataUncontrolled external sharing👉 Invisible → until crisis ✅ Tenant Durability Checklist Ask yourself:Who owns this system?Is there a lifecycle?Is someone monitoring it?Can someone explain it?If not → you have governance debt 🔄 Continuous Governance Governance is NOT:A projectA checklistA one-time setupGovernance IS:A continuous systemA feedback loopAn evolving architecture🏢 Executive TakeawaysShadow IT = design failureSecurity ≠ restriction → must be usableAI exposes weak governance instantlyCapability without readiness = risk🚀 Practical StepsAudit your tenant honestlyDefine governance intentImplement the 3-zone modelReduce Global Admin sprawlBuild monitoring loopsCommunicate governance as strategy🔮 Why This Matters NowAI (Copilot) is accelerating everythingGovernance debt is becoming visibleRegulations (EU AI Act) are tighteningCosts are rising → pressure to optimize👉 Governance = competitive advantage 💡 Final Insight The most dangerous system is not bro Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support. If this clashes with how you’ve seen it play out, I’m always curious. I use LinkedIn for the back-and-forth.

    1h 27m
  2. 500 Episodes Later: Why Consistency is a Lie (and What Actually Works)

    1D AGO

    500 Episodes Later: Why Consistency is a Lie (and What Actually Works)

    After 500 episodes, Mirko Peters shares an uncomfortable truth: consistency alone does not create results. What started as a daily podcast to get hired failed in its original goal—but revealed something far more valuable. This episode breaks down the difference between output and leverage, why visibility doesn’t convert, and what actually drives business outcomes: distribution, positioning, execution, and relationships. 🚀 Key Topics Covered 1. The Original Plan (That Failed)Podcast started as a job portfolio machineGoal: prove value through daily outputAssumption: consistency → trust → job offersReality: production ≠ conversion2. Why Consistency Is a LieConsistency builds activity, not outcomesOutput without structure = unrewarded laborMarkets reward:RelevanceFitRisk reductionNot effort, volume, or discipline alone3. The Real Problem: Missing TranslationContent answered: “Do I know something?”Market needed: “What changes if I’m in the room?”Gap = business relevance & positioning4. Failure #1: Content as a Job PortfolioVisibility ≠ hiring confidenceAudience ≠ decision-makersProof of work ≠ proof of fit5. Failure #2: The Certification TrapMore credentials = more inventory, not leverageCertifications prove knowledgeBut not:JudgmentTranslationBusiness impact6. Failure #3: The Consistency MythDaily output created momentum illusionHigh activity, low conversionConsistency keeps the engine running—but does not define where it goes⚙️ What Actually Worked 1. Distribution > ProductionReal growth came from:LinkedInNewsletter (~30K subs)LivestreamsOwned audience = reachable attentionDistribution = movement of value2. Script Writing = Thinking UpgradeForced clarity and structureShift from:Explaining features → explaining consequencesResult: better positioning & communication3. Event Execution (m365con)~5,400 attendees, 70 speakersProved:Operational capabilityTrust under pressureExecution > theory4. Network DensityBiggest ROI wasn’t content—it was peopleAccess to builders → faster learning & opportunitiesRelationships = core infrastructure🧩 Core Insight Output creates assets. Leverage creates outcomes. 🏢 Executive Takeaways 1. Shadow IT Is a Design FailureUsers bypass systems when:Processes are too slowGovernance is too complexSolution: better system design, not more control2. Decision Flow > Tool CountMore tools ≠ more speedBottleneck = unclear ownership & decisionsFix the flow before automating3. The Copilot Value GapAI doesn’t fix broken systemsIt amplifies themROI depends on:Clean dataClear processesDefined ownership🔄 The Real Shift From:Tech explanationsFeature updatesTo:Business consequencesOperational realityDecision impact🧱 What 500 Episodes Actually Built Not:A job machineBut:A thinking machineA distribution systemA network of trustA business platform💡 Final Takeaway Consistency is not the answer. The real stack is: Consistency + Distribution + Positioning + Execution + Relationships 🎯 Call to Action If this episode made you rethink your own work:⭐ Leave a review🔗 Connect with Mirko on LinkedIn💬 Share what system you’re buildingAnd most importantly: 👉 Don’t just ask what you’re producing 👉 Ask what your system is actually creating Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support. If this clashes with how you’ve seen it play out, I’m always curious. I use LinkedIn for the back-and-forth.

    1h 4m
  3. 5 Microsoft 365 Business Models That Are Quietly Making People Six Figures

    2D AGO

    5 Microsoft 365 Business Models That Are Quietly Making People Six Figures

    🚀 INTRODUCTION — The Death of Hourly ConsultingMicrosoft 365 is not just a productivity suite — it’s a distributed decision engineIt continuously makes thousands of authorization and governance decisionsThe old consulting model is dead because:Expertise is no longer scarceDocumentation is abundantCompute is infiniteWhat organizations lack today: 👉 Governance, not toolsThe Problem with Hourly ConsultingIncentivizes more hours, not better outcomesLeads to:Margin compressionCommodity positioningClient replacement with cheaper laborMarket shift: 👉 From effort-based billing → outcome-based pricing🧠 SECTION 1 — Architectural ArbitrageMicrosoft releases hundreds of features yearlyOrganizations can’t govern the complexity → entropy increasesOpportunity: 👉 Not in implementation 👉 But in controlling system behaviorOld Model vs New ModelOld ConsultingNew ModelSell hoursSell outcomesProject-basedRecurring revenueGeneralistSpecialistReplaceableDefensible 💰 SECTION 2 — Why Complexity = Six-Figure NichesFeature velocity creates:More riskMore misconfigurationMore governance gapsMarket ShiftGeneralists are losingSpecialists are winningExamples:Identity specialists → eliminate attack surfacesAI orchestration experts → replace headcountGovernance experts → manage data lifecycle👉 Depth > breadth = premium pricing 🤖 MODEL 1 — Agentic Workflow Factory Core Idea: You’re not building flows — you’re managing digital labor Key Concepts:Multi-agent orchestration (not linear workflows)Systems that adapt in real-timeYou own:Decision logicAgent behaviorOptimizationRevenue Model:Build: $50K–$150KUsage: $2–$5 per interactionRetainer: $10K–$30K/month👉 Replaces FTEs → immediate ROI 🔐 MODEL 2 — Entra-First Security Boutique Core Idea: Identity is the only perimeter that matters Why It Works:Legacy authentication deadline (Dec 31, 2026)Forced demand → every org must modernizeROI Drivers:90% fewer password resets60% infrastructure cost reduction85% reduction in breach riskService Stack:AuditRemediationEnforcementOptimization (retainer)👉 Year 1: ~$300K+ per client 🏛️ MODEL 3 — Governance-as-a-Service Core Idea: Microsoft 365 naturally decays into chaos Common Problems:Teams sprawlSharePoint data swampBroken DLP policiesInconsistent labelingFailed access reviewsSolution: 👉 Continuous governance as a service Revenue:$8K–$25K/month recurring80–90% margins👉 You’re selling entropy control 📊 MODEL 4 — Decision Engine Architect Core Idea: Dashboards don’t create value — decisions do Shift:From reporting → to automated decision-makingEnablers:Real-time data (Fabric / OneLake)Event-driven architectureML-based decision modelsUse Cases:Predictive maintenanceReal-time pricingInventory automationRevenue:Build: $150K–$300KRetainer: $5K–$20K/month👉 You automate what happens next 📦 MODEL 5 — Industry Tenant-in-a-Box Core Idea: Stop selling services → start selling a product What You Build:Fully pre-configured M365 tenantDesigned for a specific industryExamples:Legal (privilege protection, case mgmt)Healthcare (HIPAA compliance)Finance (SOC2, audit trails)Business Model:$5K–$15K/month per client90%+ margins at scale👉 Build once → license forever 💸 PRICING SHIFT (Across All Models) Traditional Consulting:$150–$250/hourLow marginsLinear growthNew Model:Outcome-based pricingRecurring revenue70–90% margins👉 Revenue decoupled from headcount 🎯 POSITIONING STRATEGY Stop Saying:“We implement Conditional Access”“We build Power BI dashboards”Start Saying:“We eliminate identity attack surfaces”“We automate executive decision-making” Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support. If this clashes with how you’ve seen it play out, I’m always curious. I use LinkedIn for the back-and-forth.

    1h 31m
  4. The 7 Levels of Azure Administration: From Zero to Architectural Truth

    2D AGO

    The 7 Levels of Azure Administration: From Zero to Architectural Truth

    🔥 Episode Thesis Most organizations misunderstand Azure administration. They treat it as a progression of:certificationsservices learnedresponsibilities addedThat model is wrong. Azure administration is not about managing resources. 👉 It is the management of entropy. And entropy always wins—unless you design systems where non-compliant states are impossible. 🧠 Core Idea This episode introduces 7 Levels of Azure Understanding, each marked by:A false beliefA moment of disillusionmentA shift in identityBy Level 7, you are no longer an administrator. You are: A curator of a distributed decision engine ❄️ Cold Open: The Comfortable Lie You’ve been promoted. You own the tenant. You manage the budget. …and yet: 👉 You’re still clicking buttons. The RealityYou don’t govern the systemYou react to itYou patch what you never designedThe Lie “If I understand Azure services, I can manage Azure.” The Truth Azure is not manageable. It is only governable. 🧩 The 7 Levels of Azure Administration LEVEL 1: The Portal Clicker “I deploy resources, therefore I understand Azure” IllusionThe portal shows you realityClicking = controlTruthYou are a human API callHigh latencyInconsistentUntraceableCore ProblemNo versioningNo intentNo reproducibilityKey Insight If it’s not declarative, it’s not managed. LEVEL 2: The Scripting Apprentice “Automation makes me an architect” IllusionScripts = controlSpeed = maturityTruthScripts scale chaos fasterImperative ≠ deterministicRisksFragilitySilent failureNon-idempotencyKey Insight You didn’t solve entropy—you accelerated it. LEVEL 3: The IaC Believer “Infrastructure as Code is the answer” IllusionTemplates = architectureTruthIaC without governance = high-speed failureWhat IaC Actually SolvesRepeatabilityIdempotencyVersioningWhat It Does NOT SolveComplianceSecurityIntent enforcementKey Insight The template is not truth. Policy is truth. LEVEL 4: The Governance Awakening “Policy is the architecture” IllusionPolicy slows teams downTruthPolicy eliminates entire classes of failureExampleNo policy → public IPs existDeny policy → public IPs become impossibleArchitectural Shift You move from:reacting to problems → preventing them from existingKey Insight Good governance doesn’t block bad behavior. It makes bad behavior impossible. LEVEL 5: The Landing Zone Architect “Structure defines survival” IllusionSubscriptions = containersTruthSubscriptions = blast-radius boundariesComponents of Real Landing ZonesManagement GroupsPolicy HierarchiesRBAC BoundariesNetwork SegmentationOutcomeFailures are containedAuthority is scopedChaos is isolatedKey Insight A landing zone is not a deployment. It is a control system. LEVEL 6: The Identity Strategist “The network is dead” IllusionFirewalls protect your environmentTruthIdentity is the perimeterTokens are the gateReality Attackers don’t break networks. They:steal credentialsobtain tokensbypass everythingCore Shift From:network-first thinking To:identity-first architectureKey Insight The perimeter is not a place. It is a decision. LEVEL 7: The Decision Engine Curator “You don’t manage resources anymore” IllusionAdmins manage infrastructureTruthYou manage the logic that governs infrastructureWhat You Actually OwnPolicy decisionsIdentity rulesConditional AccessAutomation constraintsNew Identity You are: The architect of a system that makes decisions without you Key Insight You don’t deploy resources. You define whether they are allowed to exist. 🤖 The Final Frontier: AI Agents The Misunderstanding AI is seen as:a toola chatbota helperThe Reality AI agents are:identitiesautonomous actorsAPI-driven decision-makersThe New Risk: Action Risk Not:bad answers Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support. If this clashes with how you’ve seen it play out, I’m always curious. I use LinkedIn for the back-and-forth.

    1h 16m
  5. The Copilot Governance Trap: Why Waiting for Perfect Data is an Architectural Omission

    4D AGO

    The Copilot Governance Trap: Why Waiting for Perfect Data is an Architectural Omission

    Most organizations treat governance like a gate. A checkpoint that must be passed before innovation can continue. Audit the environment. Find the problems. Stop the deployment. But what if that instinct is architecturally wrong? In this episode, we break down a real-world scenario where an organization discovered 847 orphaned SharePoint sites, zero consistent data classification, and a stalled Copilot rollout. The governance response was predictable: pause everything until the environment is fixed. But the deeper issue wasn’t the disorder. It was the assumption that governance must be perfect before deployment begins. This episode explores a different model: Governance as a track — not a gate. Instead of waiting for perfect conditions that never arrive, organizations can sequence risk intelligently and improve governance while value is already flowing. 🔍 What You'll Learn In this episode we explore: • Why SharePoint and Teams environments grow organically, not architecturally • Why orphaned sites are not governance failures — they are operational realities • The difference between disorder and the ability to manage disorder • Why waiting for perfect data creates governance debt instead of reducing risk • How parallel governance accelerates both deployment and compliance • Why Copilot does not bypass Microsoft Graph permissions • How automated governance transforms chaos into a deterministic system 🧠 The Core Insight Perfect governance does not exist. Distributed collaboration systems naturally create: • orphaned sites • incomplete ownership • unclassified data • permission drift The real question is not: “Does disorder exist?” The real question is: “Do you have systems that detect and remediate disorder continuously?” Organizations that answer yes can deploy safely. Organizations that wait for perfect conditions often delay value for months — while governance problems continue to grow. ⚙️ The Parallel Governance Model The case study organization solved their Copilot deployment problem with two parallel tracks. Track One — Rapid Governance Triage Using Microsoft Purview and SharePoint Advanced Management, the organization: • Scanned all 847 sites for sensitive data • Applied automatic sensitivity labels • Assigned interim site ownership through automated policies • Implemented lifecycle policies for inactive sites Within 10 weeks: ✔ 94% of orphaned sites had documented owners ✔ Sensitive data was classified automatically ✔ Governance enforcement became continuous Track Two — Scoped Copilot Deployment Instead of waiting for remediation, Copilot was deployed immediately to: • Finance • Legal • Human Resources These teams already had stronger governance maturity and high-value workflows. Within the first month: • Users saved 26 minutes per day on average • Productivity improvements became measurable • Executive support for expansion increased Governance improvements and deployment momentum reinforced each other. 📊 The Metrics That Changed the Conversation Three metrics convinced leadership the approach worked. Remediation Velocity 94% of orphaned sites remediated in 10 weeks Time-to-Triage Initial risk analysis across 847 sites completed in 72 hours Productivity ROI 26 minutes of daily time savings per user For the 1,200 pilot users: $21.6 million in annual productivity gains 🔐 The Security Reality About Copilot A common fear is that Copilot exposes sensitive data. It doesn't. Copilot operates on Microsoft Graph permissions. If a user cannot access a document today: Copilot cannot retrieve it. Copilot does not create new risk. It reveals existing governance posture. And that visibility often accelerates governance improvements. 🏗 The Architectural Principle Governance is not a gate. Governance is the track the deployment runs on. Gates assume a perfect state before progress begins. Tracks assume imperfection and build systems that manage risk continuously. The organizations that succeed with Copilot are not the ones with perfect data. They are the ones with deterministic governance systems that operate in real time. 📚 Key Technologies Discussed Microsoft technologies featured in this episode: • Microsoft Copilot for Microsoft 365 • Microsoft Purview • Sensitivity Labels & Auto-labeling • Data Loss Prevention (DLP) • SharePoint Advanced Management (SAM) • Microsoft Graph Permission Model 🚀 The Takeaway Waiting for perfect governance before deploying Copilot is an architectural mistake. It delays productivity gains. It allows governance debt to grow. And it prevents organizations from building the governance systems that modern collaboration actually requires. The better question is not: “Are we perfectly ready?” The better question is: “Do we have mechanisms to manage risk while we deploy?” If the answer is yes — move forward. Governance will improve along the way. 🎧 Listen & Continue the Conversation If you enjoyed this episode of M365 FM, please leave a review and share it with a colleague responsible for Microsoft 365 governance or Copilot adoption. Your feedback helps other IT leaders discover insights that turn complex technology into real business value. Connect with Mirko Peters on LinkedIn to continue the conversation and help shape future episodes. 🎙 M365 FM Podcast Where architecture meets real-world Microsoft 365 strategy. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support. If this clashes with how you’ve seen it play out, I’m always curious. I use LinkedIn for the back-and-forth.

    1h 16m
  6. The Ghost in the Tenant: Why Accountability is the Only True Security Patch

    MAR 13

    The Ghost in the Tenant: Why Accountability is the Only True Security Patch

    Most organizations treat Microsoft 365 like infrastructure — something that quietly runs in the background while business happens on top of it. That assumption is wrong. Microsoft 365 is actually a distributed decision engine making thousands of real-time authorization decisions across identity, data access, collaboration, and AI systems every day. And in most tenants… Nobody owns those decisions. When governance has no owner: identities accumulate without lifecycleconfigurations drift away from policy intentAI assistants access data nobody classifiedautomation runs long after its creator leavesThe system continues operating — but without accountability. That’s what I call the ghost in the tenant. In this masterclass we analyze three real failure patterns that prove the same thesis: Microsoft 365 does not fail because of technology. It fails because nobody owns governance. Then we build a 30-day operational blueprint to fix it. Key Topics Covered 1. The Accountability Vacuum Why governance committees create shared avoidance instead of shared responsibility. Key concept: Intent vs Configuration Drift Organizations define policy intent, but over time configuration drifts away from it. That gap is where risk lives. 2. The Three Layers of Microsoft 365 Failure Most incidents follow a predictable pattern: Layer 1 — Identity Sprawl unmanaged service accountsorphaned automation identitiesstale guest accessLayer 2 — Configuration Drift policy exceptions accumulateexternal sharing expandsConditional Access remains in report-only modeLayer 3 — AI Governance Collapse Copilot inherits sprawl permissionsagents run with cached privilegesdata classification is missingWhen these three layers align, incidents become inevitable. Incident Case Studies Incident 1 — The Orphaned Agent A Power Automate workflow built for invoice processing continues running after its creator leaves. Because it inherited broad permissions, it continues emailing sensitive financial data externally for 12 months. No alert. No review. No owner. The automation still had permissions. It no longer had a human. Incident 2 — Configuration Drift Collapse A Fortune 500 tenant allows unrestricted Teams creation and external sharing. Within six months: 400 unmanaged Teamsthousands of external guest permissionsuncontrolled connectorsRansomware enters through a compromised account. The attack was not hidden from monitoring tools. It was hidden inside configuration chaos. Incident 3 — Memory Poisoning in AI Assistants A Copilot-enabled tenant allows AI assistants to learn from shared documents. An attacker inserts malicious prompt instructions into a SharePoint document. Copilot retrieves the poisoned context and later recommends sharing sensitive employee salary data externally. The organization cannot explain: why the agent made the decisionwhat context triggered itwhere the reasoning originatedThere was no agent provenance. The 2026 Governance Crisis: Agentic Systems AI agents are fundamentally different from automation. Traditional automation is deterministic. AI agents are probabilistic systems. The same prompt can produce different outputs depending on: memorycontexttrainingretrieval dataWhich means organizations must introduce Agent Governance. Key components: Agent registryLifecycle ownershipConnector governanceProvenance tracingWithout those controls: Your tenant becomes programmable by attackers. The Governance Owner Model The fix is simple but uncomfortable: One person must own governance. Not a committee. Not shared responsibility. A named authority. The Governance Owner controls: Tenant Governance Authority Responsible for configuration drift monitoring. Connector Approval Every external integration requires approval. AI Agent Lifecycle All agents must have: ownerpurposepermissionsexpirationEscalation Authority Security decisions with risk impact route to this role. The 30-Day Operational Blueprint Phase 1 (Days 1-30) — Establish Authority appoint Governance Ownerdeploy Purview sensitivity labelsenable Copilot audit loggingbuild initial agent inventoryPhase 2 (Days 31-60) — Enforce Lifecycle require agent lifecycle documentationimplement Entra Conditional Access for agentsconduct first access reviewenable risk-based monitoringPhase 3 (Days 61-90) — Operationalize Governance monthly governance reviewsquarterly policy updatescontinuous configuration drift monitoringfull lifecycle management for AI agentsThe Deterministic Governance Model Organizations must choose between two operating models. Deterministic Governance decisions made by Governance Owneroutcomes predictabledrift actively correctedProbabilistic Governance decisions made by committeesexceptions accumulateentropy increasesOnly one of these scales. The Copilot Deployment Inflection Point Most deployments fail between weeks 6 and 12. Why? Because governance processes designed for pilot scale cannot handle expansion. Organizations add committees and processes instead of authority. Entropy accelerates. Core Thesis The most important decision in your Microsoft 365 architecture is not technical. It is organizational. Who owns governance? Without an owner: agents become orphanedpolicies drift Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support. If this clashes with how you’ve seen it play out, I’m always curious. I use LinkedIn for the back-and-forth.

    1h 8m
  7. Microsoft Power Platform Has a SERIOUS Problem

    MAR 12

    Microsoft Power Platform Has a SERIOUS Problem

    A global enterprise recently ran a tenant audit and discovered something shocking:6,200 Power Apps4,000 Power Automate flows900 connectorsAll inside a single Default Environment. Apps owned by employees who left years ago. Automations triggering business processes with no monitoring. Sensitive data moving through integrations nobody documented. This wasn’t a breach. It wasn’t rogue developers. It was the natural outcome of treating a development platform like a productivity tool. In this episode, we unpack why Power Platform governance fails in most organizations—and how to fix it before sprawl becomes unmanageable. 🚨 The Cold Open: The Default Environment Discovery A large enterprise audit revealed thousands of apps and flows living inside the Default Environment—a space intended only for experimentation. Instead, it had become a shadow application platform:Apps owned by employees who left years agoBusiness-critical flows with no monitoringUndocumented integrations moving data between systemsNo lifecycle management or ownershipThis wasn’t malicious behavior. It was architecture without governance. 📈 Why Low-Code Adoption Exploded Ten years ago, IT organizations faced an impossible backlog. Project queues stretched 12–18 months. Developer talent was scarce and expensive. Business units needed solutions faster than IT could deliver them. Low-code platforms promised a solution:Apps built in weeks instead of monthsDrag-and-drop developmentCitizen developers solving business problems directlyExecutives loved the narrative:Faster deliveryLower costReduced IT backlogBy 2026, analysts estimate citizen developers will outnumber professional developers four to one. But there was a critical misunderstanding. Low-code didn’t remove governance. It distributed it across the entire organization. 🧠 The Architectural Misunderstanding Most organizations treat Power Platform like a productivity tool. Like Excel. Like SharePoint. Something users can experiment with freely. But that assumption is wrong. Power Platform is actually a distributed development platform embedded inside Microsoft 365. It includes:A runtimeA data platformAutomation enginesExternal system integrationsApplication logicWhat it doesn’t include:Required code reviewMandatory deployment pipelinesStatic analysisVersion control enforcementArchitecture validationWhich means every citizen developer is effectively doing software engineering work. Without the engineering discipline. 💥 The Default Environment Disaster Every Microsoft 365 tenant includes a Default Environment. Its intended purpose:ExperimentationLearningPersonal productivity appsIts real-world use:Production workflowsDepartment applicationsCritical integrationsTenant audits consistently show: 70–80% of Power Platform assets exist in the Default Environment. The result is predictable:Thousands of appsThousands of flowsNo ownershipNo lifecycle managementNo architecture oversightThe Default Environment isn’t the problem. It’s the symptom of missing platform governance. 🔌 The Connector Governance Gap Power Platform connectors allow apps and flows to integrate with external systems. Examples:SharePointDynamicsSQL databasesDropboxGoogle DriveExternal APIsHere’s the issue: Connector approvals are tenant-wide, not application-specific. If a connector is approved, every app and flow can use it. That creates serious data risk. In one financial services organization, auditors discovered flows moving confidential SharePoint data into personal Dropbox accounts. The platform allowed it. No alert triggered. No policy violation occurred. Because connectors were approved globally. Without proper Data Loss Prevention (DLP) policies, data leakage becomes inevitable. ⚙️ The Flow Explosion Problem Power Automate flows are incredibly easy to build. A user can create an automation pipeline in minutes. At enterprise scale, this leads to automation sprawl. One retail organization discovered: 11,000 Power Automate flows Running continuously across their systems. Consequences included:API throttlingPerformance degradationLicensing spikesInvisible operational dependenciesMost flows had:No ownerNo documentationNo lifecycle policyAutomation became hidden operational debt. 💸 The Licensing Surprise Power Platform licensing scales with usage. Costs grow through:Dataverse storagePremium connectorsAPI callsAdditional environmentsOrganizations often discover the cost only when the bill arrives. One multinational enterprise saw $2 million in unexpected licensing costs within two years. Why? Because they couldn’t answer basic questions:Which apps deliver value?Which flows are critical?Which environments are abandoned?Without lifecycle management, companies end up paying for unused assets. 🧟 The Zombie App Problem Tenant audits consistently reveal a troubling pattern: 30–50% of apps show zero usage after creation. These zombie applications still:Access live dataRetain permissionsConsume resourcesIncrease attack surfacePower Platform does not enforce automatic retirement. Apps remain indefinitely unless man Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support. If this clashes with how you’ve seen it play out, I’m always curious. I use LinkedIn for the back-and-forth.

    1h 30m
  8. The Future of Microsoft ISPs Is Not Technical

    MAR 11

    The Future of Microsoft ISPs Is Not Technical

    If your Microsoft practice still differentiates itself through deployment expertise, you are competing in a market that no longer exists. Technical excellence used to create a moat. Today it is simply expected. Over the next 18 months, Microsoft partners who rely on implementation services will face increasing pricing pressure, rising customer acquisition costs, and shrinking margins. The very thing many partners built their businesses on—technical capability—has become a baseline assumption. This episode explores a fundamental shift happening inside the Microsoft ecosystem: The market is moving from technical implementation to economic stewardship. Why Microsoft Partner Economics Are Changing Several structural forces are reshaping the partner ecosystem simultaneously. CSP Margin Compression Microsoft announced changes to the partner model years ago, but the impact is landing now. By January 2026, large Enterprise Agreements will transition directly to Microsoft. This represents a $2.5B commission wipeout across the partner ecosystem. Many partners built their businesses on licensing margins and renewals. The problem is simple: When your strategy depends on someone else’s pricing structure, you don’t have a strategy—you have exposure. Automation Is Commoditizing Implementation Microsoft’s own tools are standardizing the work partners used to charge for. Examples include: • Autopilot simplifying endpoint onboarding • Lighthouse automating tenant health checks • Copilot embedding AI directly into workflows • Native diagnostics reducing troubleshooting work As these capabilities improve, the skill gap between partners and internal IT teams continues to shrink. Customers increasingly ask one question: “Why should we pay extra for something that’s becoming automated?” Certification No Longer Differentiates For years, partners competed through certifications. Solutions Partner badges Security specializations AI Cloud Partner designations These credentials demonstrate competence. But competence is now table stakes. Customers assume partners can deploy the technology. They don’t pay a premium for it. The Core Economic Tension Most Microsoft partner businesses rely on episodic revenue. Examples include: • migrations • tenant configuration • security deployments • endpoint rollouts These projects follow a simple pattern: You deploy the solution. You invoice the project. The engagement ends. Revenue stops. Growth depends on constant deal velocity. The Alternative: Structural Revenue Economic advisory operates very differently. Instead of implementing technology and leaving, partners become operators of the tenant environment. Responsibilities include: • license optimization • governance architecture • cost-to-value measurement • entitlement reviews • Copilot adoption oversight • quarterly optimization cycles This creates repeatable revenue that compounds over time. Customers depend on the clarity you provide. The Commoditization Curve Every technology market follows the same pattern. 1️⃣ Complexity Emerges New technology requires specialized expertise. 2️⃣ Specialists Dominate Experts command premium pricing. 3️⃣ Standardization Occurs Best practices and frameworks appear. 4️⃣ Automation Follows Tools reduce manual complexity. 5️⃣ Commoditization Arrives Price competition replaces expertise. Microsoft implementation services are now in stage five. Value has migrated upstream. The Three Microsoft Partner Models That Are Dying Most partners today operate within one of three legacy models. 1. The License Reseller Revenue model: Buy licenses cheaper Sell them higher Manage renewals The flaw is structural. You depend entirely on Microsoft’s pricing structure. When Microsoft changes the rules, your margins disappear. You also have no switching cost with customers. They can buy licenses anywhere. 2. The Migration Factory Migration factories grew rapidly during the cloud adoption wave. They built teams focused on: • Azure migrations • infrastructure modernization • tenant transitions But migration is finite work. Cloud adoption has entered its mature phase. The remaining projects are smaller and more competitive. Margins continue to compress. 3. The Feature-Driven MSP Feature-driven partners build their strategy around Microsoft’s roadmap. New feature → new webinar → new deployment project. The flaw is simple: Customers don’t buy features. They buy outcomes. Turning on Copilot does not create business value unless workflows actually change. Why Technical Excellence No Longer Differentiates Customers assume partners can deploy: • Defender • Conditional Access • Azure migrations • Endpoint management Technical competence is no longer rare. But customers lack something far more valuable: Economic visibility. They cannot answer questions like: • Are we actually using the E5 capabilities we pay for? • Which licenses are underutilized? • Which security tools overlap? • Is Copilot actually saving time? That gap creates a massive opportunity. The Microsoft Economic Steward The next generation partner is not an implementer. It is a tenant operator. An Economic Steward focuses on three core responsibilities. 1. Economic Telemetry Understanding the relationship between technology spend and business outcomes. Examples include: • E5 capability utilization • identity lifecycle waste • license optimization opportunities • cost-per-outcome analysis This transforms technical data into financial insight. 2. Architectural Stewardship Partners design governance frameworks that prevent operational drift. Key areas include: • identity lifecycle management • permission entropy reduction • governance operating models • information architecture alignment Governance becomes a retainer service rather than a one-time project. 3. AI Value Governance Copilot adoption must connect to measurable outcomes. Partners evaluate: • workflow compression • decision latency reduction • productivity improvements • cost-per-user ROI AI governance ensures technology investments produce real value. The Tenant Stewardship Model Combining these three pillars creates a new operating model. Instead of delivering projects, partners operate the tenant continuously. This includes: • quarterly economic reviews • governance audits • telemetry dashboards • ongoing optimization cycles The partner becomes embedded in the customer’s operations. The Structural Reality The partner economy is dividing into two categories. Commodity Deployers Partners who sell implementation services. Characteristics: • price-driven competition • lower margins • high pipeline pressure • higher customer churn Economic Stewards Partners who own economic outcomes. Characteristics: • high retention • pricing power • strategic influence • recurring revenue This shift has nothing to do with company size. It is purely an operating model difference. What Microsoft Partners Must Do Now To remain viable beyond 2026, partners must: 1️⃣ Audit their current business model 2️⃣ Reduce reliance on commoditized services 3️⃣ Build economic telemetry capabilities 4️⃣ Offer architectural governance services 5️⃣ Develop AI value governance frameworks 6️⃣ Shift sales conversations from features to outcomes 7️⃣ Move from projects to retainer relationships This transition moves partners from delivery vendors to strategic operators. The Competitive Advantage Partners who adopt the Economic Steward model gain three major advantages. Pricing Power Customers pay for outcomes rather than delivery hours. Customer Retention Partners become operationally embedded in the organization. Strategic Influence CIOs and CFOs rely on them for economic visibility. This creates a defensible moat competitors cannot easily replace. Final Thought Technical excellence built the Microsoft partner ecosystem. But today it is simply the entry requirement. The future Microsoft partner is defined by three capabilities: • architectural governance • financi Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support. If this clashes with how you’ve seen it play out, I’m always curious. I use LinkedIn for the back-and-forth.

    49 min
See All (501)

Ratings & Reviews

5
out of 5
3 Ratings

About

Welcome to the M365.FM — your essential podcast for everything Microsoft 365, Azure, and beyond. Join us as we explore the latest developments across Power BI, Power Platform, Microsoft Teams, Viva, Fabric, Purview, Security, and the entire Microsoft ecosystem. Each episode delivers expert insights, real-world use cases, best practices, and interviews with industry leaders to help you stay ahead in the fast-moving world of cloud, collaboration, and data innovation. Whether you're an IT professional, business leader, developer, or data enthusiast, the M365.FM brings the knowledge, trends, and strategies you need to thrive in the modern digital workplace. Tune in, level up, and make the most of everything Microsoft has to offer. M365.FM is part of the M365-Show Network. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support.

Information

You Might Also Like