Throughout my time at Amazon, I have worked with senior/principal engineers who made what seemed impossible look almost annoyingly normal.
Not because the work was actually normal. Sometimes they were dealing with a production issue, a weird bit of infrastructure, a project that had been stuck for weeks, or an ambiguous request that everyone had interpreted differently. They just had a way of taking the situation apart, finding the important part, and making it possible to move again.
I want to be careful about what I can claim here. I am not a staff or principal engineer and I have never been their manager. I cannot really evaluate how good they are at managing budgets, setting organization-wide strategy, or doing the invisible business work that probably matters a lot at that level.
But I have worked beneath some very good senior engineers, and I have noticed some common traits. The technical depth is obvious. The less obvious part is how much of their value comes from making other people more effective.
They still genuinely enjoy learning
This one stood out to me more than I expected.
The best senior engineers I have worked with are usually buried in work. They have a pile of responsibilities, people asking them questions, systems that only they seem to understand, and the occasional mysterious incident that appears at the worst possible time.
And yet, they still like learning new things.
Not in the performative “I read every new framework announcement” sense. More in the sense that they are curious. They want to understand why something works, try a tool, poke at an unfamiliar system, or figure out whether an idea from another field applies here.
I think that curiosity is part of how they got so good in the first place. Experience clearly matters, but experience by itself can turn into doing the same thing for ten years. The senior engineers who stand out seem to keep adding new material to work with.
Their technical depth is real, but it is also connected
Yes, the obvious one: they know a lot.
They have usually seen more systems fail, more strange edge cases, more migrations, more shortcuts that came back to haunt someone, and more versions of “this should be simple” than I have. They can often explain what is happening several layers below the thing I was looking at.
But the really useful part is not just that they can remember obscure details. It is that they can connect ideas that do not initially look related.
They might use an operating-systems concept to reason about a distributed system. Or recognize that a problem that looks like an application bug is actually a queueing problem, a data-model problem, or an incentive problem. Or they know some bizarre shell trick that saves everyone ten minutes a day and somehow turns it into a reliable little tool instead of a cursed one-liner nobody can maintain.
I watched this happen once with an issue that had been sitting around for about two months. A senior engineer heard about what another team in a completely different part of the organization was building. They spent a little time playing with that team's code and realized that the approach they were using could also work in our codebase. It was not an obvious connection, and I do not think anyone on our team would have thought to look there. But that small bit of exploration gave us a way through an issue that nobody had managed to tackle.
They come at problems from odd angles because they have more angles available.
That feels like one of the biggest differences to me. A less experienced engineer may know the tools directly in front of them. A great senior engineer has enough experiences stored away that they can reach sideways and ask, “What does this problem resemble? Could I pull the answer from someplace else?”
They can explain things without making you feel dumb
Deep knowledge is helpful. Being able to share it is a separate skill.
The senior engineers I have learned the most from can explain a complicated concept to different people at different levels. They can give a stakeholder the actual tradeoff without burying them in implementation details. They can walk a junior engineer through the mechanics. They can talk to another experienced engineer without slowing the conversation down.
Most importantly, they do not make questions feel expensive.
There are people who are brilliant and still intimidating enough that everyone works around them. You hesitate to ask for help because you expect the interaction to be painful, so small misunderstandings survive longer than they should. That is not a great setup for a team, no matter how technically capable the person is.
The best people I have worked with somehow do the opposite. They make you feel like the question is reasonable, even when the answer is “this is weird and I also had to learn it the hard way.” That makes it much easier to learn, and it makes the whole team faster over time.
They are force multipliers, not just problem solvers
This is probably the trait I admire most.
Senior engineers are often the people who can take on the hardest work themselves. But the most effective ones do not just collect the hard work and disappear into it. They take a large, unclear problem and turn it into pieces other people can own.
That might mean clarifying the actual goal, drawing the boundaries between components, making a small technical decision that unblocks three people, or handling a tiny but horrible issue that has been wasting everyone else's time. Sometimes the highest-leverage thing they do is not glamorous at all. It is finding the one permissions issue, flaky deployment step, unclear API contract, or missing bit of documentation that has quietly stopped other work from moving.
They also seem comfortable letting other people take real ownership. Instead of keeping the interesting parts for themselves, they create a path for someone else to do them successfully. That requires trust, patience, and a good sense of where help is actually needed.
In practice, this can make them look like they are doing less than the person who is heads-down implementing a huge feature. I think they are often doing something harder: increasing the amount of good work the whole group can get done.
They sometimes end up doing manager-shaped work
There is a weird space between pure implementation and management, and good senior engineers frequently seem to occupy it.
They help untangle priorities. They make sure people know what needs to happen next. They resolve disagreements before they become months of low-grade frustration. They coach people through a problem instead of just fixing it for them. They notice when someone is blocked, overloaded, or about to build the wrong thing for a perfectly understandable reason.
I do not mean that engineers should quietly become unpaid managers. Teams still need actual managers, and management is its own demanding job.
But from below, it is very noticeable when a senior engineer can provide some of that direction and stability without turning every technical conversation into a power struggle. It makes a team feel much less chaotic.
They have the people skills to make their technical judgment usable
This is related, but I think it deserves its own point.
Someone can be technically extraordinary and still be difficult to work with. Maybe they are dismissive, impossible to approach, combative in every disagreement, or so scary that nobody brings them bad news until the problem has become much worse.
That limits how much influence their technical judgment can have.
The people who move into real positions of trust seem to pair technical credibility with basic human skills: listening, being direct without being cruel, admitting uncertainty, and treating people like adults. They can disagree without making the disagreement personal. They can say “I think this is a bad idea” and still leave room for a useful conversation.
It sounds painfully obvious when written out. It is much less common in practice than I would have guessed.
They know when the technically interesting answer is not the right answer
The best senior engineers I have worked with like experimenting. They are curious about tools and architecture and would probably enjoy building the more elegant version of a system.
They are also unusually good at asking whether that version actually solves the problem the business has.
Sometimes the right answer is the new tool. Sometimes the right answer is a boring database, a smaller design, a manual process for now, or simply not building the thing at all. The point is not that business needs should always beat technical concerns. Technical debt, reliability, and maintenance costs are business concerns too, even if they do not show up in a spreadsheet immediately.
The useful skill is being able to hold both sides at once: understand the technical tradeoff deeply enough to see the future cost, while staying grounded in what the company or user actually needs right now.
They do not wait to be handed every problem
The senior engineers I have watched most closely do not need a ticket to notice that something is wrong.
They seem to have a working model of where the business is going, what the team is trying to accomplish, and what is likely to break on the way there. Then they go looking. They ask questions, notice rough edges, and take care of problems before they become urgent enough for somebody to officially assign them.
That does not mean randomly refactoring everything in sight. I think it comes back to judgment. They have enough context to distinguish between a personal annoyance and something that will genuinely slow down the team or the business.
At their best, the only direction they need is the direction the business is moving. They can identify the important technical work from there.
They have enough trust to get things done across the company
Finally, there is social capital.
The strongest senior engineers tend to know a lot of people, but it is not just a giant collection of Slack contacts. They have earned trust across teams. People know they understand their systems, keep their word, explain their reasoning, and will not throw someone under the bus when a project gets difficult.
That makes it much easier for them to get things done. They can ask the right person for context. They can bring two groups together before a decision hardens into a conflict. They can influence a plan without needing formal authority over everyone involved.
“Playing politics” has a bad reputation, and sometimes for good reason. But there is a non-sleazy version of it: understanding people, incentives, and relationships well enough to make useful work happen. I do not think you can be effective at a senior level without some version of that skill.
What I am taking from this
When I think about becoming a better engineer, my first instinct is usually to focus on technical depth. Learn another system. Get better at debugging. Read more. Build more things. That is still important, obviously. The people I am describing are technically strong for a reason.
But when I take a step back, I do not think the answer is just becoming the person who knows the most things.
I am trying to get closer to the other traits too: staying curious even when I am busy, explaining things clearly, paying attention to what is blocking other people, and understanding enough of the wider context to work on the problems that actually matter. A lot of that happens adjacent to writing code. It means talking to people, learning how other teams work, writing things down, and noticing friction before it turns into a fire.
I am definitely not there yet. But I find that a more useful goal than simply trying to become a deeper technical specialist. The engineers I admire most do not just have more answers. They make it easier for everyone around them to find answers and get useful work done.
That is the kind of engineer I am trying to become.
Top comments (1)
Điểm mình thấy đúng nhất là khả năng nhìn ra những rủi ro hệ thống trước khi dòng code đầu tiên được viết xuống. Ở môi trường lớn như Amazon, việc giải quyết vấn đề không chỉ là viết code chạy được, mà là hiểu được sự tác động dây chuyền lên các service lân cận và khả năng mở rộng về sau. Một kỹ sư giỏi thường dành nhiều thời gian để đặt câu hỏi "nếu điều này thất bại thì sao" hơn là tập trung vào việc áp dụng các pattern mới nhất. Sự thận trọng đó chính là thứ phân biệt giữa một người thợ viết code và một người thiết kế hệ thống thực thụ.