I think I have read maybe a hundred articles about building high performance engineering teams. All of them say the same things: hire good people, set clear goals, build psychological safety. Yes, that is correct. But it is also not very useful.
Because most of us don't get to build a team from zero with unlimited budget. We take over existing teams. We work with what we have. And the real question is - what do you actually do on a Tuesday afternoon that makes the difference?
I have been managing engineering teams for more than ten years. Different company sizes, different tech stacks, different cultures - including here in Vietnam where I worked in both local startups and companies with foreign clients. I've had teams that were really high performing. Shipping fast, feeling good, growing. And I've had teams that were technically okay but somehow just... slow. Grinding. Fragile. I was the same person in both situations. That was uncomfortable to realize.
What "high performance" actually looks like
It is not a dashboard. Not velocity points or deployment frequency, even though those can be signals.
What I notice on good teams is more like an energy. PRs get reviewed the same day. Someone has a blocker and two people help without being asked. When a production incident happens, no panic, no blame - just focused people fixing the problem together. Decisions get made. Things ship.
The opposite is also easy to recognize. PRs stay open for days. Everyone waiting for someone else to make a decision. People are busy but nothing actually moves. That feeling where you always push from behind.
The difference almost always comes from three things: clarity, trust, and how the team handles disagreement. You don't learn this from a framework. You learn it from watching.
The mistake I made early on
When I first became engineering manager I over-managed. A lot. I thought my job was to make sure everything was going right, so I was everywhere. Reviewing everything. Jumping into Slack threads I didn't need to be in. Asking for daily updates.
I really thought I was being helpful. I wasn't.
What I was actually doing - without meaning to - was sending a message that I didn't trust people. Engineers who were perfectly capable started asking me before making decisions they should own themselves. The team got slower. I got more stressed trying to keep up with everything. A bad loop.
The fix was not comfortable. I had to deliberately remove myself from things. Stop reviewing every PR. Stop being first to answer every message. Let decisions happen without me. It felt irresponsible at first. But the team actually did fine. Better, honestly. Some things went wrong and we fixed them. But giving people that autonomy changed how they showed up.
Under-managing is real too - I've seen managers go so hands-off that the team has no direction at all. But in my experience, over-management is more common, especially if you were a strong engineer before becoming a manager.
Psychological safety, actually
This phrase gets used a lot and I think it confuses people. It sounds soft. Like, you need to make everyone feel comfortable. That is not quite it.
In practice, psychological safety means people will say the uncomfortable thing. They'll tell you the estimate is wrong. They'll flag the technical debt everyone is ignoring. They'll disagree with your idea in the meeting instead of agreeing and then doing something different later.
You build this by reacting well when it happens. If an engineer tells you something is a bad idea and you get defensive, they will remember that. Maybe they won't say it next time. That is how it slowly erodes. It is small and slow and by the time you notice, people are just executing quietly, not really thinking.
The most concrete thing I do: when someone pushes back on me and they are right, I say it out loud. "Yeah, you're right, I was wrong about that." Not in a big dramatic way, just normal. It sounds small but it does something. It shows that being right matters more than who has the title. And that disagreeing is safe.
Senior and junior on the same team
This is something that trips a lot of managers. The easy thing is to let seniors run and give juniors only small, safe tasks. Keeps things moving, right?
Short term yes. Long term the juniors don't grow fast enough and the seniors get tired of carrying everything. The team becomes unbalanced.
What worked better for me: give juniors real features with real ownership. Not just subtasks. Seniors as reviewers and collaborators, not rescuers. I'm explicit about this - I'll tell the senior, "your job here is to help them ship it, not ship it for them." Sometimes the junior takes longer. That is okay. You are building a person, not just shipping a ticket.
And seniors need stretch too. If a senior engineer only does work they've done a hundred times, they will start looking for somewhere else to do something new. Give them ambiguous problems. Let them design things from scratch. Bring them into decisions that are a bit above their current role, not just execution work.
Clarity is infrastructure
The biggest thing I can do as a manager is make things clear. Not motivational speech - actual clarity. Who owns this decision? What does done look like? What are we trying to do this quarter and why?
Engineers are very good at solving problems. If you give them a fuzzy problem they will still try to solve it - they will just all be solving different versions of it. Then you wonder why nothing is aligned.
I write a lot of things down. Decision logs. Goals that are specific, not vague. Ownership that is named, not assumed. It is boring work. Nobody thanks you for it. But it is what makes everything else possible.
If I have to say one thing: the team is a system, and you are part of it. How you show up changes the system. What you reinforce, what you reward, how you react when something goes wrong - that is the actual job. The rest is just administration.
I have made a lot of mistakes managing people. But the teams I am most proud of were not the ones with the most talented people. They were the ones where people really wanted to work together and felt like they could do their best work. That doesn't happen by accident. It is built slowly, through a lot of small decisions that most people never see.