Who is represented, and what does their working week look like?

Synthetic demo · Provisional Baseline: 10 May 2026 to 04 Jul 2026 · 8 complete weeks · Week dates use UTC convention · Locale: en-US

The baseline covers 900 developers across six teams, with all eight Person Query weeks recorded for every developer. The median developer averaged 12.9 collaboration hours, including 7.8 meeting hours, and 12.0 uninterrupted hours per week over this period.

This is a manager view of working conditions and recorded AI use. The roster contains 1,080 synthetic people, of whom 900 are developers. The 180 other job-family records are excluded by the roster flag, rather than by tool activity. Eligibility for the Person Query and eligibility for each Copilot product are separate.

Team and role composition

Team league table for workload, focus and recorded Copilot use

Sorted by collaboration hours, Platform is the busiest team at 20.7 hours/person/week. Developer Experience has the highest GitHub Copilot recorded-active share at 100.0%, Data Engineering leads M365 Copilot at 100.0%, and Mobile has the most uninterrupted time at 17.5 hours/person/week.

Ranked team view of headline metrics

Manager next step. Use the team and role composition when discussing the distribution of working hours. Agree which coordination or tooling question needs investigation before setting a target. No performance judgement or individual action is supported by these data.

How much room is there for sustained work alongside coordination?

Synthetic demo · Provisional 10 May 2026 to 04 Jul 2026 · All 900 developers · 8 complete Person Query weeks each

Platform has the highest median meeting load at 12.4 hours/person/week. Mobile has the most uninterrupted time at 17.5 hours/person/week. These are calendar-derived associations, not evidence of coding time or delivery quality.

Meeting and uninterrupted-time distributions

Calendar availability and uninterrupted time

Meeting characteristics that may warrant a conversation

Manager next step. In the next team discussion, use these distributions to ask which meetings unblock work and which interrupt it. Combine the answer with feedback on review wait times and cognitive load before testing a calendar change. Fewer meetings are not inherently better.

How is collaboration outside working hours distributed and repeated?

Synthetic demo · Provisional 10 May 2026 to 04 Jul 2026 · All 900 developers · 8 observed weeks each

Payments has the highest median after-hours collaboration at 4.1 hours/person/week. The population median is 1.7 hours, and the upper quartile begins at 3.2 hours. These describe recorded collaboration outside scheduled hours, with no wellbeing outcome available.

After-hours collaboration across teams

Persistence over the observed weeks

Manager next step. Before drawing a workload conclusion, validate work-schedule settings and seek anonymous feedback on sustainability and disconnection. Use a repeated survey alongside this distribution if the team tests a change. Do not target individual developers from these aggregates.

Where are both Copilot products used across developer work?

Synthetic demo · Provisional 10 May 2026 to 04 Jul 2026 · Same 900-developer roster · Product-specific eligibility and coverage

670 developers are eligible for both products and have complete coverage for all eight weeks. Developer Experience leads GitHub Copilot recorded-active share, while Data Engineering leads M365 Copilot recorded-active share. The other 230 developers remain visible as eligibility or coverage exceptions.

Joint footprint with coverage exceptions retained

Product-specific frequency, intensity and concentration

The concentration row is the share of GitHub suggestions or M365 illustrative actions attributable to the highest-volume 10% of active developers for that product. The number of people is rounded up and shown. Identities and individual rankings are never displayed. These populations differ, so this is not a comparison of product effectiveness.

Feature use within each product

Manager next step. Resolve licence and coverage exceptions before discussing non-use. Ask developers which tasks each product supports, using the feature table to guide the conversation. Any enablement test should track developer feedback and quality outcomes as well as product-specific use.

How do working conditions differ across recorded tool-use groups?

Synthetic demo · Provisional 10 May 2026 to 04 Jul 2026 · 670 both-eligible, fully observed developers · Same eight-week baseline

