Hacker News new | past | comments | ask | show | jobs | submit login
If management isn't a promotion, then engineering isn't a demotion (charity.wtf)
186 points by joeyespo 4 months ago | hide | past | favorite | 125 comments



This is great in principle, but it’s only a starting point - there are huge issues that are left unaddressed.

The biggest issue is that it presents status as if it can be conferred independently of power, or as if we can change the dynamics purely by changing the way we think about this.

Managers have power for many reasons - they generally do have a significant influence over subordinate’s career prospects, and they have access to all kinds of organizational information that ICs simply can’t obtain, at the very least because they can usually spend time in conversation with other managers or in meetings with people at higher levels in the organization.

Engineers obtain power through indispensable or highly valued domain expertise or institutional knowledge.

Both forms of power are real and confer status.

If you move from management to engineering and your power as a manager is not replaced with corresponding power as an engineer then you have been demoted in status, irrespective of how the organization claims to value people.

Organizations that want to deny this, even with the most positive intentions end up gaslighting their employees. I.e. saying things like “Our organization doesn’t see these moves as a demotion”, when manifestly the individual’s power and status has changed in a way they and everyone else can directly perceive.


ICs largely wield informal power within organizations, managers have real formal power, codified in organizations charts, rules and regulations. Whenever there is conflict between the two, almost always formal power wins over informal. Not the least because managers control salaries and hire/fire decisions.


Agreed, although on top of that there is usually an informal power structure within the formal one of the management hierarchy based on who is favored by those above them at a given time.


The key for those with informal power is how to leverage it to leverage the formal. Get managers to trust you, and you can have both.


That's still nowhere near the power of official management.

At a bare minimum a manager can summon their underlings, they will come and listen because they depend on him for promotions and have to make a good impression.

Try to get your teams or coworkers to do some tasks as an engineer. You will quickly realize you have no power.


I mean, this varies team by team and company by company. To spit an anecdote into the bucket, I asked some teammates to help me take care of a problem, and they did - and I don't think I hold a particularly large cache of informal power.


Send a meeting invitation and see how many people show up. Preferably a videocall or a presentation, something not too attractive to come to.

Then do the same thing as a random employee. See the difference in how much of your team doesn't show up and absolutely nobody from the other team across the corridor comes.


> Then do the same thing as a random employee. See the difference in how much of your team doesn't show up and absolutely nobody from the other team across the corridor comes.

And then do it not as a random employee, but as the senior employee who isn't technically anyone's manager but who is known for having saved the last 3 major projects by pointing out pivotal details and coordinating with other teams, and observe that everyone who's worked with that person shows up regardless of the org chart. YMMV, but let's compare apples to apples.


> and observe that everyone who's worked with that person shows up regardless of the org chart

Too bad it's only a handful of people.

Well, maybe less than a handful because most of the people you saved in the past 3 years have moved on to another company or another role. They're not here for you anymore.

However the manager got that power instantly since the minute he joined, by virtue of the position. It's not an apple to apple comparison indeed.


It's strange when one has this power, and managers do fear it. They learn to set expectations and modes of engagement with senior ICs.

What's really fun is when you can make a bunch of managers super nervous by mentioning "You know, we should re-org this." and this can trigger all sorts of shit.


Uh, I can't say I've ever had this happen to me as an IC, even when I was brand new. Maybe one or two people will decline, but it's almost always because they just have a conflict or something.

What you describe sounds totally dysfunctional. If someone is calling a meeting, I assume it's for a good reason from their perspective (even if I think the assumptions they're making are dumb or something).


If the invitation has no other context, I would PM the person calling the meeting asking what's going on - whether they're the newest hire, or the CTO.

If the meeting is something where I'm needed, I'll attend, whether it was scheduled by the newest hire or the CTO.

If it's not, I won't, etc., etc.


The manager's job is to communicate necessary information to the whole team. The IC isn't. If a manager starts abusing that presumption to schedule irrelevant meetings, people will respond appropriately.


or, worse, if the senior IC doesn't show up, then no one takes it seriously.


Exactly. We've gotten rid of managers or created brand new roles in order to retain key engineers. Managers are often easier to replace than these engineers.

If you're an IC that is providing clear & visible value to upper-management you likely wield more power than you think.


The opposite of that is more common I think, and really pisses me off. More often, I think, upper management will protect the lower managers and side with them whenever there's a dispute with an IC, even intentionally pushing the IC out.

My assumption is that upper management doesn't want to admit they've made a mistake in hiring their subordinate managers. And all of this just goes to reinforce the existing power structures.


> My assumption is that upper management doesn't want to admit they've made a mistake in hiring their subordinate managers.

