I’ve worked in big companies with the philosophy you’re advocating, and my impression is that they turn very political and lose focus on the day to day engineering work. In the extreme the engineering work even turns into something “dirty” that you should know as little as possible about, because that’s the way to be promoted into higher paying / higher status roles. When 10-20% go around “virtue signaling” their ignorance it quickly destroys the culture.

But that also means you still see managers "a top" of engineers (a "better" job).

But just because you are managing a project shouldn't mean you stand above all the people in the project. Like e.g. a trainer in football/soccer might direct the Team but the highly experienced players in the Team are, while directed by the trainer, not in a social hierarchy below the trainer. Because most times they stay when the trainer gets fired and they might get the trainer fired too if they believe the trainer is incompetent.

So in the end the problem just again boils down to seeing being a manager as a advancement of your carrier but becoming a senior engineer just as a continuation/negligible advancement.(1)

(1): assuming proper standards for senior engines, I have seen many people in senior engineer positions which do not have the skills to call them senior engineer IMHO.

No. All that’s required is that 10-20% of individual contributors see it this way. They will start manoeuvring, “virtue signalling” their ignorance, effectively destroying the culture.

You don’t see it that way. I don’t see it that way. But they do. That’s enough unfortunately.

What you need to break this dynamic is that the opportunity to be a trainer (or at least coach) is a kind of reward for learning to play the game really well. I think that’s how it works e.g. in (European) football as well.

Managers are typically comped better. Usually on a level by level basis, but also in the number of times you can be promoted before you run out of new job titles.

I think there is probably one IC equivalent for every 2-3 low level managers, and $CORP is better about these things than any other company I’ve ever worked for.

I think a lot of success in hierarchies is based around the willingness and ability to turn a screw.

What domain expertise buys you is a higher intuition on whether or not you should.

Sure, you can have a lot of technical managers who suck. You can also have a good experience with a non-technical manager.

But day by day, pound for pound, my money is on domain expertise leading to better results. This happily explains why a manager is typically a senior role.

Course, there's a lot of ways to screw that up.

Managing people is a shit job. You spend your time in endless meetings and playing politics. You're tasked with day-to-day HR-related tasks. You need to keep everybody satisfied. Your salary won't necessarily be any higher. You get the blame for stuff. You have to delegate away the fun work. You lose touch and rust faster. If you're lucky, some of the people you work with will actually like you - but if your team doesn't deliver then it doesn't really matter...

What makes any of this sound like you're somehow "climbing"?

Of course the majority of people don’t even come close to this, but people will try nonetheless.

There are also positive aspects that hang in the balance. Personally (as a people manager) I appreciated the positive impact (coaching, career development) I could make to people around me in ways that are not easily replicated in other roles. And there are many others.

It’s just not private planes and Champaign.

It's sad that our society is organized so that people who find meaningful work are stiffed by our society (teacher salaries, for example).

Seeking power is probably a miswant anyways. I think what many people desire is the social stability that it presents, something that is probably more easily achieved via volunteer work.

I think the desire for power is manufactured.

I don’t. I think it has very deep evolutionary roots: more status / power has historically translated into better access to resources, especially in times of scarcity.

But I agree it’s a miswant. In modern society nobody has much power over anybody (compared to how it was in ancient/evolutionary time). I think of it as a primitive drive that can lead some of us astray, like the sex drive can make some preoccupied with pornography.

I also think good managers should have a healthy distance to their desire for power. If they don’t they can waste a lot of company money on scratching that itch endlessly.

Sales engineers can also have customer/client consulting management roles.

Some companies promote good engineers to R&D and product strategy roles. They're still engineering-led, and not particularly about day to day development issues or longer term - but still very clearly defined - project goals.

Most of what's being described as management really seems to be line management. What you want from management is at least as much of the other types.

Generalists who can invent the future with some accuracy are particularly valuable. Giving them space to pursue that within some very broad strategic goals is far more valuable than "promoting" them to team management.

I don’t understand why this is a different perspective. The dynamic I’m describing applies if you start promoting junior engineers to these roles as well (based on interest in management and ineptitude in hands-on engineering).

