I wholeheartedly agree with point 7 Your goal is for your team to thrive without you. I spent a lot of time also playing a Scrum Master role in addition to my regular duties. So much so that some managers asked me to pursue this full time. I always explained that my goal is to be there just as a point of contact and that the team should be able to manage itself. Sadly, I see so many managers, scrum masters, or even r…
Things I've learned in my 10 years as an engineering manager
31–40 of 148 posts
Re: Things I've learned in my 10 years as an engineering manager
#32Why do people espouse goals like “not to be needed?” I never understood that. It sounds like LinkedIn virtue signaling. It’s a capitalist talking point along the lines of “I seek to be good and inexpensive capital for my corporate masters.” My goal is to help my team succeed in such a way as to keep my job or else get a better one. Being “not needed” hardly serves that goal. Look around you. We are in a world that is…
My teams would slow down without me because I can due process tasks more efficiently, but nothing demands me to be in the loop.
Re: Things I've learned in my 10 years as an engineering manager
#33Truer words have never been spoken. Note the OP put the word "Most" in there. Sure... there are a few ping-pong fanatics, but not as many as there are humans who like an emotionally fulfilling work environment.
A related sentence I've uttered is "Most engineers prefer more control over their daily tasks than cash bonuses." But again, the word "Most" is doing a lot of heavy lifting here. My experience is no more than 25% of devs will trade cash for micro-management. YMMV.
Re: Things I've learned in my 10 years as an engineering manager
#34What 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.
Re: Things I've learned in my 10 years as an engineering manager
#35Re: Things I've learned in my 10 years as an engineering manager
#36This 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 experienc…
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.
Re: Things I've learned in my 10 years as an engineering manager
#37>I wondered, “Who is this feature even for? Who will use it?” No one on my team knew. I think there's another key here - Don't assume someone else knows something. If you don't know why something is done some way, find out who does and make sure they do. I've been in so many situations where the organization gets complex - person A is loaned over here or person B is working on project X because team Y needed feature…
This is complicated by the fact that Marines deploy as MEUs, MEBs and MEFs [1] which aren't "pure" echelons, but it's a rule of thumb and guiding principle more than a hard and fast requirement.
I've ALWAYS been annoyed by engineering organizations that don't think developers at the leaf nodes of the org chart need to know what's going on. Devs may not do anything with the info, but letting people in on what's happening seems to send the message that "management thinks you're important enough to hear what we're working on" and every now and again, individual devs need to make decisions that depend on these more abstract / higher-level goals.
1. https://en.wikipedia.org/wiki/Marine_air%E2%80%93ground_task...
Re: Things I've learned in my 10 years as an engineering manager
#38Re: Things I've learned in my 10 years as an engineering manager
#39Re: Things I've learned in my 10 years as an engineering manager
#40This 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 experienc…
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)