Hacker News Reader

Comment by dathinab | Hacker News Reader

> For example, people often assume that any talented developer will end up becoming a manager.

I believe this thinking is harmful for this Industry.

While there is some overlap between a manager and software dev they are in the end two fundamental different jobs.

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.

Sure as software dev you also need to have some resource management skills (some time management, and some potential team lead skills) but as a manger you need much much more of this skills and apply them in many more ways.

So if a senior software developer becomes a manager it's wasting their potential as software developer. Similar a excellent manager doesn't need _any_ programming skills, only some understanding of the programming job and it's hurdles (which might be simplest to learn by doing programming for a few years, but there could be much more efficient ways to learn this).

So IMHO if you want to go into the management path its best to start early on, and end up there around the time you reach a mid-level skill set or earlier.

Similar don't push senior engineers into management positions, being very good in one doesn't entail doesn't entail being good in the other.

Also please don't go around spreading bs like "if a older software dev isn't a manager yet they are incompetent and shouldn't be hired".

Our industry needs more old software dev, through only such ones which continue to learn and improve their skills. Not such ones which stagnated in the past.

View on HN

This line of reasoning is popular, but it lacks one perspective: people are social animals and many instinctively want to climb hierarchies. If you promote junior software engineers into management based on interest then a lot of junior hires will start manoeuvring for that, instead of trying to get good at their trade and proving themselves that way.

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.

> instinctively want to climb hierarchies

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.

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

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.

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

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.

In my (giant) company, it appears there is a bit more room at the top for managers, but in general leveling up is more difficult as there is an expectation that the amount of headcount you manage is commiserate with the level, so the optimal leveling progression appears to stay an engineer for as long as you continue to level up and then switch into management.

You meant "commensurate", of course, but maybe "commiserate" was a Freudian slip? I often look at people managing large groups if people and think, "that looks like (it's often) a miserable job". :)

None of the companies I’m at paid managers more than ICs level-for-level.

My company also has a level for level match, except there are far more managers than equivalent high level ICs, and even the generous IC tree ends far sooner than the management one does. If a manager is so inclined one could pursue an executive position, and I’ve never seen an equivalent for IC engineers.

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 there's a different problem.

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.

There's a different perspective, which is that there are different kinds of management. At the very least there's line management, project management, product strategy, business design/strategy, and operational/delivery strategy.

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.

Different kind of management = more management bullshit and ring kissing = less autonomy, more bullshit = developer attrition.

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

> There's a different perspective, which is that there are different kinds of 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.)

> "This line of reasoning is popular, but it lacks one perspective: people are social animals and many instinctively want to climb hierarchies."

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

At some point if you win the tournament you get a C suite job with a private jet and a massive multi million dollar department budget.

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

The wording is slightly negative, but it does describe that side of the role well.

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.

I actually believe that a small percentage of people want to climb the hierarchy. Based on books I've read, finding meaning in their work, either locally (how it helps the company) or globally (how does my work serve human welfare), is far more important for most people.

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 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.

> many instinctively want to climb hierarchies

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.

I do not agree. In most of the cases a manager sits in the right meeting at the right place and right moment where a critical decision has to be taken. Those moments are often the ones that will determine how a project will go. Having management skills and being able to understand the big picture from a technical perspective makes all the difference in such situations. While it's true that the set of skills are orthogonal I strongly believe that a "technical manager" , other skills being equals, will in average be able to produce better results over non technical managers. I am working in enterprise IT and I have seen many instances of "non technical managers" taking wrong decisions at the right moment just because of a lack of understanding of the possible consequences. Good technical managers are however quite rare because they need to combine two skill sets that are already rare alone. I believe that this is the reason why companies look just for "pure managers": for me it's more a matter of convenience rather than one of performance.

I kind of agree with you, but the problem is that "management" is often (very) poorly defined. Is it people or project management? It is often implicitly the two without much rational. Even considering project management the style can vary greatly between somebody concentrating on filling various spreasheets vs somebody pressuring others all the time about deadline vs somebody wanting to ensure engineering is performed and not just mere coding vs somebody having broad picture ideas for future dev.

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.

I agree that some titles could be changed not to have manager in the title and be a role instead. For example:

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?

I think the responsibilities of project coordinator / project manager can be a part of the work of senior IC (Principal Engineer) or someone like Agile Coach, Delivery Lead.

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.

Great reply, I sit in meetings and see management who have no technical clue making pivotal decisions, resetting timelines without consulting their Architects, and will decimate them with no mercy. Yeah, I’m a paper pusher now but keep my skills up at night by doing consulting gigs on the DL and swore when I got into management I’d stop these ignorant schmucks from making decisions affecting project and product success all while rubbing their noses in their idiocy. Publicly. Those decisions get reversed and they learn to consult with technical staff before opening their uniformed pie holes.

The most talented developers I have seen were highly-introverted intense guys. You know the type, it's like most of us only on steroids. They could probably be great architects but that role doesn't seem to exist anymore and wouldn't be on the managerial track anyway.

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.

Project management is quite often a major task of the team managers, especially if they span across multiple teams. You need to budget for the teams, arrange for the work to be roughly scoped further in the future than one or two sprints. You also need to balance things if e.g. new people are hired, or teams are split etc. You are not an individual contributor anymore.

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.

(BTW I am 40, have been working as dev for the past 21 years and I am now transitioning to my first non-development role ever after working as tech lead / senior dev for over a decade)

> 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?