Avoiding situations like this is why we praise failure. When someone says “I made a mistake, this is what I learned, and this is how I will avoid making the same mistake” I give them much more respect then when they are just accepting bad outcomes.

Edit: And when I work with someone for longer than a year and they haven’t claimed any failures I assume they are either covering them up, not noticing them, or not engaging in risky enough behavior.


In other words you are asking to suck managers dick irrespective of your skill set and work ethic.


Managers win in the short term. In the long term, the winner is _usually_ but not always, the person who was right.


Hard to get to the long-term if they fire you.


Mangers are officer class, in charge of strategy and punishment/reward, seniors are NCO class, in charge of tactics, execution, and frontline people management.

Managers should also be in charge of morale and motivational management. Some understand this and are good at it, others don't and aren't.


In my experience at non-FAANG organizations managers are people who don't have the capability to code and they barely managed to survive so far.


I think the focus on "managers have power" is overstated. Places I've worked (as both an IC and a manager) there's also greater responsibility and higher ups hold the managers much more accountable than the ICs. I know many people who simply do not want the responsibility or accountability. Maybe the work is not better or worse, easier or harder, but often there is more pressure/stress.


> managers have power

Respect, too. I've lost count of how many times I've been stuck waiting for somebody in the network group to grant me access to some resource I need to do my job until somebody that they actually respect (that is, a manager) tells them that they have to.


Isn't this normal? If they're not your manager, it's not their job to make sure you can do your job.

Though arguably the manager should have arranged for an easier process if this happens more than a few times.


Too much bureaucracy for access to internal resources (api access, repository access, requisition of servers, google doc permissions, w/e) slows down ICs and is a sign of bad corporate culture.

There’s a difference between needing to ask for access to shared resources and asking for someone else to do work. So many corporations silo there teams so deeply that PRs from outside members aren’t even considered. Collaboration isn’t given anything more than lib service.


If a company gets too big, they have to start worrying more about internal adversaries. That's why you see those kind of things.


Nope. Those kinds of things are almost entirely related to control and power, not real security.

If you're legitimately concerned about internal adversaries you start by finding and catching them. Once you've set up effective mechanisms for doing that you can start to introduce stricter controls around sensitive data/operations based on what you've learned about how your internal adversaries operate. You use a light touch when doing this, because you understand that every extra control you put in place introduces inefficiency into the organization.


totally agree. See my other post here.


At lower levers in the engineering ladder, I'm OK with that. I mean, if you're a junior engineer, your job is to do whatever your manager has directed you to do at that moment. But my current rung is staff engineer, and my job is to move the whole company forward by finding sticking points and unsticking them. That doesn't mean doing people's work for them, but very often does mean making sure other people aren't blocked while they wait for something to happen.

I feel like at very senior levels, you can't really say "it's not my job". You're looking out for the whole organization, not just your direct team, and it's your responsibility to help everyone move ahead - even the ones who don't report to you.


> If they're not your manager, it's not their job to make sure you can do your job.

If their job is to manage access, it slowly morphs into "controlling access" and then "wanting justification in granting access" which is not the same thing. There's no benefit to someone pointing this out for a long time. Eventually (hopefully) this perversion is identified as the cause of why processes went from efficient to gridlock, grinding a large company to a halt.


> it's not their job to make sure you can do your job

If they're on the network team, it's literally their job description to make sure everybody has the network access they need.


Sounds very familiar...


> Maybe the work is not better or worse, easier or harder, but often there is more pressure/stress.

None of these are directly relevant to the power imbalance.


They should have more responsibility and be held accountable. When managers have narrow authority and are not honestly measured its a bad scene man.


IC = individual contributor. I was trying to figure that out till they defined it halfway through the article.


Thanks for that, I had seen the same acronym on that article from today of a (I think former) Salesforce staff engineer describing her experience there, and of course that I didn’t know what it meant.


I remember when we started using it at work, was the first time I'd seen the term, and then seeing it everywhere esp. on HN.


In my opinion the best way to deal with the issue of hierarchy would be to make management an assignment, not a job. Someone takes on the role of "manager" for an upcoming project, at at the conclusion of that project they go back to engineering.

Apparently this is how Valve does things. I've heard Gabe Newell say in an interview (that I can't find right now) that often times the management role is given to the newer employees. They see it as a big honor at first, but by the end of it they're pretty happy to go back to engineering and let someone else deal with the responsibilities of management.


Maybe this is why Valve can't seem to actually finish a project to save their lives at this point!


