[tmarice]

This kind of EM-focused articles often mention "coaching" and "career growth" -- I always wonder what does this concretely mean. Are they all managing teams of juniors straight out of college?

What can a career EM, or even an engineer-to-EM convert who has been out of the coding game for more than a few years, teach a non-junior engineer on their team?

I understand we can talk and exchange our concrete life experiences, same as I would talk to and listen to any other person, but the word "coaching" implies one party is superior to the other in one very concrete area.

[djb_hackernews]

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"

[_tlo4]

> Influencing without authority

> Getting work prioritized

> Developing 1YP+ plans for their areas

I was a little surprised by your list. Aren't these normally the responsibilities of a team lead or a manager? If I were hired as a senior engineer, I'd expect to be involved in group decisions about cross-cutting technical concerns (architecture, choosing languages and frameworks, the code review process), but changing my team's priorities would fall well outside the job description.

If somebody has the power to tell me what to prioritise, it feels topsy-turvy for them to ask me to tell them what they should tell me to prioritise. At that point, why have a leader at all?

[djb_hackernews]

I work at a large software company, senior engineers here are essentially technical leads for a team or a subsystem. They are my equals when it comes to level, often getting paid a lot more than me for high performers.

I'm here to help the team make decisions, but I delegate as much of the opinion having to my senior engineers. To have an opinion they need a bunch of inputs, sometimes getting those inputs isn't as natural as the technical inputs, that's where I come in.

Senior engineers are still involved in cross cutting technical concerns but for any work that is bounded by our team I'd be working with them scope out the work as requirements or use cases we give to mid level or early career engineers on the team to disambiguate with the senior engineer as a consult/negotiate.

[_tlo4]

Just a misunderstanding, then - thanks for taking the time to clear it up, I appreciate it.

Strange that your company calls its tech leads "senior engineers", when every other company is going through title inflation! Hiring for those roles must be a pain.

[taude]

I've never worked at a company that had a "tech lead" role as part of official HR levels. Junior engineers (couple levels) -> Senior Engineers (couple levels) -> Principle/Staff (couple levels) -> some form of really rare role of Distinguished.

Senior Engineers should definitely do what I think earlier comment thought of as "tech lead". Should be able to run juniors, solve cross-cutting needs, etc....

[ratorx]

Team lead manages the overall direction of the team (and is possibly the expert on some portions), but for an individual subsystem a senior engineer might be the expert.

For work coming from outside the team, it’s sort of upto your management chain and team lead to prioritise. But for internally driven work (tech debt reduction, reliability/efficiency improvements etc) often the senior engineer has a better idea of the priorities for their area of expertise.

Prioritisation between the two is often a bit more collaborative and as a senior engineer you have to justify why thing X is super critical (not just propose that thing X needs to be done).

I view the goal of managers + lead as more balancing the various things the team could be doing (especially externally) and the goal of a senior engineer is to be an input to the process for a specific system they know most about.

[_tlo4]

I agree, but I think that input is limited to unopinionated information about the technical impact or user-facing impact of each task.

I don't think it can be said that senior engineers persuade their leaders to take one position or the other, because you can't really argue against a political or financial decision using technical or altruistic arguments, especially when you have no access to the political or financial context in which these decisions are made. In those conversations, "we need to do this for the good of the business" is an unbeatable move.

[ratorx]

I guess this is also a matter of organisational policy and how much power individual teams/organisational units have.

I would imagine mature organisations without serious short/medium term existential risk due to product features may build some push back mechanisms to defend against the inherent cost of maintaining existing business (ie prioritising tech debt to avoid outages etc).

In general, it is a probably a mix of the two - even if there is a mandate from up high, things are typically arranged so that it can only occupy X% of a team’s capacity in normal operation etc, with at least some amount “protected” for things the team thinks are important. Of course, this is not the case everywhere and a specific demand might require “all hands on deck”, but to me that seems like a short-sighted decision without an extremely good reason.

[kenjackson]

In my 30 years in industry -- "we need to do this for the good of the business" has come up maybe a dozen times, tops. Things are generally much more open to debate with different perspectives, including things like feasibility. Every blue moon you'll get "GDPR is here... this MUST be done". But for 99% of the work there's a reasonable argument for a range of work to get prioritized.

[_tlo4]

When working as a senior engineer, I've never been given enough business context to confidently say, for example, "this stakeholder isn't important enough to justify such a tight deadline". Doesn't that leave the business side of things as a mysterious black box? You can't do much more than report "meeting that deadline would create ruinous amounts of technical debt", and then pray that your leader has kept some alternatives open.

[madeofpalk]

