The Leadership Team

Every other role in this book gets a chapter about how their daily work changes once contracts exist. Leadership's chapter is different, because leadership's job is deciding whether the rest of this happens at all. How much autonomy an agent actually earns on a given system. Whether extraction gets funded as a real program or squeezed into whatever time is left after the roadmap. Whether the engineers whose tribal knowledge is quietly holding the company together see the shift as a threat to their value or a way to make it permanent.

Chapter 11 doesn't treat that as a soft, cultural problem separate from the technical one. The two are the same problem. A capability graph that nobody funded the time to build doesn't exist no matter how sound the argument for it is. A senior engineer who reads the extraction program as "tell us everything you know so we need you less" will, understandably, slow-walk it. The chapter is about making the restructuring case in terms a leadership team actually has to weigh: what it costs to do this, what it costs not to, and why the second number grows every quarter the decision gets deferred.

It ends where a leadership chapter has to end: with what to actually do Monday morning, at whatever scale you're operating at, whether that's a two-hundred-person engineering org or a team of twelve trying to get ahead of a problem before it's load-bearing.