They actually have admitted that that's an issue, although I'm not sure what they did about it. Recently they shipped the Valve Index and released Half Life: Alyx, both of which are excellent. They also released Artifact (it did terribly, but they did release it), and a UI overhaul for Steam along with a lot of new features. So in recent years they've been doing fairly well I think.


That's project management not people management. Very different and not a senior role.


I think one thing that's missing from this article is what engineers at higher levels of IC status (up to VP) do. When a Sr. Engineer is choosing between a Manager and a "Principal Engineer" type role, I have to remind them that PEs also don't do much depth coding. They write proposals, discuss architecture, sit in meetings. Ultimately, the same mechanisms that Managers use.

There's certainly SOME PEs that go deep in some areas but the majority I've worked with are broad owners of technology in large organizations. The difference between the two roles often has to do with what balance of time you want to spend influencing others for broad goals vs. building up jr. folks to accomplish your team's goal.

In either case your authority is derived from whether people "under" you want to work with you. People who can't get a set of people to go a certain direction won't last long in either role.


This article was on HN yesterday and I like the way that four different types of staff engineers are described:

https://news.ycombinator.com/item?id=24437715



One fix could be to give managers a title that is of lower rank than an engineer e.g. a manager’s official title should be “support” and ensure that every part of their role is about supporting the engineers they are responsible to.


That kind of reminds me of how military dogs usually outrank their handler: https://science.howstuffworks.com/military-dogs-outrank-hand...

I've heard that if you abuse the dog, you can get charged with assaulting a superior officer.


I like it! "Team Support" would be the perfect job title to really drive this home


You also need to fix the decision making. Why are we letting important decisions in the hands of "support" people?


Because most engineers don't want to spend 6 hours a day in meetings to sync up with the rest of the org and get all the proper context and figure out politics and learn intimate business strategy and so on. Moreover decision by committee tends to not lead to the best results which means you in the end need someway to force a decision that not everyone likes.


Or give them a title like “collaboration engineer”


I wouldn't give anyone in management the title of engineer, just for the sake of clarity to external collaborators


Agreed, there has begun a huge overuse of the term engineer recently. It used to mean a person who made/built the adjective in their title. Now, sales people, recruiters, etc are all becoming engineers, it's becoming to tech what VP is to banking.


They're promotions if you get paid more. They're demotions if you get paid less.

People refuse promotions all the time because they don't want the role/responsibility and prefer other stuff besides money. Doesn't mean it wouldn't have been a promotion.


You get more power as a manager because you have influence over engineers and their careers, even the ones that get paid more than you unless they have been with the company for a long time and have built relationships with the higher ups.


If your compensation isn't higher when switching ladders, then it doesn't matter how much influence you have. It's a demotion.

To be clear, that's not necessarily bad.

Imagine your boss coming to you to congratulate you on your promotion, and then mentioning that your pay will be reduced by 10% because now you're management. How'd you feel about them calling it a promotion?


And more access to bonuses and equity (typically).


> People refuse promotions all the time because they don't want a major change of role/responsibility for a 5% raise.

There. Fixed it for you.


It doesn't matter how you define what is or isn't a promotion.

The real issue is that there isn't one, single right answer about what role is right for everybody.

It is not the case that being a manager is strictly better in every way for every person. That's the assumption that people need to let go of.


> That's the assumption that people need to let go of.

Its not an assumption, its a fact that managers everywhere on average get paid more than IC.

Unless you are working for a non profit or some cutting edge change the world stuff. Why would you work for less.


> Why would you work for less.

Because I am more than comfortable on my engineer salary and being a manager would make me miserable.


Sure but by that logic no two jobs can ever be compared to each other. Someone can always say because I am comfortable doing X than Y, thats not something anyone can respond to.


Seems like people instinctively associate status with having control over other people. Maybe engineers could fight back by calling their programs cute names or putting hats on servers? Cloud computing is not helping though.


One further complication is when a move back to engineering is coupled to a change in employer.

As an interviewer, seeing somebody whose last job was in a management role apply for an IC position is a warning signal for me. Do they just apply for that position to get a foot in the door (especially for a move to a FAANG), and will they immediately angle for a move back to management?

So this is generally an area where I would ask follow up questions (and probe a bit harder in the technical interview, to assess whether any rust has crept into the technical skills). It's not an automatic red flag; we've hired former managers for IC roles and it worked out, and leadership ambition can be a positive in any role, but it's worth some exploring.


> The work done by a database engineer is different from the work done by a VP marketing, or a director of database engineering. It is not inherently better or worse, easier or harder, more or less deserving of praise and admiration. It is simply different.

The big problem is that it is the VPs and directors who are getting together and deciding what everyone should be paid. And, lo and behold, somehow, they almost always decide that VPs and directors should get paid more than database engineers.


