The slow death of the hands-on engineering manager(zaidesanton.substack.com)
zaidesanton.substack.com
The slow death of the hands-on engineering manager
https://zaidesanton.substack.com/p/the-slow-death-of-the-hands-on-engineering
66 comments
That's a cool conceptual framework but like all conceptual frameworks it's meant as a simple, immediate rule of thumb, not a theory of how engineering management works.
In practice, the last three Ds depend heavily on familiarity with the first one, as they ultimately boil down to steering it at (team) scale. Without it, you're going to decide the wrong thing for what your team needs to do, delegate the wrong things to people who can't do them, and ultimately design an organisation that can't do shit.
Actually doing it isn't the only way to attain that sort of familiarity but for lots of people it's the only one that works. For them it's anything but the least important type of action a leader can do. Once they stop doing it at all, the clock of knowledge obsolescence starts ticking and all the other Ds atrite, as they inevitably end up deciding, delegating and designing based on yesterday's realities.
In practice, the last three Ds depend heavily on familiarity with the first one, as they ultimately boil down to steering it at (team) scale. Without it, you're going to decide the wrong thing for what your team needs to do, delegate the wrong things to people who can't do them, and ultimately design an organisation that can't do shit.
Actually doing it isn't the only way to attain that sort of familiarity but for lots of people it's the only one that works. For them it's anything but the least important type of action a leader can do. Once they stop doing it at all, the clock of knowledge obsolescence starts ticking and all the other Ds atrite, as they inevitably end up deciding, delegating and designing based on yesterday's realities.
Maybe it’s just my own bias because I love prototyping… But I feel in software engineering there’s a fifth D that combines the first and last items on this spectrum. (Sort of like magenta is a color that’s produced by the mix of wavelengths at the opposite ends of the visible spectrum.)
Designing by Doing can cut through a lot of wasted time. If a principal engineer builds a working prototype, it can immediately move the discussion past the “Is that even possible or realistic” stage where lots of ideas go to die.
Leading by doing is often a much better use of an experienced engineer’s time than promoting them to an architect role where they produce diagrams that nobody barely looks at. Design isn’t a panacea.
Designing by Doing can cut through a lot of wasted time. If a principal engineer builds a working prototype, it can immediately move the discussion past the “Is that even possible or realistic” stage where lots of ideas go to die.
Leading by doing is often a much better use of an experienced engineer’s time than promoting them to an architect role where they produce diagrams that nobody barely looks at. Design isn’t a panacea.
I agree 100% to this. I use analogy of Scout in Age of Empires game. Scout allows one to explore the terrain, mark areas of resources, enemies, their civilization type and hence strengths/weaknesses.
Similarly prototyping enables simultaneous exploration of problem space and solution space. After prototyping one can propose a design/architecture which is rooted in ground reality. You are more clear about upstream/downstream dependencies. Might even uncover gaps in product specs.
Similarly prototyping enables simultaneous exploration of problem space and solution space. After prototyping one can propose a design/architecture which is rooted in ground reality. You are more clear about upstream/downstream dependencies. Might even uncover gaps in product specs.
Those 4Ds are so abstract and tautological to the point of being useless. As a practicing line EM I spent most of my time hiring, project management, people management, networking, resolving conflicts, mentorship, to name a few things of the top of my head.
But all of this was built on a solid foundation of the system my team owned. And that was only possible if I understood things at the code level how various product flows worked. And I personally can’t understand code unless I fiddled around with it.
But all of this was built on a solid foundation of the system my team owned. And that was only possible if I understood things at the code level how various product flows worked. And I personally can’t understand code unless I fiddled around with it.
Some of these "frameworks" are always something like "just do the right thing."
As if that is ever easy to understand.
As if that is ever easy to understand.
The whole premise of clockwork is to setup a system that's self sustainable to make you money with minimal effort - it's a book for owners.
If everyone in the business worked like this - carving out roles where they get paid, but did next to nothing, then I suspect the business wouldn't do very well.
If everyone in the business worked like this - carving out roles where they get paid, but did next to nothing, then I suspect the business wouldn't do very well.
> carving out roles where they get paid, but did next to nothing, then I suspect the business wouldn't do very well
That's exactly what happens at big tech companies, except the business can be doing so well that the impact is only felt on a 10-year timeline.
That's exactly what happens at big tech companies, except the business can be doing so well that the impact is only felt on a 10-year timeline.
And perhaps worse than doing nothing - because they do have to occassionally have to justify their role - they need to initiate/be involved in big transformational projects every so often.
At best these just cost money, at worse they get in the way of the real work.
Obviously sometimes you really need these sort of projects - led by people who are truely trying to transform things - the problem is when it's led by people whose sole aim is to look busy by creating busy work for others.
At best these just cost money, at worse they get in the way of the real work.
Obviously sometimes you really need these sort of projects - led by people who are truely trying to transform things - the problem is when it's led by people whose sole aim is to look busy by creating busy work for others.
That's exactly what happens at big companies and a bunch of midsized companies.
The problem is that if you don't do much, you will get out of touch and all the other Ds will be coming from a place with little understanding. I have seen it a lot, especially with companies growing larger. Then they focus on the wrong things due to telephone game between layers.
> Sometimes that might be coding, most of the time though, it is not.
I agree 100%, though I will add it is important to have a manager who can do, so that at the very least they can have technical conversations.
Nothing worse than a manager who has no concept of what the doing even is.
I agree 100%, though I will add it is important to have a manager who can do, so that at the very least they can have technical conversations.
Nothing worse than a manager who has no concept of what the doing even is.
For a good IC it might feel important that the manager understands engineering and has domain knowledge, but for the organisation it is import that the manager understands engineering and has domain knowledge so they can work out which ICs are good.
This one is new to me. I know of 3D: Do, Delegate, Defer
I am a combination Tech Lead/Line Manager. I'm at a lower position than an Engineering Manager but the problems don't seem that different.
I found that losing touch with the code is disastrous - one cannot make sensible decisions without a familiarity. I need to know how difficult it's getting to write tests and get features done if I'm to make decisions about how to simplify everything for other developers. I have to understand what's possible.
I also cannot really review code well in a PR - it's meaningless until I've worked on that code and thought "oh #$%#$%, we can't do this like this.....!!"
So the decision part of management is just not possible without some time programming. I like to do refactoring - esp of tests and bits of code where I know that people have been in a rush and done a bit too much copy/pasting. I try to make log messages more useful, simplify things that I realise can be simplified. I write scripts to make annoying bits of work trivial so other developers have an easier time. I try to punch through problems with debugging or development.
Some management tasks soak up energy:
I found that losing touch with the code is disastrous - one cannot make sensible decisions without a familiarity. I need to know how difficult it's getting to write tests and get features done if I'm to make decisions about how to simplify everything for other developers. I have to understand what's possible.
I also cannot really review code well in a PR - it's meaningless until I've worked on that code and thought "oh #$%#$%, we can't do this like this.....!!"
So the decision part of management is just not possible without some time programming. I like to do refactoring - esp of tests and bits of code where I know that people have been in a rush and done a bit too much copy/pasting. I try to make log messages more useful, simplify things that I realise can be simplified. I write scripts to make annoying bits of work trivial so other developers have an easier time. I try to punch through problems with debugging or development.
Some management tasks soak up energy:
* hiring is one. I'm new to it and I am only beginning to have ideas about how to do it more efficiently. I wanted to get my team to help choose people but this ends up taking far too long to arrange. I realise I need to man up and do more of the initial choosing and present them with a limited choice at the end - I want people who will work well with everyone else. No arseholes, however good they might be.
* helping people get their tickets done - which is good work and always worthwhile but to do it well you do need to understand the codebase a bit.
* meetings about future features...which are incredibly inefficient because they're about getting everyone to understand what is wanted and trying to imagine an acceptably rapid way of doing it that will also fit in with other plans. This is very inefficient because people talk a great length then forget and have to understand it all again weeks later. On the other hand, doing work where everyone has a different understanding of what's needed is a deadly problem, so the horrendous hashing-things-out sessions generally pay off in the end. I just wish there was a better way.For your feature meetings the recipe for success is the same as any meetings, have an agenda and other materials people need to review before the meeting to be prepared to contribute without wasting everyone’s time, and take minutes and distribute them after the meeting, the minutes document the decisions made so they don’t need to be rehashed on the next meeting, and the minutes feed in to the preparation package for the next meeting.
It is a lot of work to prepare these meetings and keep them on track, on the agenda items, so that the required decisions get made.
This only works if you're the gate keeper to a feature shipping. If the role is flipped, meaning you need to convince the gate keeper, good luck getting them to read your minutes. And it doesn't necessarily need to be a toxic relationship, they're just busy and you need to do the work to get them where you want them.
It sounds like you lack a Staff engineer that can be your number 2 on the team.
It's invaluable to have someone that can champion these technical aspects of the job. It doesn't mean that you need to relinquish all technical work to them, but having someone you can trust to keep the team technically solid and keep you in the loop when you inevitably have to focus on non-technical stuff, is key to a high performant team in my experience.
It's invaluable to have someone that can champion these technical aspects of the job. It doesn't mean that you need to relinquish all technical work to them, but having someone you can trust to keep the team technically solid and keep you in the loop when you inevitably have to focus on non-technical stuff, is key to a high performant team in my experience.
Hiring is a fun challenge because you:
- need to work with your upper management to get the best talent for what may be more money than they are willing to part with. You need to be great at negotiating to achieve this.
- need to find the right culture fit. Will the team want to spend 40+ hours a week with this new person? Do they have any personality conflicts?
- find a way to get the best talent without offending your team. Sometimes you have the option to hire someone whose skillset is radically better than what already exists on your team. Do you hire that person? Does your team handle it well? Does this mean the person who thought they would get a promotion in 18 months is going to slow their output because they assume that their future "slot" is now gone? How do you cope with that.
- balance the time between your "day job" and hiring a new person. I believe when you have an opportunity to hire, it needs to be one of your most critical AND urgent priorities because the impact is ultra-high and the effort is much lower than most long-term efforts (I once made the mistake of moving too slowly on a backfill caused by a lateral promotion, and I didn't see the cracks forming until we lost a 2nd engineer to burnout. We ended up running way too lean for way too long. Eventually we backfilled the two positions with two superior engineers, but it was a very tough time and I could have realistically replaced those positions much more rapidly and my team would have been better for it.)
- need to work with your upper management to get the best talent for what may be more money than they are willing to part with. You need to be great at negotiating to achieve this.
- need to find the right culture fit. Will the team want to spend 40+ hours a week with this new person? Do they have any personality conflicts?
- find a way to get the best talent without offending your team. Sometimes you have the option to hire someone whose skillset is radically better than what already exists on your team. Do you hire that person? Does your team handle it well? Does this mean the person who thought they would get a promotion in 18 months is going to slow their output because they assume that their future "slot" is now gone? How do you cope with that.
- balance the time between your "day job" and hiring a new person. I believe when you have an opportunity to hire, it needs to be one of your most critical AND urgent priorities because the impact is ultra-high and the effort is much lower than most long-term efforts (I once made the mistake of moving too slowly on a backfill caused by a lateral promotion, and I didn't see the cracks forming until we lost a 2nd engineer to burnout. We ended up running way too lean for way too long. Eventually we backfilled the two positions with two superior engineers, but it was a very tough time and I could have realistically replaced those positions much more rapidly and my team would have been better for it.)
We adopted Amazon's 6-pager strategy for meetings. It has been incredible helpful. TLDR - one person writes a document explaining the proposed feature, max length 6 pages. That one person does 80% of the work (whatever your org wants e.g. timeline, target customers, planned KPIs and/or ROI).
Process: Start the meeting, turn on your camera (surprisingly important for us), and set a timer. Everyone quietly reads for ~20min. AFTER they finish reading, restart and engage via comments - positive/agreement comments are great, questions are useful, answering/responding to other's questions is encouraged. Post 20min, one speaker goes through the comments. Many (70% is common for us) will already have been resolved or will not require discussion. Long comment chains or lack of consensus on a comment chain is where we spend the discussion time. Common pitfall - Speaker DOES NOT present the document, that just wastes 20min and bores everyone to death. Small nuance - speaker (doc preparer) is already familiar with doc, so they watch the timer. They also check in e.g. at 15 give a 5min warning, at 20min check if anyone needs more time, etc.
Huge net positive for us: - No more "pre-read" (no one does it), we just say that a 45min meeting is when you BOTH get the information AND discuss is - Post the "20min" we are already 80% on the same page - Far far fewer "basic" questions that kill time - those were answered by the doc - Quiet reading gives people time to mentally switch/shift from their last 5 meetings and come up to speed. Less "anxious energy" when talking - Increase collaboration - "Type A" talkers cannot (as easily) dominate the comments. Leaves "airshare" for quieter team members to participate via comments. We've begun encouraging all to leave at least 4-5 comments
Negatives: - REQUIRES senior team member support, else 1 senior "ass" will break the rules and start talking - Writing the document is time consuming and not easy. This really becomes one persons "work" to gather the data from all stakeholders in a 1-1 fashion, organize it, summarize it
Process: Start the meeting, turn on your camera (surprisingly important for us), and set a timer. Everyone quietly reads for ~20min. AFTER they finish reading, restart and engage via comments - positive/agreement comments are great, questions are useful, answering/responding to other's questions is encouraged. Post 20min, one speaker goes through the comments. Many (70% is common for us) will already have been resolved or will not require discussion. Long comment chains or lack of consensus on a comment chain is where we spend the discussion time. Common pitfall - Speaker DOES NOT present the document, that just wastes 20min and bores everyone to death. Small nuance - speaker (doc preparer) is already familiar with doc, so they watch the timer. They also check in e.g. at 15 give a 5min warning, at 20min check if anyone needs more time, etc.
Huge net positive for us: - No more "pre-read" (no one does it), we just say that a 45min meeting is when you BOTH get the information AND discuss is - Post the "20min" we are already 80% on the same page - Far far fewer "basic" questions that kill time - those were answered by the doc - Quiet reading gives people time to mentally switch/shift from their last 5 meetings and come up to speed. Less "anxious energy" when talking - Increase collaboration - "Type A" talkers cannot (as easily) dominate the comments. Leaves "airshare" for quieter team members to participate via comments. We've begun encouraging all to leave at least 4-5 comments
Negatives: - REQUIRES senior team member support, else 1 senior "ass" will break the rules and start talking - Writing the document is time consuming and not easy. This really becomes one persons "work" to gather the data from all stakeholders in a 1-1 fashion, organize it, summarize it
> I found that losing touch with the code is disastrous - one cannot make sensible decisions without a familiarity.
This. Your decisions become less and less grounded in reality the farther you get from the code base. It is the same as in the military: generals always fight the last war, usually with disastrous results, like attempting to charge machine gun nests in WW1, because they are too far removed from the reality on the ground.
This. Your decisions become less and less grounded in reality the farther you get from the code base. It is the same as in the military: generals always fight the last war, usually with disastrous results, like attempting to charge machine gun nests in WW1, because they are too far removed from the reality on the ground.
> I also cannot really review code well in a PR - it's meaningless until I've worked on that code and thought "oh #$%#$%,
I kind of feel that way with code review in general. It's the author's code. I didn't write it. So I don't have much understanding or context (except for the simplest of PRs).
I kind of feel that way with code review in general. It's the author's code. I didn't write it. So I don't have much understanding or context (except for the simplest of PRs).
Thinking of lots of EMs I've known or worked with who used to code, across quite a few companies, its really a factor of their tenure in role. At first a bright young engineer IC taking the EM track will try to keep being an engineer and keep coding. But with time they get bored with this and realise it has no correlation with how their manager measures their success etc, and they get over that fad and coast. YMMV.
I used to think I had low quality EMs because they didn't have an IT background. However I started coming across EMs with IT backgrounds that had completely checked out of anything technical.
They'd let their source control licence lapse giving them an excuse to not get involved in shutting down long running PR debates, suggest they can only get involved in a discussion if we were still using XYZ dead language/stack from two decades ago.
They'd let their source control licence lapse giving them an excuse to not get involved in shutting down long running PR debates, suggest they can only get involved in a discussion if we were still using XYZ dead language/stack from two decades ago.
I am an IT project manager at a company with 750 employees. In my role, I coordinate various teams – both internal and external. My work requires me to quickly grasp complex IT systems and rapidly acquire domain knowledge. While programming is not part of my core responsibilities, my ability to write, deploy, and test code allows me to communicate effectively with engineers and better understand technical challenges. So yes, being able to work in terminal, to write code, to run it, play with it, to review code is very helpful for me.
This article is pretty on point with my experience. I'm a "senior technical" manager (of about 60 engineers) and with that comes a ton of responsibility that pulls me away from coding at every turn. I have to be in every call, I have to know everything that's going on and I have to be able to be able to communicate all of this in ways that advocate for the team but also navigate the politics of the organization.
All that said, I often get criticism that I should not be picking up coding tasks every sprint. There seems to be some unwritten rule that remaining a coder is a net negative when you start tickling the upper management ranks. On the one hand I'm told that I need to train the other managers to be more like me and then on the other hand I'm told that I code too much, I'm going to burn out and need to find ways have others do the work.
I personally think being able to do all kinds of coding tasks (prototyping, bug fixes, major time sensitive features, etc) does a lot for me as a manager... the team respects me, I stay close to the code so I can speak about it as well as anyone can and I can contribute to just about anything if the need arises. If I ever get promoted to Director level then I probably will have to step away from coding as an official duty, but I'll happily keep enjoying that part of my job for now.
All that said, I often get criticism that I should not be picking up coding tasks every sprint. There seems to be some unwritten rule that remaining a coder is a net negative when you start tickling the upper management ranks. On the one hand I'm told that I need to train the other managers to be more like me and then on the other hand I'm told that I code too much, I'm going to burn out and need to find ways have others do the work.
I personally think being able to do all kinds of coding tasks (prototyping, bug fixes, major time sensitive features, etc) does a lot for me as a manager... the team respects me, I stay close to the code so I can speak about it as well as anyone can and I can contribute to just about anything if the need arises. If I ever get promoted to Director level then I probably will have to step away from coding as an official duty, but I'll happily keep enjoying that part of my job for now.
What is the source of work for these 60 people? Who is keeping them fed?
That is beyond a full time job, and if your cup isn't full today, staying aligned with the product requirements and architectural implications, you need to let go and focus on that.
That is beyond a full time job, and if your cup isn't full today, staying aligned with the product requirements and architectural implications, you need to let go and focus on that.
I'm the senior manager, I have about 5 managers under me so I don't have 60 reportees.
> There seems to be some unwritten rule that remaining a coder is a net negative when you start tickling the upper management ranks.
sometimes I wonder if this is a thing because managers just don't want to code, and having other managers doing it makes them look bad
sometimes I wonder if this is a thing because managers just don't want to code, and having other managers doing it makes them look bad
60!? I struggle with ~10. Teach me, Yoda.
On a more serious note, 100% agree. I'm asked to delegate more, but I don't want my skills to atrophy and, I'm happy when I'm coding. If I had to JUST manage, I wouldn't survive, figuratively speaking.
On a more serious note, 100% agree. I'm asked to delegate more, but I don't want my skills to atrophy and, I'm happy when I'm coding. If I had to JUST manage, I wouldn't survive, figuratively speaking.
I have 5 manager under me, so the 60 are not direct reportees. I do interact directly with most of the devs, but the other managers do a good deal of the lifting too.
Wait 60? Surely not direct reports? I'm guessing you have about 4-5 managers? Impressive that you have the luxury of picking up some coding tasks with 4-5 managers!
Yeah, I should have made that more clear. You are 100% correct, I manage 5 other managers and they have about 10 devs each under them. I do work directly with virtually all of the devs and handle the majority of PRs so we are all one big team.
Here are my two cents. I understand that there are coding things which I could do as an EM. And I can find time for it if I want to. But .. at any given time when I want to I have to decide if it is the most important thing I can do with my time. Sadly, the answer usually is “no”.
That did shift over time, I now manage teams maintaining three distinct products - and between managing the people and the products, setting the vision, dealing with customers.. there is just never any time for coding which isn’t taking away from the time I could better spent doing something else.
That did shift over time, I now manage teams maintaining three distinct products - and between managing the people and the products, setting the vision, dealing with customers.. there is just never any time for coding which isn’t taking away from the time I could better spent doing something else.
Throwaway because market is too bad to say the truth.
Managers who code learn they are inviting political suicide.
1. Managers need to navigate office politics - a full time and full energy job.
2. Other teams will use lack of 8 hours of "coding output" as a weapon to prove that manager is not working.
Putting more political pressure on them and their team.
Managers who code learn they are inviting political suicide.
1. Managers need to navigate office politics - a full time and full energy job.
2. Other teams will use lack of 8 hours of "coding output" as a weapon to prove that manager is not working.
Putting more political pressure on them and their team.
The trend is to cut down on these non hands on managers. If you are one of those, hold onto that job with dear life since they are disappearing
My experience: I lived every day in agony knowing there's nothing of value I'm contributing to this company and everyone around me knows. I was turbo depressed.
If this is you I'd advise you to leave that job as soon as possible and take matter into your own hands.
I became an individual contributor at a different company after being in this non-hands-on manager role for just about 2 years. What followed was a sense of accomplishment, being a happier person overall and earning way more money.
If this is you I'd advise you to leave that job as soon as possible and take matter into your own hands.
I became an individual contributor at a different company after being in this non-hands-on manager role for just about 2 years. What followed was a sense of accomplishment, being a happier person overall and earning way more money.
Agreed. Good on you to make that decision. If only the vast majority of other middle managers had that much integrity
>If only the vast majority of other middle managers had that much integrity
I would argue the vast majority of other middle managers can't code, so play manager is all they can do.
I would argue the vast majority of other middle managers can't code, so play manager is all they can do.
>The trend is to cut down on these non hands on managers.
If only. A lot of them have embedded themselves deeply in the org to make themselves feel indispensable to the upper echelons. So even though they are dispensable, as long as those at the top don't know that, they're not going anywhere.
If only. A lot of them have embedded themselves deeply in the org to make themselves feel indispensable to the upper echelons. So even though they are dispensable, as long as those at the top don't know that, they're not going anywhere.
I agree and let me explain that we are actually talking about the same thing.
Basically senior managers are offering less senior managers as sacrifice to embed themselves deeper. But that shtick doesn’t last forever I can promise
Basically senior managers are offering less senior managers as sacrifice to embed themselves deeper. But that shtick doesn’t last forever I can promise
And the now more important senior managers will re-hire new managers when they can because it's too much work to do entirely themselves.
yes, if you're reading this and your EM job consists of: taking notes during sprints, 1:1s, meeting with other "leaders", discussing "culture" issues, and interviewing ... go practice some leet code, cause your marketability is a sinking ship (source: I interview many of these archetypes, and they are allergic to technical interviews)
You should throw them a fizzbuzz, curious how many EMs can pass that
I was an engineering manager, but I am now more of a co-manager, because I suck at managing difficult engineers. Our business is small and we asked our product manager to help manage engineers too. She is not technical, but is great at managing people.
I now write software, assign tasks, hire and sometimes fire people too. But I don't do the hard stuff of managing people, doing their reviews, encouraging and coaching them and giving them a shoulder to cry on. I know my limits.
I love this arrangement. Sharing a role works well if you can find someone who is good at what you suck at.
I now write software, assign tasks, hire and sometimes fire people too. But I don't do the hard stuff of managing people, doing their reviews, encouraging and coaching them and giving them a shoulder to cry on. I know my limits.
I love this arrangement. Sharing a role works well if you can find someone who is good at what you suck at.
That sounds like more of a tech lead role than EM. Nothing wrong with that, it's good that you found a way to balance it.
If you want to continue on the manager path, I'd suggest leaning into that area of weakness and trying to improve it as much as you can. At Director+ levels, these skills are non-negotiable.
If you want to continue on the manager path, I'd suggest leaning into that area of weakness and trying to improve it as much as you can. At Director+ levels, these skills are non-negotiable.
I feel more at home as a Senior Dev, or maybe a Tech Lead/Mentor, but here I am in management for the last 7 years. The article definitely resonates with me, as do many of the comments. I miss coding, deeply. I try to pick up the occasional project at work, but too often I have to turn it over due to lack of time. Sometimes I do not turn it over and it ends up taking far, far longer than it should have. I know I sometimes hold things too close to the chest. Delegating is not my strong suit but, in my mid 40's, I'm getting better.
Whatever I'm doing, imposter syndrome be damned, seems to work. My team always look to me for help and plead with me to never leave; though I'm sure they'd find their way. I do find it difficult to keep up with all the projects going on at times, which complicates ongoing project discussions Especially when the developer isn't the best at communicating effectively and I need to be the liaison between them and upper management. Trying to keep up with all of that is really what limits my time as a developer.
I was pleasantly surprised that the article linked a write-up on building an internal ChatBot. We're been looking at doing the same through Elastic AI but scratching that itch myself seems fun. I just wonder how long it'll be before I have to hand it over to someone else...
Whatever I'm doing, imposter syndrome be damned, seems to work. My team always look to me for help and plead with me to never leave; though I'm sure they'd find their way. I do find it difficult to keep up with all the projects going on at times, which complicates ongoing project discussions Especially when the developer isn't the best at communicating effectively and I need to be the liaison between them and upper management. Trying to keep up with all of that is really what limits my time as a developer.
I was pleasantly surprised that the article linked a write-up on building an internal ChatBot. We're been looking at doing the same through Elastic AI but scratching that itch myself seems fun. I just wonder how long it'll be before I have to hand it over to someone else...
Better than rolling out an AI to hopefully find the docs you're looking for, it would be better to create an actual framework for the docs. This would remove uncertainty about where docs live and improve discoverability to peruse as needed.
AI and search is only as helpful as the content provided, and most applicable to those already familiar with the existing domain.
AI and search is only as helpful as the content provided, and most applicable to those already familiar with the existing domain.
If you're not touching code you're not an engineering manager. You're a manager that happens to oversee engineers.
I might be a bit jaded, but I don't feel like I've seen an implementation of EMs I actually feel work well, at least from an IC perspective. The EM often ends up being a mix of both tech lead and all HR stuff, being overworked and unavailable, or neglecting one of the tasks.
I've actually preferred when my "EM" is on a different team than me. Can then speak freely to the person about issues in my team etc.
I might be a bit jaded, but I don't feel like I've seen an implementation of EMs I actually feel work well, at least from an IC perspective. The EM often ends up being a mix of both tech lead and all HR stuff, being overworked and unavailable, or neglecting one of the tasks.
I've actually preferred when my "EM" is on a different team than me. Can then speak freely to the person about issues in my team etc.
> If you're not touching code you're not an engineering manager
Surprise: Not all engineering is software engineering.
Surprise: Not all engineering is software engineering.
The tweet article talks about writing code.
Your first statement certainly attracted some downvotes, but I can't disagree.
Engineering Management is supposed to be a support role, working from the sidelines on enabling engineers to deliver, manage career progression, and sometimes help untangle actual technical problems - but not act as a tech lead. My experience echoes yours: EMs serving multiple teams can do that most effectively without the role getting muddled.
It was meant to replace non-technical project management, and gives space for product to become a non-management role. If the EMs stop being technical, what's the point?
Engineering Management is supposed to be a support role, working from the sidelines on enabling engineers to deliver, manage career progression, and sometimes help untangle actual technical problems - but not act as a tech lead. My experience echoes yours: EMs serving multiple teams can do that most effectively without the role getting muddled.
It was meant to replace non-technical project management, and gives space for product to become a non-management role. If the EMs stop being technical, what's the point?
I deserved the votes jo-jo-ing up and down, as I didn't manage to put my thoughts down as eloquently as you and it came out a bit harsh.
Probably because of my recent bad experience before summer. I was tech lead at a small 3 dev team (including me). Then we got an EM assigned working full time in the team. Somehow nothing changed, I still did all the technical leadership, contributed code and talked with the stakeholders. While he was just always "busy" going to some meeting, and never could contribute. But those meetings didn't exist before he joined, and no one really knew where his time went or what he did, even had PMs asking me. And upper management expected more output now that we were one engineer more, and I had to explain I hadn't seen him work in weeks.
Of course, this is a singular bad EM, but made me question the role even more. Not the first time I've seen EMs slowly fading, getting away with doing very little except busy work.
Probably because of my recent bad experience before summer. I was tech lead at a small 3 dev team (including me). Then we got an EM assigned working full time in the team. Somehow nothing changed, I still did all the technical leadership, contributed code and talked with the stakeholders. While he was just always "busy" going to some meeting, and never could contribute. But those meetings didn't exist before he joined, and no one really knew where his time went or what he did, even had PMs asking me. And upper management expected more output now that we were one engineer more, and I had to explain I hadn't seen him work in weeks.
Of course, this is a singular bad EM, but made me question the role even more. Not the first time I've seen EMs slowly fading, getting away with doing very little except busy work.
A team of 3 doesn't need an EM. A team of 7 probably does.
I've seen organizations go in the opposite direction now with the hands-off individual contributor. Their only job seems to be to attend meetings and pass on the minutes to others.
Today in HN: catchy title to drive clicks to RAG tutorial.
Tweet like quality.
Tweet like quality.
I was a "first-line" manager, for over 25 years. I managed a small, high-functioning team of experienced and mature C++ image pipeline engineers.
I chose not to go higher, because I felt that I was being most productive, where I was, and because, quite frankly, I didn't trust anyone else to do the job right (I still believe that this was a correct assumption). I had absolutely no stomach, whatsoever, for the political games, "above" my level, and was making enough to keep me satisfied.
When I first became a manager, I continued to code, but, as time went on, I hired people who were better at it than I was (I was pretty good, but they were better), and also, I couldn't be reliable enough to be in a "critical path," so I worked on tools and experimental projects that didn't have deadlines.
My managers did not want me coding. They actively discouraged me from it. Eventually, I stopped coding for the company (but kept coding on my own). I feel that continuing to code on my own, made me a much better manager. I think my bosses were dead wrong to discourage me from being technical. It was a cultural thing; not a practical one.
I feel that "first-line" managers should still be very technical. Maybe they shouldn't have "critical path" responsibilities, but I believe that they should be absolutely conversant with the latest technologies and techniques, as well as be extremely sympathetic to the challenges faced by their employees.
I believe that the rules are different for higher-level managers.
BTW: I hated every minute of my work as a manager. I don't regret it, but I was glad to see the back of it.
I chose not to go higher, because I felt that I was being most productive, where I was, and because, quite frankly, I didn't trust anyone else to do the job right (I still believe that this was a correct assumption). I had absolutely no stomach, whatsoever, for the political games, "above" my level, and was making enough to keep me satisfied.
When I first became a manager, I continued to code, but, as time went on, I hired people who were better at it than I was (I was pretty good, but they were better), and also, I couldn't be reliable enough to be in a "critical path," so I worked on tools and experimental projects that didn't have deadlines.
My managers did not want me coding. They actively discouraged me from it. Eventually, I stopped coding for the company (but kept coding on my own). I feel that continuing to code on my own, made me a much better manager. I think my bosses were dead wrong to discourage me from being technical. It was a cultural thing; not a practical one.
I feel that "first-line" managers should still be very technical. Maybe they shouldn't have "critical path" responsibilities, but I believe that they should be absolutely conversant with the latest technologies and techniques, as well as be extremely sympathetic to the challenges faced by their employees.
I believe that the rules are different for higher-level managers.
BTW: I hated every minute of my work as a manager. I don't regret it, but I was glad to see the back of it.
As a long time IC turned EM; in my experience non-technical EMs are alright, technical EMs are great, but pseudo-technical are the most dangerous both to the company and their direct reports. It's like the midwit meme, but in real life.
Perhaps the belief is somewhat self serving, but I've seen dozens of examples of good non-technical EMs and good technical EMs, but never a good pseudo-technical EM. The pseudo-technical ones are so jaded with technical work that's palpable.
Also, reminds me of the famous Elon Musk quote[1]:
> Managers in software must write great software or it’s like being a cavalry captain who can’t ride a horse!
[1]: https://x.com/elonmusk/status/1522609829553971200
Perhaps the belief is somewhat self serving, but I've seen dozens of examples of good non-technical EMs and good technical EMs, but never a good pseudo-technical EM. The pseudo-technical ones are so jaded with technical work that's palpable.
Also, reminds me of the famous Elon Musk quote[1]:
> Managers in software must write great software or it’s like being a cavalry captain who can’t ride a horse!
[1]: https://x.com/elonmusk/status/1522609829553971200
Now I want everyone to print out all the code they have worked on for the last month and bring it to my office for review.
Wonder how far a corp borrowing USMC "everyone is a rifleman" but applied to tech would get
We've such crazy margins that we can support too many "i'm not technical hehe" managers than should really be feasible
We've such crazy margins that we can support too many "i'm not technical hehe" managers than should really be feasible
"Non-technical EM" is an oxymoron and should have never existed. The role itself was meant to replace non-technical project managers with people who had a better grasp of the engineering challenges.
[deleted]
Mike Michalowicz's Clockwork has a really nice framework, called 4D:
- Do - the least important type of action a leader can do and where they should spend as little time as possible
- Decide - a level higher, but still not the core activity for leaders. Being the decision makes means that they have to be informed about everything.
- Delegate - this is an important skill for leaders, assigning who is responsible for which outcome
- Design - the most important type of action: designing the organization of the future and creating the right conditions for that organization to emerge; Put differently, this is truly working ON the business rather than IN the business.