I am an EM that manages several senior engineers currently. I find it super common for senior engineers to get promoted mostly on technical merit, we end up thinking the rest "can be coached". Or it's coaching to the next level. Here are some areas I coach them on:

- influencing without authority. Managing up. Leadership.

- getting work prioritized

- providing useful performance feedback (promos etc)

- coaching and giving feedback to early career engineers

- communicating ideas effectively

- developing 1YP+ plans for their areas.

- idk, there are a lot, senior engineers are rarely "complete"

Coaching doesn't imply superiority. Most coaching can be done with little to no context and the goal is to guide the other person in finding the right answer on their own. I think you might be confusing coaching with mentoring.

As an example, I attended a coaching training session and when we broke out in groups I played the coach role. The other individual brought up a concrete issue they were having and I was able to unblock them and I never met that person before. I was their guide even though I had no context (but I have experience mentoring and coaching).

I've been a manager for years and there's a lot outside of raw technical ability that a good coach and mentor can keep you honest on. Rarely will you find someone who's reached full potential or who doesn't want to improve at all (maybe surprisingly based on your comment but I have found seniors to be the most eager to grow)

Most of the job is noticing friction and clearing paths — which requires context and trust more than technical superiority.

In practice: Start a note for each engineer you manage. Fred Brooks called this a "career file". Start by writing down things that frustrate them enough to complain about publicly. Add hurdles that come up in their one-on-one. Identify problems you can solve, problems you understand but cannot solve right now and problems you do not understand.

Then put on your PM hat; sort by priority and execute.

I think the biggest thing I've found myself teaching my younger colleagues is basically the internals of the systems or in what ways some of the things they've written might fail.

I haven't written any production C++ in about 2-3 years and honestly lost track of all the language updates since c++14. But when I explained how the code they write gets translated to assembly and runs on the machines, that's what i felt demystified the large codebases to my younger colleagues.

Same with many other topics - the event loops behind the JavaScript async/await, memory mapped io behind every read/write calls their operating system syscalls, basic data structures/algorithmic complexity behind their DB queries, scenegraphs and graphics APIs behind user interfaces etc... especially when pair programming.

I don't think I'm superior to them in any of these areas. I feel I'm fairly slower than them when writing code in any of these things. I definitely haven't kept up with all the changes in web frameworks or CLI tools or vim plugins. But sharing the behind the scenes knowledge helps them write better code is what i felt.

In my experience, I have used coaches that don’t have more technical skill than me, but are able to provide insight, questions, and provoke me to think through my problems in ways I might not have otherwise.

I break things down into coaching vs training vs mentorship.

Training is when you need to learn a very specific skill from someone that knows more than you. A great example is learning how to drive - it requires training from someone who knows more than you.

Mentorship is when you need to grow more holistically and are learning from someone that is significantly more advanced in your chosen area of study than you. Usually this involves not just technical training, but also a mindset that you wish to learn. Examples of this are apprenticeships or when you seek out a mentor that you think has done well and wish to learn from.

Coaching is when someone may not have more technical skill than you, but is still able to help you improve by probing, prompting, reflecting, or observing. A great example are sport coaches, who are not necessarily more skilled than many of the players they coach.

These are loose and blurry definitions, but I hope it helps frame another perspective on coaching.

Top tier sports people still have coaches. Some even have multiple coaches. Musicians have managers.

Unlike coaches for kids/ novices these folks aren’t necessarily better at the craft.

Yet, they (ideally )have a outside perspective that would improve an individual in their craft.

Coaching in my role is mostly about seeing the person up for promotion and helping them focus on the right stuff for the teams success. Even great senior engineers sometimes lose focus or miss the sentence in s career ladder that doesn’t mesh with what they want to be doing.

I’ve got a senior IC who is always hesitant to reach out to non-engineers, so to coach him I’m constantly asking him to reach out directly. It will improve his impact if he does so.

I am not an EM (anymore) but I see a lot of more junior engineers struggle with ambiguity and complex decision making in general.

It is not uncommon to end up in situations where there are not clear right answers and developing the techniques as an individual, and as a technical contributor to navigate these well is tricky.

I don't think this is an EM specific function at all though and is just something more experienced people should be doing for their team. I think the EM definitely has a role in making sure people identify that they could benefit from that kind of help and make sure they find it, but doing the actual coaching is optional.

The mindset shift from IC to EM is very complex. And the newly appointed managers don't always know how to not be a programmer when in that role. It sometimes bleeds into the reports' work and damages than helping.

I guess the "coaching" is to understand that mindset shift.

Not an EM, but definitely think a strong technical EM can provide valuable feedback when it comes to system design and data modelling.

How does a football coach do their job if they can’t run or throw or block as well as the players?

Dude, soft skills. 80% of any job, software development especially, is messy human problems. Engineers more than anyone can generally benefit from improving these skills.