The comparison includes 670 developers with common eligibility and complete observation for both products. The group with the highest median collaboration hours is Both recorded. Groups are descriptive categories based on recorded use in this same window, with no treatment assignment or causal estimate.

Selected working-condition distributions

Role and team context for the comparison

Privacy note. Role breakdowns are withheld for M365 only recorded, Neither recorded. Team breakdowns are withheld for GitHub only recorded, M365 only recorded, Neither recorded. Each withheld breakdown contains at least one cell below 10 distinct people.

Interpretation. Team, role, seniority, task selection and tenure can influence working patterns and tool use. These charts are intentionally limited to selected agreed measures. No broad metric scan, adjustment model, causal claim or preferred tool-use group is presented. The simulation applies separate product propensities with planted team signatures and does not assume that dual users have better outcomes.

Manager next step. Discuss a specific workflow with the team before selecting an intervention. Define the intended feedback-loop, cognitive-load or flow improvement, then choose a direct measure for it. Recorded AI use alone cannot demonstrate that improvement.

What varies over time, and what would credible evaluation require?

Synthetic demo · Provisional History: 04 Jan 2026 to 04 Jul 2026 · 26 complete weeks · Baseline pages use only 10 May 2026 to 04 Jul 2026

All 900 developers have Person Query coverage in every week. Across the 26 weeks, the median collaboration-hours line ranges from 12.6 to 14.2 hours/person/week. Product-use rates use separate eligible, adequately observed denominators in each week, so denominator movement is shown rather than hidden.

Weekly working conditions for the full developer population

Recorded weekly product use with valid denominators

Evaluate a documented change with developer feedback and delivery outcomes

1. Team manager, before the next pilot: document the actual change, start date, affected population and expected mechanism. Use this roster and coverage baseline to define eligibility before outcomes are observed.
2. Analyst and delivery owner, before launch: agree a comparator or randomised rollout where feasible. Check pre-change comparability, seasonality, staffing, observation coverage and concurrent changes. Track changes in composition rather than treating changing denominators as adoption.
3. Manager and developer representatives, at an agreed follow-up: combine a repeated anonymous DevEx survey with service-level delivery speed and quality, plus balancing measures such as rework and workload. Judge success against pre-agreed outcomes and uncertainty, rather than higher tool activity alone.

Decision supported now. Select a workflow question and close its measurement gaps. An intervention effect, productivity gain or wellbeing conclusion requires additional evidence. No operational action is justified by synthetic values.

Definitions, sources and reporting contracts

Synthetic demo · Provisional

Scope and units. Pages 1 to 5 use the last eight complete weeks, 10 May 2026 to 04 Jul 2026. The full source window is 04 Jan 2026 to 04 Jul 2026, with Sunday-start weeks. Dates are ISO dates interpreted using a UTC convention. This is an illustrative date contract, not evidence about developers’ time zones. The generator assumes a 40-hour scheduled week for calendar availability. It does not simulate actual calendars or work schedules.

Aggregation. Working-condition values are weekly Person Query metrics. Baseline charts first average each person’s eight weekly values and then compute group percentiles. Each developer has equal weight. Weekly trends instead take the cross-sectional median each week. Product-active rates divide active eligible, covered developers by all eligible, covered developers for that product and window. Baseline product tables require all eight weeks. Joint comparisons require both products throughout the window.

Source definitions. Metric descriptions on pages 2 and 3 are paraphrased from the Microsoft Viva Insights metrics reference, checked on 10 September 2026. The extended field names and synthetic generation are local demonstration contracts. They are not a claim that a real flexible query exports this exact schema. Scheduled_call_hours is an illustrative construction field. Open_1_hour_block is a calendar count, while uninterrupted time incorporates email and Teams activity. Collaboration hours are included as a Viva Insights-style metric and contain meeting hours and scheduled-call hours by definition.

