I might not have been clear, but this was my manager, who was not spending time pair coding with us and things like that. His job was to deal with things at a m

I might not have been clear, but this was my manager, who was not spending time pair coding with us and things like that. His job was to deal with things at a much higher level, and this was the type of thing he would do in meetings where we were writing design documents for complex new features or entire new systems; at the abstraction where he was involved, the discussion wouldn't be about the "how" but the "what" and the "why. Building off of your example, let's say one of his engineers wrote a design document about a new piece of data called Foo that was getting added to our database, and the document mentioned that the new piece of data would be considered optional rather than required because we'd only have access to it in the newest version of the client software, and the EOL for the last version not to provide it was two years away. He might mention that customer Bar just upgraded to the latest version of our client and expressed interest in using the Foo data, and ask why they wouldn't be able to get the Foo data from their client, with the idea that he'd be corrected and told that the customer would be able to get the Foo data because they had just upgraded and the latest client had access to it.