Tools For Fools
So I spoke with a VP of App Development recently who in the middle of our conversation throws up his hands in frustration. I asked him what was up. He turns to me with a look of wild exasperation and says, “We are fools for tools!”
We had been talking about what his developers are using to get stuff done. As he started listing off tools, he quickly lost track of what he mentioned before. I do not remember the number, but it was a lot, most of which were not even used much anymore or had been totally forgotten. His team had a bigger collection of tools than products they supported.
We live in a tech utopia that provides a ton of software choices to do every imaginable thing you could possibly conceive of to getting your work done. But do we have it too good and are we jumping the gun before asking the most important question of all, “why do we need this”?
There are two lens by which I view tools. The first is does it directly address and solve the problem. The second is utilization value, which is derived from the following four factors:
· Potential upside — personal and organizational productivity gain
· Opportunity cost — how much time dedicated that could be used elsewhere
· Time to value — how soon can I get value
· Cost savings — what hard costs do I take out of the operating model
Some tools are obvious when you look at both ability to solve the problem and utilization. Code repository services are essential and a huge time saver. Some may not be so helpful or valuable, such as documentation tools or “rapid” application development tools. Then there are tools that are temporary just to get a particular job done, especially when migrating a legacy system.
How does this type of evaluation work in practice? Perhaps you are exploring the use of a knowledge management app. There are plenty of resources for publicly available developer and infrastructure knowledge, especially with the growing use of open source in enterprises. Could an internal knowledge management tool be of value then?
Let’s go back to the two lens I mentioned. First, is the lack of a centrally accessible and easily discoverable source for internal, proprietary technology knowledge a big enough problem in your organization? In other words, is access to common knowledge a barrier to developer productivity to the extent that it slows delivery of projects? The second lens is whether an internal knowledge tool would deliver enough of a boost to productivity and reduce costs across the team versus the time committed to implementing it?
With the large enterprises I work with, the answer has usually been yes to both questions. For regulated industries, there is even a third critical question to ask. Is not having internal technical systems fully documented and easily auditable a potential liability for the organization?
So back to our VP of App Development from the beginning of this post. He realized that the lack of tool usage was a problem and realized that the developers did not have a place to share best practices on how to use the tools. He realized the best way to address that is to use a collaborative knowledge management tool to allow the teams to document all of useful internal technology content and have it be accessible for everyone else, so that it becomes the trusted repository for the organization’s internal tools, products, microservices, and API’s.
When you consider your priorities, how does the introduction of new tools fit into those plans and how does that stack up against other key priorities?
Division by zero and its restrictions?
My son literally asked me this last week, and there is a site for all math answers!
We help IT leaders in enterprises solve the cultural challenges involved in digital transformation and move towards a community based culture that delivers innovation and customer value faster. Learn more about our work here.
