Context switching की क़ीमत पर लगभग हर article एक ही आँकड़ा quote करता है: interruption के बाद काम पर लौटने में 23 मिनट 15 सेकंड। यह सेकंड तक सटीक है, एक प्रतिष्ठित UC Irvine researcher से आता है, और इसे quote करने वाले ज़्यादातर पेज इसका मतलब ग़लत बताते हैं।

मैं वहाँ लौटा जहाँ से पाँच सबसे दोहराए गए आँकड़े शुरू हुए — papers और pages पर, न कि posts को quote करती posts पर। दो टिकते हैं, caveats के साथ। बाक़ी हैं: एक असली measurement जिसका label ग़लत है, एक टिप्पणी जिसे finding बना दिया गया, और एक table जिसे मैं किसी data तक नहीं खोज पाया।

Terms पर एक नोट, क्योंकि operating systems में "context switch" का मतलब कुछ और होता है: वहाँ यह kernel द्वारा एक process की state सहेजना है ताकि दूसरा चल सके। यह article इंसानों के बारे में है — पहला task ख़त्म होने से पहले अपना ध्यान एक task से दूसरे पर ले जाना। Psychologists इसके lab version को task switching के नाम से पढ़ते हैं।

छोटा जवाब: research तीन अलग-अलग क़ीमतें measure करती है। Lab में, एक switch आपके अगले response को एक सेकंड के कुछ हिस्से से धीमा करता है — एक ठेठ उदाहरण में क़रीब 200 milliseconds — और पहले से तैयारी उस क़ीमत को घटाती है पर हटाती नहीं। जिस task को आप अधूरा छोड़ते हैं वो attention residue छोड़ता है जो अगले task में आपकी performance गिराता है। और असली offices में, जिस रुके काम को उसी दिन दोबारा उठाया जाता है वो पहले क़रीब 25 मिनट इंतज़ार करता है — यही इंतज़ार, दोबारा focus होने में लगा समय नहीं, मशहूर "23 मिनट" की जड़ है।

Lab में task switching की क़ीमत

हर switch नए task पर आपके पहले response को धीमा और ज़्यादा error-prone बनाता है — Monsell के ठेठ उदाहरण में क़रीब 200 milliseconds से — और यह क़ीमत कुछ हद तक तब भी बनी रहती है जब आपको पता हो कि switch आने वाला है। दो tasks मिलाकर चलने वाले blocks, एक task वाले blocks के मुक़ाबले हर response में क़रीब एक सेकंड तक धीमे हो सकते हैं।

Classic demonstration है Rogers and Monsell (1995): लोग एक fixed schedule पर अंकों (odd या even) और अक्षरों (vowel या consonant) की पहचान करने के बीच बारी-बारी करते थे। 0.6 सेकंड तक की तैयारी ने क़ीमत घटाई। उसके आगे मदद बंद हो गई, और तैयारी के लिए 1.2 सेकंड मिलने पर भी "एक बड़ा asymptotic reaction time (RT) cost बना रहा।"

Rubinstein, Meyer and Evans (2001) ने ज़्यादा कठिन tasks use किए — बदलते rules के तहत shapes sort करना और arithmetic करना — चार experiments में, हर एक में 12 से 36 undergraduates के साथ। एक task दोहराने के मुक़ाबले बारी-बारी करने की क़ीमत हर response पर 614 से 1,096 milliseconds थी: complex rules के लिए ज़्यादा, और जब कोई cue बता देता कि आगे क्या है तो कम।

Monsell की 2003 review इसमें एक mixing cost जोड़ती है: जब switch आ सकता हो, तो लोग उन trials पर भी धीमे होते हैं जहाँ task दोहराता है, यानी switching पूरे block पर टैक्स लगाती है। पाँच या ज़्यादा सेकंड तैयारी का समय मिलने पर भी बची हुई क़ीमतें दिखी हैं। हालाँकि ये ideal conditions में सरल tasks हैं — Slack thread से रुके code review जैसी बात बिल्कुल नहीं। अगली दो research lines इससे क़रीब आती हैं।

