> if documentation is the metric, the organization will prioritize documentation, regardless of its effect on delivery. If working code is the metric, documenta

> if documentation is the metric, the organization will prioritize documentation, regardless of its effect on delivery. If working code is the metric, documentation may still happen if it helps to deliver working code. IMO, good organizations should have both metrics. You should document your intent, and then you should be able to show that it worked out after the fact. "Working code" is a lagging metric with many dimensions (functional, secure, performant, etc.). If your only reason to believe you will get to working code on all those dimensions on a 6 month+ project is that the person who is building it thinks it's right, that's a big risk. It seems like you're describing a particular kind of dysfunctional org where there's top-down mandates for forms of documentation that aren't valuable for sharing plans or informing later decisions. That hasn't been my experience of how design is done where I've worked, where writing designs is a collaborative process that starts with your team.