> For me ability to code (like knowledge of programming language) is a necessary but relatively minor ability of a good software developer.

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

What is the best way to develop engineering & troubleshooting capabilities?

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

I think to a certain degree it’s just an innate capacity for creativity coupled with logic that gets refined in practice. If you don’t have those core components in you you are pretty much at a disadvantage to develop them.

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.

I'm 40 but I've been on both sides of the aisle. It's not just moving from a "development" into a "non-development" role. You're basically moving into an environment with very different incentives, interpersonal relationships and so on.

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.

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

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.

> 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.

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).

> 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.

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.

Just wanna say, as a self-taught developer over the past few years who _might_ go into a leading role, this thread is pretty informative. Thank you.

I think that the "politics and strategy" level is over-played. It exists, but it is not essential to the creation of a product - it is a consequence of the creation of an organisation to create the product.

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

I am very very negative on "management" as a skill in the software world.

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 forgot herding cats. Good luck automating that.

Cats respond to incentives.

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

Cats often value their autonomy and sense of mystery over any particular incentive one can offer.

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

You are probably easier to train than your cat!

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

> My view is leadership is the least important part of a successful business

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.

>>> When they started making the Model 3 or PowerWalls or rolled out the SuperCharger network, it’s because leadership decided to

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

Different people have different incentives. No, throwing money at people does not solve every problem.

> this only includes skills up to the "mid"/"just after junior" software dev level

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.

Is that true? In the companies I have worked for, the technical risk assessment and everything related to “is this a viable tech solution” is done by senior engineers. Managers barely limit themselves to agree with what senior engineers say.

Yes, it is. A lot of companies run like you've seen, but that's not how it should be.

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.

In most companies this is something that is delegated to either the team lead or the tech lead (formal or not)

It is true but just like others said, if you don't have ambitions, the junior developer you train will quickly become you boss, have more pay and manage what you do or can't do (and possibly have the power to fire you too).

I'd compare it to sports, there's a bit of skill overlap between playing ability and coaching but not much. The majority of great coaches were fairly average players, the majority of great players fail as coaches.

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

Exactly, it's like saying talented artist end up becoming Museum Managers.

very very few developers do the kind of work that can be compared to a talented artist.

Talented developers.....it was a example, is it hurting your feelings?

I don't quite agree. Managers will be the ones assessing the devs and making all sorts of decisions as to the overarching architecture or the software development process.

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

You assume this is the case everywhere, in many organization managing people and managing technology are separate jobs. Managers have no say in how the architecture looks like, and very little to do with how SDLC looks like (outside maybe getting rid of organizational impediments or suggesting some other approaches to planning)

Technology is actually made by people (who would have thought!)

So managing technology means managing people.

There's a fair bit of difference between being a line manager and a tech lead. You do have a noticeably different dynamic.

In many organizations the line manager is the tech lead (at least at the lower levels of the hierarchy). Having a separate leader and manager is only useful if you aim to create a barrier between technology and the business, which is typically not a very healthy thing if you're a technology-driven company. Nevertheless it's a common practice in places where technology is just a supplier servicing the business.

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.

It may be harmful for the industry but good for the individual.

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.

Nope. Starbucks won't hire you without restaurant management experience. You'd be lucky if they hired you as a barista.

Without coffee making experience you'd be lucky to get a toilet cleaning job at Starbucks.

So I have seen another slightly different angle to this (and this applied to me). As companies get bigger org boundaries are a real thing. Engineers who prefer breadth (I contributing across the stack and boundaries) are stymied. And making this kind of impact is really hard unless you have a high enough title but getting there needs a lot of political maneuvering. For these engineers who are more driven by building vs impact management starts to look appealing as side projects may start offering more excitement and challenges than yet another crud service.

https://en.wikipedia.org/wiki/Peter_principle

>While there is some overlap between a manager and software dev they are in the end two fundamental different jobs.

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.

the program coming when someone who makes less money than you is managing you , doesnt really work. So managing is like a reward.

Just have your staff+ engineers report into directors and VPs rather than line level managers.

You need a line level manager to insulate the suits from developer lunacy.

More other way around

There's a reason good line level managers get called shit umbrellas for the team.

Been on both sides of that line, in my experience there is FAR more lunacy among the development folks.

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

It is often expected to be defined in the expectations towards engineers at Staff+ level that people on that level are good at communications and can balance technical and business points of view.

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.

Yes let’s fire all management. Remove all that harm from the organization and put a bunch of lunatics in charge who all believe without a shred of doubt that they are the smartest person to ever walk the earth.

What could go wrong?

I did not suggest to replace managers with engineers, just give an opportunity to work and be represented on more strategic level to some engineers. It can be seen as a good career progression for ICs.

There is always an assumption by engineers (especially folks early in their careers) that management is somehow “easier” and therefore it’s an easy and a reasonable career path for folks in engineering to have available to them should they choose it. It’s not easier, it’s simply different, and in many ways much more difficult. I have seen a lot of folks try and make the transition and ultimately either fail or spend a lot of time as terrible managers until they develop the skills to do it.

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.

> makes less money than you is managing you , doesn't really work

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.

Is that a मस्त कलेण्डर ?

Haha qalandar has a few different letters but I still chuckled

What is a मस्त कलेण्डर?

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

Are you a Qawwali fan at all?

https://youtu.be/v38w5djsbXM

Why? I make less money than every single one of my staff. I’m an EM, I manage 9 engineers, and never once has the fact that they make more money seemed relevant.

_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.

Reply on news.ycombinator.com