> Generalists who can invent the future with some accuracy are particularly valuable. Giving them space to pursue that within some very broad strategic goals is far more valuable than "promoting" them to team management.

In my experience it’s very hard to invent the future and realise the vision without some sort of formal leadership / management (in the broadest sense) role. (Unless it’s small enough for one or two people to build of course.)

Office space joked about having eight different bosses, the secret to worker happiness is less management in their lives, not more.

I think some, myself and Apple included when I worked there for years, consider hierarchies as a restricted sort of graph (essentially trees) that, to be a tree, necessarily collapse multiple dimensions of talent per individual into the single hierarchy, and thereby loses information. Hierarchies were avoided even whenever possible.

This has worked out fantastically for me for decades. But would-be managers have vested interest in promoting the supposed intrinsic instinct thing. Individuals don't have to play along.

It makes sense to have "managers" in fast foods. It's way harder to even just define the role in an environment where everybody is a knowledge worker. Maybe we should even stop using that term and stick with more precise role descriptions.

Product manager -> product designer

But what about the people who decide salaries, promotions, hiring, and reviews? Part of the role is “project coordinator” and another part is “staffing and compensation”. Is there an alternative title for that?

Recently, I was a Chief Architect - an IC role - and organised and drove cross-team initiatives was a part of my work. It is not an easy skill, it needs practicing and the work is time consuming, may not be a fun quite often, but I think you do not absolutely have to assign it to a manager.

As a side-note, I have no idea why we have "managers" in large companies. I see more and more that a "team lead" is just another developer who has to deal with spring planning and work assignment without much/any difference in compensation. A team "manager" doesn't touch/see any code at all and never impresses me with his technical insights. So other than hiring/firing and 1-on-1s I cannot see them doing anything which would justify the prestige and benefits.

Of course you can have the team lead do that, but they will quit in a month because they no longer have any time to write code or spend with the team.

> Sure having some understanding of software is helpful as a manager but IMHO this only includes skills up to the "mid"/"just after junior" software dev level.

I disagree. There is a lot of useful skills that a developer can pick up usually only after you are very comfortable with the coding and technical problem solving.

Ability to improve processes, being able to influence morale of your team, ability to think though a coherent strategy for what you are working on, handling emergencies, preventing emergencies, creating space for your teammembers so that they can thrive, teaching others useful skills, managing up, and so on and so forth.

> So if a senior software developer becomes a manager it's wasting their potential as software developer.

Sure. But maybe they can now "leverage" (building towards that bullshit bingo card...) their experience in a position that has more impact?

Absolutely. I have been in tech since the eighties and it’s remarkable to me how all the other skills that used to be necessary to create quality systems have seemingly taken a backseat to this skill. There are far to many developers with a severe lack of good engineering and troubleshooting capabilities nowadays…but boy are they fluent in the language de jour

Definitely seems a lot less clear cut than just practicing a language

To be honest in the last 10-15 years with the shift to Agile it really feels like the type of folks who become software devs prior to that shift represent about 15-20% of the new devs now. The rest are kind of just commodity devs. Give them good detailed requirements and they can churn out code. That 15-20% are the ones who can churn out something without a hyper level of detail or refined requirements.

As a tech lead / senior developer, you're very much part of the operational level, and your decisions are mostly tactical and working from an existing strategical framework which you don't control.

That changes when you move into a (mid) management role. You now have to come up with overarching strategems, long term vision, be able to form strong alliances, navigate political landscapes, know who will fight you and why they will fight you, be able to broker deals and understand how your stance on a current issue creates much needed leverage down the road.

Technical knowledge matters far less. Being prepared when going into a meeting room means knowing who sits in front of you, what drives their motivations, what they want / oppose, and having a deep understanding of what you can say, and - more importantly - how you are going to say it. People will try to get under your skin, not because they have a personal dislike of you, but simply because the position you were promoted / hired into may be perceived as threatening to them. You're skin needs to grow thick.

