A healthy dashboard can still hide a frustrating service. This November 8, 2026 listening brief examines hidden friction for enterprise application and IT leaders: work people cannot show you, dependencies a migration must preserve, and problems nobody wants to raise. Four newly published episodes offer different ways to find that friction; the practical goal is to improve one user journey without turning discovery into indiscriminate data collection.
- Theme: find the friction your dashboard cannot explain.
- Pair a user conversation with a task-level signal, not another aggregate score.
- Respect confidentiality; improve visibility without collecting sensitive work.
This week’s theme: hidden friction
Our recommendation: before proposing another automation, ask where a person gets stuck completing an existing task. Choose a journey small enough to observe from request to usable result. An access request, a document review, or a failed configuration change is a better starting point than “improve the employee experience.” The narrower question gives the service owner something specific to investigate and change.
There are two different questions here: did the system behave as designed, and did the person accomplish the work? They need different evidence. The Azure Well-Architected guidance recommends connecting telemetry to system and user flows and business objectives. Use that principle to test the usefulness of a dashboard: can it distinguish a completed task from a technically successful interaction that leaves the user waiting?
Imagine an application that returns a successful response while its user must chase an approval in another channel. That is a hypothetical diagnostic example, not a customer benchmark. Counting responses would answer the application question; following the approval would answer the service question. Resist the temptation to treat the first as a proxy for the second simply because it is easier to measure.
The same distinction applies to feedback. A quiet meeting is not the outcome you are trying to optimize. Ask for the last point where someone needed help, repeated information, or abandoned the approved path. The Power Platform design principles recommend learning users’ struggles through research and involving them throughout design. Our interpretation is to make discovery part of service delivery, rather than a survey sent after the implementation team has dispersed.
Visibility also has a boundary. The monitoring guidance says to separate workload data from telemetry and scrub sensitive information before logging. Do not resolve an evidence gap by copying confidential documents into a support workspace. Agree on permissible signals first: a failure category, a stage transition, or an approved synthetic example may be sufficient. For regulated teams, involve the appropriate privacy and security owners before changing collection.
Then choose a change proportional to the problem. A clearer status message, a better handoff, or removing a repeated entry may be more useful than a new agent. Microsoft’s experience guidance emphasizes reducing unnecessary steps and giving clear status and error feedback. Test whether the person can finish the task, not whether the implementation team likes the new interface.
This is not a call to postpone modernization until every complaint disappears. It is a way to choose the next increment deliberately. Our Azure diagnostic settings guide addresses the platform logging baseline; the leadership question here is what that evidence misses about the journey. Our Managed Environments guide covers platform guardrails. Keep those controls, but investigate whether users understand the safe path through them.
Episodes worth your time
These selections were published between November 2 and November 4, 2026. Descriptions below are based on official show notes or publisher transcripts, not listening impressions. Start with the legal-agent discussion for technology and the hospitality discussion for leadership; each approaches the gap between the designed service and the work people actually experience.
Latent Space: Building Legal Agents When You Can’t See the Data
Host Basil Chatha; co-host swyx; guest Jacob Lauritzen, CTO of Legora · 1:07:21 · published November 2, 2026
What it covers: The notes describe the difficulty of testing legal agents when confidential client work is not available to the engineering team. Chapters cover simulated customer environments, collaboration between legal and engineering specialists, and narrowing failures without reading the underlying work.
Why it matters for leaders: Treat confidentiality as a design requirement for discovery, not a reason to accept an untestable service. Ask your team what representative test cases it can construct safely, and what user-facing failures those cases still cannot reveal.
Listen: Listen on Spotify or read the official episode notes and chapters.
RunAs Radio: PowerShell 7.7 and DSC 3.3 with Jason Helmick
Host Richard Campbell; guest Jason Helmick, Microsoft Senior Product Manager · 36:25 · published November 4, 2026
What it covers: The official feed describes a discussion of PowerShell and Desired State Configuration, enterprise migration from Windows PowerShell 5.1, and preserving existing automation while improving security. It was recorded October 1, 2026; publication date does not establish the availability of the versions in its title.
Why it matters for leaders: A modernization plan should expose dependency pain before changing the execution environment. Ask operators which business task depends on each important script, so compatibility testing protects an outcome rather than merely proving that a command runs.
Listen: Open the RunAs Radio episode.
HBR IdeaCast: The Topics We Avoid at Work—and How to Start Talking About Them
Hosts Alison Beard and Adi Ignatius; guest Christina Wing, Harvard Business School senior lecturer · 30:40 · published November 3, 2026
What it covers: The notes cover sensitive workplace subjects, raising mistakes without defensiveness, and making room for employees to discuss ambitions. They also describe recovering when a difficult conversation goes poorly.
Why it matters for leaders: Build a discovery conversation that invites a concrete problem without demanding personal disclosure. For an IT service review, ask about unclear responsibilities or troublesome handoffs; do not turn an operational retrospective into compulsory discussion of private circumstances.
Listen: Open the HBR IdeaCast episode.
Coaching for Leaders: Lead With Unreasonable Hospitality, with Will Guidara
Host Dave Stachowiak; guest Will Guidara, former co-owner of Eleven Madison Park · 39:32 · published November 2, 2026
What it covers: The notes and publisher transcript distinguish performing a service from how the recipient experiences it. They cover mapping the customer journey, addressing persistent pain points, and giving attention to the final moments of an interaction.
Why it matters for leaders: Translate the restaurant setting into a service-desk question: does ticket closure leave the person able to work? Improve the final handoff and confirm the result, rather than borrowing hospitality language to justify unlimited concierge support.
Listen: Open Coaching for Leaders episode 807 and its transcript.
Put it to work this week
Bring one journey to your next service review. Use the checklist to produce a small, testable change proposal, not a new organization-wide measurement program. The output should name the troublesome stage, the evidence you may collect, and the result you will compare.
- In the service review, map one task from request to usable result; confirm the map with an operator and a user.
- Compare one task-level signal with that user’s account; record the point where the two disagree.
- With privacy and security owners, approve the minimum diagnostic data; verify that the example excludes confidential content.
- In the change backlog, propose one bounded fix and its owner; test that the user can finish the previously troublesome task.
For the follow-up, compare the same journey before and after the change. Look for repeated entry, extra handoffs, or a need to reopen the request. If the user still needs a workaround, revise the proposal rather than declaring success from a greener dashboard.
Find hidden friction at the level of a person’s task, then fix one constrained part of the journey. Better visibility should make the service easier to use, not make confidential work easier to collect.
Last reviewed: November 2026
Sources
Authoritative sources
- Architecture strategies for designing a monitoring system (Microsoft Learn)
- Experience Optimization design principles (Microsoft Learn)
Episodes featured
- Building Legal Agents When You Can’t See the Data (Latent Space)
- PowerShell 7.7 and DSC 3.3 with Jason Helmick (RunAs Radio) — publication and duration from the official RunAs Radio feed
- The Topics We Avoid at Work (HBR IdeaCast)
- Lead With Unreasonable Hospitality (Coaching for Leaders)
Discover more from Cloud Osprey
Subscribe to get the latest posts sent to your email.