Time vs. attention April 27, 2026

Spending time on something and giving attention to something are not the same thing. At all. Mistaking one for the other can have real impact, as I found out when a customer called me a “grumpy old guy” when I was fresh out of university.

The following is a reflection on the difference and why it is important. Maybe it can save you the pain of having to find out the hard way.

Time ≠ attention

I can spend time on something without giving it a lot of attention. For example, I had the initial thoughts that led to this blog post while cycling home from shopping groceries. I didn't really pay attention to my cycling beyond being generally aware of my surroundings (as one should when on the road).

Of course, paying attention to something does take time, but the quality of the attention does not depend on the amount of time you spend. Or rather, it does, but it is inversely correlated. The more time I spend on something, the harder it is to keep up my attention.

Time without attention

Spending time on something without giving it attention means I don't get much from the experience. This only makes sense if all I'm interested in is the result. When cycling home with my mind elsewhere, I wanted to get my groceries home, and (to a lesser extent) exercise my body a bit. I wasn't really interested in the cycling per se. As another example, I often do chores like washing the dishes or ironing while listening to podcasts. I'm not interested in the chores themselves, but I do want the results, so I spend time on them, but don't give them attention beyond the bare minimum required.

This works for tasks I can actually do without thinking about them, but it doesn't work for tasks that require a non-trivial amount of attention from me to complete them successfully. Such tasks don't leave enough attention free to give to something else.

Into which category a task falls depends not only on the task itself, but also on my expertise.

Two kinds of expertise

As I see it, there are two kinds of expertise. One is the ability to perform tasks efficiently and without them taking much attention. For example, the guy who delivered our new washing machine last week unpacked and installed it with the minimum number of hand movements required and almost without looking. And in my current team, there is a colleague who can handle incidents like nothing. He immediately knows where to look for any given problem, how to decide if it is an issue in our system or elsewhere, and who to talk to in various cases.

You develop this kind of expertise, let's call it process expertise, by repetition, and its main benefits are efficiency and a low error rate. The washing machine guy installs washing machines all day long, and he can do it much more quickly and much more reliably than me. As a software guy, I would probably end up with a leaky connection and forget to remove some transport protection part. And if I was extra careful, I'd take ten times as long. Same for our incident champion. Having handled a lot of incidents, most of them now look familiar and it's just more of the same for him.

The other kind of expertise is the ability to solve new problems – or even new kinds of problems – effectively. Let's call it solution expertise because it's the kind of expertise you need to find a solution when the process breaks – as opposed to process expertise, which makes the process fast and smooth as long as it's working. If the washing machine guy is given a new type of washing machine with a different connector, or if the installation site has a nonstandard water connection, that's when he needs solution expertise. Similarly, our incident champion needs to call upon his solution expertise when he encounters an incident the likes of which he hasn't seen before.

What does expertise have to do with the topic of this post? Well, process expertise enables you to spend less time when doing something. And it also reduces the need to pay attention, freeing it up for something else.

Solution expertise, on the other hand, requires the ability to focus your attention to such a degree that you can solve previously unknown problems. You don't necessarily save time on something, but you unlock potential that has been blocked by the problem before. And you do this by giving more attention (and possibly also time) to an issue, not less.

Automation

There is another way to save time: automation. If you can codify your expertise, you can automate away the need to spend time applying it. So far, this seems to apply primarily to process expertise, recent attempts to apply it to solution expertise notwithstanding.

You do this by focusing your attention on devising an automated solution, thus unlocking time-saving potential when the solution is deployed. Giving attention requires a certain time investment, but this can hopefully be recouped later – if the solution saves more time than is spent building and maintaining it.

I did this recently in a project with an elaborate multi-step process for getting small fixes (like dependency updates) into production. After going through this process several times, I wrote a script that did much of it for me. It wasn't 100% reliable, but it still saved time when applied multiple times per week.

Saving even more time by paying attention

Giving attention to a process can save time in another way, too. Sometimes, it enables you to realize that parts of it are redundant or unnecessary, or that the process shouldn't exist at all. Once, I was in a team that had a manual process for routine database cleanup, and a few team members were discussing how to improve this process. They did what I described above: applied attention in order to make the process more efficient. Having seen a few database issues in the course of my career, and having an outside view due to being relatively new on the team, enabled me to see the overarching pattern and ask the question none of them had considered: why was the cleanup even necessary?

It turned out the transaction handling in the application was broken, leaving stale database entries behind. Once this was fixed, there was no need for the cleanup anymore. We saved even more time than if the cleanup had been automated and increased quality at the same time.

Giving this much attention to a process you already have expertise in requires special effort precisely because of this expertise. The whole point of process expertise is to spend less time and attention on the process. Sometimes, this can impede progress because it makes you blind to alternatives.

Attention in knowledge work

I believe that knowledge work – and in particular, software development – is attention work. Things I'm spending time on that don't require much attention should be automated as far as possible. My value proposition as a software architect and developer is that I can focus, give full attention to hard problems, and solve them. In other words, I bring solution expertise.

What I actually do at work consists of a mixture of this and some repetitive “process” stuff. Some of the process is mandated, some things are just hard to automate due to tooling restrictions, but in general, I strive to eliminate this as much as possible so I can focus my attention on the things that require it.

Getting it wrong

Mistaking a situation that merely requires spending time on it for one that requires attention results in less efficiency. How bad this is depends on the situation. It might even have positive consequences if it leads to new insights that might save time later on.

It's much more critical the other way around. If a situation requires your full attention, but you try to minimize that because you believe only the result is important, the consequences may be dire indeed. The worst mistake I personally made in this regard occurred early in my career. In my first job out of university, I was part of a team developing a product that we licensed to customers. It was a B2B product, so few customers with large budgets, which made the customer relationship very important. The development team was small and was also responsible for customer support, which meant answering phone calls from customers who had questions about our product.

One day, a colleague who had been working at a customer site said he had something to tell me. He took me into a conference room where we wouldn't be interrupted and told me about a conversation he had had with the customer. In short, the customer had asked him who this grumpy old guy on the telephone was who didn't seem to want to talk to them.

This hit hard. My colleague didn't have to add much to make me realize how bad this was. In essence, I had been treating support calls as a necessary evil, to be gotten over with as quickly as possible so they didn't pull my attention away from more important work. But, in fact, they were important work, not only to resolve our customer's problems, which was often simple to do, but to demonstrate competence, engender confidence in our company, and strengthen the business relationship. After I had digested this feedback, I changed my approach to customer support entirely and quickly reached a very good working relationship with the customer.

Conclusion

I think spending time on something is not the same as giving attention to something. The key to get it right is to know which situation you're in.

• If the process is known and unavoidable and I'm only interested in the result, I minimize the time I spend on it by automating it or at least minimize the amount of attention I give it, enabling me to do something more interesting at the same time (like listening to a podcast while ironing).
• If the process is known and I suspect it might be avoidable (like the database cleanup), I focus my attention, but not only on the process itself, but on the context it is embedded in, and try to understand why this process exists and what it accomplishes.
• If the process is unknown, but a solution to the problem is desirable, I give my full attention to finding the solution. This is what I like most about software development.^[1]

And of course, when thinking about problem solving and optimization, you should never forget that there are things worth doing for their own sake. Don't make the mistake of optimizing those away!