Architecture, choosing languages and frameworks, the code review process are all aspects where "influence without authority" comes into play. What if you want to introduce a new lint rule or CI process that might impact other teams?

Having technical influence across other teams of peers is exceptionally important for senior developers.

[dilyevsky]

In a large company there aren’t enough teams to lead for everyone who wants to get more money (promoted) so management invents these meaningless (for a regular senior) hoops to jump so they can track kpis and can’t be accused of favoritism. Something like that =)

[parthdesai]

I'm sorry, but if a senior engineer needs coaching on getting work prioritized, they are not a senior engineer.

[johngunderman]

I interpret this comment as talking about prioritization across a broader org. A senior engineer should be able to prioritize inside of their team and adjacent teams. But there is a reason why there are levels of engineer beyond senior - beyond just increased technical judgement, there is increased influence in orgs spanning hundreds or even thousands of engineers.

There is always opportunity for growth in this dimension. For example even the CEO has to build the right skills to convince the board of their priorities.

[ecshafer]

I worked with someone who had 30 years of experience, and would routinely go down rabbit holes of minimal value that they thought were valuable. Days spending on local environment setup and configuration scripts, for multiple platforms, when it only took a few commands to start everything up in a few seconds. Or making custom patterns to "improve maintainability" of the code base, that were brittle, overly abstract, and confusing.

[parthdesai]

Well in my opinion, they really aren't a senior engineer then. 30 years of experience doesn't automatically mean you're a senior engineer IMO.

To me, you can trust a senior engineer to get the project done properly without any oversight

[GabriDaFirenze]

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)

[tv26101617]

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.

[tl]

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.

[saidinesh5]

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.

[addaon]

Are you at a company that tends to hire from non-traditional backgrounds? The topics you mention -- the underlying "how it works" of the tech we use to build things day to day -- should be, and in my experience are, the areas where juniors have the clearest understanding relative to more senior engineers, since they just finished 4+ years learning about it five days a week in detail.

[saidinesh5]

Good point.. A lot of those colleagues were indeed either fresh out of college (math, computer science, mechanism etc...) or graduated in things like electrical engineering etc.. and worked in software roles for 3-5 years..

[0kl]

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.

[super_mario]

Coaching does not imply superiority. I doubt any sports coach could substitute any player in a competitive game, yet they can coach them to become better version of themselves.

What engineers usually struggle with as they grow into more senior roles is the transition from being primarily a technologist to being a leader. This is such a huge shift for a lot of engineers and requires soft skills and communication style adjustments. The more senior you are the more your focus shifts from coding to listening, networking, influencing, selling the technical vision, building trust relationships, understanding what other engineers need and want, to mentoring, to raising the quality of the team around you through influence to motivating others as well. Being able to influence the product direction, being able to express in business terms why something has to be done or should be a higher priority etc. Also, understanding the organization and becoming organizationally savvy is important.

All of these skills take time and practice to achieve, and good managers can guide their people through the journey.

[doctaj]

Here are a couple more things: - holding people accountable to their own goals - like getting a certification or learning about a particular, new topic. This benefits the company by having more highly trained people, and the individual benefits from higher success rates or more depth of learning accomplished. - setting expectations for promotions. Often, it’s a squishy guessing game about when a promo will come, but if you’re able, you can set the bar and hold the person to that to set them up for success. - one tangible example of coaching is just noticing bad behaviors — like, being late to meetings, lazy code, missing deadlines… and letting the person know you’ve noticed it, understand what’s going on, and hold them accountable to stopping the bad behavior.

[jampa]

There are already some great responses, but I want to add that one effective way to coach senior employees is to give them responsibilities one level above their current role and then provide feedback.

For engineers aiming to move into management or staff engineering, you can assign them a project at the level they aspire to reach and give feedback once they complete it. For example, for an engineer aiming to be an EM, I expect them to lead not only meetings but also all communications related to this project, while I act as their director. Afterwards, I provide feedback.

It doesn't have to be that extensive right away. You can start small, like asking them to lead a roadmap meeting, and then increase responsibilities as they improve. Essentially, create a safe environment for them to grow.

[devdp430]

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.

[__alexs]

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.

[throwaway173738]

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.

[singleshot_]

> the word "coaching" implies one party is superior to the other in one very concrete area.

The opposite seems obvious to me. After all, your manager isn’t writing the code. He’s not your boss because he’s a better coder than you are, but because he’s a better boss.

(If this does not fit your experience, I’d recommend quitting your job as soon as practicable).

[dasil003]

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

[nitwit005]

Their job in professional leagues isn't to provide some sort of educational instruction, it's closer to being a strategist.

[parthdesai]

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

[idiotsecant]

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.