I disagree with the quoted statement, and my disagreement leads to your conclusion as a consequence, but not as a problem.

Leaving aside whether the different positions are better/worse, easier/harder, etc, the higher you go, the more influence your decisions have. The engineer, if he does his job well, might be responsible for a few features and best case, be responsible for part of the revenue, and worst case, waste the time of a few engineers. The director, being responsible for perhaps a whole product, is responsible for a large portion of the revenue, and can waste the time of several dozen people if he doesn't do his job right. The VP, responsible for lines of products, can waste the time of hundreds of people. And so on up the chain. As an engineer, implementing the wrong feature probably won't get you removed from your position. As a VP, choosing the wrong product line can definitely get you removed from your position. And this is in addition to the increasing need to be able to negotiate with internal and external stakeholders to get increasingly larger scope of things done the higher you go. It's high stakes, high reward, and that's why the compensation is higher for those who can demonstrate that they can make a significant dent in the bottom line.


> As a VP, choosing the wrong product line can definitely get you removed from your position.

In theory. In practice they'll blame someone else and use the information they control the flow of as proof. Politics matters more than ability to improve things overall. The Director who gets promoted is the one who saves the VP's backside in the previous example and not the one who increased revenue five fold.


This is why VP's own P&Ls. It doesn't matter if it's someone else's fault. You own the P&L and it's your job to fix it.


I've been the Director. HR mostly sets salary bands. The recruiter, candidate (via negotiating), and hiring manager can only really move around within those bands. Those bands are largely based on market research.


Eh, market forces are more influential than this. You can't simply decide how much to pay engineers, any more than you can decide what your rent is going to cost.


The rule of thumb is “the closer you are to the money, the more you make”.

People rarely demand what they are worth since they usually value security over maximizing income, but if you are familiar with the numbers, then you are in a much better negotiating position.

People should always keep applying to jobs, even if they don’t intend on accepting them just to keep a pulse on the value of the labor they are selling.


The supply of database marketing VPs seems harder to define than the supply of engineers who could build production features in large database projects. In particular, the former seems a lot more easily manipulated and dependent on who existing VPs consider qualified.


There was a whole scandal about this, wasn't there?


I am sure this is going to sound silly, but I honestly still have trouble figuring out what value is contributed by managers and executives at all.

I can't get past the gut feeling that essentially the model hasn't changed for thousands of years: wealthy owner, boss with whip, wage slaves being watched over.

I mean I imagine a group of people who are actually competent and intelligent working together. Some people would have more seniority and power, but everyone is actually a useful worker there involved in the day-to-day work.

I feel like most managers I have had have spent the majority of their efforts trying to pretend that problems don't exist and reduce the amount of actual useful engineering work in order to push _anything_ out faster and cheaper. Or just basically telling people to hurry up.

That's why I think we had the Boeing crapshow. The guy at the top was actually good at doing what management actually is for most companies, like I described above. He avoided doing real engineering and got a product out. And then hundreds of people died. And still they tried to blame the engineers.

It actually comes down to a class struggle for me. Parasites without integrity have managed to work their way to the top while feeding off of the honest workers below.

Sorry I know it's kind of extreme but I am just being honest.


You need management because:

- you need project management. It is an administrative work.

- you need people management. You can leave that to HR, they will do a very poor job, so it's better to have a person from the team fill that role, the more senior and experienced the better. This is admin work

- you need to simplify large organizations into smaller, manageable teams that can focus on items they can swallow. You need team leaders (for the 2 reasons above) and good communicators to keep the team in sync with the rest of the company

- when you have many teams you need "teams of teams", that is one or more management levels.

In any army you don't have management, you have a chain of command. You have generals with a strategy and a vision, you have officers that lead portions of the army, you have NCOs that lead small teams and you have specialists or riflemen that do the grunt work. They all have a role and in most cases you find the higher the rank, the higher the competence, otherwise nobody would follow in battle an incompetent officer (or even shoot him in the back, it's easier in a battle than getting rid of a bad manager in the office).

This hierarchical organization came from real needs and stays there because the need is still there. You can argue some hierarchies gets corrupted, in theory all do, but a hierarchy is generally better than no hierarchy whenever the group is large enough.


