The Habits That Make an Engineer Worth Routing Work Through

Reliability is a skill, and it is learnable

Every team has one or two engineers who other people route work through. Not necessarily the strongest technically, though often quite strong. What they have in common is that when something is given to them, it comes back, and if it is not going to come back on time you hear about it early rather than late.

That reputation compounds faster than technical depth does. It decides which projects you are offered, whose opinion gets asked in a design discussion, and eventually what you get promoted for. And it is made almost entirely of habits that are unglamorous and completely learnable.

Here are fifteen of them, as situations and defaults. None require permission, a title, or a supportive manager, which is what makes them worth knowing early.

Being easy to work with

1. A task + ambiguity → resolve it before you build. Thirty minutes of questions at the start beats a week of work aimed at the wrong target. The fear that asking looks uninformed is backwards: asking early looks careful, and asking on the day it is due looks like something else entirely.

2. An estimate + natural optimism → give a range and what would narrow it. "Three to eight days, and I will know which after I have looked at the export path" is a genuinely useful sentence. A single confident number is a promise you cannot support, and people plan around it as though you could.

3. A blocker + a whole day gone → surface it the same day. Blockers do not improve with age and their cost is entirely in how long they stay invisible. Nobody has been thought less of for flagging a dependency on Tuesday. Plenty have been for revealing on Friday that Tuesday was already lost.

4. A commitment + a slip → say so as early as you can see it. The damage from a missed date is almost never the date. It is the fact that other people planned around a thing that was quietly not going to happen. Early bad news is a favour and it is received that way.

The work itself

5. A new codebase + your first week → ship something small and real. A tiny fix, deployed properly, end to end. You learn the build, the review process, the deploy path and the people, which is most of what actually slows a new joiner down, and you do it while expectations are still low.

6. A long project + a long silence → deliver visible increments. Three months of heads down work followed by a reveal is a bet on nobody's understanding having changed. Something demonstrable every week or two lets the direction be corrected while correcting it is still cheap.

7. A hard problem + a rabbit hole → write down what you tried as you go. A running list of hypotheses and results keeps you from testing the same theory twice at hour four, and it turns into the pull request description, the postmortem note and the answer for whoever hits it next.

8. Everything urgent + a queue → do the thing that unblocks other people first. Your own throughput is worth less than the team's. The task with three people waiting behind it outranks the more interesting task that only you care about, every time, and choosing that way is noticed quickly.

Reviews, in both directions

9. A review comment + a personal preference → label it as one. Say plainly which comments block the merge and which are opinions the author may ignore. Reviews stall mostly because nobody can tell the difference, and an author who cannot tell treats everything as mandatory and resents all of it.

10. Feedback on your code + a defensive reaction → separate yourself from the diff. The reviewer is describing the code, not you, even when the wording is graceless. Engineers who take review well get more of it, which means they improve faster, which is the entire mechanism.

11. Someone junior + a question they could answer → give them the method. Where you would look, how you would narrow it, what the error is really saying. Handing over the answer solves today at the cost of the same question next week, and the method is the part that transfers.

Being known for it

12. A meeting + a decision → write the summary afterwards. Four sentences: what was decided, why, who is doing what, by when. It takes five minutes, prevents the same discussion recurring in a month, and the person who writes it has a quiet and disproportionate influence over what the decision is remembered as.

13. The same question + the third time → write the document. Answering repeatedly feels helpful and scales to nobody. A short page you can link to is worth more than the twelve conversations it replaces, and documentation is one of the few contributions that keeps working while you are asleep.

14. An incident + five people helping → one person coordinates. Someone holds the timeline and says who is looking at what, and that person is usually not the one deep in the logs. Uncoordinated help is how three engineers independently restart the same service.

15. Solid work + nobody knowing → send a short weekly note. What shipped, what is in progress, what is blocked. This is not self promotion, it is removing the need for anyone to ask, and it means that when your work is discussed in a room you are not in, there is an accurate account of it available.

What else belongs on this list

Saying no properly, which mostly means saying what would have to move for the new thing to fit rather than refusing outright. Finishing things, because a trail of ninety percent complete projects is the most common reason strong engineers stall. And leaving the code slightly better than you found it, at a rate the review can absorb.

The one I would add above the rest is answering the question that was asked. It sounds trivial. In practice a great deal of frustration on teams comes from someone asking whether the deploy is safe and receiving four paragraphs about the caching layer, and the engineers people rely on are the ones who answer first and then explain.

The short version

Clarify before building. Estimate in ranges. Surface blockers the same day and slips as early as you see them. Ship something small in week one. Show increments. Keep notes while debugging. Unblock others before yourself. Separate blocking review comments from preferences and take feedback without flinching. Teach the method. Write the meeting summary, the document and the weekly note.

None of that is about being the cleverest person on the team, and the people who are relied on are usually not. They are the ones whose work arrives when they said it would, and who told you in advance on the occasions when it will not.