Don't you get bored with spending many years learning and becoming advanced or an expert in a system paradigm (like different hosting systems), a programming language (i.e. Perl), or a framework (pick your JS framework), only to have it completely obsoleted a few years later? And then in a job interview, when you try to sell yourself on your wisdom as expert on thing X, new to Y, they dismiss you because the 25 year old has been using Y since its release three years ago?
And when you're in an existing company, stuck in thing X, knowing that it's obsolete, and the people doing the latest Y that's hot in the job market are in another department and jealously guard access to Y projects?
How about when you go to interview, and you not ONLY have to know Y, but the Leetcode from 15 years ago?
So maybe I've given you another alternative to 'it has to be power, there's no other rational reason to go into management'.
Here's a gentler one: if you want to build big things, involving many people, you need to be in management.
Do you enjoy brick laying and calculating angles around doorways? You're the engineer. Do you want to be the architect hiring engineers, working with project managers, and assessing the budget while worrying about approvals? They're different types of work, and it's not about 'power' like you are suggesting. Autonomy and decision-making power are more the 'power' engineers often don't get (unless they are lucky, very very smart or in a small startup-like environment).
N=1 but I do love constantly learning new things, and building small, purposeful, tailored products with small groups of people.
I've gone back and forth across the lead and management lines many times now, and it is career limiting in many many ways. But it's too fulfilling to give up. And I swear there is magic in what small, expert groups are able to produce that laps large org on the regular.
From my (limited) experience, that magic is incredibly linked to autonomy and ownership.
Some research around British government workers found higher job satisfaction in units with hands-off managers. It resonates with my own career. I’m really excited and want to go to work when I’m on a small, autonomous team with little red tape and politics. Larger orgs simply can’t — or haven’t — ever offered me the same feeling; with some exceptions in Big 3 consulting if I was the expert on a case.
As a manager, I love being hands-off - I like directs that take ownership and I try to give people projects and roles that they want. They use their creativity and I help unblock, expand, course correct or suggest as needed. It saves them from the politics and they get high level mentoring.
The worst manager is the micromanager - either because he's nervous about his job security, because he doesn't know how to delegate, or because he's been hands-on forever and can't let go.
isn't that more a question of company size and industry (i.e. less regulated than healthcare and financial services) than whether management is good or bad?
I don't see why it contradicts my little rant above. Of course I also prefer small, nimble teams with lots of autonomy, with individuals who thrive being delegated only extremely broad tasks. The only part where I think there's a difference is the constantly learning.
I love constantly learning. My issue isn't that. It's that I don't want to HAVE to constantly be practicing at home and on the weekend. I did this in my 20s and I can't/won't do this anymore. I just have no time or energy now as an Old.
I don't really think management is good or bad, just different, and not really for me. The management career ladder though I do feel goes higher in large organizations than small.
For myself it is the hands-on work I find most fulfilling unfortunately. I have some sort of brain worm that makes me want to practice all the new things at home/weekend if work isn't letting me. I'm sure it'll burn me out at some point, but to paraphrase a famous creep: I keep getting older, my brainworm stays the same age.
I don't think having to practice at home and at weekends is necessarily a part of engineering though. Every place I've worked at, there have been ample opportunities to keep up-to-date on paid hours, be that in conferences, learning materials, trying out side projects or weird ideas in more niche technologies, etc.
I think if you have a job that gives you the chance to expand your skills, pick new tech with the ability and time to learn onsite, and offers you that grace, that's a great company to work for.
Within my power I try to do that with my directs, making sure new interesting things are cycled in so their CVs become stronger. But me, personally, I've had really bad luck with this. I always had to study on the weekends for something that either isn't used in my company or someone else jealously guards because it's hot on the market.
Web servers have existed for more than 30 years and haven’t changed that much since then. Or e.g., React + Redux is pretty much the same thing as WinProc from WinAPI - invented some time in ~1990. Before Docker, there were Solaris Zones and FreeBSD jails. TCP/IP is 50 years old. And many, many other things we perceive as new.
Moreover, I think it’s worth looking back and learning some of the “old tech” for inspiration; there’s a wealth of deep and prescient ideas there. We still don’t have a full modern equivalent of Macromedia Flash, for example.
> React + Redux is pretty much the same thing as WinProc from WinAPI
I can't tell if this is sincere or parody, it is so insufferably wrong. Good troll. I almost bit.
Why is it wrong? Please elaborate. For more substance, here’s a discussion from 2015:
https://news.ycombinator.com/item?id=10381015
>only to have it completely obsoleted a few years later
Almost nothing goes obsolete in software; it just becomes unpopular. You can still write every website you see on the Internet with just jQuery. There are perfectly functional HTTP frameworks for Cobol.
obsolete in the software *industry
> Do you enjoy brick laying and calculating angles around doorways? You're the engineer. Do you want to be the architect hiring engineers, working with project managers, and assessing the budget while worrying about approvals?
These are inherently different levels of power. I'm not sure how your example is supposed to be the opposite when you compare someone laying bricks to someone making hiring and firing decisions about groups of people. Your scenario is fundamentally a power imbalance
You might be right about a Leetcode effect and the difficulty to find new interesting positions. But OP wasn't stressing that at all but the desire to architect and manage. I might have put to much emphasis of the managing and too less on the urge to architect and see things from above. I agree.
I am scientist and worked from time to time as a research engineer merely to pay the bills, so I may see things differently. I always like doing lab / field work and first-hand data analysis. Many engineers I know would likely never stop tinkering and building stuff. It may be easier for a scientist than for an engineer to still get trilled, I don't know.
Some of us actually enjoy programming.
Yea, I enjoy being the engineer
A rare occurrence these days. I suppose a lot of it has to do with shrinking attention spans and instant gratification and the lack of effort required to do so many things that required even a little bit of effort before
Same. The process (and all of its struggles) is an inseparable part of the satisfaction.
In my opinion, time spent learning Perl or an outmoded framework still helped me learn new things and stretch myself. A lot of that knowledge is transferable to other languages or frameworks. After learning QuickBasic and REXX it was pretty easy to pickup Ruby and Python. ;-)
And I would argue that what you are describing is why we end up in a system where the people who are talented and have in depth knowledge end up in "dumber ~ managerial" roles and we end up losing real talent and knowledge because of the incentives you explicitly describe.
If only the world incentivized ICs with depth of knowledge to stay in those roles for the long haul instead of chopping off our knowledge of specificity at the apex of their depth of knowledge. So many managers have no talent, no depth of knowledge and a passable ability to manage people.
Many ICs have no talent or depth of knowledge, I don’t think thats a criticism unique to managers.
> only to have it completely obsoleted a few years later?
That sure beats having it completely obsoleted a few weeks later, which sometimes feels like the situation with AI
Thank you for adding color. This is the exact reason why I want to get in to management. Sadly, I am just not cut out to manage people. Nowadays, my role is more of a hybrid between Principal and EM, which may be awkward at times. If it weren't for excellent PM & PgM, I'd be stretching myself too thin.
Why aren't you cut out?
It's a skill that takes practice -coordinating disparate people and groups, creating communication where you notice they're not talking to each other, creating or fixing processes that annoy or cause chaos if they're not there, encouraging people, being a therapist, seeing what's not there and pushing a vision while you get the group to go along, protecting people from management above and pressures around, etc are mostly skills that you learn.
Sometimes no one will give you feedback so you have to figure it out yourself (unless you're lucky to get a mentor), so you just have to throw yourself in and give yourself grace to fail and succeed over time.
The only skill of these I think is possibly genetic or innate, is being able to see the big picture and make strategical decisions. A lot of tech people skew cognitively in narrow areas, and have trouble conceptualizing the world beyond.
One challenge here is the ubiquitous 'managers just approve vacations and waste space' sentiment on here and in some places. These people are a chore to manage (and sometimes are better not being present in your group).
> if you want to build big things, involving many people, you need to be in management.
No, you don’t. You need some kind of decision making and communication process but a separate management is not necessary.
How will the widget get built if we don’t have someone stack ranking us?
Since when do your line managers choose to stack rank?
Do you know what stank ranking even is and where it comes from? If you have to rate your group from 1 to 5, each individual, and you rate them all 4s and 5s, they crack down and force you to select a 2 and a 3 and only have one 5. Now, would you prefer a CFO, CTO or even a project manager be the one to do it? It's a weird comment.
Weirder that you think every group has a 2 and exactly one 5. You don't see the problem with that?
Re-read and think about what was written - the 2s aren'tcoming from the line managers, you're barking up the wrong tree in the stack ranking process. I just explained that stack ranking gets scaled and adjusted by the brass, and I just in this example rated everyone a 4 and 5.
Again, as an older manager today, I can see myself in my 20s in the resistance and stubbornness to 'how corporations work' espoused in comments like yours. I sympathize, but I warn you against being naive and ideological, because unfortunately human groups be human groups, and organizations for better or for worse behave in predictable patterns. You might as well know as much as possible so you can deal with it better.
Do you think every group of people contains someone who is operating at 40%?
Nope! In fact I think stack ranking is horrible. But you missed the point I was making (and then re-made). I think you read 40% of what I wrote.
Weirder that you think software couldn’t get built without a CFO. The GP comment was noting that management is an outcome of capital wanting more control, not because many layers of middle managers is a naturally optimal way to complete software projects
CFOs manage budgets and funding and things tech people don't. I hate to parrot your tone but, weirder that you think software can be built in a company without there being a budget of some kind.
Can you go into more detail?
I have worked at organizations where most engineering and many product decisions were made bottom-up, through written RFDs and ADRs, and horizontal conversations between lead, staff and principal engineers. The tradeoff is that it can take weeks, months or years to both agree or schedule work on larger projects, where other (especially small) organizations might take hours to weeks.