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.
Mistakes I made as an engineer, but had to become a manager to see
81–90 of 109 posts
Re: Mistakes I made as an engineer, but had to become a manager to see
#82...will we see this followed up with "mistakes I made as a manager, but had to become an executive to see"? ;)
[dead]
Re: Mistakes I made as an engineer, but had to become a manager to see
#83I 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 th…
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.
Re: Mistakes I made as an engineer, but had to become a manager to see
#84So basically the mistakes were mostly not solving management problems as an engineer? Uhhh... ok.
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.
Re: Mistakes I made as an engineer, but had to become a manager to see
#85A 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 th…
> 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.
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.
Re: Mistakes I made as an engineer, but had to become a manager to see
#86Earlier quoted context omitted.
> 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.…
It's funny people tolerate this kind of stuff. I'd be out the door immediately, and I have been before. You don't have to work for companies that do this kind of insanity.
What insanity? Being asked by your PO to work on the actual stuff your team has agreed to work on in the sprint planning , you know the stuff that management thinks will actually happen? If you don't tolerate this, it's certainly better for both sides to depart.
Re: Mistakes I made as an engineer, but had to become a manager to see
#87"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.
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 you…
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.
Re: Mistakes I made as an engineer, but had to become a manager to see
#88Like 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.
Re: Mistakes I made as an engineer, but had to become a manager to see
#89Earlier quoted context omitted.
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.
Right. The "soft skills" that make you popular and likeable with your peers are seriously disjoint from the "soft skills" that show you're in tune with management's (possibly unstated) priorities and know how to navigate them and know where the actual decision-making power centers are (and aren't). Sometimes, these skills are antagonistic to each other. Trying to munge these all together under one label seems counter…
Where can I learn more about these practical, important, or less thought about "soft skills" (like ZephyrBlu's interesting examples) more effectively? I feel like I've encountered these points (e.g. writing for a specific audience) through separate online posts at disparate times. But, is there a definitive, more comprehensive resource detailing all of these soft skills and more? I realize that I'm basically looking for a career panacea, so maybe it doesn't exist. Even if it existed, should I even spend my time reading it—as someone very early in their career—versus actually making the mistakes myself, learning from it, and internalizing it?
Re: Mistakes I made as an engineer, but had to become a manager to see
#90Management shoild be automated.