Attention residue: आपका वो हिस्सा जो पीछे रह जाता है

Attention residue यानी task B पर चले जाने के बाद भी task A के बारे में बचा हुआ सोचना। Sophie Leroy ने दिखाया कि यह B पर performance गिराता है, सबसे ज़्यादा तब जब A अधूरा छोड़ा गया हो।

Leroy (2009) में, undergraduates ने पाँच मिनट एक word puzzle पर लगाए, फिर résumés से job candidates का evaluation किया। जिन्हें ऐसा puzzle दिया गया जो ख़त्म ही नहीं हो सकता था, वो résumés से कम याद कर पाए, और दूसरे experiment में एक reaction-time test ने दिखाया कि switch के बाद भी puzzle के शब्द सक्रिय थे। ख़त्म करना भी हमेशा काफ़ी नहीं था: जिन्होंने आराम की रफ़्तार से ख़त्म किया उनमें residue ज़्यादा था, बनिस्बत उन लोगों के जिन्होंने time pressure में ख़त्म किया।

Study ने switch के तुरंत बाद residue measure किया, इसलिए यह मिनटों में कोई अवधि नहीं देती। जो पेज 20 मिनट से ज़्यादा समय लगने वाले refocusing का ठीकरा residue पर फोड़ते हैं, वो दो असंबंधित findings को जोड़ रहे हैं। और ये students थे, छोटे lab tasks पर।

Leroy and Glomb (2018) ने interruption करने वाले task पर ग़ौर किया। जिन्हें उम्मीद थी कि रुके काम पर time pressure में लौटना होगा, उन्हें interruption पर focus करने में दिक्क़त हुई। चार studies में जो fix काम आया: switch करने से पहले, नोट कर लें आप कहाँ थे और आगे क्या करने वाले थे। वे इसे ready-to-resume plan कहते हैं, और इसने residue घटाया तथा interruption वाले task की performance बचाई।

काम पर interruptions की क़ीमत

Field में, ज़्यादातर रुका काम उसी दिन दोबारा उठता है, पर एक लंबे detour के बाद। Lab में, रुके हुए लोग भरपाई के लिए तेज़ी करते हैं और क़ीमत stress में चुकाते हैं।

Mark, González and Harris (2005) ने 24 managers, analysts और developers के साथ हर एक के क़रीब तीन दिन बिताए — 700 घंटे से ज़्यादा observation — और "working spheres" track किए, यानी उनके शब्दों में project-sized काम की इकाई; इनमें से 57% रुके। जो रुका काम उसी दिन लौटा वो औसतन 25 मिनट 26 सेकंड इंतज़ार करता रहा (standard deviation 54 मिनट 48 सेकंड), और बीच में 2.26 और spheres आए।

Lab में, Mark, Gudith and Klocke (2008) ने 48 लोगों से काम की emails का जवाब लिखवाया, जबकि एक "supervisor" क़रीब हर दो मिनट में उन्हें रोकता रहा। रुके हुए rounds शांत round से जल्दी ख़त्म हुए, errors या विनम्रता में कोई फ़र्क़ नहीं — लोगों ने छोटी emails लिखीं। क़ीमत questionnaires में दिखी: ज़्यादा stress, frustration, workload, effort और time pressure — "सिर्फ़ 20 मिनट रुके हुए काम के बाद।"

Timing क़ीमत बदल देती है। Iqbal and Bailey (2008) ने notifications को task के natural breakpoint तक रोका। Programming या diagrams edit करते 16 लोगों के साथ, इसने तुरंत भेजने के मुक़ाबले frustration और reaction time घटाया, औसतन 90 सेकंड से कम देरी के लिए; इसने resumption छोटा नहीं किया। मैं Timex बनाता हूँ, एक Mac time tracker, और यही study है जिसकी वजह से इसके Energy nudges किसी app switch या एक मिनट के ठहराव का इंतज़ार करते हैं।

मशहूर context switching stats, audit किए हुए

जो पाँच आँकड़े सबसे अक्सर सामने आते हैं, उनकी जड़ तक खोज:

