“A” for Effect: 4 Situations Where Doing Nothing Beats Doing Something
If you’re a conscientious worker, your bias towards immediate action may be accidentally hurting the bottom line.
We’re paid to work, so it makes sense that we should generally be doing stuff while we’re there. Unless you’re explicitly on retainer, there’s an implicit idea that you’re being paid for your action, not for your inaction. Even on retainer, the idea is that you’re being paid for the chance that your action might be required. The retained lawyer may be sipping margaritas on the beach, but he’s paid to put them down fast when the need arises.
It’s hard to find the employer who wants to pay you to do nothing at all.
If you have no qualms about pulling the wool over your employers eyes to see how much you can “get away with”, this article is not for you. You’re already taking all my suggestions, you’re probably more of an expert than I am.
This article is for the effortful employee who unwittingly takes action he shouldn’t. It happens all the time. I see it all around me. I probably do it myself, despite being on the lookout. Here’s the thing: if I’m your manager, I would much rather you take no action than do something well-meaning that hurts the business.
Work is not an “A for effort” situation. It’s an “A for effect” situation.¹
With the goal of maximizing effect while minimizing effort, and knowing that most things in work (and life) are rife with uncertainty, one of my most frequently used tactics is delay. I find delay to be a safe and successful tactic in countless scenarios. Not only in the “count to 10 before responding” situations where I might say something regretful, but also as a strategy for avoiding whiplash, waste and buyer’s remorse on behalf of my team. There’s also a kicker:
Frequently when I delay something, I quickly find it doesn’t need to be done at all!
Particularly in engineering management, where product decisions change fast and engineer context-switches cost money, managers who wait 24 hours before course-correcting based on their latest meeting will save their companies boatloads.
While businesses want to “move fast,” there’s a misunderstanding that individuals taking fast action translates into companies moving fast. In fact, the reverse is often true. Here are a few scenarios I’ve encountered where employees reacting quickly slows things down for the company.
#1 / Anger and Frustration
This is the easy one. Take the advice from kindergarten. If you’re angry with your coworker, count backwards slowly from ten before you yell something that gets you in trouble with HR.
Badly handled communications cause a big toll in productivity, and can even cause long-term damage.
This is not to say you should bottle it up. Just be careful with how you respond, and take a breath before you do.
#2 / Boss’ New Idea
Do what your boss says, and your boss will be happy, right?
Not right away. Write it down, and come back to it 24 hours later. For argument’s sake, let’s say there are three ways this plays out:
- 24 hours later it’s still a good idea. You finish up your last task, get started on the new one, and both your boss’ last idea and this new idea get done, in that order. You have taught your boss that you will finish what you start, that you are consistent, and that you don’t unthinkingly execute whims, and (perhaps most importantly) you did not take “my boss talked to me” to mean “I must re-order my tasks according to the last thing he talked to me about”
- 24 hours later he comes to tell you it’s no longer a good idea. Good thing you didn’t waste your time, or even lose focus on the last thing you were doing.
- 24 hours later it’s still a good idea, but needs some more thinking through. This is the “realistic” scenario. There’s almost no such thing as a whim that appears from nowhere, gets executed, and is a huge win. In this case you might think that your 24 hour delay caused some delay in the tail end of the project. Waiting 24 hours to get started means the project finishes 24 hours later, right? Not if there’s ambiguity to be worked out. Usually if the project hasn’t been thought through, starting before it’s ready will cause more time lost in thrash than you’ll gain in the first 24 hours. Most of the time, you’re better off playing video games for that first 24 hours.
Let’s recap. By waiting 24 hours, you have risked nothing. By waiting 24 hours you have potentially earned more trust from your boss, saved the frustration of having lost 24 hours of your own effort to the wind, and helped identify that a project needs more thinking-through before proceeding. Nice!
#3 / Changing Priorities
This one is more about fessing up to reality than it is a deliberate tactical move. In order to understand the idea, we need to come to grips with what a priority is. Here’s Merriam Webster:
[A priority is] something given or meriting attention before competing alternatives
It’s just the order in which a list of things should happen. It’s a ranking of importance, but with some dash of “how hard is it?” thrown in for balance.
Priorities should take longer to execute than they do to change. If you have a list of priorities that keeps shifting around all the time, it’s actually a sign that your priorities aren’t clear. Demons lie there.
The reason to delay changing priorities is because if you understand your priorities well, they can’t change fast. Your to-do list might change fast if you decide to change how you’re approaching a particular problem, but the big-picture problem you’re solving — the prioritized things — probably doesn’t.
For example, if you’re trying to broaden your customer acquisition funnel, you might have two approaches you’re working on (call them A and B). You’ve decided to do A first. Things might change, causing you to start working on B instead. But the priority in this example is “broaden customer acquisition funnel”, which would only change if you finished, or something became more important than broadening the acquisition funnel.
See what I mean? If it’s important to broaden the acquisition funnel, that’s a priority that’s not going to just disappear overnight.
That said, organizations have numerous priorities that they’re working on simultaneously, and they sometimes conflict. In a small company, you might be working on the customer acquisition funnel then get yanked off to work on firefighting for a customer who was already acquired. This could yield yet another new priority: stability of production systems. If you’re an engineering team of one, this is bound to happen.
#4 / It’s the Best Solution, But It’s Still Bad
Sometimes, there just isn’t a good way. The product team wants to deliver a simple-sounding and reasonable feature, but the only way for engineering to build it involves tradeoffs that don’t make sense:
- Yes, we can build it! But we’ll have to change all of our data models first.
- Yes, we can build it! But we’ll have to build it three times for each of three different contexts.
- Yes, we can build it! But we’ll have to migrate our infrastructure to another provider first.
- Yes, we can build it! But users won’t see it until we complete this other project we’ve been putting off for years.
If you’re hitting tech debt that changes the balance of the “are we willing to commit that much time to it” equation, it’s usually best to slide higher priority projects higher into the queue.
In this scenario, delay is still the right tactic, but it’s harder to execute because you need to tell people about it. You can’t just not begin a large project that everyone thinks is underway: you’ll need to bring all the stakeholders along with your decision to delay or reprioritize.
Use With Caution: When Not To Delay
I’ll conclude by noting there are also times and places where you don’t want to delay. While I’ve found selective delay to be one of the most useful tools in my daily toolbox, there’s one area in particular you should never delay. Human Dependencies.
If you discover in the middle of working on something that you’ll need something unanticipated from someone else, that needs to rise to the top of your list immediately. Even if it’s small. Even if you just need someone to hit “reply” on an email to say “yes, Phil should have permissions to create a new API key,” — and you won’t need that permission until a week from now — you should write that email now.
People go on vacation. Other people’s workflows will be interrupted. You’ll need to get in a queue. Sometimes what you think is simple will be hard for someone else. Maybe they’re using a frustrating strategy of delaying everything 24 hours! Maybe it’s just you being courteous, and giving someone all the time you can.
Whatever it is, if you need something specific from someone else, take action now!
Notes
¹ This oversimplifies, because it discounts risk. I’m a firm believer that businesses need to find ways to reward takers of good risks that don’t pan out. But as well documented by Daniel Kahneman in “Thinking Fast and Slow”, most organizations reward based on results rather than the quality of risk assessments. This leads to conservative decision making at all levels of large organizations. It’s also unrelated to the idea in this article of “useless effort.”
Was this piece thought provoking? Did I miss something huge, or hit the nail on the head? Please reach out in the comments, and connect on LinkedIn. I want to learn from your perspective!
This story is published in The Startup, Medium’s largest entrepreneurship publication followed by 337,320+ people.
Subscribe to receive our top stories here.
