BONUS: When Burnout Looks Like Productivity—The Hidden Risk to Your Team's Innovation Capacity

In this BONUS episode, Alison Campbell shares the research that reframes burnout as a measurable threat to a team's ability to innovate. We learn why your most productive people may be your biggest innovation risk, how to spot capacity draining out of a team before the output drops, and where Scrum Masters have the leverage to protect the one thing that keeps teams building: the space to think.

From the ER to the Research

"I kept normalizing the stress, the exhaustion, eventually the stomach aches as, well, this is just the price of entry. This is part of being a busy, full-time executive and working mom."

Alison spent nearly twenty years in corporate roles—moving from finance to e-commerce to HR tech, with analytics as the through line and a love for the building phase inside companies. The pandemic was the turning point. With two young kids at home and a global team to hold together, she pushed through eighteen months of warning signs she had normalized, until severe stomach pain landed her in the emergency room needing surgery. That was the stop moment. What started as private shame—the feeling that she alone had failed while everyone else "had it all figured out"—became a research question the moment she started talking about it and heard the same story mirrored back from colleague after colleague. This wasn't one exhausted mom at a hard moment. It was a design and systems problem worth studying.

When Burnout Looks Like Productivity

"Even when that innovative work behavior was high, when burnout was high, that segment of our sample had the lowest innovation capacity of the entire group we surveyed."

The counterintuitive finding at the center of the research: activity, busyness, and visible output stayed high even when burnout was high. Burnout doesn't always look like withdrawal, disengagement, or someone who has already collapsed. Often it looks like the person still shipping, still moving fast, still showing up to every meeting—while the deeper capacity underneath quietly erodes. Alison's study measured this through two separate constructs, and the gap between them is the whole point:

• Innovative work behaviors — the visible signs of innovation: coming to meetings, generating creative ideas, being present and active.

• Innovation capacity — the cognitive and strategic bandwidth to hold complexity, make hard decisions, collaborate well over time, and translate ideas into durable, long-term company value.

The people scoring high on visible activity while burned out were exactly the people whose capacity to do the deep work had already dropped the lowest.

What Innovation Capacity Actually Is

"Not just, am I coming to the meetings, am I visibly showing up—but do I have the ability to translate these ideas into durable, long-term company value?"

This isn't only about product features or new products. Innovation capacity shows up in every layer of the work: the micro decisions, the macro strategy, the processes, the willingness to try a new tool or approach at all. Innovation capacity is present when people have the mental space to be curious, to ask questions, to explore, to want to play with something new. When that space disappears—when the answer to every new idea is "we don't want to hear no, we don't want to hear that there's a problem"—the work turns tactical and reactive. People narrow their thinking and just chip away. That's the moment you stop getting the best from your team, even though they look every bit as busy as before.

The Signals to Watch For

"Can I name what is blocking progress? Do I feel safe enough to say, this is what's at risk? Or is this a culture where we don't talk about what's not going according to plan, and we just keep our heads down and keep going?"

The conditions most strongly correlated with high burnout and low innovation capacity clustered around a few themes: uncertainty—especially about the role of AI in someone's work—unclear meeting outcomes where a lot of meetings produce little clarity on the next action, and a general cluster of fear and ambiguity. The fix isn't to make everything finite and remove all agility—that's the wrong message in a genuinely uncertain world. It's to provide bounds. Communicate clearly about what you do know and why, so teams can operate confidently even through an uncertain pivot. For Scrum Masters, this maps directly onto AI adoption conversations: when curiosity turns into anger, frustration, or blanket anti-AI resistance, that's a signal worth investigating. Get at the why—both by taking a genuine pulse on the team, and by making sure the team understands the bigger-picture why the whole company is driving toward. As Alison put it, strip it all down and you land on good communication and psychological safety: the conditions where people can name what's blocking them and still do their best work.

Fragmented Work and the Myth of the Finished List

"It's about baking in periods of rest and reset, and being comfortable with this notion that the list is quite literally never going to be done."

Fragmented work—context switching, too many things in flight, the sprawl of tools and issue trackers—came up as a real innovation-capacity killer, and it's something agile teams can actually measure. The study asked about context switching, interruptions, and how many channels people move between; a deeper follow-up study is now underway focused specifically on AI-driven uncertainty and tool-switching. Alison's guidance isn't "do less and stop switching," because that reality isn't going away. It's to design rhythm into the work: periods of sprint followed by a deliberate pull-back—reflective work, postmortems, space to talk about what didn't go to plan. She didn't put a number on the right ratio of recovery to sprint; it's contextual to the industry, the stage of the business, the size of the team. The leadership move is to look at the actual rhythm of the business, and to proactively plan and openly name the recovery after a big push—instead of treating "recovery" like a bad word.

