6 ms·

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

• dasil003 8mo ago
  How does a football coach do their job if they can’t run or throw or block as well as the players?
  • nitwit005 8mo ago
    Their job in professional leagues isn't to provide some sort of educational instruction, it's closer to being a strategist.
• __alexs 8mo ago
  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.
• GabriDaFirenze 8mo ago
  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)
• tl 8mo ago
  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.
• djb_hackernews 8mo ago
  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"
  • parthdesai 8mo ago
    I'm sorry, but if a senior engineer needs coaching on getting work prioritized, they are not a senior engineer.
    • johngunderman 8mo ago
      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 8mo ago
      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 8mo ago
        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
• 0kl 8mo ago
  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.
• idiotsecant 8mo ago
  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.
• saidinesh5 8mo ago
  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 8mo ago
    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 8mo ago
      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..
• tv26101617 8mo ago
  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.
• throwaway173738 8mo ago
  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.
• devdp430 8mo ago
  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.
• parthdesai 8mo ago
  Not an EM, but definitely think a strong technical EM can provide valuable feedback when it comes to system design and data modelling.
• jampa 8mo ago
  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.
• doctaj 8mo ago
  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.
• deleted 8mo ago
  [deleted]
• super_mario 8mo ago
  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.
• singleshot_ 8mo ago
  > 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).
• deleted 8mo ago
  [deleted]