Common problems managing senior engineers

The four hardest senior engineers to manage and how to coach them.

Aug 07, 2025

I’ve managed over 30 engineers across different levels. But if I look at where I’ve spent most of my time coaching, mentoring, and unblocking… it’s not juniors or new grads.

It’s Senior Engineers.

It was not what I’d expected. Because these are experienced engineers who’ve mastered their craft. They solve complex technical problems and ship features. All without needing much direct help.

So ideally they should be really easy to manage, right?

Well, for the most part yes. I’ve noticed four archetypes of senior engineers who need more intentional management. If 45% of all engineers are seniors, chances are you’re managing one (or more) of them already.

Don’t worry, I’ll share how you can coach them.

1. The Over-Engineer

Give this senior engineer a problem and they’ll come back to you with an idea of a highly scalable app.

As a manager, you may get impressed by the proactivity and the ownership. It happened to me once. An engineer told me they’re going to build a service with Redis as a storage layer, to migrate about a thousand github repos from one build process to another. I let them do it.

It took 3+ months to build a buggy version of that service and we didn’t have enough logging or visibility into why it broke later. The ROI on this started to decline. It didn’t meet the rosy picture in our heads. And the migration deadline was looming.

These engineers love to solve complex problems. They might even look for complexity when there is none. They just want to build cool things.

How EMs can help:

Bring them back to the customer value. Ask, “What’s the simplest thing that could work? What’s something we can deliver quick that will deliver the same (or similar) outcome?”
Ask to create decision records. Have them consider all alternatives and list pros and cons. Involve others to help decide or brainstorm ideas.
Put some artificial constraints. It can be the amount of time or infra cost. Or the number of people or skills E.g. “We don’t want to build our own UI.” Be careful to not block their thinking.

2. The Builder-First

This engineer is eager to build. They jump straight into implementation. And they design things on the go.

I once asked an engineer to spike on an operational metrics dashboard using Splunk and Grafana. The expected deliverable was a document with a layout of the dashboard, what metrics to show and why, how we’ll collect the data, etc.

For days, there was little to no progress on the doc. When I dug deeper, they were actually making progress but not in that doc. They were writing the queries and building the dashboards. They had planned to write the doc later, so it’s more accurate.

This archetype of senior engineers don’t feel comfortable proposing something unless they’re 100% confident. So they build it first.

How EMs can help:

Don’t expect perfect design and let them know this expectation. “It’s ok to miss edge cases. Validate what you can and make some assumptions. We can iterate.”
Help them see the value in designing. “It helps understand the feasibility of the project. It helps guesstimate the effort, timeline and constraints. And what if you need another engineer to work on this project?”
Encourage pattern matching. “What other systems you built in the past that were similar? Now work backwards and design that system first.” When docker was new, the way most people understood it was by comparing to a VM.

3. The Ambiguity-Freezer

While most engineers say, “Just tell me the problem and let me figure out how to do it,” they actually freeze when real world ambiguous problems come their way.

In tech, the higher you go the more vague the requirements get. Instead of,

write an api to return a json of transactions from the orders database

the requirements are more like,

we need to understand customer behavior.

This engineer may say “Ok sure, let me look into it” but they go and do random things hoping the clarity comes to them magically in the process.

How EMs can help:

Coach them to define clarity. Ambiguity starts to disappear as you ask questions and seek answers. “Who are the stakeholders and what do they care about? If you were to convert this into a metric, what would that be?”
Highlight the value of both answers and non-answers. When we ask questions we expect answers, so we get stuck on non-answers. Like “I can’t do anything if developers don’t resolve build failures on time.” But this is also an answer about what you expect (i.e. solve failures on time) and what the boundaries are (i.e. developers can do it).
Encourage them to invert the problem. Instead of asking what would lead to success, they should ask what would guarantee failure, and then do the opposite. My fellow author
Michał Poczwardowski
wrote about Inversion in depth.

4. The Soloist

This senior engineer loves to work solo. They feel that others, especially new engineers, will be a drag. They justify, “Oh it’s just easier for me to finish it off in a few hours than to spend time sharing the entire context and still wait .”

They’re fine helping and teaching others. They even review their code. But when it comes to a project they’re working on, they don’t feel comfortable delegating.

Sometimes because the solution is really easy and small. Sometimes it’s because they’re building it on the go, so they don’t know what’s next.

How EMs can help:

Help them to think in parallel workstreams. I realized this type of engineer often thinks linearly - task1, then task2, then 3, and so on. Ask to break down work into smaller chunks and ask which ones can be done in parallel.
Help them see how they can scale themselves. Show them what high-leverage task they could be doing if they could delegate some tasks on their plate. “If you delegate part of this implementation, you can start work on this new AI feature.”
Allow them time to build trust with the other engineer. Often they don’t delegate because they’re not sure if the other engineer will deliver to their taste and liking. They just need to spend more time together. Ask “Who in the team did you have 1:1 with? Did you pair program with someone lately?”

That’s it, folks!

Closing Thoughts

Senior engineers are an asset. But they do need your help to overcome some of their blind spots to grow.

They don’t need micromanaging, they need coaching. Remember that most of these gaps comes from their strengths. Like they don’t delegate because they can do it faster. So highlight their strengths first.

As a manager, it’s your job to spot their patterns, name them, and coach them through. Because after all, when senior engineers grow, your whole team levels up and your own job becomes easier.