The Engineer nobody chases

Ask most engineers what determines their next promotion and you will hear technical depth, ownership, impact, visibility. All roughly true and none of them measurable in the moment.

Here is a version that is measurable.

How much does your work cost the people around you after you have finished it?

Not while you are doing it. After. When the ticket is closed and you have moved on.

Some engineers finish something and it is finished. The handoff has a name attached. The risk was raised while there was time to act. The person who needed to know already knows. Nothing comes back.

Other engineers finish something and a small amount of work quietly appears elsewhere. Somebody has to ask what state it is in. Somebody has to check whether the other team was told. Somebody has to find out whether the thing that looked risky in the ticket turned out to be risky.

Neither engineer is doing anything wrong. The second one is not lazy or careless. They finished their work. The residue is invisible to them because it lands on other people.

But it accumulates, and it forms an impression, and the impression is not about your code.

If you want one word for the thing being measured, it is chasing.

Chasing is a status update somebody had to request. A decision that stalled because it was not clear who owned it. A merged change that nobody verified in production. A conversation that started with any update on this.

Every instance is small. Two minutes. Nobody is annoyed. It is a completely normal part of working with other people.

The problem is that it is also cumulative and asymmetric. Your manager is tracking maybe eight engineers. If two of them require regular chasing and six do not, the difference is not subtle to them, even though no single instance was significant enough to mention.

And here is the part that makes it invisible to you: nobody tells you. Chasing someone is easier than telling them they need chasing. The second conversation is uncomfortable, might be unfair, and has to be justified with specifics that nobody wrote down.

So it does not happen. It goes into an impression instead, and the impression surfaces at review time as be more proactive, or take more ownership, or we need to see more from you at this level.

All of which are true, and none of which say chasing.

Three things, in order of how much they matter.

You do not get given ambiguous work.

This is the largest cost and the least visible. Managers allocate work partly on how much supervision it will need. Something vague, cross-team, and important goes to somebody who will close it without being followed up. That is not favouritism, it is a rational allocation of the manager's own attention.

So the engineer who needs chasing gets clearer, smaller, better-specified work. Which is more comfortable, and which is exactly the work that produces no evidence of scope.

You end up with a year of well-executed tickets and nothing to point at.

Your work does not travel.

Senior means you own hard problems and deliver them. The next level up, whatever your company calls it, means the work left your team. Somebody else built on it, adopted the pattern, followed the migration path you wrote down.

None of that happens by accident. It requires a last ten percent that most people skip: writing it down, generalising slightly, telling one other team it exists. The work was already done. The travelling is the bit at the end. Staff engineering starts where your work changes other teams.

Engineers who need chasing rarely do the last ten percent, because the last ten percent is exactly the part that has no ticket attached.

And nobody can describe you.

When your name comes up, somebody has to be able to say what you are for. She owns the sync layer. He is the person for anything touching payments. That sentence is what gets you considered for things.

If the honest answer is that you are good and reliable, that is a compliment and it is not a description. Compliments do not get you assigned to anything.

Two things, because the advice in this area is usually wrong in both directions.

It is not about visibility. The standard suggestion is to promote your work more: post in channels, present at demos, make sure people see what you do. Some of that helps. Most of it addresses the wrong thing, because being chased is not a perception problem. It is a completion problem. Announcing incomplete work more loudly does not help.

And it is not about being louder. The engineers I have seen advance were not the ones who spoke most in meetings. Several were the quietest people on their teams. What they had in common was that their work arrived finished, and finished included the parts that happen after the code works.

If you have been avoiding this feedback because the fix sounded like becoming a different person, it is not.

Specific, because the abstract version is unactionable.

The handoff without a name. Work moves to someone else and the moving is assumed rather than confirmed. Nobody said the words: you own this now, by Thursday. The fix is one sentence and it is the highest-return habit in this article.

The status that had to be requested. Somebody asks where something is. That question is a signal you missed a beat. The version that prevents it is not more updates, it is updates that report a changed state rather than logging activity. Yesterday I worked on the auth stuff is a timesheet. Yesterday I completed JWT validation, which unblocks the frontend login flow, is coordination.

The risk raised too late. You saw it. You mentioned it when it was already a problem. Everyone thanks you and the fact remains that the moment it was cheap to act has passed. Flagging something while there is still time to change course is worth far more than flagging it accurately afterwards. A strong architecture review makes risk and reversibility explicit.

The merge with no verification. The change went in. Whether it did what it was meant to do in production is unknown to you. Somebody either checks it later or nobody does, and both outcomes are bad.

The thing that quietly stopped. An initiative loses priority, or gets blocked, or turns out to be the wrong idea. Stopping is often correct. Stopping without telling anyone means someone eventually asks about it and gets a surprise.

Do not attempt all five. That is how this becomes a source of guilt rather than a change.

Pick one, and pick it by counting rather than by feeling.

For each of the five, count the separate times it happened in the last three weeks, because here a higher number is worse. Not how often you would, or how conscientious you feel. Count instances. If you cannot name a specific one, it is zero.

Take the highest number. That is the one costing the people around you most, and it is the one to fix first. Do that one thing deliberately for three weeks and ignore the other four.

Then count again. The first number measures what you were. The second measures what you did after you knew.

The reason this persists is that nothing about it feels like a problem while it is happening.

You are working hard. Your tickets close. Your reviews are good. There is no moment at which anyone tells you that a small amount of coordination work is landing on other people, because it is never enough to be worth a conversation.

You find out at review time, in three words that do not describe it.

The good news is that this is the cheapest thing in your career to fix. It is not more skill, more hours or more visibility. It is a handful of sentences said at the right moment, and most of them take under a minute.

The engineer nobody chases is not working harder than you. They are finishing differently.

I put the full set of fifteen behaviours behind a free diagnostic. Counted rather than rated, four minutes, no signup: take the proactive diagnostic