https://www.blockchainengineer.tokyo/entry/makersschedule
タイトルは、ポール・グレアム氏（Yコンビネーター）の「メイカー（作り手）のスケジュールとマネージャーのスケジュール」(Maker's Schedule, Manager's Schedule) からの引用です。
マネージャーは多くのミーティングをこなすなど、1時間単位でタスクにあたりますが、エンジニア（プログラマ）は最低でもまとまった半日単位の時間を作業に必要とする、と書かれています。
日本語訳
エンジニア上がりのプロダクトマネージャーとして開発もプロダクトマネジメントも並行してこなしてきたのですが、意思決定のためのミーティングスケジュール、自身が開発を行うためのスケジュールをやりくりするバランスに腐心していました。
自身のタイムマネジメントで特に感じた点として、ミーティングとミーティングの間に1時間が3コマある時の開発生産性と、3時間まとまった程度の空きがある中での開発生産性は等価ではないことでした。同じ1時間あたりでも後者の生産性の方が数倍高かったように思います。この現象について2009年のポール・グレアム氏のブログで言語化されていました。
また、開発チーム自体のマネジメントや他チームとのやりとりも行うようになったことで、チームの生産性を上げるために気をつけるべきことを考えています。この記事では、エンジニアの時間の使い方と、チームの生産性を上げるためにマネージャーはどのように振る舞うべきかを考えてみます。
They generally prefer to use time in units of half a day at least. You can't write or program well in units of an hour. That's barely enough time to get started. 概してエンジニアは最低限半日の時間を使いたい。1時間単位ではろくにコードを書くことはできない。取り掛かるのにぎりぎり十分な時間である。
件のエッセイからの引用ですが、コードを書く仕事は取り掛かるエンジンがかかるまでに時間がかかります。私の感覚ではありますが、ビジネス的な意思決定や普段の生活での頭の使い方と開発とでは頭の使い方が異なっており、切り替えに時間がかかるように感じます。コードを書いたことない方には数学の証明課題など、普段と異なる頭の使い方を要する課題に取り掛かった記憶を思い浮かべていただくと良いかもしれません。
ビジネス業務と開発業務を1日の間に行き来していた時、頭のスイッチングコストが高く、自身のパフォーマンスについて「人と話していると、コンピュータと話すのが苦手になって、コンピュータと話していると人と話すのが苦手になる」と冗談を言っていました。
しばらく集中してコードを書いていると「フロー状態」と呼ばれるような集中状態になることがあります。楽しく作業に没頭している状態です。コーディングに限らず、作業に没頭して普段の数倍の生産性を出せた経験がある方は多いでしょう。
一方でマネージャーのスケジュールは、指示や意思決定のためのスケジュールです。1時間単位でミーティングを行ったり考えをまとめたり、開発などの実作業が伴うわけではないので、細切れの時間軸での動きになりがちです。
エンジニアチームのマネージャーには、チームメンバーがフロー状態を作りやすい環境の用意が求められます。
For someone on the maker's schedule, having a meeting is like throwing an exception. エンジニアのスケジュールにおいて、ミーティングは例外処理を行うようなものだ。
エンジニアが開発でフロー状態に入っているとき、ミーティングが入るとそのフロー状態は中断され、再度フロー状態に入るための時間を要します。これが「スイッチングコスト」です。
とはいえ、作業の進捗状況を確認することや、1on1などでミーティングは必要です。ミーティングはなるべく作業に入る前の朝か、作業が終わった後の時間帯である定時少し前に設定することが望ましいのだと思います。9~18時が定時の職場で15時などに入れると午後を完全に分割してしまうのであまり望ましくはないでしょう。