The Cost of Being the Person Who Knows

Sometimes that's part of the job.

Sometimes it isn't.

But the expectation often feels the same.

You know how to solve the problem. Therefore you should.

The Person Everyone Calls

Every workplace has one.

The person who knows how the system works.

The person who understands the deployment pipeline.

The person who remembers why a decision was made three years ago.

The person everyone calls when something breaks.

I've been that person more than once. And while there's value in being trusted, there's also a cost that often goes unnoticed.Responsibility tends to stick to people who are capable.

The more you know, the more likely you are to become the fallback plan.

The Weekend That Isn't Yours

I've spent a fair amount of time being on call.

One thing I've always found interesting is how differently engineers and managers sometimes view it.

A manager might look at a report and see that you only handled one incident all weekend.

An engineer often sees a weekend that wasn't really theirs.

• You need to be reachable.

• You need your laptop nearby.

• You need internet access.

• You need to be ready.

Maybe the phone never rings.

But your availability was still spoken for.

The company isn't just paying for the incident.

It's paying for the responsibility.Or at least that's the idea.

In reality, on-call compensation is often based on what happened rather than what could have happened.

The incident is easy to measure. The responsibility isn't.

The Bug Bounty

I've had similar thoughts when discovering bugs or security issues.

Especially when it comes to large organizations.

If I find a bug in a product I use, I might report it because I want it fixed.

That's my choice.

But I've always found it interesting that there is often an expectation that independent developers will spend their own time investigating, documenting, reproducing, and reporting issues.

Why?

Security research is work.

Testing is work.

Analysis is work.

Documentation is work.

Most large organizations employ QA engineers, security teams, consultants, auditors, and compliance specialists.

Yet there's often an assumption that someone who happens to discover a problem will voluntarily contribute that effort.

Some companies recognize this through bug bounty programs.

Others don't.

This isn't really about the payout.

It's about acknowledging that the work itself has value.

I also find it interesting that bug bounty programs seem much more common among international technology companies than many Swedish organizations.

Maybe that's changing.

Maybe I just haven't looked hard enough.

And it's not necessarily a criticism. Many organizations have dedicated security teams and formal reporting channels.

But when I browse platforms like HackerOne, I see plenty of global technology companies actively inviting security researchers to participate.

That at least acknowledges something important:

Finding vulnerabilities, reproducing them, and writing useful reports is work.

The Carpenter

I sometimes wonder if this happens because technical work is largely invisible.

If a carpenter spends four hours building something, everyone can see the result.

If a developer spends four hours tracking down a production issue, the result might be a single configuration change.

One looks difficult.

The other looks easy.

Even if the effort was exactly the same.

Most people wouldn't expect a carpenter to spend their evening inspecting a deck and writing a report explaining how to fix it.

Most people wouldn't expect a lawyer to review a contract for free because they happened to spot a problem.

Yet in technology, there often seems to be an assumption that expertise should be freely available simply because someone possesses it.

Expertise Versus Expectation

This isn't really about helping.

It's about expectations.

There's a difference between someone choosing to contribute their expertise and people expecting that expertise to be available simply because it exists.

The first is generosity.

The second is entitlement.

And I think that's what I've noticed throughout my career.

The more technical knowledge you have, the more responsibility tends to find its way to you.

At work.

During on-call rotations.

When systems fail.

When bugs are discovered.

When security issues are found.

And I've always found it interesting how often the expectation is that this expertise should simply be given away.

Not because people are malicious.

Not because companies are evil.

But because somewhere along the way, we've become surprisingly good at seeing the outcome of technical work while completely missing the expertise behind it.

Just One Quick Question

There's another pattern I've noticed over the years.

Someone has a question.

Instead of asking in a team channel, they send a direct message.

Most of the time they're trying to be efficient.

They know I might know the answer.

So they ask me directly.

During work hours, the cost is interruption.

Programming isn't just typing code.

A lot of the work happens in your head.

You're holding requirements, architecture, edge cases, and implementation details all at the same time.

A direct message can break that context in seconds.

The answer might take 30 seconds.

Getting back to where you were can take much longer.

Outside work hours and during absence (sick, vacation etc), the cost is different.

Technically, I don't have to check Slack.

Technically, I don't have to open Teams.

Technically, I don't have to respond.

But when you're the person who knows the system, that's easier said than done.

• What if it's important?
• What if production is down?
• What if someone is blocked?
• What if it's a customer issue?

Most people don't ignore those messages.

Not because they're required to.

Because they care.

And because responsibility has a habit of following expertise.

The person sending the message only sees a quick question.

The person receiving it often pays a much larger cost.

Then again, maybe I'm overthinking it.

It's entirely possible that after spending years debugging apps, production incidents, and network issues, I've simply developed a professional allergy to the phrase:

"Quick question..."

Although I still maintain that if you're about to send me a direct message instead of posting in the team channel, at least give the channel a chance first.

Last words

I don't really have an answer. Maybe that's just how it is.

I just find it interesting and maybe I`m completely off base.

Why do we often treat technical expertise differently from other professional skills?

Why is being on call often measured by the incidents rather than the responsibility?

Why are direct messages seen as a quick question when they can derail an hour of focused work?

And why does "you know how" so often become "you should"?

Maybe that's just part of working in IT.

Or maybe we've become so used to technology being everywhere that we've stopped seeing the expertise behind it.

Either way, if you need me, I'll be busy ignoring a notification while simultaneously wondering if it's important and awaiting Skynet.

And for those struggling with the pressure of always being available, always being the person who steps up and carries the responsibility.

A psychologist once taught me an important lesson.

We're not surgeons. We're not doctors.

Nobody is going to die on our watch.

So whenever the pressure starts building, or you're thinking about skipping lunch just to fix that issue first, remember:

Nobody is going to die.

The bug will still be there after lunch.