Distinguish tools vs. methods vs. policies. Tools that support a range of methods and policies are much more useful a and much more likely to get used.
Frank Chimero: No New Tools
What’s interesting about digital tools for information work is how frequently they are born from a specific ideology: someone thought work should be done in a certain manner, they found no tools to support that method, so they set off to build their own tool that presumes their ideology is true and best. Thus, we get another to-do app, Twitter client, or project management app.
Everything that’s made has a bias, but simple implements—a hammer, a lever, a text editor—assume little and ask less. The tool doesn’t force the hand. But digital tools for information work are spookier. These tools can force the mind, since they have an ideological perspective baked into them. To best use the tool, you must think like the people who made it. This situation, at its best, is called learning. But more often than not, with my tools, it feels like the tail wagging the dog.
Frank Chimero in “No New Tools“
For a while I was fighting with the auto-correct features built into various content management systems after I enabled “Correct Spelling Automatically.” It had seemed like a great idea given the number of typos I produce, but it would not let me enter words easily that were not in the built in dictionary and often miscorrected a typo to the wrong word. Better to go back to red squiggly lines under a word that it cannot find in the dictionary. The word “bootstrapper” comes up a lot on this blog, always with red squiggly lines (which can mask when it is misspelled).
Entrepreneurs try to design software tools that make customers lives easier. But it’s hard to avoid assumptions about “the right way” or “why would you ever want to do that” from creeping in. It’s not uncommon to visit a customer who has been using your product for six months or so and have to repress the urge to say “you are using our product wrong!” and instead say, “Wow, that’s an interesting use for our technology: what led you to apply it this way?”
People Manage People, Tools Manage Data
IT organizations developing tools face a double whammy: their own built in assumptions and the end user trying to bake policy into the tool so that it cannot be used to violate policy. I remember watching a demo of a new in-house scheduling tool a few years ago and one of the features was that the schedule was always feasible. You could not over-commit anyone’s time or assign them to competing projects on that theory that people cannot be in two places at once and we should make plans based on extraordinary efforts. Good as far as it went but it rendered the tool useless for planning (which was about two-thirds of the motivation, time tracking was the other primary goal) because you could not enter a preliminary plan and see where it was infeasible. You could enter a plan with slack and underutilized people or equipment, but you could not temporarily overcommit and then shuffle assignments to make it feasible.
We had this same conversation with a recent BeamWise prospect: they wanted the software to prevent any invalid configurations from being designed. Our suggestion was that it was useful to know how much margin/overlap you had between conflicting elements instead of simply knowing that two or more items would not fit together correctly.
Allowing For Infeasible Solutions Enables Rapid Exploration
I am not advocating for accounting systems that don’t add expenses correctly or tax software that does not produce a correct return. But one of the advantages of software is that it allows you to investigate hypothetical configurations and alternate futures. Think about how you can enable exploration of a design space as much as validate that what is being designed is correct.
Related blog posts
- People Manage People, Tools Manage Data
- The Best Feedback From Your Early Customers Is a Story
- Don’t Practice Veterinary Marketing: Talk to Prospects
- Connecting Technical Know-How With Customer Needs
- Appreciative Inquiry Mindset is Essential to Customer Discovery
- Kierkegaard on the Art of Helping Others to Understand which offers this advice by Soren Kierkegaard “The helper must first humble himself under the person he wants to help and thereby understand that to help is not to dominate but to serve”
Here are a few on BeamWise:
Pingback: SKMurphy, Inc. Esther Derby's Six Rules for Change - SKMurphy, Inc.
Pingback: SKMurphy, Inc. Managing Change in an Organization: An Incomplete Resource List