Tangential on hierarchies and meshworks by Manuel De Landa: http://netbase.org/delanda/meshwork.htm "To make things worse, the solution to this is not simply to begin adding meshwork components to the mix. Indeed, one must resist the temptation to make hierarchies into villains and meshworks into heroes, not only because, as I said, they are constantly turning into one another, but because in real life we find only mixtures and hybrids, and the properties of these cannot be established through theory alone but demand concrete experimentation. Certain standardizations, say, of electric outlet designs or of data-structures traveling through the Internet, may actually turn out to promote heterogenization at another level, in terms of the appliances that may be designed around the standard outlet, or of the services that a common data-structure may make possible. On the other hand, the mere presence of increased heterogeneity is no guarantee that a better state for society has been achieved. After all, the territory occupied by former Yugoslavia is more heterogeneous now than it was ten years ago, but the lack of uniformity at one level simply hides an increase of homogeneity at the level of the warring ethnic communities. But even if we managed to promote not only heterogeneity, but diversity articulated into a meshwork, that still would not be a perfect solution. After all, meshworks grow by drift and they may drift to places where we do not want to go. The goal-directedness of hierarchies is the kind of property that we may desire to keep at least for certain institutions. Hence, demonizing centralization and glorifying decentralization as the solution to all our problems would be wrong. An open and experimental attitude towards the question of different hybrids and mixtures is what the complexity of reality itself seems to call for."


[Assuming good faith despite some inflammatory language.]

In smaller teams everyone talking to each other and building a shared vision can be quite sufficient. It's indeed common to have startups that have very flat organisation, they might have a designated CEO that's in no actual way above the others. They can be plenty capable of producing amazing results despite the small team size.

However such a small group can't handle larger challenges, like designing and building a commercial jet, they will need many more workers. 1000 workers can't just come together and agree on a shared vision, even ignoring the square law of communication paths just giving each person 10 minutes to present their view would take weeks. Hence, in the very least we will need some communication hierarchy to allow workers to do their job while still synchronising with relevant other teams.

However, just communication is not sufficient, coordination is also important, if the jet is going to have the appropriate range, fuel tanks, engine efficiency and packing density needs to be designed to provide that range. Again, this would take quite some time if everyone should be involved in the process.

This is mostly in the leadership side of course, but covers those who are attentive to the trade off between security and deadlines. It's not reasonable for the individual engineer to be solely responsible to make that tradeoff. In particular, a sloppy engineer might think security is not important at all, and another engineer might think that no risk at all is acceptable to the point where nothing can ever be produced to achieve their standards. It's leaderships role to make sure that standards are aligned between engineers so we don't get a ten year delayed jet with some key parts made out of brittle plastic.

Now, managers can also have a people management role, and tom me those are the ones responsible to keep me as a worker happy and productive. They are also there to detect when some area is understaffed and find solutions to such issues, eg. talking with other teams for assistance, recruiting, decreasing scope, etc. If they weren't there, this job would fall on each individual worker, who would have to go out hunting for support instead of focusing on their actual tasks at hand.


I did not say it had to be flat. I said the people making decisions with power should be involved in doing real work solving problems (such as engineering).

What the Boeing leadership did (not an engineer) was actually to insist that the engineers NOT engineer a new aircraft meeting the new requirements but instead to kludge together something with the minimum changes based on the outdated design so that they could save money and avoid thorough testing.

The reason I use strong language is because the extreme failures of leadership dictate a realistic and honest and strong reassesment. The part that was inflammatory was when those outdated aircraft with oversized engines crashed into the ground and killed hundreds of people.


Interesting to compare this with practices in other professions, eg Doctors, Architects, Scientists and so forth.

Certainly management happens in those areas, but I believe that as your career progresses you would naturally be expected to take on more management activities - there isn't a dual track in quite the same way.

In more recent times the waters appear to have become muddied somewhat, with the appearance (and glorification) of administrators, project managers, 'CEOs' of various kinds.


Most of those people are independent entrepreneurs or senior ICs, not managers.


This reads more like an attempt to extract “powers” that managers have and give them to staff / principal engineers, but I think this is a bad mistake.

The people in those roles should influence those things, sure, but not “own” them, under some faulty idea that management doesn’t lead or own strategic and technical roadmaps or execution.

An engineering manager is someone who takes inputs from their immediate team or staff, as well as cross-functional stakeholders like product managers, directors, staff/principal engineers, and more. Then you synthesize that into team or org investments: projects, roadmaps, staffing, resources, tools.

An engineering manager is not someone who “just executes 1-1s and fills out HR feedback cycles.”

They are more like a staff engineer or architect who takes an expanded point of view to include team dynamics, career growth, budgets, strategy and resources into the solution design process.

This often just is a promotion above staff or principal IC roles because it usurps and supersedes a lot of that work while also involving additional new work managing career growth, hiring, training, resource investment, etc.

I’d put product manager and engineering manager at the top of the promotion pyramid (excluding director / VP / executive roles). Staff and Principal ICs are next, then the rest of ICs.


If one group has firing power, and the other does not, they are not equal, regardless of what's written down.


