GitHub’s CEO publicly defended a controversial internal Microsoft memo that urged managers to factor employees’ use of Copilot‑style tools into performance reflections, calling the guidance “totally fair game” and reframing the conversation as learning and mindset rather than blunt surveillance or raw output quotas.
In mid‑2025 an internal Microsoft note circulated among managers that said, in essence, “AI is now a fundamental part of how we work” and suggested managers include employees’ engagement with company AI tools — notably GitHub Copilot, Microsoft Copilot, and Teams Copilot — as part of “holistic reflections” on performance. The memo, attributed to Julia Liuson, pushed teams to accelerate internal adoption of AI tools for product feedback and practical familiarity.
On the August 7 episode of the Decoder podcast, GitHub CEO Thomas Dohmke publicly responded. Rather than rejecting the memo, he described its intent as nuanced and defended the principle that managers may reasonably ask employees to reflect on how they used AI and what they learned — a stance he summarized as “totally fair game.” He clarified that such reflections should not be reduced to gamable metrics (for example, counting lines of AI‑generated code) but should focus on demonstrated learning and outcomes.
The conversation landed against a broader backdrop: Microsoft’s aggressive company‑wide push to embed Copilot across products and teams, pressure to show internal adoption for products the company sells, and a wave of workforce restructuring in 2025 that has left employees especially sensitive to any signals tying new skills to job security.
That strategy also lines up with a simple business incentive: embedding Copilot across Microsoft teams strengthens the narrative that Copilot is mission‑critical and worth enterprise spend. When employees become product evangelists, the company benefits from better metrics, case studies, and organic product advocacy. The memo is as much about commercial alignment as it is about capability building.
Practically, Dohmke’s comments signal that leaders at Copilot’s parent organization view tool adoption as both cultural alignment and product stewardship. But the statement also exposes the tension of being a product owner inside a company: GitHub must both serve external developer trust and align with Microsoft’s internal adoption goals — goals that can look like pressure to some employees.
If properly designed, making AI fluency part of development and performance conversations can accelerate capability building, product quality, and developer productivity — benefits that are supported by rigorous studies. (github.blog, arxiv.org)
If handled poorly, however, the move risks producing a culture of surveillance, gamed metrics, and inadvertent legal exposures. The difference will depend on implementation detail: whether managers use AI metrics to coach rather than to punish, whether organizations invest in training and guardrails, and whether employees retain meaningful voice and transparency in how they are evaluated. The outcome of this experiment will shape workplace norms for AI across the industry — and it will be judged as much by employee trust as by any productivity statistic.
Source: AOL.com GitHub CEO says Microsoft's memo about evaluating AI use is 'totally fair game'
Background
In mid‑2025 an internal Microsoft note circulated among managers that said, in essence, “AI is now a fundamental part of how we work” and suggested managers include employees’ engagement with company AI tools — notably GitHub Copilot, Microsoft Copilot, and Teams Copilot — as part of “holistic reflections” on performance. The memo, attributed to Julia Liuson, pushed teams to accelerate internal adoption of AI tools for product feedback and practical familiarity.On the August 7 episode of the Decoder podcast, GitHub CEO Thomas Dohmke publicly responded. Rather than rejecting the memo, he described its intent as nuanced and defended the principle that managers may reasonably ask employees to reflect on how they used AI and what they learned — a stance he summarized as “totally fair game.” He clarified that such reflections should not be reduced to gamable metrics (for example, counting lines of AI‑generated code) but should focus on demonstrated learning and outcomes.
The conversation landed against a broader backdrop: Microsoft’s aggressive company‑wide push to embed Copilot across products and teams, pressure to show internal adoption for products the company sells, and a wave of workforce restructuring in 2025 that has left employees especially sensitive to any signals tying new skills to job security.
What the Microsoft memo actually said — and what managers heard
The memo’s core line
The memo’s most publicized line — that “using AI is no longer optional” and that AI fluency is comparable to collaboration or data‑driven thinking — has been cited across multiple outlets and internal summaries. That language functions as both a strategic signal and a practical expectation: if your company’s products and roadmaps depend on AI, the argument goes, employees must know how to use those tools to contribute effectively.The nuance managers were asked to apply
According to leadership commentary, managers were encouraged to treat AI usage as part of reflective performance conversations — asking, for example, “Did you use Copilot to summarize a meeting? If not, why not? What did you learn?” — rather than enforcing a usage quota. In practice, though, that advice is fragile: the line between “reflective conversation” and “metrics to check” can blur if teams lack training, governance, and HR guidance.Where the disconnect appears
Critics flagged three predictable translation problems:- Tactical managers under performance pressure often default to measurable proxies (counts, sessions, token usage).
- Employees perceive any requirement tied to tools as coercive or a pretext for surveillance.
- Without robust guardrails (security configs, allowed models, IP protections), internal adoption can increase operational risk.
Why Microsoft wants this — product, feedback loops, and corporate strategy
Microsoft’s push is driven by a tight, product‑level feedback loop: more internal usage yields faster, higher‑quality feedback on Copilot integrations; more employee usage can help demonstrate product value to customers and accelerate product improvements. GitHub, which operates Copilot, is central to that insertion. GitHub leadership, including Dohmke, has argued publicly that internal dogfooding is a legitimate way to discover real world issues and accelerate improvement.That strategy also lines up with a simple business incentive: embedding Copilot across Microsoft teams strengthens the narrative that Copilot is mission‑critical and worth enterprise spend. When employees become product evangelists, the company benefits from better metrics, case studies, and organic product advocacy. The memo is as much about commercial alignment as it is about capability building.
What Dohmke said — context, quote, and implications
Thomas Dohmke framed the issue as a cultural expectation. He argued that GitHub employees must use GitHub and that reflecting on AI usage is part of modern professional practice: it’s a growth‑oriented conversation about what was learned, how tools were applied, and where training is needed. He explicitly warned against simplistic metrics like counting lines of AI‑generated code, calling such measures “easily gamed.” His stance reframes the memo as an invitation to learning rather than explicit surveillance.Practically, Dohmke’s comments signal that leaders at Copilot’s parent organization view tool adoption as both cultural alignment and product stewardship. But the statement also exposes the tension of being a product owner inside a company: GitHub must both serve external developer trust and align with Microsoft’s internal adoption goals — goals that can look like pressure to some employees.
Evidence on Copilot’s productivity and why it matters here
A central argument for encouraging Copilot adoption is productivity. GitHub’s own research and peer‑reviewed studies find meaningful gains:- GitHub research and its controlled trials report improvements such as developers coding up to 55% faster in experimental tasks and better code quality metrics, with higher pass rates on unit tests and improved readability and maintainability. (github.blog)
- Independent academic work has replicated similar magnitudes in controlled settings: a randomized experiment found participants completed a coding task ≈55.8% faster with an AI pair programmer. (arxiv.org)
The real risks — surveillance, measurement, IP, and inequity
1) Perception of surveillance and psychological safety
Asking about tool usage during reviews creates a perception risk. Even framed as “learning,” employees often instinctively view monitoring as a signal about job insecurity or impending automation. This risks eroding trust and damaging team morale, especially in an environment that has recently seen layoffs. The memo’s timing matters.2) Gamable metrics and perverse incentives
Raw counters — lines of code generated by Copilot, number of Copilot sessions, or tokens consumed — are trivially gamable. If managers use these as proxies for performance, teams will optimize metrics rather than outcomes, leading to lower quality, rushed reviews, and possibly bypassing safety steps. Dohmke explicitly discouraged such measurement choices.3) Privacy, IP leakage, and compliance exposure
Copilot‑style tools can surface proprietary code, secrets, or private data if used without proper guardrails. Mandating usage before proper configuration and training can increase the chance of accidental leakage, licensing conflicts, or regulatory compliance violations. Enterprises must pair any performance expectation with strict tooling policies and technical configurations that prevent sensitive data from being sent to unapproved models.4) Equity and accommodation
AI fluency is not uniformly distributed. Tying reviews to AI competency without offering training and reasonable timelines disadvantages nontechnical staff or those requiring accommodations, risking disparate impact. Employers should avoid creating implicit barriers to advancement.5) Legal and labor implications
When usage becomes evaluative, it can trigger labor law considerations — from reasonable accommodation to discrimination claims — and may affect collective bargaining in unionized environments. Performance criteria must be defensible, transparent, and consistent with employment law.How to make “AI use in reviews” fair, practical, and defensible
Organizations that choose to include AI usage in performance conversations should design the program carefully. The following is a practical playbook for managers and HR teams.- Define the competency, not the raw number.
- Describe what proficiency looks like (example: “uses Copilot to prototype and document code, verifies and tests generated code, and documents changes”).
- Prioritize outcomes over activity.
- Evaluate whether the work delivered met quality, security, and timeliness goals, and whether AI was used responsibly to aid those outcomes.
- Build mandatory, role‑appropriate training and time.
- Require training sessions and allow ramp time; don’t penalize employees before they’ve been given the tools and time to learn.
- Set strict data governance rules and approved tool configurations.
- Provide enterprise‑grade guardrails: private tenant models, disabled telemetry where necessary, and clear instructions on what not to paste into an assistant.
- Use human review and appeals.
- Ensure human oversight on any evaluative decisions tied to AI use and provide an appeal route for employees who feel evaluated unfairly.
- Monitor for disparate impacts.
- Collect anonymized metrics on the policy’s effect across demographics and adjust if gaps appear.
- Communicate transparently.
- Publish the rationale, the evaluation rubric, and examples of acceptable evidence of learning (logs of experiments, annotated outputs, test results).
For developers and individual contributors: how to protect yourself
- Keep concise documentation of AI experiments: prompts used, outputs, edits made, and validation steps. This turns vague questions into demonstrable evidence of learning and responsible usage.
- Adhere strictly to approved tool configurations and consult security/legal if unsure before sharing sensitive code.
- Request training and explicit success criteria before being assessed on AI use.
- If evaluation metrics feel opaque or gamed, raise the issue through HR or employee representation channels.
Strategic implications for GitHub, Microsoft, and the developer ecosystem
- For Microsoft, encouraging internal Copilot use helps iterate and sell the product, but it also heightens scrutiny about whether platform owners can remain impartial stewards of open‑source communities when product incentives align with internal adoption. Dohmke’s public defense attempts to balance those tensions, but the optics are difficult.
- For GitHub, the message that “everyone at GitHub uses GitHub” is both logical and fraught. On one hand, internal dogfooding is best practice; on the other, mandating internal product use raises trust questions among an ecosystem that often values neutrality and openness.
- For the broader developer community, this episode is a test case in how large platform providers will socialize rapid tool adoption without undermining developer goodwill. If Microsoft and GitHub manage the rollout with good governance, transparent metrics, and training, the payoff could be real productivity gains. If they don’t, the backlash could deepen developer distrust. (github.blog)
Critical assessment — strengths and red lines
Notable strengths
- Evidence‑backed productivity gains: Multiple studies, including GitHub’s own research and independent academic work, show substantial productivity improvements with Copilot in controlled settings — effects that justify promoting adoption. (github.blog, arxiv.org)
- Product feedback loop: Internal adoption accelerates product maturity through everyday feedback, bug reports, and feature discovery.
- Alignment with modern skills: Making AI literacy a recognized competency helps organizations retool for a future where AI‑augmented workflows are ubiquitous.
Red lines and risks
- Quantitative, gamable KPIs: Counting sessions, lines, or tokens should be avoided; such measures distort behavior.
- Lack of training or governance: Mandating usage before providing time, training, and technical guardrails invites errors and legal exposures.
- Opacity and punitive implementation: If employees experience the policy as punitive rather than developmental, trust will erode quickly — with downstream costs in retention and recruitment.
What to watch next
- Will teams translate “holistic reflection” into concrete scorecards, or will HR issue firm guidance restricting quantitative measures?
- How will Microsoft and GitHub align product incentives with external trust signals (open‑source neutrality, privacy)?
- Will regulators or labor bodies scrutinize performance criteria tied to AI usage for fairness or privacy implications?
- Will other large employers follow Microsoft’s lead — and if so, will best practices consolidate into industry norms?
Conclusion
The debate sparked by the Microsoft memo and Thomas Dohmke’s “totally fair game” remark is more than a corporate squabble; it’s a frontline case in how organizations reconcile product incentives, workforce development, and employee rights in an AI‑first era. The strongest defensible approach is not coercion but structured learning: clear competency definitions, transparent rubrics, role‑appropriate training, robust data governance, and human oversight.If properly designed, making AI fluency part of development and performance conversations can accelerate capability building, product quality, and developer productivity — benefits that are supported by rigorous studies. (github.blog, arxiv.org)
If handled poorly, however, the move risks producing a culture of surveillance, gamed metrics, and inadvertent legal exposures. The difference will depend on implementation detail: whether managers use AI metrics to coach rather than to punish, whether organizations invest in training and guardrails, and whether employees retain meaningful voice and transparency in how they are evaluated. The outcome of this experiment will shape workplace norms for AI across the industry — and it will be judged as much by employee trust as by any productivity statistic.
Source: AOL.com GitHub CEO says Microsoft's memo about evaluating AI use is 'totally fair game'
