Blog Context switching
Context switching
What 10 Real Workdays Show About Context Switching
Across 10 reconstructed weekdays, one operator calendar touched a content project, outbound follow-ups and a video channel on the same day. The logs show streams overlapping on the clock. They do not measure the minutes lost to switching.
We rebuilt 10 weekdays in September 2026 from the existing work logs of one small marketing operation. A content project, outbound follow-ups and a video channel appeared on every one of those days, and an early morning ops run started 8 of them. Where logs carry clock times, streams overlap in the same morning. No switch minutes were measured, so this shows how work stacks up, not what switching costs.
10
weekdays rebuilt from existing work logs, with partial data on every day
3
work streams present on every one of the 10 days: content, outbound and video
0
switch minutes measured; this is a log reconstruction, not a stopwatch diary
The thesis
Context switching shows up first as several work streams sharing one calendar day. In these 10 weekdays the same streams appear together again and again. That is a pattern you can see in ordinary logs. Turning it into lost minutes or lost money needs a real measurement, and this is not one.
The scene
One day, several streams
No dramatic interruptions needed.
The day starts with morning ops notes before most people are awake. By mid morning, outbound follow-ups are going out and a content check is running. In the evening, a video channel publishing run closes the day. On some days, contact lookups or planning for small public tools join in as well.
None of this needs a dramatic interruption story. The load is built in: several streams are allowed to share one day, and the records show that they did.
So we asked a narrow question. What do ordinary work logs actually show about streams stacking up in a day, and what can they not show?
How we looked
Ten weekdays, rebuilt from logs
One operation, partial records, nothing invented.
We took the 10 most recent weekdays on or before September 30, 2026 that had real logged work, from September 17 to September 30. Weekends were left out.
Each day was rebuilt from the records that already existed: morning ops notes, content project files, an outbound send log, and a video channel post log. Names, brands and links were removed.
- One operation, not a survey. The logs describe one operator. Many rows were written by assistants or routine runs working under that operator.
- Partial data every day. No day has a full record of what was left, what was picked up and how long the return took.
- Order only where clocks exist. Work in separate records on the same date counts as a stream touch, not as a sequence.
Finding 1
The same streams share almost every day
Three streams on all 10 days, and an early morning ops run on 8.
A content project, outbound follow-ups and a video channel have records on every one of the 10 days. Where a day is thin in the records, we kept it labelled thin rather than filling it in.
An early morning ops run appears on 8 of the 10 days, logged between about 05:00 and 05:20 ET. On one more day, ops work showed up only as a weekly business review in the afternoon. Contact lookups (one day) and planning for small public tools (two days) show up as extra streams, not as everyday fixtures.
What the logs record for two streams
| Stream | What a typical weekday looks like | Exceptions in the window |
|---|---|---|
| Outbound follow-ups | 12 ok sends, spread from mid morning to mid afternoon | One Friday logged 6, all between 12:26 and 14:31 ET |
| Evening publishing | Posted counts of 27, 21, 19, 23, 17, 26, 21 and 24 | One evening logged 22 posted and 1 failed; one evening log was incomplete |
These are volume signals. They show the streams were busy on the same days. They are not a measure of time lost.
Finding 2
Streams overlap on the clock
Where records carry times, the overlap is visible without a stopwatch.
- One Friday: a content check at about 09:23 ET, while outbound follow-ups were logged from 09:54 ET.
- One Thursday: morning ops at about 05:10 ET, outbound from 09:56 ET, and a live content check at about 10:36 ET while outbound kept going until 14:32 ET.
- A busier Friday: morning ops at about 05:00 ET, outbound only in an early afternoon window from 12:26 to 14:31 ET, a content status check at about 13:25 ET inside that window, and evening publishing.
- Interrupted mornings: twice, the morning ops run stopped partway when it hit a limit of 100 tool calls, at about 05:20 ET on one Tuesday and about 05:00 ET on a later Monday. Other streams carried on later the same day.
Read together, these records support one plain reading: the calendar is built to carry several streams at once. They do not support an average number of switches, a cost in minutes, or a claim that fewer switches would have produced better work.
Limits
What this does not prove
Four hard limits stay in place.
- No switch minutes. There is no timed record of leaving one task and getting back into another, so we do not apply any fixed lost minutes figure.
- No switch count. Separate records on the same date are stream touches, not a validated tally of switches.
- One operation, partial logs. This is not an industry benchmark and not an experiment comparing batched and unbatched days.
- No cost or revenue claim. Streams sharing a day and overlapping on the clock is not money math.
Studies of interruption costs exist elsewhere. We do not borrow their numbers or apply them to these 10 days.
What to do with it
Read your own calendar the same way
Four questions to ask before you try to fix focus.
- Which streams are allowed on the same weekday by default?
- Which overlaps already show up in your clock times or publishing logs?
- Which stream is thin or on hold, and should stay labelled that way instead of being padded?
- If you want the real cost of switching, what will you record: the task you left, the task you moved to, what triggered it and how long it took to get back in?
A clearer operating rule usually names the two or three streams that own each day and keeps the rest visible as backlog. That does not make the work smaller. It makes the tradeoffs readable before anyone decides the problem is just multitasking.
Key terms and facts
The short version
- Work stream
- A recurring kind of work with its own records, such as outbound follow-ups or a video channel.
- Stream touch
- A stream that has records dated on a given day. It shows the work happened that day, not in what order.
- Clock overlap
- Two streams with logged times inside the same part of the day, taken from different records.
- Switch cost
- The time it takes to get back into a task after leaving it. It needs a from task, a to task and a timed return, which these logs do not have.
Key facts
- TEAMULATE STUDY (one operation, 10 weekdays, September 2026)content, outbound and video records appear on all 10 days; morning ops run on 8 (plus one afternoon weekly review).
- TEAMULATE STUDYoutbound logged 12 ok sends on most weekdays; one Friday logged 6, all in the early afternoon.
- TEAMULATE STUDYevening publishing logged posted counts between 17 and 27 on the evenings with a complete log.
- TEAMULATE STUDYdata quality is partial on all 10 days, and no switch minutes were measured.
Run it on your numbers: To see how many streams your own hours can carry, try the free Marketing Capacity Planner
Takeaways
What to do with this
Start from streams, not a switch average
Count which streams share a day before you try to put a number on switching.
Multi stream days are the pattern
Content, outbound and video shared all 10 days, and an early morning ops run started 8 of them.
Volume is not lost time
Send counts and post counts show busy days. They say nothing about how long it took to refocus.
Measure before you claim a cost
If you need minutes or money, keep a simple, voluntary log of each switch and the time it took to get back in.
Questions and answers
Common questions
Did this study measure how much time context switching costs?
No. The 10 days were rebuilt from existing work logs, and no switch minutes were measured. The logs show which streams shared a day and where they overlapped on the clock, not how long it took to refocus.
How many work streams shared a typical day?
Three streams had records on all 10 days: a content project, outbound follow-ups and a video channel, and an early morning ops run started 8 of them.
Can I use these results as a benchmark for my team?
No. The logs describe one operation over 10 weekdays, with partial data on every day. Use them as an example of how to read your own calendar, not as a standard to compare against.
What is the difference between a stream touch and a switch?
A stream touch means a stream has records on a given day. A switch means leaving one task and moving to another at a known time. These logs show stream touches, and order only where clock times exist.
How would I measure the real cost of switching?
Keep a voluntary day log that records the task you left, the task you moved to, what triggered the move and how long it took to get back into the work. Without those times, any lost minutes figure is a guess.
Sources
Named sources
Teamulate reconstruction of 10 weekdays of one small marketing operation, September 2026, from its existing work logs with names, brands and links removed. No outside studies or figures are used.
Full report
Download the research
Full report
All 10 days in one place, with the stream map, the clock overlaps and the limits (PDF).