In this article, I discuss some of my thoughts on how tools can make some tasks harder while making others easier and what it means for our organizations. I also go into why adopting a tool that makes some tasks harder may not be all that bad and touch on a strategy or two for managing these tools. I’m considering this a first public draft rather than a final article. I am curious how you all see it.
I am using “tool” in this article to refer to any technology, any process, or any other thing that you may adopt to get work done. It could be a hammer, it could be a database server, it could be a management theory. The notion of assessing easiness applies to all of these.
What do I mean by easiness? Isn’t that a given? Sort of.
Easiness comes in many forms and most of our tools are not perfect. Let’s think of driving nails. Is the old school “Armstrong”1 carpenter’s hammer easier than a pneumatic nail gun? The pneumatic nail gun makes the individual task of driving a nail easier: just pull the trigger. However, the hammer has much simpler set up requirements: get it out of the tool box. Setting up the nail gun is harder: get out the compressor, plug it in (where?), connect the hose, load the nails. On top of that, the nail gun and compressor need regular maintenance. Even cordless electric nail guns used for smaller nails still need to be charged up and maintained. The nail gun can only be used for driving nails and only those nails that fit it, the hammer is much more versatile. The hammer has a claw to pull nails with and only the hammer can be used for general purpose hitting and prying.
If we were setting out to buy a nail driving tool, we can say that a pneumatic nail gun makes nail driving easier at the cost of making setup harder and other tasks are impossible (thus, we need other tools). Let’s list out what we need to do.
|Drive Correct Nails
|Drive Other Nails
|Transport & Storage
So, why would we buy the nail gun? We can buy the hammer and do everything. I am willing to bet that I didn’t even finish the sentence before you were thinking “Yeah, but…”
The obvious answer (at least if you’re semi-familiar with these tools) is that the cost of driving a single nail with a nail gun is so low, plus the ease of transporting a hammer so high, that it is worth it to have both.
When someone(the “promoter”) is trying to get us to adopt a tool (e.g., a sales person trying to sell us their product), they will often point to how easy the tool is to use. Even though they may be trying to sell you on other factors like the opportunities the tool creates or the risks it may reduce, many of the other features they are selling us on can be reduced to down to making one thing or another easier. That could be ease of securing your systems, ease of reporting financial data, ease of deploying software, ease of interacting with a database, handling more packages at once, and so on. I am lumping “helps you do more” in with easiness, so almost any efficiency gain promised can be called an easiness promise. Even when the promoter tells you “this will make your employees happier,” the reason will often come down to making a task easier. Conversely, the more the promoter stands to gain from you adopting the tool, the more you can be sure they will try to avoid talking about the things the tool makes harder. That does not lessen the need to discover that detail, it just makes it, well, harder.
This isn’t going to be a surprise: Just like I did above for nail driving tools, you can and should plot a table or graph with all of these categories of ease and then rank how much they matter to you. Even if you just do that in your head, you still need to do it. You probably do it automatically. So why am I writing an article on the obvious?
We are taught to weigh pros and cons, we talk about “build vs. buy” in the software world, we examine the cost of adoption vs cost of operation. We don’t discuss how you determine why a given feature matters except vague mutterings about identifying return on investment (ROI). ROI is a financial calculation. While we can reduce many things to financial terms, it can be very hard to calculate in financial terms the risk that you might lose an employee who got tired of dealing with a tool that makes their life harder.
What about those tools makes someone’s life harder? I’m not talking about tools that don’t impact already hard tasks. I mean cases where the tool actually hurts more to use for some tasks than the tool (or lack of tool) that it is replacing. The emergence (re-emergence?) of the “Low Code” and “No Code” development tools segment (e.g., Microsoft Power Apps, Mendix, UIPath) in the late twenty-teens started me down this line of thinking. As I developed that thinking that sometimes tools make our life harder, I started thinking about more traditional development tools like the Object Relational Mapper tools that promise to make it easy to communicate between applications and databases. In both types of tools, you can find products that fall into this pattern: they make the easy tasks easier and the hard tasks harder. To paraphrase an old joke about architects and engineers4: we’ll go on making the easy tasks easier and the hard tasks harder until the easy tasks are automatic and the hard tasks are impossible.
Let’s use a nice business-y graphic to help illustrate:
Going left, hard tasks get harder. Going right, hard tasks get easier.
Going down, easy tasks get harder. Going up, easy tasks get easier.
This model is designed only to help summarize. We still need to think about each feature of a tool and assess them independently.
When we see easy tasks getting easier while hard tasks get harder, it could be because the creator of the tool is targeting everyday use. The promoter may think we have experts working on hard tasks and may even take the position that there are fewer of those hard tasks to do. They may also think we would get another tool to do the hard tasks. Think of nail guns and hammers.
Looking at the labels on the graphic, “The Dream” region is where both types of task get easier. This is rare, but it happens. Because it’s the happy place, I’m not going to spend any more time on it. We Do our victory dance when we find these tools. We will never wear your dancing shoes out because there are very few tools that will put us in the Dream.
It’s more common to find the “Everyday Efficiency” zone where easy things get easier, but the tools doesn’t change the hard tasks very much. When applied to software, the upper regions of this graphic are inhabited by end user focused tools. They make the non-technical or low-tech user’s life easier, most of the time. When these are business tools and they make the easy work much easier, but the work hard harder, then we may consider hiring specialists to handle those hard tasks. That’s why it’s labeled “The Specialist Sector” here: expect to train specialists, develop special procedures, or set aside dedicated time to handle those hard tasks. If those hard tasks are rare compared to the easy tasks, this can be a fine place to live in. If the hard tasks become impossible or cost prohibitive, then we need to look for another option.
Going across that upper right quadrant, we find the area where the hard tasks get easier, but the easy tasks don’t become easier. This is good place to be in when we need to tackle the hard tasks often and especially when those hard tasks soak up the time of some of the best people in the organization. It’s the possibility of freeing up the most talented people that led me to label this area the “Innovation Engine”. I don’t use the label because the tool drives innovation, more that it keeps key people from being distracted and thus lets us spend more time innovating in other areas.
Key thought: Few tools are going to bring us into The Dream by themselves, but if we can assemble the right combination of Everyday Efficiency and Innovation Engine tools, we can find ourselves there.
Moving downward, we get into making the easy things harder. If that comes with the benefit of making hard tasks easier, we can be ok with that. More training or more oversight can help mitigate the increased difficulty of easier tasks, so this is labeled “the School Zone” — I was also tempted to call this the Specialist Zone #2. Again, we can look to apply other tools (keep in mind a process can be a tool) to lift ourselves out of this zone. If we have a lot of hard tasks and not a lot of easy tasks, we may be happy to make the easy tasks harder if it means alleviating the misery of the hard tasks.
That bottom left looks like a scary place. Is “the Danger Zone” a strong enough statement. Should we label it something like “Here be dragons?” Every thing is harder! Why in the world would we ever want these tools?
We run into a situations where we have no choice. New regulations can change the rules we operate by (think HIPAA, GDPR) and there simply are no good solutions for us to adopt. The result is that we adopt a painful set of processes and technologies.
On a more positive note, when we identify new market opportunities, we can end up working more manually than we’re used to. Over time, we’ll look to add tools to bring us up and to the right, but the market opportunity makes the pain worth the gain for now. Hopefully, we’re only at the bottom of our little chart when we are on the Cutting Edge, that’s why it’s labeled as such.
It also may not be quite true that everything is harder. One thing may be easier and that one thing may be worth dealing with all the other grief we get. On the other hand, if we’re replacing an existing tool with one that moves us down here and there’s not a good reason, we should be brave enough to halt the path we’re going down. That can require flexing some political muscle in your organization if the tool has strong advocates or money has already been sunk into the tool.
The theme of the Danger Zone is we need a reason that goes well beyond “it is better.” Whether that’s regulation, opportunity, or something else, don’t stay too long in this area. Find or make the tools you need to ease the tasks you made harder as soon as you can.
While this model is a bit too simplistic, it’s a good starting point for understanding a philosophy of a tool. Many tools deliberately choose to focus only on making certain tasks easier and that’s fine. The key to being happy and successful with our tools is knowing what they make easier and figuring out when we need to find or make supplemental tools. To borrow the line from an old kids’ show, “knowing is half the battle.”5 If it helps or you have your own ideas, please let me know via LinkedIn or Mastodon.
“Armstrong” is a bad old joke name for unpowered tools. They make you use your arm muscles, hence they make your arm strong. The joke uses the fact that Armstrong is also an English & Scottish family name and so sounds like a brand name. It’s a bad joke, but it was common enough on the construction sites that I worked on in my youth that everyone knew what you means by an “Armstrong” saw or hammer. ↩
I’ve driven thousands and thousands of nails. It’s not hard for me anymore. But it took many bent nails, misses, and sore thumbs to get to that skill level. Hence, I’m calling it hard here. ↩
It isn’t impossible to hit things with a nail gun, but chances of a bad outcome (broken tool) are high. ↩
“An architect starts out knowing a little about a lot. They go on learning less and less about more and more until they know nothing about everything. An engineer starts out knowing a lot about a little. They go on knowing more and more about less and less until they know everything about nothing. A contractor starts out knowing everything about everything. Due to their association with architects and engineers, they end up knowing nothing about nothing.” That joke, author unknown, hung on the wall of my parents’ office for years. ↩
If you were a boy in the US in the 1980s, you probably know where this came from: https://tvtropes.org/pmwiki/pmwiki.php/Main/AndKnowingIsHalfTheBattle? ↩