It's not that simple.

First line managers rarely have the power to simply fire on a whim. There has to be cause, and it needs to be evidenced, and there will be multiple people involved in the decision.

If you're a more senior engineer, you may report to a manager of managers, and line managers may be your peers organisationally, and probably not paid as well as you are.

Engineers also get to make a different kind of decision to managers; and it's often the longer term, higher leverage, more strategic kind of decision. Line managers are much more operationally focused and rarely have the bandwidth or tasking for strategic decisions.


Managers do have some formal powers engineers don't. They are three: they have access to budget; they perform the management function which assigns resources to problems. Since demand on resources almost always exceed available resources, they must assign priorities well. They also have high input on hiring choice.

Doing this well requires,

- requiring internal service suppliers to be (internal) customer driven. Too often however things we'd never put up with an external supplier we'd pay money for are tolerated and even protected by management. Internal suppliers are required for use. It's hard to fire them.

- cross functional management: reduce silos. Again my area and your area might be "clean" but users of both of our services are often left to die in the crummy alley way between our groups. That's a major source of frustration for engineers.

- promote openness and honesty: there's too much happy talk and PC correctness at the office.

- supply chain management: engineers are often confronted by too many point solutions that don't integrate. See above points. Managers need to cull and combine supply chains time to time.

- be customer in not supplier out. Older companies often have organizational norms where what can be produced is more a function of what internal politics allow or company culture tolerates than what customers want. Managers need to be on top of this.

- top management needs to give TLC to middle management perhaps the toughest job. Here they (middle mgmnt) cannot micromanage while they are held accountable for broad corporate goals like lean organizations, top line growth, reduce expenses, and better expense control. They neither are hands on nor are too far from the real work to be too abstract.

- teamwork (see schutz's human element the best single read on this) namely that ridgid individuals are the single fastest way to break teams. Today's work depends more than ever on good teams.

When managers do above well it's a pleasure to work with them. It's a difficult task.


If you think there are a lot of bad managers now wait until they're explicitly paid less and aren't accountable for their team's impact (what happens when you shift all accountability of technical strategy to TL).


Solution: take away some of the formal powers of management - for example the ability to assign resources on personal decisions. A manger wants X to happen so spends Y of her budget to hire a team to do it.

That is power.

Simply make all such decisions open, transparent and democratically elected - in other words have employees vote.

We live in a world where we value democracy but spend our working lives in autocratic dictatorships.

Yes Coase and efficient allocation, but really I think information revolution is changing that equation.

Democracy in companies now! Struggle brothers !


I upvoted you because the point about spending our working lives in dictatorships is very valid, but I don’t think for a second that voting would work.


But ... let's look at GE.

It's basically worth nothing at net now. And it was the great poster child for brilliant management decisions - that take any industry and run it using GE managers and allocate capital the GE way and it will win.

Turns out not so.

This is the lesson of history - great Kings and Emperors really do make great world beating decisions. But anything less than great leads to disaster whereas parliaments don't do great but they do keep growing and managing well for centuries.

We need to stop relying on great CEOs and kings and look for ways to run a company well.

PIRC has lots of research on the central founder risk to long term value.

but just ask this - imagine Elon Musk retires tomorrow. Do we want to hope we hire his clone or do we want a strong driven community of engineers to keep knocking out battery improvements for 2 decades.

I know which one i want my money in, and which one will make better headlines.


Everything you just said is fine, however, nothing in your comment in any way suggests or supports the idea that voting would work.

Agreeing on a problem is not the same as agreeing on a solution.


Ok - so we agree on a problem.

Just to ask, what solution have humans found to replace dictators and kings apart from (weakly or strongly) elected parliaments ?

Rome had two consuls (or three), but I am not sure that's a big step beyond one.

I just think we need to find the right ways for democracy to evolve not just chuck it in the bin :-)


Again, no argument from me, but also no argument from you that direct democracy would work as a form of corporate governance.

Can you find even one example of where it has? The closest I am aware of is Mondragon, but Mondragon has almost no direct democracy - voting is for people rather than decisions.


As a brit I have recently learnt to be wary of direct democracy (ala referendums) but frankly I will take any form of democracy as a bastion against the mono-culture.

Perhaps we can take heart from the media - https://www.ft.com/content/afe3386e-d3bb-11e4-a9d3-00144feab... - The Guardian's editor was appointed following an indicative vote from staff.

But I would suspect that appointed leaders and elected policies will be a much easier sell than the other way round. Any leader can happily say they always agreed with a policy forced on them. It's much harder to say you agree with them firing you.

And I shall have to do some more research. Thank you for pushing