Why Managers Are at Higher Risk

"Managers were 1.7 times more likely to experience high burnout—and about three times more likely to say, yes, I delay complex problems or hard decisions."

When the data was split between managers and individual contributors, the extra management layer showed up as a measurable source of additional pressure. Managers reported high burnout at 1.7 times the rate of individual contributors, and were roughly three times as likely to strongly agree with the statement "I delay complex problems or hard decisions"—a direct marker of eroded innovation capacity. There's more to unpack there, and a second paper is coming in September that adds caregiving as a third dimension, building toward a "responsibility index" that looks at how obligations outside of work—an aging or sick family member, for example—compound the burnout picture. For a Scrum Master, the takeaway is that the pressures draining a team's capacity are often invisible from the outside, and they land hardest on the people carrying the most responsibility.

One Thing to Start Tomorrow

"Not another meeting—but a reflective question first. Rate your energy, rate your stress, and look at where your time actually got spent versus the goals you had."

Alison's concrete recommendation for anyone who suspects something is off: start a weekly check-in. First an individual reflection—rate your energy and stress for the week, and compare where your time actually went against the goals you set. Then bring that same question into a Friday stand-up or retrospective and ask the team to weigh in: what was the team's stress and energy, and were there major constraints nobody saw coming? The first few weeks people may be hesitant to answer honestly. But keep the practice going week over week, and you build a real data set on how the team is actually feeling—and start surfacing the systemic blockers getting in the way of good work.

About Alison Campbell

Alison Campbell is the founder and CEO of unBurnt® and Executive in Residence at Bentley University's Center for Health and Business. Her 2026 research — "When Burnout Looks Like Productivity: The New Risk to Innovation Capacity" — surveyed 544 professionals across 17 industries and reframes burnout as a measurable threat to an organization's capacity to innovate. unBurnt® · Research · LinkedIn

You can link with Alison Campbell on LinkedIn and read her research at getunburnt.com.

Coding where context lives and collaboration happens

The best prompt may be the conversation your team has already had or is currently having. Until now, using a coding agent often meant paying context and coordination taxes. Developers had to leave the discussion, open another tool, and reconstruct the problem in a lengthy prompt: what happened, what the team decided, which constraints matter, and what needs to be built.

With GitHub Copilot in Teams, teams can move directly from conversation to action. @mention GitHub Copilot when the team is ready to act, and it can use the conversation alongside repository context to understand the request, implement the change, and create a pull request for review.

This makes working with a coding agent more collaborative and visible. Instead of one developer privately reconstructing the request, teammates can contribute context, correct assumptions, refine the approach in real time, and review the resulting work together.

Let’s explore the new GitHub Copilot in Teams experience to see how it can streamline development tasks:

GitHub Copilot in Teams is available in Teams channels, group chats, meeting chats, and 1:1 chats.

Once the GitHub app is installed and added to the conversation, @-mention GitHub Copilot to bring it into the discussion and start a task. During public preview, users can complete the following scenarios with GitHub Copilot in Teams:

• Build a feature based on requirements discussed in Teams
• Implement a fix for a bug
• Expand test coverage or improve documentation
• Create and update a pull request

No copying the discussion into a CLI. No rewriting it in a desktop app. No asking one developer to translate a team decision into the perfect prompt. GitHub Copilot works where the context already lives, and because that context is shared, working with GitHub Copilot becomes a team activity.

Built around the controls teams already use

GitHub Copilot in Teams works within existing GitHub permissions and repository policies. Branch protections and required reviews continue to apply, and people remain responsible for deciding what gets merged, ensuring that humans stay in the loop at every step.

Availability

GitHub Copilot in Teams is now available in Public Preview. To try it, install the GitHub app for Microsoft Teams and check out our documentation to get started!

Less context reconstruction. More progress from the conversations already happening.

Across Microsoft, "hill climbing" has become shorthand for how real AI progress happens: not in one dramatic leap, but through a disciplined loop. Microsoft AI defines the hill climb as an organization that continuously improves, cycle after cycle, through more compute, better data, and sharper evaluation. Reinforcement fine-tuning in Foundry defines it as improving the deployable model package one measured step at a time across quality, latency, and cost. Different altitudes, same premise: progress is not a one-shot decision. It's a loop.