At this level, the people you're going to work with don't care how the pie is being made. They want to leverage software to act on their larger strategic goals. You will have to promote technology not just because of its merits for developers, but above all because of the value it provides to stakeholders. You have to find selling points that resonate with the stakeholders you're supposed to cater to. And you have to ensure you can deliver on your word.

So, how does this apply to software developers? When you're working at an operational level, dealing with day-to-day emergencies and issue queues, working with a small team of people, building / maintaining systems and applications,... you're not really exposed to all of the above. Your supervisor is supposed to shield you from all of this and defend the work you and your team is doing. When you move up into that (mid) managerial level, you're moving into a very different world which requires skills and experience you can't easily acquire on an operational level as an IC.

Now, that doesn't mean it's impossible to grow into that level. You're transitioning into it, right? Your being recognized for your skills, the experience and the perspective you've grown over the past two decades. The big challenge ahead of you is learning how to actively "let go" of that operational level and delegate anything and everything operational so you can spend your time advocating for the stakeholders you're supposed to represent.

However, making this career change isn't for everyone. Nor is it something that ought to be seen as a marker for "career success". There's a lot of merit in being a senior developer who is keenly aware of the decision making process upstream and how things move, so they can organize work on the operational level accordingly. And this includes taking the lead in making pragmatic technical decisions regarding architecture, incorporating technologies, programming practices, documentation, setting priorities and so on. This is what sets them apart from someone who's at the beginning of their career and still has a lot to figure out about themselves as well as the workplace and everything involved in the process of building software and delivering value.

A (really) good dev will recognise where strategic framework falls short or is non-existent and will be able to find a way to fix it. He will know that he needs to build trust and budget it to get the really important stuff done. For a good tech lead this is significant part of engagement as there is typically no other very technical person that would be better positioned to do it.

As a tech lead, for example, I am in a constant battle against complexity. Managers want to only add functionality, developers want to only add technology, and I try make people aware of how this ends if it is not supplemented with hefty effort to manage complexity. And this ideally ends in significant contribution to strategy if I can succeed or, if I can't, with inevitable problems later.

> At this level, the people you're going to work with don't care how the pie is being made.

They might not, but that does not mean that how the pie is made isn't influencing the outcome.

A manager that has significant experience with development knows how the pie is made and can be very valuable if he is able to use that knowledge for better outcomes. There is of course risk that the knowledge is misused (like people using certain solutions just because they are familiar with them and not because they are right for the particular situation).

This comes with some serious caveats. On an operational level, it is never your responsibility to "fix the strategic framework where it falls short". You're not expected to, nor are you incentivized to do that and you certainly don't have the authority to do it.

For instance, if you get inundated with deadlines and unreasonable requests, there's a handful of ways you could respond. You could go into crunch time / overtime until you burn out. You could draft a list of priorities and suggestions of a manageable workload and send it upstairs. You could even suggest reorganizing or expanding the team.

However, you can't hire someone new yourself, you can't ignore planning or requests, you can't decide from one side what kind of value the team is going to deliver. Why? Because you are subordinate to the authority of management on an operational level.

If you feel that shortcomings in the strategy of your employer impacts your work to the extent that what you do on a day to day basis doesn't align anymore with your views on how you want to contribute, well, that's a red flag.

> As a tech lead, for example, I am in a constant battle against complexity.

That's par for the course. On a fundamental level, you don't stand on equal footing with management. You can hope that your suggestions will be incorporated in the overarching strategy, but don't have the authority to actually make it so. At best, you may play your cards right and gain enough clout to exert influence from the sidelines.

That changes when you move into management.

As a manager, you will sign off on the solutions that needs to be build. You're accountable for the definition of the high-level requirements of a product / service, how it fits with available budget, how it matches with the envisioned value its going to provide to stakeholders. You might collaborate with experts in interaction design and design thinking to help guide this big-picture process. Depending on how much responsibility you're allotted, you may even have the authority to hire staff, organize teams, come up with your own projects and strategies and so on.

Being able to draw from your experience with the overall process of software development may help you in your estimations and the outcomes ahead. However, the usefulness of deep technical knowledge on a managerial level is very limited. As manager, the one thing you can't do is apply that knowledge directly on a day to day basis. That's where you are expected to delegate towards the team you're managing.

