10 ms·

Mistakes I made as an engineer, but had to become a manager to see

224 points by ryanlpeterman 4y ago

givemeethekeys 4y ago
Couldn't agree more. For a long time, I'd be one of the last people to quit when a shitty manager was brought onboard. I'd give them their due time. Other senior engineers saw the writing on the wall and jumped ship. So far they've always been better off for leaving than me for sticking around.
glonq 4y ago
...will we see this followed up with "mistakes I made as a manager, but had to become an executive to see"? ;)
- ryanlpeterman 4y ago
  Hahah also good clickbait. Maybe one day if I'm lucky
- hummus_bae 4y ago
  [dead]
Jensson 4y ago
"When I was an engineer I focused on work that improved my career, but then I became a manager and realized that my engineers actually should work to improve my career!" Funny how that works.
- ryanlpeterman 4y ago
  I agree it's easy to see it that way as an IC (I thought the same!). I think the more senior you become the more you will view impact from the lens of your team/org, even as an IC
  - Jensson 4y ago
    There is a strong bias to focus on things that helps yourself, that is only natural. So IC's will focus too much on things that improve their career, managers will focus too much on things that improve their career, directors will focus too much on things that improve their career etc.
  - izacus 4y ago
    Although, the more senior you become the more you also understand about using the best tool for the job. And burning away engineers time to do management tasks is not that.
  - allenu 4y ago
    I'd say the higher you move up in management, the more and more your own goals should represent the business's goals. A lot of ICs don't really care about the business, however, and I think this is where promotions are used as a tool to get them to care. If you act in the interests of the business, the leadership of a company will (usually, but not always) reward you for your service to the business. Whether or not this is something you "should" do is up to you, in my opinion. As an IC, you can't make me care about a business. I'm there to get paid and gain career experience, the latter of which sometimes improves the business and sometimes not.
    - eggsmediumrare 4y ago
      This is why every time I take a management, I regret it. I don't care about any business and I'm beginning to suspect I'm incapable of caring about any aspect of the job other than the wellbeing of the people on my team.
- stingraycharles 4y ago
  Depends on what you’re looking for in an engineer. I consider the author’s learnings to be relatively obvious, of course and engineer that “gets to know their colleagues” is doing great. Fact of the matter is that there are a whole lot of people that aren’t necessarily into that, but are great individual contributors, and should just be left to their devices as long as they’re a positive contribution, not just to your codebase, but towards your organisation as a whole.
  - Jensson 4y ago
    Making the team stronger often doesn't make your career better though. This guy says he didn't and he got promoted to manager anyway, and now suddenly he wants the people under him to make his team stronger rather than focus on their career like he did. That smells like a corporate climber who just started to eye his next promotion rather than a new insight. Edit: Notice I'm not saying this is bad, this is just natural bias towards what benefits yourself. It is just so interesting to see how people who experience that bias shift now sees it as some kind of "insight" rather than just their own bias.
  - I_AM_A_SMURF 4y ago
    I just want to say that the usual interpretation of "individual contributors" is not that they work alone. Almost by definition a Senior and especially a Staff+ engineer gets to deal with a lot of other engineers, hardly working by him/herself. The more you go up the IC ladder the more your job becomes influencing the technical direction of your team/org. It's a very social job.
gardenhedge 4y ago
Tldr: people problems are problems, having a good team is important, socialising is important. This is such a non-article.
HellDunkel 4y ago
I dont get it. Why would you care or think much about hiring as an engineer? You probably would not even be asked to attend interviews. If you vibe with the company and share the vision okay but this is not a matter of perspective. Why would you NOT be interested in getting to know your coworkers? Why NOT have interesting conversation or a good laugh at lunch? This has nothing to do with beeing an engineer or manager either. Obsession with code maybe more important for an engineer. Does not mean it was „wrong“.
- MisterBastahrd 4y ago
  Why? Because you will eventually have to work with these people and their problems will become your problems, especially if you are seen by management as someone who can fix those issues. Young adults tend to group together and cling to co-workers because they haven't learned to cope with life independently of the situation they find themselves in. I generally like my co-workers, but I have no inclination to spend any independent time with them. It's not that I don't want to make friends at work, it's that I don't want a condition of my friendship to be tied to the workplace. If I'm not seeking that person independently now, then I'm probably not going to do it later after switching jobs.
  - HellDunkel 4y ago
    I did not state anything about „problems“. Not sure what you refer to.
  - Wowfunhappy 4y ago
    > It's not that I don't want to make friends at work, it's that I don't want a condition of my friendship to be tied to the workplace. If I'm not seeking that person independently now, then I'm probably not going to do it later after switching jobs. I've made friends at previous companies who I still see regularly. Not a ton, but some. I have dinner plans with one of them this coming Monday.
