Managers who don't do this work hard to hog all the glory, spend all their time in meetings with other managers or presenting to higher level people etc. It isn't good for them nor their reports, by not growing the reports skills they have a hard time getting to the next level as a manager. Also they create a situation where they are the bus factor 1, which is problematic in itself.
I agree. I consider delegation of high value or visibility tasks as a combination of 1 and 2. Regardless I recognize it as being very important overall.
This seems very close to the stereotype content model, which asserts that every interpersonal impression is formed along two dimensions: warmth and competence.
Feeling someone cares fits the warmth dimension; commitment to excellence is a hallmark of competence. I would say the word trust can encompass both.
Trust is neither warmth nor competence - trust is the assumption that our mental model of the person we trust somewhat reliably predicts how they actually act, combined with somewhat aligned values.
I've had some god awful managers in my engineering career and my managerial philosophy is twofold: have empathy and keep coding.
Most, if not all, of my managers over the past 10 years have been people managers cloaked as engineering managers who have all stopped programming a decade ago. So much respect is lost for managers who have turned their back on the very craft that brought them into management.
Before the people manager crowd chimes in with "it's not my job", "we have leads", etc, I want to say that it's about the principle of the matter. I don't care if it's "not your job", on principle you should want to keep your skills sharp in order to fully relate to your supports and, if shit is on fire and you're the only one around, to actually do something and fix the problem instead of completely leaning on your team.
The best engineering manager in my career was not amongst the best developers I knew. (Conversely, the worst engineering manager in my career was one of the best developers I knew).
He had two particular skills that many will never have or take a decade or two to cultivate: he could provide you feedback, empathetically, and make you feel like he is genuinely interested in your success and improvement, and he could read a room like no other, often times being the one to say the right thing to break the tension in the room or ask the right question to get us over a roadblock.
I know you aren't saying be the best or focus on coding, but if I look back and had to pick between the two, I'd pick the engineering manager who has cultivated the soft skills. At a certain scale, all engineering problems become people problems.
You need both. And in my experience it’s rare that an engineer will have strong soft and hard skills. I have known exactly one person with that rare combination, and he has since started his own successful company.
Unfortunately the smartest and most component engineers I have known have nearly always come across as being arrogant. They have a very solid grasp of their domain and a strong skillset, but they also expect everyone around them to be at their level and instantly follow everything they’re saying. These people sometimes even have disciples who follow the philosophy of arrogance and engage in gatekeeping. I have concluded that while this is not ideal, it’s often par for the course.
Conversely, the best engineering leaders I have known (architects, tech leads, product owners, requirements analysts, etc.) have had really strong empathy and encouraged healthy debate while also making everyone’s input and analysis feel welcome and valued. Their technical skillset is not necessarily the strongest but they’ve usually been good generalists who could talk intelligently about something at a high level without having to know the technical details. These people have also been able to take those arrogant engineers and have gotten them to successfully collaborate with everyone from the junior devs up to management. A good tech leader really is just a good mediator.
> Unfortunately the smartest and most component engineers I have known have nearly always come across as being arrogant.
Funny, in my experience these aren't competent engineers so much as dangerous. Engineers who worship at the altar of complexity and get enraged if you point out their mistakes.
The smartest and most competent engineers I have ever known have nearly always been furries.
That's fair but my perspective as a lowly engineer was I wanted a role model to learn from and help upskill my career. My people manager managers never had the skills to provide me with any growth, the only reason I'm at where I am today is because I decided I wanted to level up and taught myself outside of work.
It's my goal as a manager to be that manager that I never had and lead by example for my reports technically in addition to the expected soft skills of a traditional people manager.
The thing is that role model should not be your manager, it should be a senior developer. A good manager is not a role model to teach you, a good manager realizes the importance of lowly engineers having role models and creates a structured mentorship program to make sure that need is being met.
I don't understand why managers cannot fulfill both roles though? The job of management isn't hard (I'm doing it). Outside of the project management responsibilities, there is a lot of time doing nothing. If I wasn't coding, as a manager, 80% of the time I would sit around doing nothing.
I strongly believe that managers should be able to fulfill both roles but maybe it's just because I've been burned by so many managers in the past.
I’d ask a few questions about the bits of management that I think are hard.
How do you get your team aligned on the company’s priorities as they shift?
How do you foster growth?
How do you assess who needs to be promoted/given a raise?
How do you handle feedback for employees that aren’t doing well, or aren’t meeting your expectations (or even harder, employees who think they should be promoted but you think are just solid at their current level)?
And the big/meta one - what do you think the job of a manager is? (Could just be a semantic disconnect on what the job entails).
I have concluded that nothing is easy. Being a manager (at least a good one) is definitely not easy; being a good engineer is definitely not easy. They are both difficult in their own district ways.
The most important skill to have in the workplace, management or not, is humility. This absolutely does not mean that you’re a pushover, but it does mean that you should never deceive yourself with the notion that you’re infallible.
I don’t think I’ve seen it ACTUALLY be anything but B in the real world, but theoretically, to answer your question -
1) that’s interesting! What do you consider the hardest people management issue you’ve run across?
2) what is the people management problem you think most people overrate in difficulty?
It usually will surface if they, for instance, consider people management easy because they have zero emotional affect and hence never bear any emotional load, or if they’ve been bless by ignorance and don’t see the work their peer and senior managers are doing to avoid them setting everything on fire, or never consider coaching or growth of someone to be a problem - because they never do it.
I'm going to pile on here with the others. If you're legitimately a people manager (not a low grade 'team lead'), there is no way, no how, you could have 80% free time.
I've been doing this for some 23 years and had a stint as a proper manager for a year, where I spent about 20% of my time coding, and I was more starved for time than just about any other phase in my career.
I'm currently a principal eng/ arch at a mid-size medical device company, and my principal eng/people manager complement, perhaps one of the strongest devs I've ever encountered (close to a fabled 10x dev), barely has time to code at all. He's just slammed all day every day with general meetings, doing 1-on-1s, presentation prep, working on process improvements, Scrum/product owners for backlog grooming, interfacing with other managers, etc, it just kills his day for anything more than tiny bits of coding here and there, and because he is such a great dev, he does provide meaningful contributions.
I have worked at small startups where things are a bit better, but I can't recall ever seeing a case where a good manager has more than 1/3 of their time to code. 80% dead time would mean hardly managing at all.
> If you're legitimately a people manager (not a low grade 'team lead'), there is no way, no how, you could have 80% free time.
Just because you've never seen this dynamic work successfully doesn't mean that it doesn't. The best manager I've ever had operated like this. She spent most of her time coding and made sure to know what everyone on the team was up to. We were all competent professionals, so we did a perfectly fine job of prioritizing our work and working with others within the team and across teams to get things done. It helped that much of our work could easily be undertaken in parallel with strong ownership of different parts of the code by a single person, but when there were projects that required strong and frequent collaboration she just carved out a sub-team and designated a lead then trusted the lead in the same way she trusted us as individuals. Not only did this mean that we got the benefit of her very impressive technical contributions, but it also meant that we were all able to be more productive because we spent vastly less time in BS meetings.
Afterwards, I moved to a company with a more traditional structure. Ostensibly there were three people in charge of me: my engineering manager, my product manager, and my designer (since we are "design lead"). It was a pretty big culture shock. One difference is that there are a lot more junior people in my new company (the average age was around 50 in the first one), and I think younger engineers may need a firmer hand, but I'm not sure that that explains it all. I joined the first place right out of college and thrived in that environment.
I think most people don't understand just how effective a minimal management strategy can be because they've never experienced one that works well.
I meant specifically things only a manager does. For instance, the presentations he does are for director/vp level, hefty slide deck stuff.
Of course the more senior ICs do more than simply code AFA talk across teams and divisions to scope and define work, present workshops and presentations to the team and cross-departments, contribute to architecture decisions, present as SMEs across various parts of the stack, and mentor juniors. None of the ICs year on my team spend more than 80% of their time simply coding, the more senior staff spend probably more like 60-70%, and I spend about 50%.
I’ve worked at 14 companies over 23 years, from 3 Fortune 500s, to a couple mid-sized, to a bunch of smaller companies, to a handful of early stage startups. Have had probably close to 20 supervisors over this time and interfaced with dozens of other managers on related teams, and been a team lead about 5 or so times and a manager once.
I’ve never seen this dynamic play out. IME you're talking about a team lead not an actual people manager. Even in the most streamlined/simplest environments, I don’t think I’ve ever seen a people manager spend the majority of their time coding, not unless they were pushing 60+ hours doing so. Something as simple as 1-on-1s should be done at least once every week or two, and that can take up to an hour (or more counting prep) for every report.
Your mention of having multiple sups and junior heavy ICs at one place sounds dysfunctional and has little relation to any place I’ve worked at.
Those presentations to the higher levels didn’t really happen because the corporate structure was very flat. Also, I would not expect those to take up all that much time.
You may have worked at a lot of places, but your experience is still only a tiny slice of the different shops out there. My experience is likewise limited, and I acknowledge that such light touch management is probably very rare, but it can and does work.
You said she was a team lead not a real manager, which does have some truth to it, but it’s not like there was someone doing the “real” management work to pick up the slack for her. In the right environment that stuff simply isn’t needed.
> such light touch management is probably very rare
Don't be too certain about that :-) I recognize the things you mention from my first job, I had a manager / CTO who were like her. (This was a 20-30 ppl startup, high trust, not many meetings)
> general meetings, presentation prep, working on process improvements, Scrum/product owners for backlog grooming, interfacing with other managers, etc
You as a manager don't need to do all that. If you can't delegate most of that to reports then you have a problem.
In most companies, once you’ve built or found the people to delegate that too, and handed it off successfully - congrats, you’ve demonstrated you can handle the next level and you get the next round of challenges.
If you’re sitting around with nothing to do, either you’re in a dead end, or no one actually trusts you with more once you’ve ‘succeeded’ because you’ve burned too many bridges or alienated key people - even if the org chart looks good.
Of course if someone is finding themselves in that churn all day for any length of time, you are quite correct - they are busy not succeeding.
You don't delegate everything to a single person, you delegate the parts to the person best fit to do it.
And no, delegating a lot of those tasks doesn't mean that you as a manager have nothing to do. Instead you can spend 20% time doing management tasks and 80% time coding. Each person in the team sharing the "management" burden makes it pretty manageable. (it isn't really management to coordinate with other teams or present to people etc though, no reason you should have a bus factor of 1 for that role)
I literally do this for a living (20+ years now), and have never seen anyone successfully pull this off that was doing what I (or the company) called managing.
I have seen a few people convince themselves this is what they were doing (usually in a line manager/tlm role), while everyone around them was suffering from lack of a proper manager, which their lack of EQ was hiding.
If you somehow found the secret sauce for this, please do share!
Seconding that - managing for ~15 years, with 15 years eng career before that. If you're a manager who spends 80% coding on anything but a small team (<7 people), you're letting your team down.
You might think you're doing a good job, but you really aren't. 20% of your time are only 8 hours. Even if you just spend half an hour with everybody on your team of 8, 4 of those are gone. You haven't spent any time yet coordinating the team as a whole. You haven't spent any time planning. You haven't even answered e-mails yet. Neither did you do any signficant coaching. Nor did you spend time hiring. Or even writing a job description. Or planning compensation. Or helping your two star engineers who are at loggerheads to come to an agreement. Prioritized the backlog? Set up a triage process? Spent way too much time to find out why your junior is super-withdrawn and doesn't ask questions? Set them up with mentorship? How's that design review coming along? Talked UX of the latest "luxe UI" ledge? Got yelled at by them because one of your engineers decided that specs are just suggestions? How's that training program for the new toolkit coming along? Also, the team is kind of nervous because the big project will end in 9 months, and there isn't a new big project yet?
TLM roles are the biggest mistake this industry makes. They work beautifully for 3-5 people, start crumbling for 6-10, soak 100% of your time for 11-14 people just managing while you despair you can't do technical work any more, and become an incredible way to burn out people at 15+ direct reports.
As long as we are throwing out anecdotes, I've been doing this for 3 years and have seen successfully done it on several teams, though they were all at the same company. It absolutely can be done with the right culture.
> Instead you can spend 20% time doing management tasks and 80% time coding.
If you're that good at delegating that you're only using 20% of your time and your team is humming along at a high level... congrats, we've got these other four teams that AREN'T being managed that well, you're now the senior manager in charge of all of them, please get those other managers up to your level too!
Where do you work? Sign me up! I have hardly any time to code after weekly sprint-related ceremonies, 1:1's, cycle planning, and architecture and code reviews.
The job of management, like the job of any developer, varies from company to company, and situation to situation. Thankfully, the people side of my job as a manager is easy right now, but only because the people I manage are reasonable people to work with, and well receptive to feedback. It was very difficult last year when I had to work through more delicate relationships between the employee and employer. As always, it comes down to people.
It also sounds like the place you may be managing at may not be challenging enough for you. Perhaps it's time to make a change?
It all becomes a bunch of soft targets as a manager and that's really hard.
The one big success I had when I was a manager was getting our client teams to unify on the bugs they were having and to be much more cohesive. When I first got there the android and ios and web people never talked and refused to believe they had the same types of issues/bugs. LOL.
I ultimately hated it because really... I don't want to yell at people for being late to standup, so went back to engineering.
I've been a manager for a while and at best I get 20% time to code. With 8+ reports the weeks tends to break down into:
* 20% for 1-on-1s and dealing with management level issues people bring up.
* 20% spent on hiring
* 20% on various status meetings (team, cross-team, with my boss, etc.)
* 20% spent on pro-actively finding or solving issues before the explode. This includes networking with my counterparts in the rest of the org so I get information and build political capital.
I'm an engineering manager and find it hard to relate to this. With 1:1s, ops reviews, planning, retros, design reviews, support syncs, etc., I have ~6-10 hours of meetings per day - then for non-meeting work I'm writing roadmaps, interviewing, managing escalations, doing project management, status reports, etc. How do you have 80% of your time free as a manager after this? I think that makes sense to code if you have that time, but my experience is that having that much time available as a manager would be an outlier.
As an EM, 20% of time spent on project management sounds about right. What you are overlooking is the time spent managing the people on a team. Hiring, recruiting, promotions, coordinating parental leave, working out visas with immigration attorneys, check ins, comp adjustments, etc all take immense time and energy to do properly. It’s a full time job and then some.
There was a post on HN few months back where the author listed atleast 30 tasks that a manager should be doing. The list included planning, mentorship, motivating team, hiring, communicating to higher management etc. It was a long list. I don't thing any person doing those task can also be a competent programmer.
> ... as a lowly engineer was I wanted a role model to learn from and help upskill my career.
There is no reason this has to be your manager. Your managers job was to understand that this was something you needed, and find a way to try and provide it for you; it's unfortunate that didn't happen for you.
> It's my goal as a manager to be that manager
Can I make a suggestion? As a manager it's important that you respond to what your team actually needs, rather than your perception of what you would have needed in their place.
There are a number of ways to do this well, and a much larger number of ways to mess it up.
A manager is only a role model if the promotion structure is Engineer->Manager. At most modern tech companies that is not the main promotion structure. It's Engineer->Senior Engineer->Staff Engineer->Etc. Engineering management is a different path you can choose just like you can become a product manager but it is not the expected path.
Companies like to claim this, but it's not the reality due to an imbalance in power between managers and IC engineers. A manager controls a reports salary, career progression, has more face time with VPs and so on. Software engineering is unique in that ICs can still scale to a similar level of impact as executives, but it is a mistake to think that a Staff engineer and Manager are equal in the eyes of the organization. They aren't.
A title bump without the reporting structure changes to go with it is just a fancy way to dress up a raise, sure, but that's not the only option.
In companies doing this well, the high-level engineer doesn't report to the immediate team lead, but reports to the same director that lead does. Or VP vs director for even-higher-level engineers vs higher-level managers.
That structure, more than the title, is what shows you if you're really on an equivalent track.
There is nothing special about software engineering as a
technical track this way. There is no one way to set up an organization. To a large degree they are how they actually work (i.e. not what's on paper).
This balance has been an issue in managing technical teams for about as long as that has been a thing, which is a lot longer than software has been a thing. There is a fundamental tension though, in that the focus you need to maintain expertise in your field contends with the breadth you need to understand the context well enough to make good decisions.
I suspect the real reason that you don't see more of it in practice is that it's actually really hard to continue to do both well at a very high level, and it's also organizationally hard to do.
There is something special about software engineering because it is fundamentally about automation. As a result, an individual software engineer can create the sort of impact that traditionally would require a team.
I'm trying to make sense of the rest of your post, but it uses a lot of pronouns that don't appear to reference anything.
I agree software has more leverage, sometimes but we are talking here about how decision making power is distributed in a company.
Regardless about how much impact the IC technical output can have that is about how. The skills & information needed to make good decisions about what and when are different.
Unfortunately, being highly effective at both requires spending time and focus in ways that are somewhat mutually exclusive, which makes this quite hard.
Once you start crossing the sr eng -> staff eng rubicon, you start doing more managmentesque things anyway. Maybe less 1:1s with specific reports, but you are definately talking to a lot of people and teams trying to lead the direction & design of what you are working on as a group.
I've seen people go from Engineer to Manager, skipping over, for want of better phrasing, the senior engineering ranks. In both cases it went poorly and a founders child was involved, indirectly at first and then later directly.
One of the founders children was hired on to a low ranking managers team as an entry level Software Engineer. They were hired specifically by the low ranking manager and without the typical interview process. That low ranking manager, inside of a calendar year, became the director of an entirely new division in the engineering org. That division eventually went defunct, having never shipped a single product to production or having accomplished anything else of note.
The other was a founders child being promoted from SE I or SE II into a middle management role. That also did not end well.
Another general comment on this theme. In my experience people making the engineer to manager transition typically need a mentor and guidance in management even more than they ever needed a technical mentor.
I guess you talk about group leaders, not project managers. Group leaders are from developers, with added responsibilities (and that means with added work).
We worked together at what I can only describe as a data collection meat grinder. One of those places that loves to say it's all about people one side of their mouth, and act completely contrary to that in the day to day when it comes to chasing revenue and growth. He was met with heavy resistance from senior level business directors because he actually put what the company said were their principles into practice every day. This burned him out a little bit, so he took a break, and is now looking. You hiring?
Keeping current on coding, while not attempting to be the best coder in the building, is a key soft skill in terms of participating understanding, and evaluating technical decisions and problems. Empathy comes from placing yourself in the other person's shoes.
This is also true for communicating enterprise-wide considerations to coding teams. They have to trust you not to blindly push senior management priorities. If you know the cost of both capital and tech debt, you are more likely to have represented the coding team and influenced decisions, and be able to communicate decisions effectively.
I am having a hard time understanding what you are saying, perhaps you could restate? Coding is not a soft skill, even if that is in a capacity where it's used ancillary to other tasks such as the ones you mentioned.
I am glad you mentioned it, because communication and trust, on the flip side, are soft skills. You can foster trust through excellent communication and understanding Where the engineering manager does not excel in a particular area of expertise, he or she will defer to the ones that do. A good engineering manager knows their weaknesses, and how to ask for help. The good engineering manager will seek to gather understanding of the technical debts and use that to represent the coding team well. Again communicating those decisions effectively are orthogonal to that process (meaning you can communicate a poor decision effectively just as well as communicating a good decision effectively)
My last engineering manager came from a technical background but ended up being a people manager after a decade of managerial duties.
He was a nice guy but useless in that he could not relate with problems the engineers were experiencing and advocate time to fix them - kind of like a black hole for complaints. Engineers by themselves had virtually no say in what they actually worked on here.
This, coupled with a non-technical PM, meant we were constantly adding features on top of a weak foundation which created plenty of fires. And for each fire we were only given time to wave away the smoke rather than put out the fire.
So I'd agree having true empathy and being able to act on it is important for managers - they don't necessarily need to code but they still need enough technical experience to fully relate to what the engineers are doing.
You highlight one of the reasons it's BAD for an engineering manager to still be coding or at least able to code your production code. It incentivizes them to just hack things themselves rather than building proper processes and structure for the rest of the team (on call rotations, training, breaking silos, etc.). Overall that leads to a worse engineering environment rather than a better one.
I don't see where I made the connection between practicing the craft and hacking together solutions.
If an engineering manager (presumably one who attained this position because they were or are a good engineer) is going to fix something, they're going to apply best practices because they know what they're doing.
If an engineering manager was hired just because they know how to manage, well then they aren't really an engineering manager, are they? They're just a straight people manager and in my opinion, shouldn't be managing an engineering team. They should be a project manager.
Engineering skills decay with time and even the most technical manager will be out of touch compared to someone who spend 100% of their time on code. They also have the pressure of the buck stopping with them and not having to deal with the tech debt fallout which creates an incentive to just hack things. Some will avoid this but most won't.
>presumably one who attained this position because they were or are a good engineer
Why do you presume this? Management is a very different skill set than engineering. The best engineers having to become managers to advance their careers is an anti-pattern which most modern tech companies avoid. Managers thus tend to be average engineers who are good at people and process.
They don't have to spend 100% of their time coding. Why not 50%? If you spend half your 40 hours a week coding, after presumably having had a career in engineering as a developer in the past, coding half the time will continue to support your technical knowledge well into the future.
I refuse to believe that managers shouldn't code. Actual managerial tasks do not take up that much time. Like I said in a previous comment, in my experience (as a manager), managerial tasks take up maybe 20% of my time per week. What's going on with the other 80%? I'd be bored out of my mind if I wasn't coding as much as I currently am.
I've written in another post where I spend 80% of my management time. I could cut it down to 20% but then I'd be building up the management version of technical debt. As I see it, there's a lot of things you don't have to do but doing them makes your team function better in the medium and long term.
Read this, and it gave me a lot of clarify and appreciation for my own manager. Thank you for adding this. You sound like you've got a balanced perspective on the engineering manager experience.
I was hired into a new leadership role recently. I had previously worked my up at a few places and go to the point where I was coding maybe 5-10% of the time at most. The new role hired me for my management and strategic experience since I actually have almost no experience with their tech stack. Coding is coding, but I'm slightly useless to them as a dev for now and I haven't committed a single line so far.
I think the response to your original comment was more that having the "Ugh, forget it I'll just fix it myself" last resort option could be a crutch for a manager
I've struggled with the "keep coding" part. Not just because I don't have time in between my other responsibilities, but because my teams feel ownership over their products and have all the deep knowledge it takes to build and maintain them correctly. I still know how to code, but I rarely have enough depth in a particular system to know the appropriate way to solve something. I'm like a plucky junior dev/everyone's boss.
Yeah, it's a great way of burning respect in the team, take on projects you don't have the time or expertise to deliver. There's a special kind of management veto - where an important project gets completely stalled because the manager has decided "I'll take this one" and then spends the next 6 weeks sitting on it because they're too busy dealing with everything else.
I dont need managers to be coding. I do need them to have technical background and willingness to understand what tech is relevant to them - I had only bad experiences with non-technical managers.
But I really dont understand why they should be coding. Even active developers are not able to fix whatever in any module, you fix only in areas you understand. When shit is on fire, I dont want managers or other random developers to create a bunch on hotfixes that will cause new problems.
I want managers to organize the project in a way that shit wont burn on every release.
They should be coding because they're "engineering" managers. What's the point of having engineering in your title if you're not actually practicing the craft?
They should be coding because they'll be able to relate to their supports in a deeper and more fulfilling way. They'll be able to mentor and provide guidance on technology best practices and patterns.
They should be coding because they'll be able to more accurately plan and execute projects. Understanding and applying the technology is understanding it's pitfalls and anticipating potential upcoming challenges.
The role where you're still hands-on on a team is sometimes called a Tech Lead Manager, and there is a ceiling to this role. The next step up is true Engineering Manager where you have to be able to talk to engineers on other teams and gather information without being familiar with their code. If you rely on direct knowledge of code in all circumstances you won't be able to effectively operate in an organization with thousands of engineers and millions of lines of code. This is super hard, and relies on deep experience in the trenches (preferably 10 years+), but it is the only way to solve broader organizational problems that cause projects to fail, and many eng months or years to be shitcanned.
>They should be coding because they'll be able to relate to their supports in a deeper and more fulfilling way.
That's a valid point although I've seen it go badly when a mostly out of touch manager (time is finite, even the most technical manager will be out of touch) thinks they're still at the top of their technical game. They then force out of date engineering decisions on the team.
>They'll be able to mentor and provide guidance on technology best practices and patterns.
That should be done by the senior engineers and tech leads with support from the manager. These are the people who spend 100% of their time thinking technology while even a technical manager will do it 25% of the time. The manager should be the one to structure these conversations, formalize mentorship processes and so on.
> That's a valid point although I've seen it go badly when a mostly out of touch manager (time is finite, even the most technical manager will be out of touch) thinks they're still at the top of their technical game. They then force out of date engineering decisions on the team.
Yes, or even worse they don't respect it when their team tells them something is hard to build and will take more time. You get a very "back in my day I'd put this together in a weekend what's the big deal" attitude from people like this.
"Engineering" is more than coding and engineering managers can provide insights and value by demolishing higher-level roadblocks for their IC colleagues.
I would just leave it at empathy personally. I've had technically minded managers, but my best manager actually empathized with the issues I was having and advocated for me when I needed it. She basically helped me handle non-technical issues to clear the way for me to do my technical work. When I needed technical help, she would assist in getting me the help I could if she shouldn't provide it. If I ever end up in a management position, I hope I can treat people in a similar way.
If the shit hits the fan and it relies on a people manager to fix the problem, I would say that the problem is more with the company not having the right mitigation plan in place for this catastrophic problems.
I worked for a company that didn't encourage managers to be technical. In fact, they sometimes deliberately interfered with my efforts to remain technically relevant. They really lost some good stuff, that way. I'm no tech slouch.
Luckily, I didn't have a "shower clause" in my employment contract, so I did a lot of open-source work, in order to remain relevant.
They directly benefitted from that; though they would never admit it.
So did thousands of others. I did work for NPOs, and the work I did went towards a lot of lifesaving stuff.
The "empathy" part is every bit as important. It pays huge dividends, as a manager. It needs to be real empathy, though; not the two-faced kind that only appears when someone's watching.
I have avoided going the management route because I have a very strong fear of losing touch with the deep technical aspects of software engineering, which I love and have been doing my entire professional career. As a lead developer now, my role has changed in that I interface more with product owners and management, so I can already see that I need to delegate quite a bit, which makes me feel uneasy since I want to be the one doing those tasks. On top of that, as a lead I am expected to know it all while also somehow delegating.
And conversely coders - work on your people/management skills (even if you are not a manager). I have worked with coders who were highly opinionated that a great coder is all about the code and not about relationships and people. He wasn't fun to work with and probably destroyed team morale more than his technical contributions helped. Being a 160IQ asshole is worthless, if it were my business I'd avoid hiring / fire such people or at least stick them on their own project away from everyone else.
I do whatever I can to best support the team. It is practically never coding at this point. My team would likely end up frustrated with me (and rightly so) if coding comes at the expense of other things like sourcing, hiring, coaching, distilling and communicating our plans, refining and scaling our processes, etc.
This. It almost seems like people who lose all interest in coding/engineering/tech also lose respect for the people who do it, like some weird form of guilt/shame. This doesn't make them better engineering managers. You've got to keep that spark alive.
I don't need my manager to be a coder; I can do the coding. I need my manager to fight for me in our organization and to shield me and my team from various organizational BS. I don't believe that any of that has anything to do with coding ability.
> Most interactions are ego-based because people aren’t as self-aware as they could be.
Sad, but I have to agree. Self awareness is something people develop as a natural part of maturity. It is not a skill children have. For example play a board game or card game with children and realize they never know when it’s their turn to play despite watching the game, numerous reminders, and recitation of the rules. They are not self aware. That portion of the brain has not developed yet.
It is frustrating to encounter adults lacking of self awareness where a commonly expected skill of fully functional adulthood is absent. In some cases that can be due to wide spectrum disorders like autism but is more generally due to immaturity, the absence of expected normal development.
Another queue into this is a false expectation of soft skills. That doesn’t mean being soft or kind. Soft skills are perceptual skills associated is active listening and empathy, which sometimes requires being a mean asshole. People with a lack of self awareness tend to have a lot of challenge in this area. They are not the center of the universe, sometimes fail horribly and embarrassingly, and demand harsh unpleasant words. For people lacking of self awareness the harsh reality of corrective communication is likely poorly accepted as they either continue to fail or suffer emotional trauma.
Well this was a very pleasant post to read as an autistic person. I can appearantly just have a lack of self awareness completely out of my control and this is embarassing, and demands harsh unpleasant words, even though this approach is likely to fail and inflict emotional trauma on me.
"Empathy" after a social faux pas to me is kind of like a blameless post mortem. Blunt yet unjudgemental with a call to action and some discussion of what went right. Perhaps your words are so likely to fail because because you're taking the wrong approach?
Usually a person with good empathy can pick up on social spectral disorders after some time and factor for this in their communications capabilities. This is often not a hard barrier.
The problematic people are those that cannot self reflect AND are incapable of realizing the nature of their dilemma. The problem is present when a situation demands harsh words and the troubled person is utterly incapable of receiving that communication.
> Perhaps your words are so likely to fail because because you're taking the wrong approach?
If a person commits to an action that is potentially harmful they must be halted and corrected even at cost of some minor embarrassment. If that person then attempts that harmful action again they should be severely counseled. The harshness of the words should reflect the severity of the failure. Empathy doesn’t mean agreement or kindness which are akin to sympathy.
Good leaders are people who teach others to grow, progress, and ultimately become their own leaders. Most managers aren't incentivized to grow their engineers because it would mean losing them. I find it hard to fully trust my manager because I know my best interests are only partially in their mind. They also need to care about the business and their own position, which usually carries more weight than how I want to grow my career.
I think there’s a lot of great advice in here, and a useful exercise is to find equivalences - or equal but alternate ways to rephrase timeless advice x.
One such equivalence that I found to the above is to focus on regarding others honestly. Often times there are barriers to seeing people for who they are, so if you can focus on identifying those barriers and confronting them with yourself, you then have a shot at regarding others truthfully. The theory goes that if you can do that, you don’t need to have so much managerial social engineering polish. You can just be polite and honest and everything will pretty much work.
I have to say from personal experience that this has worked well with me. In the situations that it hasn’t it’s been due to others being caught in their own inability to regard me honestly. In such a case, I don’t think the smooth operating manager would fare any better or worse. So basically you can’t win at everything, but you can worry about yourself!
Example: One of your reports says something that you perceive as self-deprecating.
It can be tempting to dismiss this as mere impostor syndrome. Doing so might soothe your fear that someone you manage lacks confidence but it does not serve them well as a leader. I advocate instead approaching with a spirit of curiosity: What about their experience drives them to that imperfect expression of their professional needs?
Applying a technique named "Clean Questions" can help increase clarity about that, if you're looking for something to google.
Ron Lichty https://ronlichty.com/ is a highly experienced engineering manager based in SF and Seattle who writes, speaks and trains internationally, as well as occasionally jumping into teams as interim VP Engineering. I've had the pleasure of hearing several of his talks in-person and he's constantly emphasizing the importance of soft skills. He wrote a very helpful book on the subject, Managing the Unmanageable, published by Pearson/Addison-Wesley https://www.managingtheunmanageable.net/.
The article mentions self-awareness as the number 1, but I disagree.
| Creator mindset
| Having a creator mindset over a victim mindset is great for leadership. The victim treats situations as if they can’t change them, while the creator takes responsibility and actively shapes reality. Creators turn every situation into an opportunity.
I've actually seen this more broadly labeled as someone having a Growth Mindset instead of a Fixed Mindset, and I 100% agree. This should probably be the #1 value that makes someone a great leader. In fact, I believe it's so important, that it should be the basis for all other qualities and skills a leader develops on their journey.
It's actually a rare trait amongst software engineers and I think this is the trait that either propels someone into a great leader, or holds them back when they are forced into it.
My #2 on the list is perseverance and that goes hand-in-hand with having a growth mindset. The best way to test this quality on anyone is if you can successfully answer yes to the question, "is this person reliable?"
If you have a growth mindset and perseverance, then I believe you can pick up the other traits and learn on your way up the ladder.
A lot of this post is (good!) tactical advice. I strongly agree with the comment on emotional self-control. IMO this is one of the top ways that managers fail or struggle, especially as their teams grow or if times are hard.
I've thought about this a lot and wrote some more strategic thoughts on this topic of management soft skills here. It's written more from the perspective of hiring managers, but hopefully some of the content transfers: https://staysaasy.com/product/2020/09/06/soft-skills-for-man...
But in each case, by the end of the day, everyone had spoken roughly the same amount. ‘‘As long as everyone got a chance to talk, the team did well,’’ Woolley said. ‘‘But if only one person or a small group spoke all the time, the collective intelligence declined.’’
I liked managersclub as well. Interviews with real managers from diverse set of companies... One thing I like most about them is that they ask same questions to all managers.
Soft skills means they are hard to measure. That is the original definition. Hard skills are easy to test, you either solved the problem or you didn't. With soft skills you don't really know, you need to measure it subjectively.
Protect yourself from Machiavellianism (willingness to manipulate and deceive others), Narcissism (egotism and self-obsession), Psychopathy (lack of remorse and empathy), Sadism (pleasure in suffering of others)
I discussed some related soft skill tactics in this post - for the specific problem of managing technical respect for a specialist team (in this case a machine learning team).
Everyone asks three questions of people leading them:
1. Can I trust you?
2. Do you care about me?
3. Are you committed to excellence? (aka do you have high standards).
Think about someone you admire. Odds are the answer to the above for them is "yes" to all three.
Now think of someone you have had a lot of problems with. Odds are the answers to the above are "no".
[0] - https://en.wikipedia.org/wiki/Lou_Holtz