疲弊のアーキテクチャ：技術リーダーシップがフローを殺す理由（そしてこれが道ではない理由）
特定の種類の疲弊がある。それは難しいコードを書くことや残酷なシステム障害をデバッグすることから来るものではない。一日の終わりに画面を見て、連続した会議の間を飛び回り、4つの異なるプロジェクトをジャグリングし、15分の枠で高リスクのアーキテクチャ決定をし、サポートシステムの消火に8時間を費やしたことに気づくことから来る。
あなたは一日中働いた。一日中決定を下した。それなのに完全に枯渇し、クラフトから完全に切断され、フローゾーンから何マイルも離れていると感じる。
最近、管理時間中に必要とされるマルチタスクの膨大な量を見ていて、同じ率直な認識にたどり着き続けている：まだどう直すかの答えをすべて持っているわけではないが、これが道ではないという事実は知っている。
最近、フロー研究者のSteven KotlerをThe Knowledge Project Podcastで聴き、脳が実際にどう働くかの分解が、私が感じていた正確な摩擦に硬い科学的言語を置いた。
本当の貧困は時間であり、資本ではない
私たちの業界で仕事を測る方法には皮肉がある。塹壕の奥深くにいるとき——構築し、アーキテクトし、システムを生かし続け、複数のプロジェクトをジャグリングするとき——お金は方程式の一部に過ぎないことにすぐに気づく。
Kotlerは、彼が金のない若い記者だった頃、編集者が電話してきた瞬間の唯一の反応が「どれくらい高く跳べばいい？」だったと話す。本当の執筆をするためには、誰にも属さない「非時間」——他の誰のものでもない時間——を見つけるために朝3:30に起きなければならなかった。
この感覚は責任が増えても魔法のように消えない。代わりに、より厳しい真実に気づく：このシステムで貧しいということは、自分のための時間を持たないということだ。
一日がコンテキストスイッチ、緊急ピング、瞬間的な決定のぼやけであるとき、あなたは自分のスケジュールを所有していない——システムが所有していると気づく。物事を前に進めながらも、深い集中、創造的な問題解決、または実際の呼吸の余地がゼロで残されていないために、完全に貧困を感じることができる。本当のレバレッジは管理しているものだけではない。ドアを閉め、ノイズをミュートし、カレンダーが公共の共有地のように振る舞うことなくフローゾーンに実際に入る自律性を持つことだ。常に空のタンクで走り、注意力を反応的な消火と交換しているとき、それが本当の貧困だ。
18チャンネル認知税
Kotlerは神経生物学の単純で容赦ないルールを指摘する：フローは集中に従う。脳が問題がカチッとはまりパターン認識が急上昇する状態に入るには、認知負荷——一度に追跡しようとしているすべてが消費するバックグラウンドRAM——を下げなければならない。
20年前、プロフェッショナルが中断される方法はせいぜい3つだった：電話、メール、またはドアをノックされること。今日？私たちは同時に発射する17から18の着信チャンネルを管理している。Slack、WhatsApp、プロジェクトボード、本番アラートの間で、ワーキングメモリは永久に断片化されている。
複数のプロジェクトとサポートシステムを担当しながら一日中会議に座っているとき、認知負荷は100%に釘付けになる。脳は効率エンジンだ。5つの異なるリポジトリと3つのステークホルダー議論のコンテキストを一度に保持しなければならないとき、深い問題解決のための余剰エネルギーはゼロになる。私たちは規律が足りないから集中に失敗しているのではない。環境がワーキングメモリを部品に分解しているからだ。
アーキテクチャ決定は30分枠に収まらない
ポッドキャストから家に響いたことの一つは、深い仕事の「苦闘」フェーズを私たちがどう誤解しているかだ。
フローは朝のスタンドアップとロードマップ同期の間でフリップするライトスイッチではない。それは重いロードフェーズから始まる生物学的サイクルだ——問題でワーキングメモリを過負荷にし、無意識の脳が引き継ぐまでの意識的な挫折の期間。さらに、睡眠が90分のREMサイクルで動作するのと同じように、覚醒した脳は生物学的に90分ブロックで集中するように配線されている。
今、それを技術管理の現実と比較せよ。
私たちは基礎的なアーキテクチャ決定——システムの信頼性とチームの速度を次の2年間決定する選択——を、採用同期とベンダーコールの間に挟まれた30分のカレンダーブロックの中で行うことを期待されている。システムアーキテクチャの複雑さをロードし、苦闘の閾値に達し、直感的な突破を22分のネット会議時間で達成することはできない。代わりに、重要な何かを見逃したという低レベルの不安を抱えながら、表面的なヒューリスティックに頼らざるを得ない。Kotlerが指摘するように、不安がある閾値を超えると、コルチゾールでシステムを氾濫させ、生物学的にフローを完全にブロックする。
出口を見つける
会議を排除したり、レガシーシステムを魔法のように自己維持させたりする銀の弾を持っているふりはしない。技術的な仕事をリードするとき、人々は決定を必要とし、プロジェクトは整列を必要とし、システムはサポートを必要とする。
しかし、これが道ではないと認めることが最初のステップだ。最高の認知エンジンを燃やさずにリーダーシップを生き延びたいなら、いくつかのことが変わらなければならない：
- 容赦ないコミュニケーションのバッチ処理：チャットアプリとメールをリアルタイムの中断ではなく、非同期キューとして扱う。一日の始めと終わりにバッチする。
- 90分ブロックを保護する：アーキテクチャとシステムデザインは断片化したカレンダーの紙吹雪の中では起こり得ない。決定が重要なら、着信通知ゼロの壁に囲まれた枠が必要だ。
- 混沌をチャンクに分ける：5つのプロジェクトが方向を争うとき、それらをすべてRAMに保持しようとすることはバーンアウトを保証する。巨大な目標を孤立した管理可能な問題に分解しなければならない。
- 「非時間」を守る：本当の統合は誰もあなたの注意を所有していないときに起こる——アイデアを実際にいじり、圧力なく反復できる静かな時間。
私たちはキャリアの多くの時間をシステム信頼性、クリーンコード、ソフトウェアのスループットに執着して過ごす。しかし自分の脳を、カレンダー招待のDDoS攻撃を受けているシングルスレッドサーバーのように走らせている。
常に利用可能で、絶えずコンテキストスイッチし、空のタンクで高リスクのコールをすることは名誉のバッジではない。それは私たちがリードする方法のバグだ。私はまだこれを中心に自分のスケジュールをリファクタリングする方法を図っている。しかし、その感覚——その絶え間ない摩擦とすべてをどうバランスさせるかわからない感覚——は、単に古い壊れた企業のプレイブックによる「良いリーダー」のなり方を知らないということを意味するだけかもしれない。そして正直なところ、それでいい。なぜならそのプレイブックこそがまず私たちを燃やしているものだからだ。