- "I'm an architect, too."
- "You know, I have a M. Eng."
You know you're on their shit list when you hear that. lol.
11–20 of 224 posts
- "I'm an architect, too."
- "You know, I have a M. Eng."
You know you're on their shit list when you hear that. lol.
Earlier quoted context omitted.
Yup, that's a common career path mistake companies do - making the only possible 'next step' for senior engineers to become managers. If your company doesn't have a strong career path for senior ICs, you should push for one
Honest question -- why does there need to be a "next step?" It's been over a decade since I've worked at a company with managers. However, it was common for the top programmers to make more money than their managers there.
Earlier quoted context omitted.
Yup, that's a common career path mistake companies do - making the only possible 'next step' for senior engineers to become managers. If your company doesn't have a strong career path for senior ICs, you should push for one
Honest question -- why does there need to be a "next step?" It's been over a decade since I've worked at a company with managers. However, it was common for the top programmers to make more money than their managers there.
Earlier quoted context omitted.
Yup, that's a common career path mistake companies do - making the only possible 'next step' for senior engineers to become managers. If your company doesn't have a strong career path for senior ICs, you should push for one
Honest question -- why does there need to be a "next step?" It's been over a decade since I've worked at a company with managers. However, it was common for the top programmers to make more money than their managers there.
Programming and managing are completely different jobs that accomplish different things for the organisation, but they are typically arranged in a top-down fashion, the manager has power over the programmer. A manager's job is to do the function of interacting with the wider organisation in order to determine the best way for the programmer to spend his time, in effect it's a research job, then he presents the programmer with the results of his research and they both agree that the most value can be added to the organisation by working on bug X today instead of feature Y. But what actually happens is the manager says "do this, because I said so, and if you don't I'll block your next raise". Or so-called engineering managers cherry-pick the most rewarding work for themselves and assign the unfulfilling work to subordinates as punishment. That's deeply dysfunctional but it's what happens when you have a group who wants to do real work, and another group who has plenty of time on their hands for full-time politicking.
Earlier quoted context omitted.
Honest question -- why does there need to be a "next step?" It's been over a decade since I've worked at a company with managers. However, it was common for the top programmers to make more money than their managers there.
It's been over a decade since I've worked at a company with managers. However, it was common for the top programmers to make more money than their managers there. Programming and managing are completely different jobs that accomplish different things for the organisation, but they are typically arranged in a top-down fashion, the manager has power over the programmer. A manager's job is to do the function of interact…
If you, like the author of this article, spent 13 years as an IC, perhaps it is OK for you to focus on acquiring the soft skills required to be an efficient engineering manager.
After 13 years as an IC, you have a pretty good perspective on what it means to be an IC, how to identify valuable team members, how to assess their skills, how to identify blockers and facilitate solutions, and most importantly, how to classify technical problems, how to analyze requirements, how to plan, estimate, communicate on deliverables and releases, etc.
If you have the hard skills, it's fine to spend most of your effort growing your soft skills. But if you don't have the hard skills, you'll have to focus on that as well.
You can delegate things to different team members, but at the end of the day, the responsibility is still yours. Team members can "own" things, but you're still responsible if they don't execute. And in order to do that efficiently, you have to be prepared to ask the right questions to the right people, and that requires hard skills.
Earlier quoted context omitted.
It's been over a decade since I've worked at a company with managers. However, it was common for the top programmers to make more money than their managers there. Programming and managing are completely different jobs that accomplish different things for the organisation, but they are typically arranged in a top-down fashion, the manager has power over the programmer. A manager's job is to do the function of interact…
There are companies where managers are truly in a supporting function. I'm not here to advertise but my last two jobs were like that.
Unless programmers have equal knowledge of and input into their managers salary as their manager does in their's, there's still that fundamental top-down structure.
This sounds like the kind of role a lot of good engineers get promoted to unwillingly/unknowingly, how do you avoid being assigned this role and remain a valued engineer once you have experience?
This sounds like the kind of role a lot of good engineers get promoted to unwillingly/unknowingly, how do you avoid being assigned this role and remain a valued engineer once you have experience?
This sounds like the kind of role a lot of good engineers get promoted to unwillingly/unknowingly, how do you avoid being assigned this role and remain a valued engineer once you have experience?