You had a brilliant senior engineer, with years of experience, and they left after four months. In the exit interview, they said the job itself was fine. The problem was the manager: meetings with no agenda, feedback only when something went wrong, zero conversation about where their career was headed.
It's a well-known pattern in tech: people don't quit the company, they quit their direct manager. On remote teams that effect multiplies, because the manager is practically the only human point of contact a developer has with the company. If that relationship doesn't work, no nice office or competitive salary makes up for it.
How to Improve as an Engineering Manager on a Remote Team
1. Make the Weekly 1:1 a Real Priority, Not a Box to Check
Canceling the 1:1 when things get busy is the fastest way to tell your report they don't matter. If you manage eight people, that's eight hours a week at most, and it's the highest-return investment you'll make as a manager. Use that time to talk about what's blocking the person, not to ask for a sprint status, that's what the standup is for.
2. Define What Doing the Job Well Means for Each Role
Creating clarity around expectations is probably the most important job of an engineering manager. There are three levels of goals a developer needs clear to perform well:
Team goals: where the architecture or the product is headed this quarter, and why. Individual goals: what that person is specifically developing, whether it's a technical skill, technical leadership, or ownership of a module. Weekly priorities: the one thing that truly matters to get done, so the person doesn't end up firefighting all day.
If everything is a priority, nothing is. Your job is to filter the noise before it reaches the team, not forward it exactly as it landed on you.
3. Delegate What's No Longer Your Job, Not Just What's Left Over
The most common mistake when moving from senior IC to manager is still reviewing every PR as if you were still the code's owner. Delegating for real means identifying which tasks take up your time without needing your specific judgment, and letting them go, even if you could do them faster yourself. If you're still the team's technical bottleneck, you're not managing, you're postponing your own role.
4. Give Specific Feedback, Not the Compliment Sandwich
Saying good job on the feature, but check the naming doesn't help anyone improve. Feedback that changes behavior is concrete: what happened, what impact it had, what you expect next time. And it needs to happen close to when it occurred, not saved up for the quarterly review.
5. Coach Instead of Solving Everything Yourself
Most managers got the job because they were good at solving technical problems. The instinct to give a direct answer when someone on the team is stuck is strong, but every time you give it, you take away that person's chance to learn to solve it on their own. Asking what have you tried or what options do you see before stepping in builds more autonomous teams, even if it's slower at first.
6. Don't Look Away From the High Performer Who Mistreats the Team
When a manager doesn't address a star engineer's bad behavior (the one who tears junior devs apart in code review, the one who only responds to the CTO), they're telling the rest of the team that results matter more than how you treat each other. It's one of the fastest ways to lose the good people who actually know how to work as a team.
Being a good remote engineering manager isn't an innate talent, it's a practice you build meeting by meeting. The real metric of whether you're doing it well isn't how much code the team ships this week, it's whether, a year from now, the people you have today are still there, and still want to be.
