5 exercises — the language of flow state, context switching, deep work blocks, and communicating DX investment to leadership.
Core vocabulary
Flow state — deep concentration requiring 15-25 min to enter; destroyed by interruptions
Context switching cost — cognitive tax of shifting between tasks; 15-25 min reload cost
Maker's schedule — half-day blocks for makers vs. one-hour slots for managers (Paul Graham)
Deep work blocks — protected calendar time for uninterrupted focus
Async-first — defaulting to non-synchronous communication to protect flow
0 / 5 completed
1 / 5
A senior engineer writes in a team RFC: "We need to protect focus time — uninterrupted blocks of 2+ hours are when the highest-value work happens. Meetings and Slack notifications fragment these blocks and eliminate the productivity gains we are trying to achieve." What concept does "protect focus time" relate to in developer experience?
Flow state (also called deep work, coined by Cal Newport) is the mental state where a developer is fully immersed in a complex problem, making progress at high speed and high quality. Research by Mihaly Csikszentmihalyi and, in the developer context, by the SPACE framework and Google's DevEx work, shows that: (1) flow state takes 15-25 minutes to enter; (2) a single interruption destroys it and costs 23+ minutes to recover; (3) most developers get fewer than 2 uninterrupted hours per day. Protecting focus time means explicitly blocking calendar time, silencing notifications, and establishing team norms like "no meetings before 11am" or "focus hours from 9-12." In DX communication: "Our engineers average 47 minutes of uninterrupted focus time per day — well below the 2 hours needed to enter flow state consistently."
2 / 5
An engineering director explains to a VP: "The context switching cost is higher than it looks — every time an engineer moves from the feature they are building to answer a support ticket, we lose not just the time they spent on the ticket, but the 20 minutes it takes to reload the mental model they had before." Which phrase best completes this presentation sentence? "Context switching is not just a time cost — it is a ___."
Context switching cost is a cognitive tax — each switch requires the brain to: (1) save the current mental model (what code is loaded, what the goal is, what edge cases were being considered); (2) switch to a new task; (3) reload the previous mental model when returning. Studies cited in engineering effectiveness literature put the reload cost at 15-25 minutes per switch. The compound effect: an engineer interrupted 4 times per day could lose 60-100 minutes of effective work — without working a single minute less. Key vocabulary for presentations: "context switching cost,""cognitive overhead,""mental model reload,""interruption cost." In reporting: "Reducing on-call interruptions from 6 to 2 per engineer per week would recover approximately 3 hours of focus time per person."
3 / 5
A DX lead proposes a new team working agreement: "We will adopt deep work blocks — two-hour segments in the morning where no meetings are scheduled and Slack response time expectations are set to 4 hours." This practice is most directly associated with which concept from the developer productivity literature?
The maker's schedule vs. the manager's schedule is a concept from Paul Graham's 2009 essay that became foundational in developer experience thinking. Makers (engineers, designers, writers) need half-day or full-day blocks — a single meeting in the middle of the morning destroys two blocks. Managers work in one-hour slots; a meeting is just one slot. The conflict: when managers schedule meetings without considering maker schedules, they cause disproportionate productivity loss. Deep work blocks operationalise the maker's schedule in team agreements. Practical vocabulary: "maker's schedule,""no-meeting mornings,""focus hours,""meeting-free zones." In DX proposals: "By moving all recurring syncs to afternoon, we protect the maker's schedule and recover an estimated 90 minutes of focus time per engineer per day."
4 / 5
A platform team writes an internal announcement: "We have invested in communicating DX investment to the wider organisation — explaining why reducing build times from 12 minutes to 3 minutes is not just a quality-of-life improvement but a measurable business outcome." Which framing most effectively communicates DX investment to non-technical leadership?
The most effective DX investment communication converts tool improvements into business-language outcomes: time saved × engineers × frequency = recovered capacity. Option C does exactly this: (1) states the improvement in measurable terms; (2) multiplies across the team to show organisational scale; (3) translates to FTE equivalents that leadership understands. This is the core vocabulary of DX ROI communication: "saved N hours per engineer per week,""multiplied across the team of N engineers,""equivalent to N FTEs of additional capacity,""annualised savings of £X." Option A is technical but not business-relevant. Option B is anecdotal. Option D presents a metric without business translation. In presentations, always follow the formula: improvement → time saved per person → team multiplier → business outcome.
5 / 5
An engineering manager proposes a team norm: "When someone is in a flow state — headphones on, focused — we default to async communication. We post in Slack and wait, rather than tapping someone on the shoulder or sending a direct message expecting an immediate reply." Which phrase best describes this team agreement in DX vocabulary?
Async-first culture means defaulting to asynchronous communication (Slack messages, comments, documentation) rather than synchronous interruption (tap on the shoulder, call, instant DM). It is one of the most effective DX interventions because it: (1) preserves flow state for both the interrupted and the interrupting developer; (2) creates a written record; (3) allows people to respond at a natural break. Common team agreement language: "We are async-first — please post in the channel and allow up to 4 hours for a response during focus hours." Companion concepts: "response time expectations,""flow state protection,""do not disturb norms,""maker's schedule respect." In DX programme documentation: "Since adopting async-first norms, self-reported interruptions per day dropped from 8 to 3, and flow state hours increased from 1.2 to 3.4 per engineer."