One argument would be that working for a business and not finding another job is inherently vote for the leadership.


That sounds rather weak - the fact I have not left the country does not imply I have voted for Boris Johnson as PM.

Although Trump could then claim that 11M card-less Mexicans who have not left the USA in November were actually voting for him, which would give him California in the Electoral College.

In the end I do not see a way to imply someone's vote - one needs to actually count their vote in the normal way.

I respect your position but I remain convinced that some form of democracy is needed in corporate life.


You must realize that leaving the country is not even remotely comparable to changing job. My argument may be weak for some other reason but this is not a valid one.

It’s also worth mentioning that there are democratic workplaces.

They are called cooperatives.

Another example: https://en.m.wikipedia.org/wiki/John_Lewis_Partnership

Relevant questions seem to be - why are they not more successful or widespread?

Also, have you considered working for one?


Yes good point on the co-op.

Relevant questions seem to be - why are they not more successful or widespread?

The co-op store (similar food john lewis) sprang from the mid victorian co-operative movement where different models where tried out by wealthy philanthropists who essentially gave back huge amounts of their wealth to their workers

I think that last sentence shows why it is not more widespread - perhaps we simply need to force companies to become co-op/ partnerships at a certain state of growth?


By last sentence - you mean where I ask whether you have considered working for one?


Ok second to last :-)

But this seems interesting for the actual last sentence

https://electricembers.coop//pubs/TechCoopHOWTO.pdf


This hit close to home.

A manager at a previous company kept saying that his role was to support engineers and that management was a separate track, that he wasn’t my superior (probably from some internal training BS). He acted completely the opposite way. He obviously wielded more power by having more information, and, to add insult to injury, played tech lead as well.

Suffice it to say, over the years almost all the original ICs have left his team, and he’s still wondering why he can’t get the team to run.

Good riddance.


Does anyone do the pendulum? How well does it work?


I've gone from IC to Manager and back a couple times. The first time was becoming "manager by default" in a growing startup. I then moved on to another startup as a tech lead, became "manager by default" again, and eventually VP of Engineering. That startup was acquired and the teams dispersed, and I eventually ended up back in an IC role (which, despite assurances from my boss, ended up being a demotion resulting in lower bonus and reduced stock awards).

I sucked it up and worked as an IC for while and realized that, after 20 years, I have little interest in writing code for a living any more. I truly enjoyed the strategic and personal growth aspects of managing, so I left that company and have only taken manager roles. I find managing to be much more stressful, but supporting my people through these trying teams has been a highlight of my career.


I've done it. Like many people, I moved to the management track when my first kid was born. I realized that moving up as a manager required actually competing with the other managers and being better than them. It wasn't going to happen. As the low level project manager, I got the low level projects.

I moved back to IC when they finally posted an opening to backfill my job. I went to my boss and said: "I can be a mediocre manager or a great engineer, you choose."

Later on there was a big reshuffling of the department, and I was asked if I wanted to be a manager. I said yes. More reshuffling thinned my team down to 2 reports, and I kind of oozed my way back into IC by just doing IC work for people when I wasn't managing.

All of these moves were promotions in both pay and title.

One thing you learn by being through a few annual cycles at your business is how it really works. For instance, things like performance reviews, pay increases, promotions, etc. This knowledge will serve you in any career.


> project manager

In every organization I've ever worked in, project management was very different than management management: project managers never ended up actually "managing" people as in hiring, firing, budgeting, setting direction for, etc.


Quite true. I was a people-manager the second time around. And as an entry level manager I had very little actual discretion over those things. I'm just giving myself as an example of someone who went back.


Sort of. I've worked at startups the last 10 years. I've gone from IC to "executive" three times now. Twice I decided to just join a company as an IC after leaving the last as a manager to avoid the stress/hassle and then ended up leading things. You get more insight, respect and influence on your compensation as a manager. Comp is also worse as an IC unless you get lucky or have a personal connection to the leadership.


I haven't personally, but from my experience interacting with some more traditional engineering organizations like oil and gas companies, it is incredibly common and useful there.

You have people who were managing several (5-80) engineers and technicians at a manufacturing plant, refinery, or other operational location, move to corporate and become an IC in various capacities. Some become advisors to senior mid-level, or VP-level management, or take on more commercial IC roles. They'll do those roles for a couple years and then rotate back into management in either their old orgs or the new org.


There is another aspect of it: when you want to change from management to "lower" status jobs, the person hiring you will have a hard time understanding your decision. "You understand you're overqualified for this post, right"? They get suspicious even if you're a perfect candidate.


