ترجمه و برداشت آزاد از ایده‌های اصلی مقاله، با ارجاع به منبع اصلی.

Paul Graham در این مقاله از یک سوءتفاهم بسیار ساده شروع می‌کند: چرا برنامه‌نویس‌ها، نویسنده‌ها و آدم‌هایی که چیزی می‌سازند این‌قدر از جلسه بدشان می‌آید؟ پاسخ او این نیست که این آدم‌ها اجتماعی نیستند یا از هماهنگی فرار می‌کنند. مسئله این است که آن‌ها زمان را با واحد متفاوتی مصرف می‌کنند. جلسه برای کسی که کارش مدیریت است یک بخش طبیعی از روز است؛ اما برای کسی که کار عمیق می‌کند، همان جلسه می‌تواند ساختار کل روز را خراب کند.

او دو نوع تقویم را از هم جدا می‌کند: تقویم مدیر و تقویم سازنده. تقویم مدیر شبیه دفتر قرارهای سنتی است؛ روز به خانه‌های یک‌ساعته تقسیم می‌شود، هر خانه می‌تواند به یک جلسه، تماس یا تصمیم اختصاص پیدا کند، و تغییر موضوع در طول روز اتفاق عجیبی نیست. اگر کسی روی این مدل کار کند، پیدا کردن یک زمان خالی و گذاشتن جلسه در آن بیشتر یک مسئله لجستیکی است تا یک بحران ذهنی.

اما تقویم سازنده با چنین واحدهایی کار نمی‌کند. برنامه‌نویس، نویسنده، طراح، استراتژیست یا هر کسی که باید چیزی پیچیده را بسازد، معمولاً به نیم‌روزهای کامل یا بلوک‌های طولانی احتیاج دارد. یک ساعت برای شروع کار عمیق کافی نیست؛ بیشتر شبیه گرم کردن موتور است. ذهن باید مسئله را دوباره بالا بیاورد، لایه‌هایش را نگه دارد، چند مسیر را امتحان کند و تازه بعد از مدتی به نقطه‌ای برسد که خروجی واقعی ساخته شود.

به همین دلیل جلسه برای سازنده فقط یک جابه‌جایی ساده از کاری به کار دیگر نیست. یک جلسه در وسط بعدازظهر می‌تواند کل بعدازظهر را به دو تکه بی‌مصرف تقسیم کند؛ هر تکه برای کار سخت کوتاه است و خودِ آگاهی از اینکه جلسه‌ای در راه است، بخشی از توجه را می‌گیرد. آدمی که در تقویم مدیریتی زندگی می‌کند همیشه منتظر اتفاق بعدی است، اما آدمی که در ریتم سازندگی است باید حضور ذهن عمیقش را حفظ کند.

Graham حتی می‌گوید اثر جلسه ممکن است فقط همان نیم‌روز نباشد. وقتی آدم بداند عصرش شکسته می‌شود، ممکن است صبح هم سراغ کار بلندپروازانه نرود، چون می‌داند فرصت کافی برای فرو رفتن در آن ندارد. پروژه‌های جدی معمولاً نزدیک مرز توان ذهنی آدم قرار دارند؛ کمی افت انرژی یا انگیزه کافی است که آدم شروعشان نکند. برای همین یک قرار کوچک می‌تواند اثر آبشاری روی کل روز بگذارد.

هر دو مدل تقویم به‌تنهایی سالم‌اند. مدیر واقعاً باید با آدم‌های مختلف هماهنگ شود، تصمیم بگیرد، پیگیری کند و دسترسی‌پذیر باشد. سازنده هم واقعاً باید زمان بی‌وقفه داشته باشد. مشکل وقتی شروع می‌شود که این دو مدل روی هم می‌افتند. چون آدم‌های قدرتمندتر سازمان‌ها اغلب در تقویم مدیریتی زندگی می‌کنند، ناخواسته بقیه را هم مجبور می‌کنند با ریتم آن‌ها کار کنند. مدیران باهوش این هزینه را می‌فهمند و برای آدم‌هایی که کار عمیق می‌کنند فضای طولانی و محافظت‌شده می‌گذارند.

Graham از تجربه Y Combinator مثال می‌زند. سرمایه‌گذارها معمولاً با تقویم مدیریتی کار می‌کنند، اما او می‌گوید در YC تلاش کرده‌اند تا حدی روی تقویم سازنده بمانند. راه‌حلشان چیزی شبیه office hours است: چند بازه مشخص در هفته را برای ملاقات با بنیان‌گذارها کنار می‌گذارند و قرارها را در انتهای روز جمع می‌کنند. این کار باعث می‌شود جلسه‌ها مزاحم قلب روز کاری نشوند؛ یعنی جلسه هست، اما وسط جریان ساختن فرو نمی‌رود.

او از تجربه استارتاپ قبلی خودش هم یک الگوی جالب می‌آورد: روزش را عملاً به دو روز کاری تقسیم کرده بود. شب‌ها تا دیروقت برنامه‌نویسی می‌کرد، چون آن زمان احتمال وقفه کم بود؛ بعد دیرتر می‌خوابید و بخش دیگری از روز را به کارهای تجاری و ارتباطی اختصاص می‌داد. بدون اینکه آن موقع اسمش را بداند، در واقع یک بخش روز را با تقویم سازنده جلو می‌برد و بخش دیگر را با تقویم مدیر.

