On Home Grown Tools

If you’re playing a round of buzzword bingo, I’ll give you a quick win. As organizations, we have things that fall squarely in the middle of our (ready for it?) core competencies. For the rest of the problems looking for solutions, someone else has made that problem space their core competency. If we all stay in our lanes, build what we should build and buy the rest, we can focus our energy on the things that differentiate us from our competition and deliver high-quality, high-value solutions to our customers.

When we build our own home-grown tools for our internal customers, the value of these tools should be measured in adoption, and efficiencies recognized by the consumers of these tools.

Before embarking to build custom, internal solutions, we need to ask ourselves what problem we’re aiming to solve, if this is already a solved problem and if buying an existing solution if more cost-effective. Given the cost of building, maintaining, and supporting software, the answer to this is typically going to be a resounding “yes”.

If you do decide to build a custom tool in-house, it should be done with clear criteria for what constitutes success, a plan for how it will be supported if it is successful, and a plan for how/when it will be shut down if it isn’t successful enough to warrant prolonged support. You need to be prepared for both cases or you end up with poorly supported tools that many people depend on, or the you end up supporting something that isn’t cost-effective for a couple internal customers.