Tool builders

A post titled If You're Not Gonna Use It, Why Are You Building It? contains some sage advice:

If you find yourself creating something, and you don't understand how it will be used, and you don't plan on using it yourself, then it's time to take a few steps back and reevaluate what you're doing.

"Because someone told me to" is rarely a good reason to be building something. If someone can accurately describe what someone else wants to have built without being able to articulate why they want it, alarm bells should be ringing.

This problem arises when deciding whether to consolidate tool-building expertise in one place, separately from the tool users. Clearly there are scenarios where one extreme makes sense (imagine the chaos if the sys admin role was pushed out to everyone in a low tech-expertise environment) but with complex, bespoke tools, the answer is rarely as obvious.

Specialize and consolidate expertise on the tool, platform or system, but risk having the builders lose touch with how and why people are using it?

Or, align tooling ownership with people using it? In many ways this is equivalent to 'everyone owns it'. Changes and feature additions are well understood but aren't necessarily built in the context of a broader 'vision' and therefore might not work with other aspects.

There are benefits and drawbacks to both approaches.