Claim जैसा आमतौर पर quote होता है असल में कहाँ से आता है क्या measure हुआ Verdict
"Interruption के बाद दोबारा focus होने में 23 मिनट 15 सेकंड लगते हैं" Gloria Mark, उनके shadow किए 36 लोगों के बारे में एक 2006 Gallup interview में; 24 लोगों पर उनका 2005 paper 25 min 26 s बताता है Observed office workers को उसी दिन रुके project पर लौटने में कितना समय लगा, क़रीब दो और projects के बाद असली आँकड़ा, ग़लत मतलब। यह projects के बीच का detour है, focus वापस पाने में लगा समय नहीं। Paper के 25-मिनट mean का standard deviation 54 मिनट है, यानी mean से दोगुने से ज़्यादा; interview कोई नहीं देता।
"Tasks switch करने में आपका 40% तक productive समय जाता है" 2006 का एक APA पेज उस आकार का कुछ नहीं। पेज David Meyer की एक टिप्पणी ("40 प्रतिशत तक") report करता है और कहता है कि अकेले switches की क़ीमत "एक सेकंड के कुछ दसवें हिस्से" भर हो सकती है खींचा हुआ। एक upper-bound टिप्पणी, result नहीं।
"Workers दिन में 1,200 बार apps के बीच toggle करते हैं, हफ़्ते में 4 घंटे गँवाते हैं" Murty, Dadlani and Das, HBR 2022 137 workers, ज़्यादातर mid- या back-office jobs में (finance, HR, supply chain…), तीन Fortune 500 companies में, पाँच हफ़्तों तक; हर toggle पर दोबारा orient होने में "दो सेकंड से थोड़ा ज़्यादा" लगा टिकता है, उस group के लिए। तीन में से दो authors Soroco में काम करते हैं, जो measuring software बनाती है। चार घंटे मोटे तौर पर दो सेकंड × दिन में 1,200 toggles हैं, एक हफ़्ते में जोड़े गए — खोया focus नहीं।
"हर अतिरिक्त project या task आपका 20% समय खा जाता है" Gerald Weinberg की 1992 की किताब Quality Software Management, p. 284 की एक table, जिसे Chris Gagné ने cite किया एक साथ चल रहे projects के बीच switching; मुझे table के पीछे कोई study या dataset नहीं मिला Unverified estimate। Projects के बारे में, app switches के नहीं।
"पाँच सेकंड की interruption आपकी errors तिगुनी कर देती है" Altmann, Trafton and Hambrick (2014) Steps की एक fixed sequence follow करते 300 undergraduates: 4.4-सेकंड की interruptions ने sequence errors तिगुनी कीं, 2.8-सेकंड वाली ने दोगुनी; बाक़ी errors नहीं बदलीं टिकता है, सीमित दायरे में। यह step-by-step procedure में अपनी जगह खोने के बारे में है।

दो rows एक साथ वो मतलब नहीं रख सकतीं जो आमतौर पर उनसे लिया जाता है। अगर हर app toggle की क़ीमत 23 मिनट 15 सेकंड होती, तो HBR के दिन के 1,200 toggles में रोज़ 465 घंटे लगते। Sources पढ़िए और विरोधाभास ग़ायब हो जाता है: एक windows पलटने के बाद दो सेकंड का reorientation है, दूसरा रुके project को दोबारा उठाने से पहले 25 मिनट का detour।

अपनी context switching ख़ुद कैसे measure करें

अपने दिन के record से प्रति घंटा app switches गिनें। यह क़ीमत का वो एक हिस्सा है जिसे आप सीधे observe कर सकते हैं; residue और resumption का आप सिर्फ़ अनुमान लगा सकते हैं।

Install नहीं। Free day audit tool में आप अपने पिछले आठ घंटे एक 24-घंटे की timeline पर paint करते हैं और यह deep blocks तथा एक task-switch count report करता है। यह memory पर चलता है, इसलिए count को एक estimate मानें।

