Trust comes from predictability more than brilliance. Do what you said by when you said, raise problems early, leave work easy for others to pick up, and own your mistakes plainly. Good code gets you respected; reliability gets you trusted.
What people tell me
I am a developer with a year or two of experience. My code reviews are usually positive and I can solve hard problems, but I notice that when something important comes up, my lead gives it to someone else. I want to be the person people rely on, not just someone who is technically good. I am not sure what I am missing, because nobody has said anything is wrong.
A composite of the messages behind this question, with personal details left out.
Key takeaways
- Trust is built from small promises kept, repeated over months. It is predictability, not heroics.
- Say when something will be late as soon as you know, not on the day it is due.
- Make your work easy for others to review, run and pick up without you.
- Own mistakes in one sentence with the fix attached. Never make people chase you for the truth.
- Help others get unstuck. People trust engineers who make the team better, not just their own tickets.
Good code earns respect, reliability earns trust
When a lead decides who gets the important piece of work, they are rarely asking "who is the smartest?" They are asking "who will I not have to worry about?" Those are different questions, and many technically strong engineers only answer the first one.
Trust is mostly predictability. It is the feeling that when you say something will happen, it happens, and when it will not, you will say so early. That sounds ordinary, and it is. It is also surprisingly rare, which is why it is so valuable.
The habits that build it
In the teams I have worked with, the engineers everyone relied on had a handful of habits in common, and none of them were about clever code.
| Habit | What it looks like in practice |
|---|---|
| Keep small promises | "I will review your PR by 3pm" and then you do, every time |
| Raise problems early | "This is looking like Thursday, not Tuesday, because of X" on the day you notice |
| Close loops | Replying "done, merged" instead of leaving people to check |
| Make work easy to pick up | Clear PR descriptions, notes on decisions, no knowledge locked in your head |
| Own mistakes quickly | "I broke the export, here is the fix, here is how I will prevent it" |
| Care about the outcome | Checking your feature actually works for users after it ships |
Look at that list and ask honestly which ones you do consistently. Most people find one or two gaps immediately.
Estimates and bad news
The single fastest way to lose trust is to go quiet and then miss a date. The fastest way to gain it is to deliver bad news early, with a plan.
A useful rule: the moment you think something will slip, say so, even if you are only fairly sure. A message like this does more for your reputation than finishing on time by working all night:
Heads up: the payment retry work is taking longer than I estimated because the provider's sandbox behaves differently from production. I now expect Friday rather than Wednesday. If Wednesday matters, I can ship retries without the admin view first.
Notice it includes the reason, the new date and an option. Your lead now has something to work with instead of a surprise.
Make yourself easy to depend on
Some engineers are strong but hard to work with in quiet ways. Their pull requests have no description. Their code works but only they understand why. They are the only person who knows how a system is deployed. That might feel like job security. It actually makes you a risk, and people route important work around risks.
Instead:
- Write pull request descriptions that explain what changed, why, and how to test it.
- Leave short notes when you make a non-obvious decision.
- When you learn how something works, write it down where the team can find it.
- Review other people's work carefully and kindly, and on time.
Mistakes are where trust is decided
Everyone makes mistakes in production eventually. What people remember is how you handled it. The trusted engineer says what happened, what the impact was, what they have done about it, and what will stop it happening again, all without being asked twice. The engineer who minimises, delays or blames loses far more than the bug cost.
Help the team, not just your tickets
Trust also comes from being useful beyond your own work. Pairing with someone who is stuck for twenty minutes. Answering a question in the team channel. Noticing a flaky test and fixing it. None of this shows up in your ticket count, but all of it shows up in how people talk about you when you are not in the room.
Ask, instead of guessing
Since nobody has said anything is wrong, ask directly. In your next one-to-one with your lead:
I would like to be someone you feel comfortable giving the high-stakes work to. Is there anything that would make that easier for you?
It is a slightly uncomfortable question. The answer is usually specific and fixable, and asking it is itself a sign of the maturity they are looking for.
Give it time
Trust compounds slowly. You will not see a change in a week. Keep the habits for two or three months and you will usually notice the work you are given changing before anyone says a word about it.
If you are still stuck
Read The Habits That Make an Engineer Worth Routing Work Through and Twelve Moves That Take You From Mid Level to Senior.
If you want someone to look at your specific situation, join Sefism and, as a member, book a 1:1 session. You can also browse the other career questions people have asked.
Was this answer helpful?
Read next
- Twelve Moves That Take You From Mid Level to SeniorGetting to mid level is mostly time and repetition, and then the path stops being clear. The thing that got you here, doing assigned work well, is not what the next level rewards, and nobody says so directly, so capable engineers respond by doing more of what already worked. Twelve heuristics for the part that is not obvious.
- The Habits That Make an Engineer Worth Routing Work ThroughEvery team has one or two engineers other people route work through, and what they have in common is not raw technical strength. It is that when something is given to them it comes back, and when it will not, you hear about it early. Fifteen habits that build that reputation, none of which require a title or permission.
Your situation is not quite this one?
Members get written answers to their own questions, a roadmap built for them and feedback on their projects. Early access is open to X and Instagram followers and university students. Prefer to talk? A free call works too.