Line illustration: a tired man in glasses sits at a desk at night with his chin resting on his hand. In front of him a monitor with firewall rules and a shield with a tick, next to it a steaming mug and a router. A moon outside the window, the wall clock shows 11:40 pm

The prevention paradox: when everything works, nobody asks why

29/10/2026

It is 11:40 pm. The tea on my desk is going cold and I am checking for the third time that a new firewall rule does exactly what it should. Nobody asked me to. Nobody will ever find out, either, because if everything works, tomorrow simply nothing will happen.

And that is exactly the point.

At 8:15 the next morning the phone rings. The printer is not working.

Line illustration: a tired man in glasses sits at a desk at night with his chin resting on his hand. In front of him a monitor with firewall rules and a shield with a tick, next to it a steaming mug and a router. A moon outside the window, the wall clock shows 11:40 pm(enlarge)
The hour nobody asks about

What the prevention paradox is

The prevention paradox is when successfully preventing a problem makes the problem look made up. If nothing bad happened, maybe there was no threat at all? Or maybe someone was just overreacting?

The best example is the year 2000 problem. For several years thousands of IT people around the world went through code and patched banking, energy and aviation systems. Then 1 January 2000 came and nothing happened. Planes flew, cash machines paid out, the lights stayed on. Very quickly people started saying the whole thing had been blown out of proportion.

It had not. Nothing happened precisely because someone had done an enormous amount of work beforehand. Only that work could not be seen. All anyone could see was the absence of a disaster, and the absence of a disaster is hard to photograph.

Work nobody sees

Everyday IT work is the same, just on a smaller scale. Most of what I do leaves no trace by definition. When it is done well, nobody notices.

Things like:

  • system and software updates, often done in the evening so they do not get in anyone’s way,
  • backups nobody has ever needed, because nothing broke,
  • monitoring that catches a problem before anyone feels it,
  • security rules that stop attack attempts every day, attempts nobody even knows about,
  • documentation and procedures required by cybersecurity law, such as NIS2 and the Polish national cybersecurity system act,
  • digital accessibility, so that a website or a document can also be read by a blind person,
  • planning infrastructure several years ahead, before the old one simply stops being enough.

None of these things is impressive. There is no ribbon cutting, no photo for the newsletter. There is only a day on which everything works the way it did yesterday.

What is most interesting, though, is that even big projects can be invisible. Building a large portal for residents from scratch, one that runs without interruption, takes months of design, coding, testing and fixing. From the outside all you see is the finished website. Nobody sees the hundreds of hours that went into it, or the decisions that made it secure, fast and accessible to everyone.

The same goes for rolling out new solutions. Replacing expensive commercial software with open source means real savings, often thousands of złoty a year that no longer have to go on licences. But to make it work you first have to find the right tool, test it, migrate the data, train people and take responsibility for everything working. When it succeeds, there is one visible result: everything works as before, only cheaper. In other words, once again nothing happened.

After hours

This work cannot be wrapped up at 3:30 pm. Technology does not wait for the working day to end. New threats appear every week, hardware ages, and what is new today will be standard in two years.

That is why many IT people learn in their own time and often with their own money. In the evening they test something in a home lab, at the weekend they read documentation, they build a server from used parts just to see whether an idea makes sense at all. Then they bring that knowledge to work, ready and proven.

With big projects the amount of that time becomes huge. A portal, a new system, a migration from a commercial program to an open one: much of it gets built in the evenings and at weekends, because during the day there are day-to-day matters, support requests and that wretched printer. If you added up all those hours, they would make more than one extra full-time job.

I do not do it because I have to. I do it because I enjoy it. Looking for new ways, figuring out how to do something better, cheaper or more securely is a pleasure for me, not a duty. But passion does not change the fact that these are hours nobody counts. And results few people know the origin of.

What others see

From the other side of the desk it looks completely different. You see the printer that jammed. The password that had to be changed. The computer that took longer than usual to start in the morning. The program that has a button in a different place after an update.

Nobody asks about the server that has not had a minute of downtime in three years. Nor about why there was not a single serious incident in the past year. Questions come only when something stops working.

And that is natural. It does not come from ill will or a lack of respect. People judge what they understand and what affects them directly. Well-run infrastructure is like electricity in the socket. Nobody thanks the power station when the kettle boils. But everyone notices when the lights go out.

Except that after years of this kind of work it is easy to feel the effort goes into a void. That a good IT person is one nobody talks about, and the only time anyone does is when something has gone wrong.

Graphic from the Notes from the workshop series: There are days when you come home tired, but feeling that something really worked out. When everything works, nobody asks why. And maybe that is the whole point(enlarge)
From the Notes from the workshop series

What to do about it

You can take offence. Or you can accept it as part of the job and try to change the rules of the game a little. A few things that I think really help:

  1. Show your work. A short summary once a quarter: how many updates, how many blocked attacks, how many hours without downtime. Numbers say more than descriptions.
  2. Talk about outcomes, not technology. Nobody cares about the new cluster configuration. They care that the data is safe and the system will not stop in the middle of the day.
  3. Tell people about what did not happen. Every incident that was stopped is a story worth telling now and then, without giving away the details, of course.
  4. Look for recognition outside your workplace too. Among other IT people, at conferences, online. There people know what it takes to produce something that looks like an ordinary day from the outside.
  5. Do not measure your worth only by other people’s attention. The satisfaction of a problem well solved is real, even if nobody noticed.

And what if someone does not like it?

Showing your work has another side. Someone may take it as bragging, as a hint that others do less, or as stepping on someone else’s turf. Sometimes a person will simply feel awkward because their own work looks more modest by comparison.

A lot depends on the form. A factual summary for your manager is something else than publicly announcing your successes. The usual advice is also to talk about the success of the whole organisation rather than your own, and to share the credit with those who gave the green light.

But this is where a question comes up that many IT people ask themselves. What if it was not a shared success? What if you were the one giving three hundred per cent, sticking your neck out and staying up at night? And not once, but for four years, seven, eleven. How much longer can you hide behind the word “we”?

I think the honest answer is this: share the credit where someone really had a part in it. But modesty cannot mean disappearing. You can talk about the result for the organisation and at the same time say clearly who achieved it. The sentence “I prepared and rolled out a solution that saves the institution several thousand złoty a year” is not bragging. It is a fact. And if after years of such work there is still no room to say it, the problem is not the way the message is put.

And if it still bothers someone? The best thing is simply to talk and ask what exactly the problem is. Often it is about the form, not the content. But if what bothers someone is the very fact that good work was noticed, that says more about them than about the work. You cannot please everyone, and silence has its cost too. Then nobody knows the work exists at all.

Can you see a good IT person?

Back to that evening and that firewall rule. It worked. The next day nobody knew about it, and I answered the call about the printer and went to fix it. I am glad when the printer works too.

So can you see a good IT person? You can. You just have to know where to look. Not on the days when something breaks, but on all those ordinary days when nothing happens. In systems that simply work. In data that is where it should be. In a silence that is no accident.

Next time everything works, it is worth asking one simple question: why?

Click or scroll to zoom in. Drag to move around.Double tap or pinch to zoom in.