Joins and missingness. The roster anchors the population. The coverage reference anchors the weekly panel. Daily feeds aggregate to unique person-week keys before left joins. One-to-one and many-to-one join assertions prevent row amplification. A missing activity day becomes zero only within an eligible, fully covered product-week. An incomplete or ineligible week remains NA, and any such week excludes the person from that product’s eight-week summary. Even a partially observed positive record would not prove complete observation. Zero-filling in a real tenant requires an independently verified source-completeness contract.

Zero, missing and not applicable. 0 is an observed or justified zero. NA is unresolved measurement and is never silently replaced outside valid coverage. Ineligible people are labelled as eligibility exceptions rather than as non-users. An undefined ratio would be shown as N/A, not as zero. The synthetic completeness reference is reliable by construction. Production licences, eligibility dates, time zones and ingestion completeness must be independently validated.

Privacy, reproducibility and simulation assumptions

Privacy floor. At least 10 distinct people are required for a published group. Percentile visuals use vivainsights::create_boxplot(..., mingroup = 10, return = "table"). Composition breakdowns with any cell below 10 are withheld in full for that parent group, preventing subtraction from the parent total. No individual points, identifiers or individual leaderboards appear in the HTML. Source CSV identifiers are artificial and exist only to demonstrate joins. They must never be replaced with identifiable customer exports in a shareable repository.

Simulation. Seed 20260910 generates a shared roster, 26 Person Query weeks, separate sparse daily activity feeds and weekly eligibility/coverage references. Product-use propensities are generated separately for each product after applying the team signatures below. Working hours depend on simulated person-level variation, role/seniority context and the same team signatures. There is no planted intervention, time effect or dual-user advantage. Cross-sectional team differences are planted for illustration and carry no real-world meaning. M365 feature counts are explicit illustrative extensions, not consumption credits or tokens. Model and language files allocate synthetic suggestions for secondary exploration only. No PR, delivery, survey or wellbeing outcomes are fabricated.

Synthetic effect contract. Automated checks require Platform to lead meeting and collaboration hours, Payments to lead after-hours collaboration, Developer Experience to lead GitHub Copilot recorded-active share and intensity, Data Engineering to lead M365 Copilot recorded-active share and intensity, and Mobile to lead uninterrupted time while sitting lowest on meeting hours, collaboration hours and recorded AI adoption.

Rerun. Knit the canonical Rmd, or run Rscript render-github-developer-experience.R from this folder. The Rmd sources github-developer-experience-helpers.R, which generates and validates the CSVs before rendering. Set RSTUDIO_PANDOC to a local Pandoc folder if needed. All CSVs are regenerated from the seed. The HTML embeds its charts, styles and scripts. Reference links need a connection only when followed. The consumption report and its data are not read or modified.

Formatting. Locale is en-US with British prose. Percentages use one decimal place. Counts use thousands separators, but identifiers never do. Plots label stacked segments of at least 6%, with exact counts and percentages in adjacent tables or expandable details. Rounded shares may not total exactly 100.0%. Neutral colours identify categories, not good or bad performance. On narrow screens, wide charts and tables scroll within their cards. Use a desktop for presentation, or browser zoom for smaller text. Charts are display-ready aggregates, not a certification of the underlying metrics.

Research framework and future extensions

• The SPACE of Developer Productivity, ACM Queue, 2021. Productivity is multidimensional and cannot be reduced to one activity measure.
• DevEx: What Actually Drives Productivity, ACM Queue, 2023. Connect feedback loops, cognitive load and flow with developer feedback and system measures.
• DORA’s software delivery performance metrics. Current guidance, checked on 10 September 2026, describes five metrics across throughput and instability, best applied to one application or service at a time.
• Viva Insights metrics reference. Primary reference for the paraphrased collaboration and focus definitions.

Source-access limitation. The ACM pages returned HTTP 403 during this rebuild. The citations and framework summaries above are retained, but a fresh full-text review could not be completed. Microsoft Learn, DORA and the package function reference were accessible.

Next step. The manager, analyst and delivery owner should agree the workflow question, data owners, evaluation window and success measures before any real-data pilot. This synthetic report requires no operational response.