Recorded दिन से। Timex हर सेकंड frontmost app का sample लेकर एक local SQLite file में डालता है, हर tracked segment की एक row: app का bundleId, window title, URL, start, end और duration। File को free SQLite viewer में खोलें, जो बिना signup के आपके browser में चलता है। Settings से ZIP export use करें या ~/Library/Application Support/io.muvon.timex/ वाली file, फिर एक बार में एक query paste करें।

एक दिन के लिए प्रति घंटे app switches (date बदलें):

WITH seq AS (
  SELECT startAt,
         bundleId <> LAG(bundleId) OVER w
           AND (julianday(startAt) - julianday(LAG(endAt) OVER w)) * 86400 < 120
           AS switched
  FROM activity
  WHERE date(startAt, 'localtime') = '2026-10-08'
  WINDOW w AS (ORDER BY startAt)
)
SELECT strftime('%H', startAt, 'localtime') AS hour,
       COUNT(*) FILTER (WHERE switched) AS app_switches
FROM seq
GROUP BY hour
ORDER BY hour;

प्रति tracked घंटे switches, एक start date से हर दिन की एक row:

WITH seq AS (
  SELECT date(startAt, 'localtime') AS day,
         duration,
         bundleId <> LAG(bundleId) OVER w
           AND (julianday(startAt) - julianday(LAG(endAt) OVER w)) * 86400 < 120
           AS switched
  FROM activity
  WHERE date(startAt, 'localtime') >= '2026-10-01'
  WINDOW w AS (PARTITION BY date(startAt, 'localtime') ORDER BY startAt)
)
SELECT day,
       COUNT(*) FILTER (WHERE switched) AS app_switches,
       ROUND(SUM(duration) / 3600.0, 1) AS tracked_hours,
       ROUND(COUNT(*) FILTER (WHERE switched) * 3600.0 / SUM(duration), 1) AS switches_per_hour
FROM seq
GROUP BY day
ORDER BY day;

तीन rules गिनती को ईमानदार रखते हैं:

  • Switch वो row है जिसका bundleId पिछली row से अलग हो — सिर्फ़ कोई नई row नहीं, क्योंकि एक ही app के अंदर window-title बदलने से भी नई row शुरू हो सकती है।
  • Gap 120 सेकंड से कम होनी चाहिए। Timex बिना keyboard या mouse input के 120 सेकंड बाद एक segment बंद कर देता है (front app में बजता audio या live mic उसे खुला रखते हैं), इसलिए इससे लंबी gap का मतलब है आप दूर चले गए थे, और lunch के बाद किसी दूसरे app पर लौटना switch नहीं है।
  • Timex समय UTC में store करता है, इसलिए हर दिन और घंटा आपकी घड़ी से मिलाने के लिए SQLite के 'localtime' modifier से गुज़रता है।

Publish करने से पहले मैंने दोनों को test किया, UTC में stored और UTC+7 time zone में पढ़े गए एक 14-row database पर: आठ ज्ञात switches, साथ में एक ही app की दो rows, 15-मिनट की away gap, दो घंटे की gap, पिछले local दिन की एक row और एक row जो UTC में पिछले दिन पर है पर locally पूछे गए दिन पर। दोनों queries ने ठीक आठ switches लौटाए, local समय के 9, 10 और 11 बजे के घंटों में 4, 2 और 2 बँटे हुए — Python के sqlite3 में और sql.js में, यानी viewer के साथ आने वाली WebAssembly build में।

फिर आँकड़े को वैसा ही पढ़ें जैसा वह है। HBR के हिसाब से हर reorientation पर सवा दो सेकंड, तो घंटे में 40 switches की क़ीमत भी क़रीब डेढ़ मिनट है — सेकंड महँगा हिस्सा नहीं हैं। उन घंटों को खोजें जहाँ असली काम की आपकी सबसे लंबी अवधियों के अंदर switches उछलते हैं। मेरे मामले में वो "coding की पक्की सुबह" थी जो असल में चालीस मिनट थी, नौ बार कटी; मैंने लिखा कि उसने मेरे focus sessions का क्या किया। अगर आप code लिखते हैं, तो time tracking for developers वाली post दिखाती है कि editor, terminal, AI tools और chat उसी data में अलग-अलग कैसे दिखते हैं।

