I think the more abstract point the author was trying to make with that statement was that teams should be allowed to define what they want to do, but the CTO i

I think the more abstract point the author was trying to make with that statement was that teams should be allowed to define what they want to do, but the CTO is the one who should be keeping an eye on the impacts of those decisions with respect to the rest of the organization. A good CTO is a bullshit deflector. And sometimes that bullshit is in the form of "Why should an engineer have to consider decades-long maintenance timelines including projects he or she isn't even associated with?" Sometimes the CTO needs to say "No" to a proposal, but the benefit to the engineer is the rest of the time they're isolated from having to think about impacts they don't want to.* *All of this is only applicable to orgs past a certain size