For most teams, the decision of what model to use when is made manually or with custom routing tools. A developer picks a model based on benchmarks, familiarity, or the last launch that made headlines, ships it, and revisits the choice only when something breaks. In an ecosystem where the frontier moves monthly, that decision goes stale fast. Model router in Foundry Models brings the hill climb to the selection layer.

What's new: a bigger pool, in more places

This release expands where teams can deploy model router, broaden the supported model pool, and delivers updates through a stable endpoint. Together, these changes help teams run production workloads in more locations, match a wider range of tasks to suitable models, and adopt supported updates without changing the application integration.

A refreshed model pool. The supported model list now includes Anthropic Claude Opus 4.8 — a high-capability model built for complex reasoning and long-form generation, for scenarios that demand depth, structure, and quality — and the GPT-5.6 family. Just as importantly, the pool is pruned: gpt-5-chat, gpt-5.2-chat, gpt-5.3-chat, Deepseek-V3.1 have been removed from the model router as models reach the end of their lifecycle and are deprecated in Foundry.

New region availability. The model router is now available in 28 regions for global standard and 21 data zone regions. For many organizations, inference requests must stay within specific geographic boundaries for regulatory, governance, or customer-trust reasons — and intelligent routing shouldn't force a compromise on that. Find the full list of regions here.

The most important detail is what you don't have to do: these updates occur automatically*. The endpoint remains stable as the supported model pool is refreshed, so teams do not need to redeploy the model router to receive the update. Applications can continue using the same integration while the model router evaluates requests against the current supported pool. Teams should continue monitoring routing traces and application outcomes to confirm that quality, cost, latency, and governance requirements are met.

*Models from Anthropic still need to be deployed separately before they can be routed to through the model router.

Interested in hearing more about what's new to the model router? Tune in for the next episode of Model Mondays with Sanjeev Jagtap and Lee Stott, where they talk all things model router from evaluations to hill climbing. Sign up here to watch live or view the replay: Model Mondays - Spotlight On Model router in Microsoft Foundry | Microsoft Reactor

The selection-layer hill climb

At the selection layer, a step is a routing decision. Each one is a micro-optimization against your objective, and each one is instrumented: every response from the model router includes a model field showing which underlying model was selected, so the climb leaves a complete, auditable trail.

Model router supports three parts of the optimization loop: A/B testing to compare two router configurations to understand quality, cost, and latency tradeoffs; model decomposition to use routing results to decompose a single-model application into a multi-model or multi-agent design, and continuous routing to keep the router in production for continuous per-request selection. Each pattern turns model choice into a measured, repeatable process rather than a fixed decision.

1. A/B Testing 

Question: Which model or routing strategy should I use in production?

A/B testing helps teams compare candidate models, model families, or router configurations against the same workload. Representative traffic is sent to competing deployments, and teams compare quality, cost, latency, and governance outcomes. The goal is to understand tradeoffs and identify the model or routing strategy that best meets workload requirements before promoting it to production.

2. Model Decomposition

Question: What work is my application actually doing?

Model decomposition uses model router as a diagnostic tool. By deploying the model router against a representative workload and examining routing telemetry, teams can see how requests naturally separate into different task classes. Simple retrieval, classification, and summarization requests may route to smaller models, while reasoning, planning, and agentic workflows may require more capable models. The goal is not to choose a winner, but to understand the structure of the workload and uncover opportunities for optimization, specialization, or architectural improvements.

3. Route continuously

Question: Why choose a single model at all?

Route continuously is the pattern model router was designed for but is not limited to. Rather than treating model selection as a one-time decision, teams leave the model router in production and allow the best-fit model to be selected for each request. As the supported model pool, regional availability, and platform capabilities evolve, teams can continue using the same endpoint while evaluating whether updates improve workload outcomes. Model selection becomes an ongoing optimization process rather than a project that must be repeated every time the model landscape changes.

Together, these patterns illustrate a broader shift: the model router is more than a model. It is a tool for the optimization loop itself, helping teams evaluate tradeoffs, understand workload behavior, test hypotheses, and continuously refine model selection as requirements evolve. Whether used to compare candidate models, decompose applications into specialized tasks, or automate per-request routing in production, model router turns model selection into an observable, measurable, and repeatable process. As the model landscape continues to change, that optimization loop becomes a durable advantage.