This is an interesting instance of two HN tropes in conflict: Managers are able to ‘create’ more (by improving IC productivity) than any individual contributor (and thus more value), unless you believe in 10x engineers.


It is a meme that is largely self-fulfilling under the wrong organizational incentives: as managers control how and what information flows in an organization, managers in many organizations claim a lions share of credit for successes and delegate failures. What is more likely: that Musk is a genius electric car engineer, rocket engineer, battery engineer, tunnel boring machine engineer, ... ? Or that he takes credit from those people in his various teams? Don't get me wrong, there is certainly value from assembling the right team.


A senior IC who is a technical lead or area lead can do the same without formally leading anyone.

I know of quite a few teams where there is a high level manager and an equal level IC who report to the same director. They're both responsible for the same scope of work, (and this is oversimplifying) just one is responsible for the tech and one for the people.


Yeah, I'm the technical lead and report to a director.

My contributions are 50% personal, 50% "team acceleration" (ie: ensure your teammates are able to get things done quicker including pairing, code walkthroughs, documentation, last minute team changes to ensure a project succeeds)


I think it is similar for managers and developers. There are 10x managers and 10x developers, but both are very rare. The are also net-negative managers and net-negative developers, both are a minority but sufficiently large that most people already met a few of them.

That is, a manager can "create more than any individual contributor", but most of them don't.


If your company is like mine, then they'll combine the jobs and pay you the lower of the two salaries while selling it as a great opportunity.

Simultaneous promotion and demotion.


I really hate these kinds of articles, primarily because they are trying to sugar-coat reality here.

The fact of the matter is this, management _is_ a promotion, because you get paid more and you gain access to more powers. If it were _not_ a promotion within the company, no one would take it up.

Management is a simple deal, you give up power _outside_ of the company for power _within_ the company. It is far easier to join another company as an Engineer than it is as an Engineering Manager.

However, I agree that it should not be. It should not be there to create a sense of hierarchy. This is why, I believe that you should rotate your managers _within_ the team. Back at my old company, we had people who would go into a Team Lead position for a certain project, and then someone else would take over.

Pay was already high, so no one really wanted to take up lead because it meant more responsibility.

This is how power needs to be treated, you should not have it for too long. This is why we have term limits.


I've never seen "team lead" as a management role. Team lead is more of technical tie-breaker role on technical decisions. It's not a management role if you can't fire someone.


I am a team lead and I'm definitely a manager - 80% of my time is managing people, not making technical decisions, that's more for technical directors(who in turn do not manage anyone). And why would managers be able to fire people though? I can recommend that someone be let go to HR, but ultimately that's not up to managers. The process takes at least 6 months unless for gross misconduct anyway, it's far too complex to be up to a single person.


This sounds a lot like differences in individual companies' organizational structures—I bet there are some where a "team lead" is more of a "first among equals," while others, as you describe, are primarily managing their group of technical specialists of whatever stripe. Similarly, in some organizations, managers tell HR, "We should fire this person," while in others, they tell HR, "Hey, I just fired this person."


I've never ever felt anything other than a first-among-equals as a lead. I've learned so much from my team, and I'm proud of where my former team members are now. I dont intend to be anything else should I become a manager again,


If you don't have the title, you are (voluntarily?) taking a pay cut relative to someone else in your company who has a manager title.


There isn't anyone at the entire company with a manager title. It doesn't exist. Well, that's not quite true - we have a "discipline manager" who works with HR but he doesn't actually manage anyone. Team leads are equivalent to what I read managers are in other companies.


I was a Team Lead, and I could fire someone, but that firing would be handled by HR. Also in Europe, you can't fire people at will like you can in the US, which is a lot more humane.


In my company, "team lead" is definitely a management role: an entry-level one, but still management. For technical tie-breaking we have a different position, "tech lead".


>The fact of the matter is this, management _is_ a promotion, because you get paid more and you gain access to more powers. If it were _not_ a promotion within the company, no one would take it up.

Disagree. It's a different job, not a harder or easier one. It's just a lateral move. Some people are better at managing people and projects, and some people are better at doing engineering. A lot of managers become managers when they realize they're a medium tier engineer and they're honest with themselves and realize the future is stagnation. These managers tend to be the better managers! They have more empathy for the tradeoffs that are occurring.

That being said, where this is partially true is that it's certainly easier to move up the ladder as a manager than an IC, in my experience. There's just more jobs to be had.


More money + more power = promotion.


Out of three levers of power in an organization, role power is the least effective, especially when you are managing engineers. Pre-Covid at least, if the engineers didn’t like a manager, you could easily find another job.

Also managers can’t force anyone with any experience to work longer hours through force of will. The people who have power in an organization get it through building relationships and building a reputation.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: