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.
> Focusing on code is probably a good thing when you are a junior.
I've seen what happens when people stop focusing on code. It's a timebomb for institutions. Code should always be focused on; it should be constantly rewritten, taking the lessons into account from previous iterations.
> 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.
I do feel even when scoping large projects that it is difficult to hold on to all of the pieces. I split it into chunks I can reason about and then (sometimes fearfully) return to the bigger picture. By the end of the project I can see all of the mistakes I made fumbling in the dark, but I’m not sure I could have managed more at the time that I did it.
I also feel this way about socializing at work. There’s something maslowian about it, when you are uncertain if you’re going to make it, it feels perilous to join socials. They’ll never fire me for not being social enough, is the message that fires through my brain at least. Though I’m sure social anxiety plays a role here as well.
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.
Yeah, I sort of had the same impression. Imagine as a junior engineer having the following conversation with your manager:
"Guess what? Yesterday I managed to triple my productivity going forward!"
"Great! How did you do that?"
"I hired two more engineers as good as me!"
"You did what?"
"Of course I had to pay them more than my own salary. Finding engineers as good as me who also work as cheaply as I do is basically impossible, I have no idea how you did it. I guess that's why you make the big bucks!"
Not sure if you've read Chris Hadfield's book (Astronaut's Guide to Life On Earth) but he talks about a similar system. In his words you can be one of three team members:
A Negative One -- You're a drain on the team and other people have to cover for you. Not so good if you're in space with limited resources.
A Zero -- You're capable and have your own shit covered. Most people in space are a zero.
A Plus One -- You're contributing to the success of the mission and helping others succeed as well.
He talks about arriving on the international space station and just making sure that he was a zero. And taking over as mission commander and on the first couple days, just trying to be a zero because the plus one fancy heroics can come later.
"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!"
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.
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
> 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.
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.
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.
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.
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.
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.
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.
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.
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“.
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.
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.
It's pretty obvious: thinking about hiring is important because you want smart and effective coworkers on your team. If engineers are not interviewing potential engineers, big problems can occur. Basically, you wind up with people who don't know what they're doing technically, but happen to "interview well." It takes a long time to fire someone. In the meantime, you got a big mess to deal with.
> Why would you care or think much about hiring as an engineer? You probably would not even be asked to attend interviews
Not with that attitude you won't, sure.
But engineers who do care about hiring, take the training seriously, and make themselves available to participate in interview loops, can make a big difference to the team with which they are surrounded.
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.
> 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 ;)
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.
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.
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. :(
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.
[+] [-] ZephyrBlu|3 years ago|reply
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.
[+] [-] beebmam|3 years ago|reply
I've seen what happens when people stop focusing on code. It's a timebomb for institutions. Code should always be focused on; it should be constantly rewritten, taking the lessons into account from previous iterations.
[+] [-] ryanlpeterman|3 years ago|reply
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.
[+] [-] willjp|3 years ago|reply
I do feel even when scoping large projects that it is difficult to hold on to all of the pieces. I split it into chunks I can reason about and then (sometimes fearfully) return to the bigger picture. By the end of the project I can see all of the mistakes I made fumbling in the dark, but I’m not sure I could have managed more at the time that I did it.
I also feel this way about socializing at work. There’s something maslowian about it, when you are uncertain if you’re going to make it, it feels perilous to join socials. They’ll never fire me for not being social enough, is the message that fires through my brain at least. Though I’m sure social anxiety plays a role here as well.
[+] [-] tenpoundhammer|3 years ago|reply
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.
[+] [-] gweinberg|3 years ago|reply
[+] [-] ar_turnbull|3 years ago|reply
A Negative One -- You're a drain on the team and other people have to cover for you. Not so good if you're in space with limited resources.
A Zero -- You're capable and have your own shit covered. Most people in space are a zero.
A Plus One -- You're contributing to the success of the mission and helping others succeed as well.
He talks about arriving on the international space station and just making sure that he was a zero. And taking over as mission commander and on the first couple days, just trying to be a zero because the plus one fancy heroics can come later.
[+] [-] seemuch|3 years ago|reply
[+] [-] jcparkyn|3 years ago|reply
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.
[+] [-] Jensson|3 years ago|reply
Funny how that works.
[+] [-] stingraycharles|3 years ago|reply
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.
[+] [-] ryanlpeterman|3 years ago|reply
[+] [-] quicklime|3 years ago|reply
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|3 years ago|reply
[+] [-] givemeethekeys|3 years ago|reply
[+] [-] izacus|3 years ago|reply
Uhhh... ok.
[+] [-] rektide|3 years ago|reply
> 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.
[+] [-] Frost1x|3 years ago|reply
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.
[+] [-] twawaaay|3 years ago|reply
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.
[+] [-] irrational|3 years ago|reply
[+] [-] jeffdn|3 years ago|reply
[+] [-] HellDunkel|3 years ago|reply
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|3 years ago|reply
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.
[+] [-] gonzaloalvarez|3 years ago|reply
[+] [-] icedchai|3 years ago|reply
[+] [-] jameshart|3 years ago|reply
Not with that attitude you won't, sure.
But engineers who do care about hiring, take the training seriously, and make themselves available to participate in interview loops, can make a big difference to the team with which they are surrounded.
[+] [-] lamontcg|3 years ago|reply
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|3 years ago|reply
[+] [-] takenpilot|3 years ago|reply
But it's the direction the industry is moving in.
[+] [-] chiefalchemist|3 years ago|reply
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.
[+] [-] guhcampos|3 years ago|reply
[+] [-] croniev|3 years ago|reply
Here it is, in case anyone was looking for a good reason to care about people's happiness
[+] [-] glonq|3 years ago|reply
[+] [-] ryanlpeterman|3 years ago|reply
[+] [-] hummus_bae|3 years ago|reply
[deleted]
[+] [-] disambiguation|3 years ago|reply
[+] [-] xwdv|3 years ago|reply
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.
[+] [-] shsbdncudx|3 years ago|reply
[+] [-] tmp923471483|3 years ago|reply
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. :(
[+] [-] dieselgate|3 years ago|reply
Edit: inter- not intra-