Indeed, having experience as a developer can even be disadvantageous. Your inherently biased towards particular tools and solutions and stepping back from them can be surprisingly hard. You also can't be overly sympathetic to the particular challenges faced by the development team. As an erstwhile developer, you might acutely relate to the pain of dealing with legacy and technical debt. But as a manager, you'll quickly find that you just can't afford addressing those as priority without potentially negatively impacting overarching goals, interests, budgets and so on.

One of the biggest challenges you will face is to unlearn to purely think from the perspective of a developer in the trenches.

Whether you like it or not, over the course of time, your technical knowledge will grow stale as technological progress replaces today's programming languages, IDE's, database systems, etc. If you keep on the managerial track, inevitably, there will come a day when you find yourself in a meeting with the next generation of developers and you can't readily bridge the gap between your and their technical expertise / perspective / knowledge.

That's not necessarily a bad thing, but you have to be mindful that becoming a manager implies that you're not a developer / craftsman anymore.

Hear, hear... oh. Here be dragons. A manager at each rung of the ladder who doesn't have insight into the technical constraints will over-promise and embellish things, and the least technically capable will do it with the greatest zeal. And the grunts will be left with an impossible task of storming a well-protected fort with inadequate support.

At a senior senior level, the focus should be on un-creating the organisation so people can focus on building the product. Stack-ranking in companies is brutal but might be kept alive because it forces re-creation of the organisation as 10% of it vanishes each year...

I think that separating "management" as something to do with navigating social politics as a separate skill is taking something humans do every day at the school gate or the football field and claiming it has special status - it gets more vicious and more consequential because of the money involved yes, so perhaps having specialists is a good idea, but from an organisational design standpoint it seems sub optimal

There are a few key outcomes needed

1. staff work 2. Policy decisions 3. resource allocation

1. is working out how the various pieces will collide (ie how long it will take to march x thousand people through various roads as a good example of army staff work). This is absolutely a job to be replaced with software. Then all that's left is the trade off in options otherwise known as

2. policy decisions. And this includes making policy on the hoof. That's fine but I think companies are going to become more democratic and much more obvious what policy decisions are being made and when - and that will take oversight

3. resource allocation. Where to spend the budget? And again this is mostly about staff work and policy

So i think the staff work (the helicopter view) will get commoditised, the policy decisions constantly reviewed and eventually replaced with democracy and frankly that's it.

What we will need is lots of administrators .. oh not that will be replaced with software ...

You only herd them when you want them to do something they do not understand or are not incentivised to do

Source: Currently trying to train a literal cat. And am a figurative cat myself.

My basic takeaway is that most jobs and businesses are terrible for society and badly organised and run. If a manager (investor / producer) wants to hire for that they need to pay well to herd cats

If they instead organise things well, and even have a glorious vision then cats herd themselves. Why is Tesla doing so well? Why was Facebook or Google great places to work?

But honestly, most businesses can be achieved without management taking over. A business is either within the phase space of engineering possibility or or is not - the electric vehicle was there and was so well recognised that Tesla actually got given grants by govenment to build it - a government department recognised what car manufacturers refused to see. One could imagine hundreds of engineers coming together without management to build that on some kickstarter like site.

My view is leadership is the least important part of a successful business and "management" is the least important part of leadership.

edit: i may be overly cynical and i really need to write up my thoughts more coherently

Leadership is the part of the company that decides what the company will pursue. Tesla started making electric cars because Tesla leadership decided to. When they started making the Model 3 or PowerWalls or rolled out the SuperCharger network, it’s because leadership decided to.

> and "management" is the least important part of leadership.

This part could very well be true.

yes, and ...

Look anything I say sounds like sour grapes but, honestly there were a thousand bloggers saying "someone should make electric cars", there were hundreds of engineers who had built prototypes in and out of major car companies. It was time. The technology was there.

Leadership is not posting a vision up on a site or sending round a memo (ie deciding to).

Leadership is having the capital in place (financial and reputation and network and that x factor), and risking it.

