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

https://www.developing.dev/p/3-mistakes-i-made-as-an-engineer

by ryanlpeterman • 3 years ago

224 107 3 years 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• 3 years ago

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

ryanlpeterman5• 3 years ago

Hahah also good clickbait. Maybe one day if I'm lucky

Jensson3• 3 years 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.

ryanlpeterman5• 3 years 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

Jensson3• 3 years 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.

izacus2• 3 years 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• 3 years 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.

stingraycharles• 3 years 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.

Jensson3• 3 years 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• 3 years 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• 3 years ago

Tldr: people problems are problems, having a good team is important, socialising is important.

This is such a non-article.

HellDunkel3• 3 years 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• 3 years 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.

HellDunkel3• 3 years ago

I did not state anything about „problems“. Not sure what you refer to.

Wowfunhappy• 3 years 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• 3 years 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.

icedchai2• 3 years ago

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.

jameshart• 3 years ago

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.

quicklime• 3 years 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• 3 years 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• 3 years ago

I think of the hiring loops that I am a part of as paid interview practice.

angryGhost• 3 years ago

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

HellDunkel3• 3 years ago

Technical skills are not really teachable much unless its a full time job.

13of40• 3 years 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."

munchbunny2• 3 years 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.

ZephyrBlu4• 3 years 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.

randomdata• 3 years ago

Understanding why soft skills matter is teachable to a coachable person. But not without a coach and when it comes to soft skills there is a general reluctance towards providing soft skill coaching, with a prevailing attitude, as seen in the first comment, that anyone who "wasn't born" with soft skills is unteachable, leaving few willing to try to be the coach.

icedchai2• 3 years ago

Some people don't have the aptitude (for either.)

ZephyrBlu4• 3 years 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.

ryanlpeterman5• 3 years 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.

ZephyrBlu4• 3 years 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• 3 years 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.

ZephyrBlu4• 3 years ago

Taking a peek at your Twitter and Linkedin, I'm honestly not sure how useful this advice is for most people and whether it's based on reality, or what you wish happened.

For example, you say you got promoted from junior on "sheer volume of work" which is contradictory to focusing on "low hanging fruit outside of code" without "too much time investment".

https://twitter.com/ryanlpeterman/status/1623745298920255489

If a junior knew how to leverage "low hanging fruit outside of code" without "too much time investment" they would basically by definition not be a junior anymore, so I see this as a bit tautological. It seems like wishful thinking rather than something based on reality.

---

I also noticed on your Linkedin that you made Staff in 5yrs, which is extremely fast and likely means you are an exceptional engineer. I'm aiming for a similar trajectory, but I noticed a little while ago (Before I was even working as an eng professionally) that giving advice to people was very difficult. How do you explain that you just "get" things?

For example, my manager told me that he liked the fact that he only had to give me feedback once and then I would implement it. He also noted that weaknesses from my previous performance review became strengths in the next one. This is with only ~3 months between reviews as well.

There are a number of similar behaviour my managers have noted that I believe have been and will continue to be critical for my growth, but how do you teach those kind of things to someone who doesn't operate like that? I don't think you can.

beebmam2• 3 years ago

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.

IanCal3• 3 years ago

You need focus on other parts though, you can have the most beautiful codebase with the most efficient algorithms, the highest coverage and the most extensible yet simple and elegant architecture but if you're not solving the business problems someone's going to eat your lunch with a hacked together excel sheet.

The other view I have on this is around trust. Do I need to "focus" on the code if I have people on the team whose job that is? At what level? At a more senior position I shouldn't be looking into the small parts, the more effective use of time is ensuring the larger components are going in the right direction and/or we're not spending time on parts expected to be unused due to a strategic shift coming in. Maybe it's more important to focus on documentation right now, or perhaps it's important to get people working on different things because everyone's fixed on their small problem and not understanding the integration issues we have.

Code is important, but it's important for a reason. Create your artistically beautiful perfect codebase when that's the goal perhaps as a personal project, but businesses have different goals and its focus should be on achieving those.

"Focus" or attention I guess, is a limited resource. Spending it on one thing is not spending it on another. Balance is needed - 0% interest in the code is a big issue, but so is 100%.

