There has been a subtle change in the kinds of messages I receive.

They used to contain requests.

“Can you build this?”

“Can you fix this?”

“Can you make this slightly larger?”

The last of these remains distressingly common, but otherwise the pattern has changed.

Increasingly, a message arrives with no obvious request at all. It contains a forwarded email, a screenshot, perhaps a document whose filename includes the word FINAL several times, and a sentence along the lines of: “Can you have a look at this?”

I have learned that this can be quite large.

Sometimes it is a website behaving strangely. Sometimes two systems disagree about something important. Sometimes a business process has reached such a state of accumulated improvisation that nobody can quite explain how it works, although several people become visibly concerned at the suggestion that it might stop.

The expectation is no longer necessarily that I will fix the thing myself. First, I am expected to understand it.

This is a different kind of work, and I am not entirely certain when I began doing it.

Perhaps competence changes how other people perceive you. If you solve enough individual problems, eventually someone assumes you may also be able to identify what the problem is. This seems flattering until you realize that the latter category has no natural boundary.

A broken form is a problem. So is an unreliable workflow. So is a team doing the same task three different ways because nobody remembers which version of the instructions is current. So, occasionally, is an organizational decision made several years ago by a person whose name is still attached to a user account nobody feels authorized to delete.

These things tend to arrive disguised as technical questions. They rarely are.

I have sat down to investigate what appeared to be a software problem and discovered, several conversations later, that the software was functioning exactly as designed. The difficulty was that three people believed it had been designed to do three different things.

No amount of debugging can resolve this. One must speak to the humans. I have become reasonably good at that too, which has not helped.

The peculiar thing about becoming the person people call when things are complicated is that one begins to occupy a role that is difficult to describe. You are not necessarily the expert on every component. Often you are speaking to people who know considerably more than you do about their particular corner of the system. Your usefulness lies somewhere between them: in noticing that the corners belong to the same room.

This requires a certain tolerance for not knowing.

When something complicated arrives, my first reaction is rarely, “I know how to solve this.” It is usually, “Something here does not fit.”

Then I begin asking questions: Why does this happen before that? Who receives this when it fails? Does anyone still use this field? What happens if Susan is on holiday?

Susan, I should clarify, is hypothetical. There is always a Susan.

Eventually the shape of the thing becomes visible. The mysterious failure turns out to be two reasonable systems making incompatible assumptions, or a manual step nobody mentioned because it has been performed every morning for seven years and therefore ceased to be perceived as a step.

At this point people occasionally say, “I knew you’d figure it out.”

This gives me more credit than is warranted. Usually I have not figured anything out. I have simply remained in the room with the confusion long enough for it to become specific.

There is, nevertheless, something satisfying about this work. Complicated things are often frightening chiefly because they have not yet been given edges. Once you can say where the problem begins, what depends on it, and what would constitute a safe change, the atmosphere improves considerably.

The problem may still be difficult. But it has become a problem rather than a fog.

I suppose this is why people call.

I am still deciding how I feel about that.