Uh, no. Not at all. (I actually yelled at the podcast. Sheesh.)
You don’t need a tool to accomplish what they suggested. In fact, when people start with a tool, they too often fail. Argh.
That work is complex and interdependent. Starting complex knowledge work with any tool defines the mental models, filters, and process for everyone very early. We become stuck in the tool mindset, not thinking enough about the problem. The tool creates an anything-but-agile approach, where we don’t adapt to the current circumstances. Too often, the tool forces people to think in very mechanistic ways. We think there is simple logic with simple answers.
I don’t see simplicity in organizations. I see “mess,” that oh-so-interesting mixture of culture and humans.
I do find some mechanistic tools helpful. When I need to hang something on the wall, I like a hammer to bang the nail (or whatever) into the wall. I don’t use a screwdriver for the banging, I use a screwdriver to tighten or loosen screws. I use a rollator to walk because I am more stable with a rollator than without. I also don’t use the rollator for banging nail into walls or for tightening or loosening screws.
That’s a simplistic approach to mechanistic tools.
Here’s the problem. All tools shape our thinking, not just about the result we want, but about our perceived problem(s).
Maslow’s Law of Instrument gave us the quote that “If all you have is a hammer, everything looks like a nail.”
In my experience, the more complex the problem, the less we can use tools that are more hammer-like. If the problem is complex, it’s possible we need several tools, each for the various steps in the process.
And, some tools get in the way of actually doing the work. (Don’t get me started on Word for writing. I don’t have enough time to count the ways that tool has failed me recently and over the years.) I don’t know about you, but I don’t use many of the features of the electronic tools I have. So many of the features don’t apply to me.
In software, we love our tools. Back when I was a young developer, we had structured design and programming. Then we moved to UML and CASE. Then object-oriented was going to save our tushes. Now, we have frameworks galore, for code and test, and for our process. Some tools help, given the context. No tool was or is a silver bullet.
We don’t need any more freaking tools.
We need ways to work where we can make our mental models clear to ourselves. We might need a tool to help us see the problem itself. We might need a tool to help us evaluate choices. Once we have a tool—if we decide we need one—we might need a way to define experiments and see the results.
I like to think of small tools that will help us make a decision now, and then help us see alternatives for our next steps.
That is the question this week: When do you need a tool?