Getting Started

Ready to start your own hill climb? Whether you're exploring the model router for the first time, evaluating routing strategies against your workload, or building a long-term optimization practice, these resources can help you move from experimentation to production with Microsoft Foundry.

• What's new in model router?
  Sign up for the next Model Mondays episode for a deep dive into new features, optimization patterns, and the latest model router updates. 
• How do I build agents with model router?
  Check out the Model Router Agents Lab and build agent experiences with routing, retrieval, web search, tool calling, and multi-agent patterns. 
• How do I evaluate model router?
  Compare model router against baseline models using your own prompts, then review quality, cost, latency, and routing decisions with the Auto Evaluation Toolkit. 
• How do I optimize model router for my workload?
  Start your hill-climbing journey with the Model Mastery workshop, where you'll test one optimization lever at a time and measure how each change impacts workload outcomes.
• How do I build a model router optimization playbook?
  Explore the Model Releases repository to track new capabilities, understand the optimization question behind each release, and try focused notebooks that demonstrate one optimization lever at a time. 

If you use AI coding assistants—whether it is Claude Code, Google Antigravity, OpenAI Codex, GitHub Copilot, Cursor, or Cline—you have likely experienced the Training Cutoff Frustration in Dart and Flutter.

Dart moves fast. Over the last few years, we have seen:

• Dart 2.12: Sound Null Safety (?, late, !, required).
• Dart 2.17: Super-parameters (super.key) and enhanced enums.
• Dart 3.0: Records, pattern matching, switch expressions, and sealed classes (while permanently dropping non-null-safe mode).
• Dart 3.12–3.13+: Private named parameters, constructor shorthands, and primary constructors (class Point(var int x, var int y);).

Because pre-training datasets naturally lag behind the bleeding edge, vanilla LLMs frequently:

1. Reject modern Dart 3.13 syntax as "syntax errors".
2. Write 15 lines of repetitive constructor and equality boilerplate where modern primary constructors belong.
3. Mess up the environment.sdk lower bound (minSdk) in pubspec.yaml.
4. Struggle to rescue pre-2.12 legacy apps because they don't know the exact milestone sequence to cross the null-safety divide.

To solve this once and for all, I extracted and open-sourced dart-sdk-skills.

🎯 What is dart-sdk-skills?

dart-sdk-skills is an authoritative, version-by-version skill package designed specifically for AI coding agents.

Rather than dumping thousands of lines into your prompt on every turn, it uses progressive disclosure:

• The agent holds a compact, fast Feature Matrix covering every version from Dart 1.0 to 3.14.
• When an agent is asked "What's new in Dart 3.13?", "What minSdk do I need for private named parameters?", or "Help me modernize this legacy Flutter app", it dynamically reads the exact changelog reference guide on demand.

🛠️ Two Massive Use Cases

1. Modern Greenfield & Bleeding-Edge Dart 3.13+

Instead of fighting the LLM over modern language ergonomics, your agent immediately knows:

• Primary constructors & this : assert(...) bodies.
• Wildcard variables (_) and digit separators (1_000_000).
• Exact minSdk verification so your pubspec.yaml never breaks CI.

2. Rescuing Legacy Codebases (Dart 1.x & Pre-2.12)

Because Dart 3 completely disallows running without sound null safety, rescuing older codebases requires a strict 4-stage pipeline:

1. Dart 1.x ➔ 2.0: Drop obsolete new keywords and enforce sound static typing.
2. Pre-2.12 ➔ 2.12: Transform @required annotations, uninitialized nullable fields, and defensive runtime assertions.
3. pubspec.yaml: Bump environment lower bound to ^3.5.0 or ^3.13.0 and replace deprecated packages (pedantic, tuple).
4. Dart 3 Modernization: Adopt super-initializers, sealed classes, and pattern matching.

📦 How to Install (One Command)

You can install dart-sdk-skills globally across all your projects in seconds using any skill package manager:

Using npx skills (Universal / Node):

npx skills add RandalSchwartz/dart-sdk-skills -g

Using the Dart skills CLI:

skills add https://github.com/RandalSchwartz/dart-sdk-skills --global --all

Once installed, your agent is automatically equipped with the entire Dart SDK knowledge base.

Check out the full repository on GitHub:
👉 https://github.com/RandalSchwartz/dart-sdk-skills