بخش مهم دیگر مقاله درباره جلسه‌های حدسی است؛ همان جلسه‌هایی که فقط برای آشنا شدن، قهوه خوردن، شبکه‌سازی یا بررسی احتمال همکاری پیشنهاد می‌شوند. برای کسی که تقویم مدیریتی دارد، چنین جلسه‌ای ممکن است تقریباً رایگان به نظر برسد؛ یک جای خالی در تقویم هست و شاید چیزی از آن دربیاید. در فرهنگ کسب‌وکار، مخصوصاً در سیلیکون‌ولی، این نوع ملاقات‌ها طبیعی و رایج‌اند.

اما برای کسی که روی تقویم سازنده کار می‌کند، جلسه حدسی هزینه بسیار بالاتری دارد. او باید نیم‌روز یا بخش بزرگی از تمرکزش را خرج احتمالی کند که شاید هیچ نتیجه‌ای نداشته باشد. اینجاست که یک تعارض اجتماعی هم شکل می‌گیرد: اگر جلسه را بپذیری، تمرکزت را از دست می‌دهی؛ اگر رد کنی، ممکن است بی‌ادب یا غیرهمکار به نظر برسی. مشکل فقط مدیریت زمان نیست، مدیریت انتظارات آدم‌هایی است که با ریتم دیگری کار می‌کنند.

Graham راه‌حل را در روشن کردن همین تفاوت می‌بیند. کسانی که تقویم سازنده دارند قرار نیست هیچ‌وقت جلسه نداشته باشند. آن‌ها هم می‌دانند که هماهنگی، رابطه و تصمیم‌گیری لازم است. خواسته اصلی‌شان این است که طرف مقابل هزینه واقعی جلسه را بفهمد. وقتی این هزینه دیده شود، می‌شود جلسه‌ها را خوشه‌بندی کرد، زمان‌های مشخص ساخت، درخواست‌های حدسی را کمتر کرد و کار عمیق را بی‌دلیل تکه‌تکه نکرد.

برای بنیان‌گذارها، این مقاله فقط درباره برنامه‌نویس‌ها نیست؛ درباره طراحی انرژی شرکت است. بنیان‌گذار در سال‌های اول هم باید بفروشد، استخدام کند، مذاکره کند و سرمایه جذب کند، هم باید محصول، روایت، سیستم و فرهنگ بسازد. اگر تقویم او کاملاً مدیریتی شود، ممکن است شرکت پرجنب‌وجوش به نظر برسد اما چیزهای عمیق ساخته نشوند. اگر هم کاملاً از هماهنگی فرار کند، سازمان قفل می‌شود. هنر کار این است که برای هر نوع کار، ریتم درست بسازد.

برداشت عملی مقاله این است که تقویم، فقط فهرست قرارها نیست؛ معماری توجه سازمان است. هر بار که جلسه‌ای می‌گذاری، فقط زمان همان جلسه را مصرف نمی‌کنی؛ ممکن است یک بلوک تمرکز، یک شروع جسورانه یا یک خروجی عمیق را هم حذف کنی. شرکت‌های بهتر آن‌هایی‌اند که هم تصمیم‌گیری سریع دارند و هم به آدم‌های سازنده اجازه می‌دهند نیم‌روزهای سالم و بی‌وقفه داشته باشند.

  • جلسه را فقط با مدت خودش نسنج؛ اثرش روی قبل و بعدِ کار عمیق را هم حساب کن.
  • برای تیم‌های محصول، تکنولوژی، محتوا و استراتژی، بلوک‌های نیم‌روزه محافظت‌شده بساز.
  • جلسه‌ها را در پنجره‌های مشخص یا انتهای روز خوشه‌بندی کن تا وسط جریان ساختن نیفتند.
  • جلسه‌های حدسی و صرفاً شبکه‌سازی را برای آدم‌های maker با دقت بیشتری بپذیر یا رد کن.
  • به‌عنوان بنیان‌گذار، روزت را آگاهانه بین ریتم مدیریت و ریتم ساختن تقسیم کن.
  • در سازمان توضیح بده که رد کردن جلسه همیشه بی‌احترامی نیست؛ گاهی دفاع از خروجی عمیق است.
  • برای هر نوع کار، واحد زمانی مناسب خودش را طراحی کن: تصمیم سریع با واحد کوتاه، ساختن سخت با واحد بلند.
  • تقویم را معماری توجه شرکت بدان، نه فقط ابزار هماهنگی.

این مقاله چه چیزی را برایت روشن کرد؟

یک واکنش انتخاب کن یا سؤال و تجربه‌ات را بنویس. بازخوردهای خوب، موضوع یادداشت‌های بعدی را شکل می‌دهند.

با ارسال، برنامه ایمیل دستگاه باز می‌شود.

این متن ترجمه آزاد و بازنویسی‌شده است، نه بازنشر کلمه‌به‌کلمه مقاله اصلی.