Context switching की क़ीमत क्या घटाती है

कम switches, natural boundaries पर switches, और जाने से पहले एक नोट। हर एक के पीछे एक ख़ास study है।

  • छोटे कामों को batch करें। हर switch की एक fixed क़ीमत है, और tasks मिलाना उन पलों को भी धीमा करता है जब आप switch नहीं करते। Messages का जवाब कुछ बैठकों में दें, जैसे ही आएँ वैसे नहीं। Mark की 2008 study ने पाया कि same-topic interruptions, off-topic ones से सस्ती नहीं थीं, इसलिए फ़ायदा कम switches में है, "related" ones को ग्रुप करने में नहीं।
  • Blocks बचाकर रखें, और ख़ुद को रोकने की उम्मीद रखें। Mark की 2005 study में, analysts और developers ने ख़ुद को उतनी ही बार रोका जितनी बार दूसरों ने उन्हें रोका। Notifications off इसका आधा हिस्सा संभालते हैं; बाक़ी आधा है कुछ check करने की उस urge को पकड़ना।
  • जब हो सके, boundary पर रुकें। Leroy ने पाया कि ख़त्म करना residue घटाता है, और Iqbal and Bailey ने पाया कि breakpoints पर interruptions लोगों को कम frustrate करती हैं। Function, paragraph या reply ख़त्म करें, फिर switch करें।
  • जब ख़त्म न कर सकें, एक ready-to-resume नोट छोड़ दें। Leroy and Glomb का fix क़रीब एक मिनट लेता है: आप कहाँ थे, आगे क्या करते। उन्होंने interruption वाले task को measure किया, पर नोट वापसी के सफ़र में भी मदद करनी चाहिए — Rubinstein के participants तेज़ switch करते थे जब cue बताता कि आगे क्या है, और नोट वही cue है।

क्या context switching fatigue असली है?

आंशिक रूप से। Short-term दबाव के लिए सीधी evidence है: Mark के 2008 participants ने 20 मिनट रुके हुए काम के बाद अपने stress, frustration और effort को ऊँचा rate किया। Long-term version — लगातार switching का आपको burnout तक घिसना — इन studies ने test नहीं किया, और authors ख़ुद कहते हैं: "हम यह नहीं कह सकते कि लोग समय के साथ cope कर पाएँगे या ये measures बढ़ते ही जाएँगे।" HBR वाला toggling article कहता है कि भारी toggling cortisol बढ़ाता है, पर इसके लिए कुछ cite नहीं करता। स्थायी नुकसान के claims को unproven मानें।

ईमानदार सीमाएँ

इन आँकड़ों के पीछे का lab work सरल tasks use करता है, ज़्यादातर undergraduates के साथ; 25-मिनट वाले आँकड़े के पीछे की field study ने 24 लोगों को देखा। इनमें से कुछ भी आपको प्रति switch आपकी निजी क़ीमत नहीं देता, और जो tool ऐसा claim करे उस पर मैं भरोसा नहीं करूँगा।

Queries app switches गिनती हैं, attention switches नहीं। Email का जवाब देते हुए bug के बारे में सोचना अदृश्य है, और एक ही browser में tabs या एक ही editor में files के बीच जाना भी — वो सब एक bundleId के अंदर रहता है। Timex सिर्फ़ आपका Mac देखता है, इसलिए task के बीच उठाया phone कभी दिखता ही नहीं। और Timex switches record करता है; उन्हें रोकता नहीं।

एक हफ़्ता गिनें

पहले हफ़्ते कुछ न बदलें। Friday को दूसरी query चलाएँ, पहली से अपना सबसे ख़राब घंटा खोजें, और सिर्फ़ उसी घंटे में एक fix आज़माएँ। एक गिनती जिसकी तुलना आप कर सकते हैं, उस stat से बेहतर है जिसे आप quote कर सकते हैं।

Timex की trial में 100 घंटे की tracking आती है, बिना credit card के, macOS 15 या उसके बाद Apple Silicon पर। Timex download करें, एक सामान्य हफ़्ता काम करें, और गिनें।

— DK