- gonzaloalvarez 4y ago
  Because as you become more senior as an IC, your personal growth is directly related with your ability to influence others and deliver through others. What’s best way to do it than to ensure you bring and groom the right talent.
quicklime 4y ago
> Hiring well is one of the best uses of your time When I was an engineer I used to think this, but now that I'm a manager, I'm not so sure... If you want to maximize your impact, and make the biggest contribution possible to your company, then yeah, sure, it's absolutely the best use of your time. But a lot of engineers are trying to contribute to the company in ways that are mutually beneficial to them, and the way that a lot of companies set up interviewing is not. It's a thankless job that takes time away from things that can actually be put a performance review, so only the more selfless engineers will do it. The article reads a bit like manager-to-engineer advice, but the advice to managers would be: keep track of who is helping out with interviewing, and who is interviewing well, and reward them for it.
- vanjajaja1 4y ago
  Investing in 'hiring well' is worth it for the skill, sticking around in 'hiring' is probably not unless you're using it to swing some cool free international trips. There's a lot of value in knowing exactly how you'll be judged at your next job interview.
  - zwkrt 4y ago
    I think of the hiring loops that I am a part of as paid interview practice.
angryGhost 4y ago
Technical skills are teachable to a coachable person, soft skills not so much
- HellDunkel 4y ago
  Technical skills are not really teachable much unless its a full time job.
- 13of40 4y ago
  I'd go a step further and say that there will be times when you can sit across the table from a grown adult and explain to them the behind the scenes details of the performance review process, explain that you want them to do X Y and Z so you can build a case to get them promoted this year, just to have them tell you to fuck off because X isn't coding, Y is boring, and Z is below their skill level. "But please still promo me ASAP."
