レイチェルは新しいチームに参加し、そこでは上司のザーンが、最低コストでウィジェット生産を最大化することに焦点を当てた、メトリクス主導のアプローチを強調していました。自動化された生産ラインは複雑なソフトウェアを伴い、テストの制約から、変更は実際の生産でのみ検証されていました。レイチェルの最初のタスクは、ユーザーは常にExcelを好んでいましたが、6つのデータベースからデータを取得するGoogleスプレッドシートのメトリクスダッシュボードを更新することでした。チームは、「単位時間あたりのウィジェット生産数」のような出力メトリクスのみを追跡しており、システムの動作やボトルネックを説明するための詳細なデータはありませんでした。例えば、自動品質管理スキャナーは、ウィジェットが拒否された理由、さらには拒否されたアイテムの数を直接記録していませんでした。ソフトウェアへの変更は全体的な出力メトリクスに対してスコアリングされ、これらのメトリクスはノイズが多く、ソフトウェア自体以外の外部要因の影響を受けていたため、検証が困難でした。拒否されたウィジェットを記録する変更を実装しようとするレイチェルの試みは、当初、彼女のコードではなく環境問題によって引き起こされたメトリクスの後退によって妨げられました。限られたテスト実行とメトリクスの後退を考慮する必要性から、単純な変更でさえ検証に数週間かかることがありました。レイチェルは、有用なシステムモデルを構築することを期待して、より詳細なデータを収集するためにコードにインストルメンテーションを追加し始めました。しかし、ザーンは主要な出力メトリクスの即時改善に固執していました。彼は、そのような診断データは「主要メトリクス」ではないと述べ、それらのメトリクスがそのように動作する理由を理解するためのデータを収集することの価値を却下しました。これは、システムの理解を求めるレイチェルの願望と、トップラインのパフォーマンス指標に焦点を当てるザーンとの間に根本的な対立を生み出しました。レイチェルは、トップレベルのメトリクスを改善するために行った変更が、その変更の動作を説明するためのインストルメンテーションも含まれるようにすることで、妥協点を見つけました。この戦略により、メトリクスの改善に対するザーンの要求を満たし、システムのオブザーバビリティを段階的に向上させることができました。最終的に、包括的な洞察なしにトップレベルのメトリクスを推進することと比較して、複雑なシステムの理解は低い優先順位のままでした。