I am not trying to belittle the leadership - but I am trying to right size it. Without the climate, without the skilled engineers and the cash and the government support and so on, leadership is just prattling on HN comments.

You could pluck any fucker from HN and put them as CEO of any random tech company and their decisions would be within 10% of the original CEO.

The hard part is not leading. We already know where we are going. The hard part is not staff work. The hard part is inspiring people so they don't fuck off and join the other guy with the same ideas but more charisma.

Just like High frequency traders the CEO competition is other CEOs. And just like HFT the secret is not the special algorithm, it's just the doing of it that gives society benefit. And just like HFT there is a lot of sound and fury and we could probably get the same social benefit with a new market structure

Not so sure about this.

Usually part of the responsiblity of managers in software is making or at least guiding those making the bigger techincal calls that have long term and broad scope impact.

These decisons typically benefit from a pretty decent assessment of technical risk, which derives from both a good first principles understanding of a proposal, and probably moreso, lots of first-hand experience of similar things going wrong and right.

It's not a coincidence that top level tech management at most big successful software companies have deep technical skills and backgrounds.

For instance, if I have to talk to tech people about that aspect of a project I'm working on, if we're talking about technical risk, I should have some different perspectives from a senior engineer that will influence our back and forth. For example, it's common for engineers to switch jobs every year or two and knowing that means I would know to ask questions specifically about what our tech risk would look like if we don't update the stack/tools for the next five years (say if I know the exec team won't fund upgrades or the non-technical parts of the organization are resistant to change). Or if we'd be able to hire engineers to maintain whatever product in 3 years: Is it being taught? Are there enough engineers on the market with this expertise that we could replace someone if necessary? Can we AFFORD to? (Will the execs/HR pay for the expertise if it's a rare skillset?) Etc.

And I wouldn't consider myself qualified to manage a team of engineers; I'd expect more skills and insight from people who are genuinely qualified.

Same for being an engineer manager and individual contributor, tons of great programmers are horrible managers and vice versa

The key to a successful business is aligning incentives, make it so each skillset is rewarded properly for their contribution. Obviously a tough task. Most fail and great engineers have to become managers to make more money and it hurts both parties

Having a mediocre developer in that position will lead to all sorts of problems.

So managing technology means managing people.

And a tech lead is very much about directing people. You need to have a vision, inspire them, make sure everybody is making progress towards the goal etc. It's hands on and operational, but that's where collaboration between people is most important.

Becoming a specialist is very dangerous, as your future is tied to a product, and the products don’t love you back. Make the wrong choice and you’re managing a Starbucks.

I used to think that early on in my career as developer. At this point I believe those two are fundamentally the same jobs: gathering, processing and transforming requirements from one form & language to another.

_Maybe_ I could change careers and be an engineer and make as much of them, but I wouldn’t want to. I’m a manager because I like being a manager. It’d be a QoL decrease for me to be an engineer just for the money.

It can, managing is (should be) a collaborative effort. It only is a problem if the manager manages in a non collaborative forceful top down manner.

It's all a question about communication skills.

Like in some sports you will find top players earning multiple times of what their trainer earns, and potentially having enough influence to get their trainer fired. They work together with the trainer for optimal results.

Similar enough wealthy people hire fitness trainer, or people which manage their cullender, schedule, appointments and might even majorly decide career directions. And it still works even through the person in power is the person being managed.

Google translate says "cool calendar" which seems ... wrong?

But to your point, the lunatics always feel like they are the “normal ones”

Also, developers are often not skilled enough to hide their “lunacy” and they are sincerely open about it. Managers are more skilful at hiding malice, incompetence, pure wish for power, that makes them more harmful for a company.

What could go wrong?

Management of technical teams is not a one sided operation, it’s not us vs them. You are beholden to those you manage, as well as your leaders above you (actually, more so). Sometimes the motivations of those two groups can be seen to be in conflict. You have to be an effective advocate for both. The problem I have seen with many engineers who try to make that transition, is that they think they job is to be an advocate for their engineers they manage. They forget the other 50% of their job…which is the 50% that is actually the most important to their livelihood.