- munchbunny 4y ago
  Soft skills are also teachable to a coachable person. I've seen it in action. However, far fewer people are receptive to coaching on soft skills because fewer people understand what "soft skills" are and why they matter. I've met plenty of engineers (anecdotally, not a majority, but enough that it's a clear pattern, and strongly correlated with how junior they are) who lump soft skills into a single category represented by broad labels like "charisma" or "schmoozing" or "eloquence". But it's really a very big category of practicable skills.
  - ZephyrBlu 4y ago
    I think "soft skills" disguises what these skills generally are and their importance in the context of an organization. Things like navigating an org, knowing how to make asks that have a high % of being accepted, writing things for a specific audience and keeping conversations on track are all very important "soft skills" that are completely hidden by the "soft skills" label.
    - smcin 4y ago
ZephyrBlu 4y ago
A more interesting question is, are these actually mistakes or just part of the journey from a junior engineer to manager? People problems and building relationships with your co-workers are things that I have realized are important over the last couple of years (Haven't done any hiring yet). In saying that, I'm not sure it would have been wise to focus on these things earlier than I did. There were too many other things I needed to learn. Focusing on code is probably a good thing when you are a junior. Leave the higher level problems for a little later down the line. I've thought about hiring and am interested in doing it and getting good at it because I see that it's very high value, but I don't think it's the right time. There are more important skills and behaviours for me to develop right now. I try to focus on things 1 or 2 steps ahead of where I currently am, no more. Otherwise it's too far away from reality.
- ryanlpeterman 4y ago
  > Focusing on code is probably a good thing when you are a junior. Leave the higher level problems for a little later down the line. Agreed that junior engineers should focus on code with most time (but not all). If you focus on the low hanging fruit outside of code you can have more impact overall without too much time investment there.
  - ZephyrBlu 4y ago
    I disagree you can do that without much time investment. The time investment is in learning, not executing. If you're a junior by definition you don't understand how to operate outside of code very well or at all, and you are still learning about operating in code. Trying to learn multiple skills at the same time is always tricky. Most people struggle to get good at one thing at a time, let alone multiple. Unless you are already becoming a more independent coder (I.e. 1-2 steps behind this point), stacking non-coding skills on top of that seems like a bad decision unless you are a very quick learner and can juggle multiple new skills.
  - moonchrome 4y ago
    I disagree - I think juniors should pay attention - but actively moving outside their role is almost always more trouble than worth. I've seen so many misguided proactive attempts waste everyones time, create noise, break focus. If there's low hanging fruit, and you're not in a dysfunctional environment, it will probably give you diarrhea.
tenpoundhammer 4y ago
I think of all of these problems as being the managers problem and not the engineers problems. Maybe a better title is "10X Manager tasks, I wasn't aware of as an engineer". To help engineers maximize their career I tell Junior/Level 1 engineers focus on becoming net productive, meaning providing more value than you take. Midlevel/Level 2 engineers should becoming independent and solving lot's of their problems on their own. As they approach the top of this level start getting involved in architecture and design. Senior/level 3 should focus on helping the team to be successful as a whole, mentoring, producing value quickly when needed, and should be able to solve most problems independently including starting a project from scratch or solving complicated performance/technical problems. Hiring and people problems are engineering manager problems. Getting to know your coworkers is a good career move for anyone.
- seemuch 4y ago
  I really like the way you categorized different SWE levels. Thank you for the insights!
- jcparkyn 4y ago
  > I tell Junior/Level 1 engineers focus on becoming net productive, meaning providing more value than you take. This feels like it could backfire, by encouraging people to ask less questions. It's easy to provide more value than you take if you never take.
  - qup 4y ago
    The take is your salary, in my experience. I'm not sure what you mean about questions.
    - idiotsecant 4y ago
      It seems obvious - if you scare a junior engineer they will sit in their office and build an abomination to avoid asking a simple question that could be answered in 3 minutes. It's a real thing and it doesn't help the junior engineer or the business.
guhcampos 4y ago
The article contains way too few mistakes. I suspect there's a whole series coming.
izacus 4y ago
So basically the mistakes were mostly not solving management problems as an engineer? Uhhh... ok.
- Frost1x 4y ago
  Yea, I don't get it. Perhaps if while you're an engineer you think management shouldn't be doing these sorts of things you had some mistaken perspective. Moving to management is not some inherently transcendental ascendancy into higher enlightenment and purpose, it's a change in responsibilities and goals. It's not for everyone, there are plenty capable of being managers and fully understand the roles but don't want to become them. This article reads like some journey to enlightenment that I think all but a junior engineer would read as pretty naive.
- rektide 4y ago
  On the one hand: 100%. Agreed. Engineers experience enormous cognitive dissonance because companies & managers don't understand the very real problems they face. This article both say it, but under the title of being a mistake of engineers: > Over the years, I’ve seen several engineers on other teams become less productive and then leave the company because they weren’t happy. Each time, I didn’t pay attention and stayed focused on my projects. Yeah, most companies have a very very difficult time understanding the deep intricate knowledge-worker problems their expert knowledge-workers are deeply entailed into & care omg about. Only like 20% of these companies/managers even bother to figure out what the real intricacies are. It's fucked up. Yeah the engineers are distressed. But this is like >80% a problem of orgs not actually knowing wtf the situations really are. I've seen plenty of scrum teams have retro after retro where we identify real challenges, where we do good retroes, but as an engineer, our power to make anyone care at all or give a shit is limited. We can try to talk to someone we want to stay, but 9 times of out of 10, we have nothing to offer, no way to help. Trying to figure out how to make the org responsive or understanding is the challenge. There is some good advice too, for engineers: Get to know your coworkers. Yeah. Do it. Don't just leave it to the managers & org. Culture never is top down, it's always a net-product. Links have to be forged at all levels. I think this is a huge challenge especially in the new hybrid/remote world.
chiefalchemist 4y ago
> For that reason, people problems are just as important as problems with the code itself. True. But somewhat understated / misleading. The difference is, people problems are 10x harder than technology problems. Technology is finite and relatively predictable. People? We're emotional and have lives outside work that of often come to the office. If technology was as erratic as people we'd all be making therapist money ;) Technology is easy. People are hard.
croniev 4y ago
> Having motivated, happy teammates is critical to getting things done. Here it is, in case anyone was looking for a good reason to care about people's happiness
GartzenDeHaes 4y ago
> People problems are as important as “real” problems I would go even further and say, "all technical problems are really people problems."
twawaaay 4y ago
Also my observations. But importance of some of these things changes as you evolve and gain seniority. Definitely it is a mistake for a junior developer to obsess over hiring people. This is something you should start paying more attention somewhere around when you become senior dev. As a manager/tech lead I really need help to make hiring decisions but for that help to be valuable it must come from somebody with enough experience and also understanding of the project. People problems are also best left to your seniors if you are a junior dev. You should pretty much be in observation/learning mode. Be respectful and kind to other people and stay away from drama. Don't try to resolve problems for others -- if you don't yet have experience you are more likely to cause more trouble than solve the problem. On the other hand getting to know other people is always important, regardless of your level.
tmp923471483 4y ago
Created a temp account to say please let there be others that cringed when reading this thinking that it was insanely obvious. I originally went to the comments expecting a big flurry of people trashing this saying that the author was really late to the game, but to my surprise this line of thinking is incredibly common here. And it appears that some people are actively pushing back on this. :(
takenpilot 4y ago
This is reinforcing the idea that all ICs eventually become managers, or that managers are just more advanced versions of ICs. Egocentric. But it's the direction the industry is moving in.
dieselgate 4y ago
I like this post but is it really only about "people skills"? Of course a manager would have more of an interpersonal focus because that's their job; ICs need to focus on their job as well (while being personable enough obviously). I'm all for interpersonal skills but think this post falls short a quite a bit for helping out engineers/ICs. Edit: inter- not intra-
quickthrower2 4y ago
I agree with the social stuff but it doesn’t have to be drinking alcohol and forced fun. Just grabbing coffee every day, organise some board games, low key stuff is good too. I can see why the party oriented social events can put off shy / religious / parents etc. But you can get to know people without that and make connections.
bitwize 4y ago
tl;dr Play the game. Watercooler politics mean more than your code when it comes down to who gets promoted. Why all the stuff about hiring? As an engineer, hiring isn't even your job. You may end up participating in the interview process and offering feedback, but ultimately you're not making the hiring decisions unless you're a manager anyway, so ignoring hiring isn't really a mistake you make as an engineer.
- yCombLinks 4y ago
  It's not just about getting promoted. It's much easier to get things done when you work well with the people on your team. And the more influence you have because of those connections, the more influence you have on hiring decisions. Keeping a bad team member from joining your team is huge.
ddmichael 4y ago
Progressing into adulthood will make you see further. Hang on.
shsbdncudx 4y ago
Most of the things that make you a more “senior engineer” are not getting better at writing code. It’s a social endeavour and you’re a bigger lever when you grow outside that small circle.
irrational 4y ago
I’ve been fortunate to work with the same core group on engineers and qa for more than a decade. Managers come and go, but we all get along well, enjoy our work, have great benefits, and are compensated well enough that none of us have felt like moving on. However, we recently got a new manager who is a pain in the ass. Fridays are normally no meeting days (this comes from much higher up), but he scheduled a 1 hour meeting this morning that he managed to drag into 3.5 hours. I pretty much have done nothing else today because I’ve been brain dead after that long meeting. For the first time in years, a number of us are talking about moving on. It is amazing how bad an effect a manager can have on a team.
- jeffdn 4y ago
  This seems like the kind of thing you could take to your skip-level or even higher in the management chain. A single new manager causing multiple long-serving employees to become disgruntled should be a bright red flag to a competent leadership team.
  - irrational 4y ago
    Unfortunately, we can’t do that. Not everyone on the team is white, but enough are that if we complained about the new manager it would most likely come off as racism. Better to find a new job first and then let HR know of our concerns in the exit interview.
lamontcg 4y ago
These seem almost a bit simplistic? What about something like hard business tradeoffs? You can never produce the perfect system if it will take so much effort that the system never ships. Your security posture will never be perfect, it just better be good enough to keep you out of the headlines, etc.
- rubidium 4y ago
  Yea, it’s from a pretty green manager it seems. Not great advice to engineers.
l_theanine 4y ago
I’ve trained hundreds of people across many roles for thirty years. I have two things I’d like to add: - A mistake you are willing to learn from is not just a mistake. It’s a lesson. It can yield as much reward as you’d like, depending on the effort you spend to reflect and change things. - Most advice like this, when it comes to things someone learned after moving up a rank in some org chart, is not as portable as we might like to think. Teams are always different shapes. In the end, if business functions are being executed well and if the people doing those things are paid well and happy to stick around, then you’ll find over time it really just doesn’t matter what the process looks like or the permutations of productivity-fu you put on it. Anyhow, this is a nice article. I enjoy reading stories about career progression like this. I wish I had read more twenty years ago to learn this stuff, I made a lot of “mistakes” then. Keep it up!
xwdv 4y ago
For a 10x engineer, heads down coding is the best state you can get them into. If you suspect someone is a 10x engineer, throw them your hardest, seemingly impossible problems, where they can stretch their legs and spend long periods of time in a flow state solving and thinking about the problem and writing large amounts of code with little to block them. The quickest way to waste your 10x engineer’s potential is throwing them lots of little, bite size problems, that require frequent interruptions and little concentration. They will do this work just fine but they’ll never end up producing a cathedral of code that leaves you in awe.
taeric 4y ago
The hiring point is... Nuanced. Heavily. Growing a team will make work for the whole team. And making work for the whole team will produce output from the whole team. And that will lead to more legacy product faster than keeping a lean team. Very well could be the right choice, but clearly has limits.
bigmattystyles 4y ago
I also have more appreciation for having to make decisions I know will be derided. I feel bad for some of my derision when I was an IC. Not for all of them but definitely some.
shswkna 4y ago
Like everything in life, striking the right balance makes the whole difference. Exactly how the balance is weighted is different for varying situations. Your unique “formula” is your secret to success.
revskill 4y ago
Management shoild be automated.
disambiguation 4y ago
Looking forward to the sequel: "Mistakes I made as a manager, but had to go back to engineering to see"
antipaul 4y ago
Good, concise memo. Notably, none of these top mistakes are technical mistakes. The implication seems to be that the person in the manager’s role is critical. I mean, if they don’t even let the team know they’re bringing in another person to the team, then good luck.
ChiperSoft 4y ago
TLDR: Give a shit about your coworkers. Thats it, thats the whole post.
lefalx 4y ago
Agree ,but do not think you have to become a manager to see those mistakes.

224 points by ryanlpeterman 4y ago

Couldn't agree more. For a long time, I'd be one of the last people to quit when a shitty manager was brought onboard. I'd give them their due time. Other senior engineers saw the writing on the wall and jumped ship. So far they've always been better off for leaving than me for sticking around.

glonq 4y ago

...will we see this followed up with "mistakes I made as a manager, but had to become an executive to see"? ;)

ryanlpeterman 4y ago
Hahah also good clickbait. Maybe one day if I'm lucky
hummus_bae 4y ago
[dead]

Jensson 4y ago

"When I was an engineer I focused on work that improved my career, but then I became a manager and realized that my engineers actually should work to improve my career!" Funny how that works.

ryanlpeterman 4y ago
I agree it's easy to see it that way as an IC (I thought the same!). I think the more senior you become the more you will view impact from the lens of your team/org, even as an IC
- Jensson 4y ago
  There is a strong bias to focus on things that helps yourself, that is only natural. So IC's will focus too much on things that improve their career, managers will focus too much on things that improve their career, directors will focus too much on things that improve their career etc.
- izacus 4y ago
  Although, the more senior you become the more you also understand about using the best tool for the job. And burning away engineers time to do management tasks is not that.
- allenu 4y ago
  I'd say the higher you move up in management, the more and more your own goals should represent the business's goals. A lot of ICs don't really care about the business, however, and I think this is where promotions are used as a tool to get them to care. If you act in the interests of the business, the leadership of a company will (usually, but not always) reward you for your service to the business. Whether or not this is something you "should" do is up to you, in my opinion. As an IC, you can't make me care about a business. I'm there to get paid and gain career experience, the latter of which sometimes improves the business and sometimes not.
  - eggsmediumrare 4y ago
    This is why every time I take a management, I regret it. I don't care about any business and I'm beginning to suspect I'm incapable of caring about any aspect of the job other than the wellbeing of the people on my team.
stingraycharles 4y ago
Depends on what you’re looking for in an engineer. I consider the author’s learnings to be relatively obvious, of course and engineer that “gets to know their colleagues” is doing great. Fact of the matter is that there are a whole lot of people that aren’t necessarily into that, but are great individual contributors, and should just be left to their devices as long as they’re a positive contribution, not just to your codebase, but towards your organisation as a whole.
- Jensson 4y ago
  Making the team stronger often doesn't make your career better though. This guy says he didn't and he got promoted to manager anyway, and now suddenly he wants the people under him to make his team stronger rather than focus on their career like he did. That smells like a corporate climber who just started to eye his next promotion rather than a new insight. Edit: Notice I'm not saying this is bad, this is just natural bias towards what benefits yourself. It is just so interesting to see how people who experience that bias shift now sees it as some kind of "insight" rather than just their own bias.
- I_AM_A_SMURF 4y ago
  I just want to say that the usual interpretation of "individual contributors" is not that they work alone. Almost by definition a Senior and especially a Staff+ engineer gets to deal with a lot of other engineers, hardly working by him/herself. The more you go up the IC ladder the more your job becomes influencing the technical direction of your team/org. It's a very social job.

gardenhedge 4y ago

Tldr: people problems are problems, having a good team is important, socialising is important. This is such a non-article.

HellDunkel 4y ago

I dont get it. Why would you care or think much about hiring as an engineer? You probably would not even be asked to attend interviews. If you vibe with the company and share the vision okay but this is not a matter of perspective. Why would you NOT be interested in getting to know your coworkers? Why NOT have interesting conversation or a good laugh at lunch? This has nothing to do with beeing an engineer or manager either. Obsession with code maybe more important for an engineer. Does not mean it was „wrong“.

MisterBastahrd 4y ago
Why? Because you will eventually have to work with these people and their problems will become your problems, especially if you are seen by management as someone who can fix those issues. Young adults tend to group together and cling to co-workers because they haven't learned to cope with life independently of the situation they find themselves in. I generally like my co-workers, but I have no inclination to spend any independent time with them. It's not that I don't want to make friends at work, it's that I don't want a condition of my friendship to be tied to the workplace. If I'm not seeking that person independently now, then I'm probably not going to do it later after switching jobs.
- HellDunkel 4y ago
  I did not state anything about „problems“. Not sure what you refer to.
- Wowfunhappy 4y ago
  > It's not that I don't want to make friends at work, it's that I don't want a condition of my friendship to be tied to the workplace. If I'm not seeking that person independently now, then I'm probably not going to do it later after switching jobs. I've made friends at previous companies who I still see regularly. Not a ton, but some. I have dinner plans with one of them this coming Monday.
gonzaloalvarez 4y ago
Because as you become more senior as an IC, your personal growth is directly related with your ability to influence others and deliver through others. What’s best way to do it than to ensure you bring and groom the right talent.

quicklime 4y ago

> Hiring well is one of the best uses of your time When I was an engineer I used to think this, but now that I'm a manager, I'm not so sure... If you want to maximize your impact, and make the biggest contribution possible to your company, then yeah, sure, it's absolutely the best use of your time. But a lot of engineers are trying to contribute to the company in ways that are mutually beneficial to them, and the way that a lot of companies set up interviewing is not. It's a thankless job that takes time away from things that can actually be put a performance review, so only the more selfless engineers will do it. The article reads a bit like manager-to-engineer advice, but the advice to managers would be: keep track of who is helping out with interviewing, and who is interviewing well, and reward them for it.

vanjajaja1 4y ago
Investing in 'hiring well' is worth it for the skill, sticking around in 'hiring' is probably not unless you're using it to swing some cool free international trips. There's a lot of value in knowing exactly how you'll be judged at your next job interview.
- zwkrt 4y ago
  I think of the hiring loops that I am a part of as paid interview practice.

angryGhost 4y ago

Technical skills are teachable to a coachable person, soft skills not so much

HellDunkel 4y ago
Technical skills are not really teachable much unless its a full time job.
13of40 4y ago
I'd go a step further and say that there will be times when you can sit across the table from a grown adult and explain to them the behind the scenes details of the performance review process, explain that you want them to do X Y and Z so you can build a case to get them promoted this year, just to have them tell you to fuck off because X isn't coding, Y is boring, and Z is below their skill level. "But please still promo me ASAP."
munchbunny 4y ago
Soft skills are also teachable to a coachable person. I've seen it in action. However, far fewer people are receptive to coaching on soft skills because fewer people understand what "soft skills" are and why they matter. I've met plenty of engineers (anecdotally, not a majority, but enough that it's a clear pattern, and strongly correlated with how junior they are) who lump soft skills into a single category represented by broad labels like "charisma" or "schmoozing" or "eloquence". But it's really a very big category of practicable skills.
- ZephyrBlu 4y ago
  I think "soft skills" disguises what these skills generally are and their importance in the context of an organization. Things like navigating an org, knowing how to make asks that have a high % of being accepted, writing things for a specific audience and keeping conversations on track are all very important "soft skills" that are completely hidden by the "soft skills" label.
  - smcin 4y ago

ZephyrBlu 4y ago

A more interesting question is, are these actually mistakes or just part of the journey from a junior engineer to manager? People problems and building relationships with your co-workers are things that I have realized are important over the last couple of years (Haven't done any hiring yet). In saying that, I'm not sure it would have been wise to focus on these things earlier than I did. There were too many other things I needed to learn. Focusing on code is probably a good thing when you are a junior. Leave the higher level problems for a little later down the line. I've thought about hiring and am interested in doing it and getting good at it because I see that it's very high value, but I don't think it's the right time. There are more important skills and behaviours for me to develop right now. I try to focus on things 1 or 2 steps ahead of where I currently am, no more. Otherwise it's too far away from reality.

ryanlpeterman 4y ago
> Focusing on code is probably a good thing when you are a junior. Leave the higher level problems for a little later down the line. Agreed that junior engineers should focus on code with most time (but not all). If you focus on the low hanging fruit outside of code you can have more impact overall without too much time investment there.
- ZephyrBlu 4y ago
  I disagree you can do that without much time investment. The time investment is in learning, not executing. If you're a junior by definition you don't understand how to operate outside of code very well or at all, and you are still learning about operating in code. Trying to learn multiple skills at the same time is always tricky. Most people struggle to get good at one thing at a time, let alone multiple. Unless you are already becoming a more independent coder (I.e. 1-2 steps behind this point), stacking non-coding skills on top of that seems like a bad decision unless you are a very quick learner and can juggle multiple new skills.
- moonchrome 4y ago
  I disagree - I think juniors should pay attention - but actively moving outside their role is almost always more trouble than worth. I've seen so many misguided proactive attempts waste everyones time, create noise, break focus. If there's low hanging fruit, and you're not in a dysfunctional environment, it will probably give you diarrhea.

tenpoundhammer 4y ago

I think of all of these problems as being the managers problem and not the engineers problems. Maybe a better title is "10X Manager tasks, I wasn't aware of as an engineer". To help engineers maximize their career I tell Junior/Level 1 engineers focus on becoming net productive, meaning providing more value than you take. Midlevel/Level 2 engineers should becoming independent and solving lot's of their problems on their own. As they approach the top of this level start getting involved in architecture and design. Senior/level 3 should focus on helping the team to be successful as a whole, mentoring, producing value quickly when needed, and should be able to solve most problems independently including starting a project from scratch or solving complicated performance/technical problems. Hiring and people problems are engineering manager problems. Getting to know your coworkers is a good career move for anyone.

seemuch 4y ago
I really like the way you categorized different SWE levels. Thank you for the insights!
jcparkyn 4y ago
> I tell Junior/Level 1 engineers focus on becoming net productive, meaning providing more value than you take. This feels like it could backfire, by encouraging people to ask less questions. It's easy to provide more value than you take if you never take.
- qup 4y ago
  The take is your salary, in my experience. I'm not sure what you mean about questions.
  - idiotsecant 4y ago
    It seems obvious - if you scare a junior engineer they will sit in their office and build an abomination to avoid asking a simple question that could be answered in 3 minutes. It's a real thing and it doesn't help the junior engineer or the business.

guhcampos 4y ago

The article contains way too few mistakes. I suspect there's a whole series coming.

izacus 4y ago

So basically the mistakes were mostly not solving management problems as an engineer? Uhhh... ok.

Frost1x 4y ago
Yea, I don't get it. Perhaps if while you're an engineer you think management shouldn't be doing these sorts of things you had some mistaken perspective. Moving to management is not some inherently transcendental ascendancy into higher enlightenment and purpose, it's a change in responsibilities and goals. It's not for everyone, there are plenty capable of being managers and fully understand the roles but don't want to become them. This article reads like some journey to enlightenment that I think all but a junior engineer would read as pretty naive.
rektide 4y ago
On the one hand: 100%. Agreed. Engineers experience enormous cognitive dissonance because companies & managers don't understand the very real problems they face. This article both say it, but under the title of being a mistake of engineers: > Over the years, I’ve seen several engineers on other teams become less productive and then leave the company because they weren’t happy. Each time, I didn’t pay attention and stayed focused on my projects. Yeah, most companies have a very very difficult time understanding the deep intricate knowledge-worker problems their expert knowledge-workers are deeply entailed into & care omg about. Only like 20% of these companies/managers even bother to figure out what the real intricacies are. It's fucked up. Yeah the engineers are distressed. But this is like >80% a problem of orgs not actually knowing wtf the situations really are. I've seen plenty of scrum teams have retro after retro where we identify real challenges, where we do good retroes, but as an engineer, our power to make anyone care at all or give a shit is limited. We can try to talk to someone we want to stay, but 9 times of out of 10, we have nothing to offer, no way to help. Trying to figure out how to make the org responsive or understanding is the challenge. There is some good advice too, for engineers: Get to know your coworkers. Yeah. Do it. Don't just leave it to the managers & org. Culture never is top down, it's always a net-product. Links have to be forged at all levels. I think this is a huge challenge especially in the new hybrid/remote world.

chiefalchemist 4y ago

> For that reason, people problems are just as important as problems with the code itself. True. But somewhat understated / misleading. The difference is, people problems are 10x harder than technology problems. Technology is finite and relatively predictable. People? We're emotional and have lives outside work that of often come to the office. If technology was as erratic as people we'd all be making therapist money ;) Technology is easy. People are hard.

croniev 4y ago

> Having motivated, happy teammates is critical to getting things done. Here it is, in case anyone was looking for a good reason to care about people's happiness

GartzenDeHaes 4y ago

> People problems are as important as “real” problems I would go even further and say, "all technical problems are really people problems."

twawaaay 4y ago

Also my observations. But importance of some of these things changes as you evolve and gain seniority. Definitely it is a mistake for a junior developer to obsess over hiring people. This is something you should start paying more attention somewhere around when you become senior dev. As a manager/tech lead I really need help to make hiring decisions but for that help to be valuable it must come from somebody with enough experience and also understanding of the project. People problems are also best left to your seniors if you are a junior dev. You should pretty much be in observation/learning mode. Be respectful and kind to other people and stay away from drama. Don't try to resolve problems for others -- if you don't yet have experience you are more likely to cause more trouble than solve the problem. On the other hand getting to know other people is always important, regardless of your level.

tmp923471483 4y ago

Created a temp account to say please let there be others that cringed when reading this thinking that it was insanely obvious. I originally went to the comments expecting a big flurry of people trashing this saying that the author was really late to the game, but to my surprise this line of thinking is incredibly common here. And it appears that some people are actively pushing back on this. :(

takenpilot 4y ago

This is reinforcing the idea that all ICs eventually become managers, or that managers are just more advanced versions of ICs. Egocentric. But it's the direction the industry is moving in.

dieselgate 4y ago

I like this post but is it really only about "people skills"? Of course a manager would have more of an interpersonal focus because that's their job; ICs need to focus on their job as well (while being personable enough obviously). I'm all for interpersonal skills but think this post falls short a quite a bit for helping out engineers/ICs. Edit: inter- not intra-

quickthrower2 4y ago

I agree with the social stuff but it doesn’t have to be drinking alcohol and forced fun. Just grabbing coffee every day, organise some board games, low key stuff is good too. I can see why the party oriented social events can put off shy / religious / parents etc. But you can get to know people without that and make connections.

bitwize 4y ago

tl;dr Play the game. Watercooler politics mean more than your code when it comes down to who gets promoted. Why all the stuff about hiring? As an engineer, hiring isn't even your job. You may end up participating in the interview process and offering feedback, but ultimately you're not making the hiring decisions unless you're a manager anyway, so ignoring hiring isn't really a mistake you make as an engineer.

yCombLinks 4y ago
It's not just about getting promoted. It's much easier to get things done when you work well with the people on your team. And the more influence you have because of those connections, the more influence you have on hiring decisions. Keeping a bad team member from joining your team is huge.

ddmichael 4y ago

Progressing into adulthood will make you see further. Hang on.

shsbdncudx 4y ago

Most of the things that make you a more “senior engineer” are not getting better at writing code. It’s a social endeavour and you’re a bigger lever when you grow outside that small circle.

irrational 4y ago

I’ve been fortunate to work with the same core group on engineers and qa for more than a decade. Managers come and go, but we all get along well, enjoy our work, have great benefits, and are compensated well enough that none of us have felt like moving on. However, we recently got a new manager who is a pain in the ass. Fridays are normally no meeting days (this comes from much higher up), but he scheduled a 1 hour meeting this morning that he managed to drag into 3.5 hours. I pretty much have done nothing else today because I’ve been brain dead after that long meeting. For the first time in years, a number of us are talking about moving on. It is amazing how bad an effect a manager can have on a team.

jeffdn 4y ago
This seems like the kind of thing you could take to your skip-level or even higher in the management chain. A single new manager causing multiple long-serving employees to become disgruntled should be a bright red flag to a competent leadership team.
- irrational 4y ago
  Unfortunately, we can’t do that. Not everyone on the team is white, but enough are that if we complained about the new manager it would most likely come off as racism. Better to find a new job first and then let HR know of our concerns in the exit interview.

lamontcg 4y ago

These seem almost a bit simplistic? What about something like hard business tradeoffs? You can never produce the perfect system if it will take so much effort that the system never ships. Your security posture will never be perfect, it just better be good enough to keep you out of the headlines, etc.

rubidium 4y ago
Yea, it’s from a pretty green manager it seems. Not great advice to engineers.

l_theanine 4y ago

I’ve trained hundreds of people across many roles for thirty years. I have two things I’d like to add: - A mistake you are willing to learn from is not just a mistake. It’s a lesson. It can yield as much reward as you’d like, depending on the effort you spend to reflect and change things. - Most advice like this, when it comes to things someone learned after moving up a rank in some org chart, is not as portable as we might like to think. Teams are always different shapes. In the end, if business functions are being executed well and if the people doing those things are paid well and happy to stick around, then you’ll find over time it really just doesn’t matter what the process looks like or the permutations of productivity-fu you put on it. Anyhow, this is a nice article. I enjoy reading stories about career progression like this. I wish I had read more twenty years ago to learn this stuff, I made a lot of “mistakes” then. Keep it up!

xwdv 4y ago

For a 10x engineer, heads down coding is the best state you can get them into. If you suspect someone is a 10x engineer, throw them your hardest, seemingly impossible problems, where they can stretch their legs and spend long periods of time in a flow state solving and thinking about the problem and writing large amounts of code with little to block them. The quickest way to waste your 10x engineer’s potential is throwing them lots of little, bite size problems, that require frequent interruptions and little concentration. They will do this work just fine but they’ll never end up producing a cathedral of code that leaves you in awe.

taeric 4y ago

The hiring point is... Nuanced. Heavily. Growing a team will make work for the whole team. And making work for the whole team will produce output from the whole team. And that will lead to more legacy product faster than keeping a lean team. Very well could be the right choice, but clearly has limits.

bigmattystyles 4y ago

I also have more appreciation for having to make decisions I know will be derided. I feel bad for some of my derision when I was an IC. Not for all of them but definitely some.

shswkna 4y ago

Like everything in life, striking the right balance makes the whole difference. Exactly how the balance is weighted is different for varying situations. Your unique “formula” is your secret to success.

revskill 4y ago

Management shoild be automated.

disambiguation 4y ago

Looking forward to the sequel: "Mistakes I made as a manager, but had to go back to engineering to see"

antipaul 4y ago

Good, concise memo. Notably, none of these top mistakes are technical mistakes. The implication seems to be that the person in the manager’s role is critical. I mean, if they don’t even let the team know they’re bringing in another person to the team, then good luck.

ChiperSoft 4y ago

TLDR: Give a shit about your coworkers. Thats it, thats the whole post.

lefalx 4y ago

Agree ,but do not think you have to become a manager to see those mistakes.