As someone with people who report to me, my #1 job is to make sure they’re effective, happy, productive. Empowering them generates more productivity than me quietly doing stuff myself.
If you have people who report to you and your main job is enabling them, you’re a manager not an engineer. Which is fine, but also it’s an important distinction to make.
Labelling someone “engineer” or “manager” is not really useful. So why go out on a perilous precipice of doing so, especially when one lacks almost all the details necessary to make an informed assessment?
I think its pretty useful distinction. I know everywhere is different, but everywhere i have worked the roles have been very distinct. Engineers, especially senior ones, mentor people of course, with that being a significant part of their job, but that is really different from having someone report to you.
My previous contract ended abruptly but then a month later they needed me again because their current onshore offshore team was very large and growing by the day but incapable of non-trivial engineering tasks, all the way up to the engineering managers. They were essentially the hire paid copy/pasters. I said I'd return under the condition that I will golf all day. They hired me back on, I made the thing they needed, then they dumped me again abruptly for another onshore offshore engineer.
So sometimes a headcount can be an engineer, a manager, or both, and still be an embarrassment to git commits everywhere.
I entirely disagree both with this point and with it’s apparent subtext that being an engineer is better and being a manager is worse. I take it that you are one who takes great pride in “being an engineer”. That’s a separate topic (for instance, one can be an engineer in a management job).
We have the abstraction of job titles or categories to help us reason about what a job is. We do this for a variety of reasons, but in this case the reason to do it is to help people understand whether this advice might apply to them. Ultimately, a job is whatever it’s primary goal is, and you said yours is to empower junior staff who report to you. That makes you very different from many (most?) senior/staff engineers I have met, who are primarily metric’d on their engineering work. Since your primary job is a management function and you write a lot of code, that makes you a manager with some (or many, pick whatever modifier seems appropriate to you) engineering responsibilities.
Bringing it home, if a reader is an engineer (or IC if you prefer to avoid the fraught term) and not a manager, this advice doesn’t apply to them very strongly. Yes they should care about junior colleagues, and they should absolutely make time for deliberate peering and mentoring, but they should focus on doing engineering (which can include docs writing etc) primarily.
Sure, but is constant "direct attention" the best way to empower engineers? I would argue that systemic improvements (e.g. onboarding process, good documentation, team communication or company culture) are more impactful since they scale better and address the root of the problem. Of course, you need both, but saying that everything other than hand-holding is "just filler" shows a lack of understanding of good leadership.
I have people that report to me. This is true a lot of the time. The other thing I do is getting people to use the thing my team built - or figuring out what they want my team to build.
It’s not, if your job is to onboard a new engineer. Those first few months make all the difference. If the “other parts” of your job prevent you from maximally optimizing the productivity of your new coworker, the compounding negative returns on that onboarding engineers time is incredibly expensive.
Unlike almost anything else you could be working on, turning someone from nonproductive to productive, or more productive, has compounding effects that can quickly help or hinder the longer term objectives
Agree. At the end of the day, someone is paying for the jr and sr person. Is that what they want? If so, then it is fine I suppose. They do need to state this clearly however.
That might be taking it a bit too far?