bitwize3• 3 years ago

Code should always be focused on; it should be constantly rewritten,

Your PO: I've noticed you've been rewriting a lot of methods in the code base. Can you please tell me which stories on the board this sprint those rewrites are attached to? We need to focus on sprint work, and as we established as a team last PI Planning meeting, the emphasis this quarter is on shipping features from the Customer Experience epic. Please refrain from needless refactoring not accounted for in your sprint work.

bruce5112• 3 years ago

Your opinion is not uncommon, but alas it is wrong (in most cases.)

In most businesses, code is a tool to get to the desired outcome, not the desired outcome itself. Like most tools it is most valuable when being used to create the outcome, not being endlessly perfected. Good enough is good enough. Perfect is a waste.

Again, context matters. The code that runs a million times a day is more important than the report that runs once a year.

Equally, a well architected system will need to balance the needs of any different users, with potentially different goals. In other words, lots of compromises are necessary. The code reflects those compromises. There's a balance, good enough is good enough, time to move on.

I will say though that your attitude is not unique. I have come across many employees, and even one-man-companies that focus exclusively on the code. Often (not always) because code offers the programmer complete control. Unlike co-worker, bosses, employees or customers, it is not messy - perfection is achievable. Dealing with people is messy. Other tasks (like marketing) are vague or immeasurable. Code is simple, objective, doesn't talk back.

Certainly coding well offers an emotional reward. It's a clean game with fixed rules, and performance can be objectively assessed. For many of us it's a safe haven in a very messy world. But unfortunately it's usually just a tool, not the outcome. Someone in the messy outside world has to pay money - and that adds 10x more messiness, which someone has to deal with.

Progressing from junior to senior programmer, then into a business space (like analyst or architect) is really just the understanding, and skills, that come with balancing that messiness with the desire to write code.

willjp2• 3 years ago

This resonates with me on multiple levels.

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.

tenpoundhammer2• 3 years 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.

jcparkyn• 3 years 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• 3 years ago

The take is your salary, in my experience. I'm not sure what you mean about questions.

IanCal3• 3 years ago

An employee spinning their wheels getting nowhere for a month because they didn't ask a question that someone more experienced could answer in 5 minutes is not a good tradeoff.

Unless you work for free, you are taking.

It's important to explain this kind of thing though, and guide people to when it is and isn't appropriate to ask for help.

stu2b50• 3 years ago

I don't think the implication is that the junior engineer should be carefully calculating their coworker's hourly rates and estimating the dollar value of what your slack DM to them will cost the company. Just that you do a good enough job that your work brings in more money than your salary costs.

tenpoundhammer2• 3 years ago

I should have added more detail but I was attempting to be brief. I meant that a junior engineer should focus on learning how to do the basics of their job so that they can provide features that help our group meet business objectives. A large part of getting there will be needing mentorship and asking lots of questions. The context is that often juniors need so much hand holding that the cost of their mentors time is more expensive than the value of the feature being produced. I wasn’t even considering their salary.

gweinberg• 3 years ago

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!"

ar_turnbull• 3 years ago

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.

seemuch• 3 years ago

I really like the way you categorized different SWE levels. Thank you for the insights!

guhcampos• 3 years ago

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

izacus2• 3 years ago

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

Uhhh... ok.

Frost1x• 3 years 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• 3 years 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• 3 years 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• 3 years 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• 3 years ago

People problems are as important as “real” problems

I would go even further and say, "all technical problems are really people problems."

twawaaay• 3 years 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• 3 years 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• 3 years 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• 3 years 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• 3 years 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.

bitwize3• 3 years 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• 3 years 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• 3 years ago

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

shsbdncudx• 3 years 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.

irrational2• 3 years 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• 3 years 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.

irrational2• 3 years 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• 3 years 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• 3 years ago

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

l_theanine• 3 years 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• 3 years 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• 3 years 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• 3 years 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• 3 years 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• 3 years ago

Management shoild be automated.

disambiguation• 3 years ago

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

antipaul• 3 years 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• 3 years ago

TLDR: Give a shit about your coworkers.

Thats it, thats the whole post.

lefalx• 3 years ago

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

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

Related Stories