9 ms·

"At Facebook, moving into management is not a promotion. It’s a lateral move, a parallel track. " This is nice in theory. But when your "peers" with Manager in

"At Facebook, moving into management is not a promotion. It’s a lateral move, a parallel track. " This is nice in theory. But when your "peers" with Manager in their title have access to more information and more decision-making power, it is not in fact a parallel track. Just saying people are equal doesn't make it so, and it doesn't change the underlying organizational structures.

0xdeadbeefbabe 10y ago
If the managers say management is a lateral move then it must be so.
- neat159 10y ago
  hmm
shostack 10y ago
Is that in fact the case?
dreamsofdragons 10y ago
If you set up the culture right, this isn't as big of a problem as you might think. On our team, it doesn't matter if you're the manager or not, the decisions for the product are made by consensus of the team. Sure management will still do approvals for time off and deal with the skinned knees and runny noses. But for day to day operations, it's peers working for a common cause.
- chrisseaton 10y ago
  Do you really work for a genuine co-operative where all decisions are made by consensus of the workers? I'd be surprised and interested to learn more if that's the case.
  - devonkim 10y ago
    There's a Brazillian company (Semco) that's like this supposedly, but I have to wonder how they're doing today with so much of the company involved with energy.
    - jaeh 10y ago
      there also is the mondragon cooperative: https://en.wikipedia.org/wiki/Mondragon_Corporation https://en.wikipedia.org/wiki/Mondragon_Corporation there also is a ted talk by semco ceo ricardo semler: https://www.youtube.com/watch?v=k4vzhweOefs https://www.youtube.com/watch?v=k4vzhweOefs
- boto3 10y ago
  The question is who decides the annual bonus and raise?
  - r00fus 10y ago
    More importantly, who decides who's manager next quarter/year? I've never seen non-managers exercise much leverage on this front. Being able to determine who works with whom is a very powerful position.
    - rhc2104 10y ago
      Actually, I planned on writing a blog post on this at some point. I work at Hired, and we had an interview process to determine who (internally) would become the next manager. This involved three interviews with engineers, and a presentation with management.
      - mymosh 10y ago
        That sounds humiliating for candidates who don't make it. Especially having to go back to work with the engineers that rejected them.
        rhc2104 10y ago
        In the "traditional" method of selecting a manager, most engineers don't get selected either. However, the process is less transparent that way. I'm saying this as a candidate that didn't get selected. I got great actionable feedback on how to be a better leader, and I'll keep my fingers crossed when there is another opportunity available.
- qq66 10y ago
  Product decisions can never be solely by consensus. At some point, barring massive groupthink, there will be a disagreement on some product decision (what color should this icon be?) but the icon will ultimately be assigned a color. There is some process by which that decision is made.
  - trbvm2 10y ago
    Usually A/B testing one would think
  - ethanbond 10y ago
    Yeah I'm not sure why people think consensus is a good strategy. The consensus established by a group should be about who you trust to make a decision, not the content of the decision itself. i.e. when it comes down to the icon, your group should agree to trust the designer, and then trust the designer. The benefits are numerous: 1) People get to make the decisions within their realm of expertise, 2) No aimless debate, products are built faster, 3) If there was a bad decision, there is one person who made the decision, but the whole team should share accountability since they all agreed to trust the person who made that decision. The process by which that decision is made is the process by which you select a person to make that decision. Ideally, that happens at the hiring level, so once, for example, a designer is assigned to your team, you already know that s/he is good enough to pick the right color. You don't have to engage in office politics to discover whether or not you can trust him/her, and you don't have to engage in office politics to allocate praise/blame in the event of particularly good/bad decisions.
- proksoup 10y ago
  I've found consensus decision making to be frustrating in the environments I've encountered it. A lot of flip flopping and lack of follow through. Who made that decision? We did. Can we give up on that and try something else? Of course. I kinda like to have at least a shepherd for the day to day decisions, if not a commander. In practice in my current environment it's been the occasional PM that takes some ownership that fills that role, but in many groups I see the floundering without leadership. Internally I think they think they're making progress because everyone on the team is always happy with their decisions, I may just be the old curmudgeon that's frustrated with what I see as wasted effort.
  - criley2 10y ago
    In my utterly-average agile environment, it's not hard. Your peers form an agile group to deliberate. You have non-management product owners and stakeholders to guide you (shepherd you). You have a supervisor who deals with HR business like time off, but is unrelated to your product decisions.
  - specialist 10y ago
    While it can work, "consensus" usually means ad hoc, no accountability, no followthru. This essay was illuminating: Tyranny of Structurelessness https://en.wikipedia.org/wiki/The_Tyranny_of_Structurelessness https://en.wikipedia.org/wiki/The_Tyranny_of_Structurelessne...
    - tedks 10y ago
      While I've always thought that essay made good points, it's somewhat dangerous to overinterpret the thoughts of a Stalinist on groups without structure. Her solution is (obviously) to just have hierarchical structure, but this leaves you with the same problems as structureless, there's now just a channel by which people who play the game well can pretend to be accountable. Stalin himself proves that hierarchical groups aren't more accountable, even if they nominally have mechanisms to be so.
    - proksoup 10y ago
      Yes, <3 that. "Contrary to what we would like to believe, there is no such thing as a structureless group." The same essay was linked to me a previous time I made a similar public complaint :)
- majormajor 10y ago
  To illustrate how consensus-decision-making can be a tricky balance, I've been in a situation before where I was managing a team of a few other developers (about 50% hands-on myself) and so tried to stay away from being "the decider" since there were others closer to the code. The feedback my own manager shared with me that had been collected from my reports was that they appreciated what I was trying to do, but that they also wanted me to have a more active technical leadership/decision-making roles. What I'd failed to do was talk enough specifically with the rest of the team around what they wanted the roles to be, vs just assuming they'd want maximum autonomy. This will vary depending on composition of team, familiarity of the devs on the team with the problem area and stack, etc. It will also depend on if managers are expected to be almost-purely people-managers or if they're also expected to be domain knowledge leaders as well. There's no one-size-fits-all approach, but the thing I've seen that separates a good manager from a bad manager is being able to adjust their approach in things like that based on the situation vs sticking to a script.
- specialist 10y ago
  "decisions for the product are made by consensus of the team" I favor democratic decision making processes. Use voting systems appropriate for the task. Roman eval for new hires, go/no go. Approval voting for triage, new features. JADs for "visions". Creative writing exercise for post-mortems. Etc. "Democratic" does not mean winner-takes-all, which is suboptimal. "Democratic" does not mean consensus.
  - jomamaxx 10y ago
    "Use voting systems appropriate for the task. " I rather don't agree with this one. 'Voting' should almost never, ever be used. For so many reasons. Rarely should everyone have an 'equal say'. You are not 'equal citizens' in this. Second - is that it leads to politics - 'I helped you last time, you help me this time' etc. Unless you get into crazy things like 'hidden ballots'. There is no substitute for leadership. Often, a mediocre decision, executed upon well, will lead to better outcomes than 'great decisions' wherein their is fudging, lack of insight etc.. In situations that require broad input, a decent moderator should be able to assess the 'consensus' and go with that. In many design situations, architects and designers should basically set the direction, absent issues brought up by team members. Things like 'should we all use the same IDE' or 'what IDE's can we use' - obviously require a lot of input from team members and maximum flexibility. But things like API design ... that needs to be really well curated and it's best left to the experts - with strong feedback from team members.
    - specialist 10y ago
      The word you're looking for is neoreactionary.
    - icebraining 10y ago
      Who decides who are the experts, and who checks their work?
    - SkyMarshal 10y ago
      >There is no substitute for leadership. Second this, true in my experience as well.
- serge2k 10y ago
  > Sure management will still do approvals for time off Not a peer.
mikek 10y ago
It is a lateral move salarywise, at least.
thkim 10y ago
This is very true. Hierarchy is hierarchy. Any organization can pretend they don't have such blasphemous thing, but if that was really true then there would be no "management" to begin with. What's wrong with accepting a leader as leader? You can't have it both ways - either you lead or be led. There's no equal footing there. It's not about making everyone equal at all times. What's important is how do you choose a leader and when.
- kevinskii 10y ago
  I don't think "leadership" is synonymous with "management". Some of my best managers have been mediocre leaders. Conversely, some of the strongest technical people I've worked with are great leaders.
m3mnoch 10y ago
we do this at my (very large) company. it's awesome. the best thing about it? engineers who aren't good at the strategic, human high-touch, or political issues, but excel at execution and implementation aren't managing teams of people -- they're busy executing and getting paid (and further promotions) based on their ability to execute, not on their ability to manage herds of programmers. as a software engineer, i love that my boss is my boss because he's good at managing teams of software engineers. not because he's the best software engineer in the house.
alexgartrell 10y ago
I think you're absolutely right, in general, but I've been at Facebook for 5 years now, and the one thing I'll say about it is that once you establish a track record of 1) doing good work and 2) making good long-term decisions, that trumps any considerations around level. The culture is definitely such that the very senior folks (Director++) will value trust over level, so it's very much "influence over authority." Personally, this has lead to me getting messed with my managers ~never, which is a very high-order bit in my work happiness.
- Mithaldu 10y ago
  The last time i was at a place where trust went above everything, literally all the code was the worst horrible shit, because they sold tyres and that being a solid business had run into zero trouble, ever, and thought that the developer who'd been with them for over a decade was the best, since "he has never made a wrong decision" (i.e. the company hadn't gone bankrupt yet), despite his code managing to create, just on its own, an amazing turn-over rate in developers.
  - pm 10y ago
    The place I'm currently about to leave had a similar situation in times past, due to the fact they weren't a software organisation. Facebook is a software organisation, so the same situation would rarely apply. However, I think you should trust but verify. If you're unable to accomplish the verify part (for whatever reason), you'll have problems.
    - alttab 10y ago
      Yeah, a lot of people make the mistake on what type of company it is. For instance, a lot of non-software companies may pay more and provide a director or executive level title to a developer and give them a team just to get them in the door. What these people don't immediately realize is they are giving up being a "tier-1" employee at the organization. First and foremost if you are at say, a tire company, software is most likely a cost center and not central to the strategy. This means they wont attract good developers, and have to do things like above to get them in the door. If you want to work with really passionate and talented software developers, you'll want to be at a primarily software organization, or one that sees the logistics of software central to the business strategy.
zippergz 10y ago
This is true, but not everyone wants decision making power. Some people want to be promoted simply for more money, or to feel a sense of progression. While there are flaws to this approach, it's nice to let people continue to get more compensation and recognition without forcing them into managing people and making broader decisions if that's not something they want to do or have a talent for.
nv-vn 10y ago
All employees are equal, only some are more equal than others.
biztos 10y ago
Follow the money, right? If, say, a Software Architect and a Senior Director have the same pay and the same perks and the same bonus structure, and it really does take a talented person the same amount of time to climb that high from (say) Software Engineer and Manager, then they're parallel. If any of that favors one side over the other then they're not. I doubt any company is going to give access to enough data to prove or disprove the claim; but the default believability isn't very high.
- tmptmp 10y ago
  >>If, say, a Software Architect and a Senior Director have the same pay and the same perks and the same bonus structure, and it really does take a talented person the same amount of time to climb that high from (say) Software Engineer and Manager, then they're parallel. I have a doubt: "the same pay and the same perks" things seem okay but "the same bonus structure" seems difficult to understand. A manager has more visibility, more access to business info then he/she will have more chance to be eligible to "bonus" than an engineer has. So, it'd great if you elaborate on how a Software Engineer and a supposedly equal Manager can have "the same bonus structure".
  - chillydawg 10y ago
    To be fair, he was talking about a Software Architect, who tend to work cross team and have a broader view than an engineer coding away in a given team.
  - jonlucc 10y ago
    In my company (pharma, not tech), the bonus structure is based on salary and some multiplier. The multiplier is the same across the entire company and is based on key performance factors from several departments. For 2 employees with the same base salary, their bonuses will be the same regardless of job title.
tn13 10y ago
This is true. I think organizations need to create more space for developers to grow as leaders which I don't see happening. In silicon valley contacts are as valuable as money and a person with manager in his title will build contacts faster and achieve more than a developer who actually might have made more impact for his employer. People with manager in title can work from home more often, travel on company paid trips more often and in general have a better social life than developers. At the end of the day managers can make a developers life bad if he/she wants too. That is what matters.
shas3 10y ago
This is pretty standard in old industrial companies.
tlogan 10y ago
I wanted to make the same point. Many large software companies have very similar structure. Since I had personal experience working in these companies here what I found as problem: - Management has decision making power. - Management has ability to control $$ (bonus allocation, etc.) - Management has access to more information than employees on "individual contributor" track It is important to note that system work up to mid-level managers. I.e., it is works well when there is "team lead" and "manager". Manager ensures that the team is not bothered by politics and get all necessary resources while team lead ensures that things are done. But when you come to mid-level and up even if the pay is comparable, the life is much better for managers. For example, if you are in 40s it is important to have job security. Senior managers and VPs will know when are layoffs are coming or certain groups will be sacked (since they have access to more informations). They can prepare for it. If you are "software architect", you are in the blind until the day of layoffs.
- alttab 10y ago
  I feel good managers often delegate the decision making power to the group or team leads. This creates scale for the manager, and allows room for the development teams to develop leaders and judgement. Companies that are set up well also give minimal control over bonus allocation or salaries. These things should be controlled by HR and recruiting, along with salary and compensation policies based on role and level. Managers supposedly have the best view on IC performance, so within some band they should be able to influence rate increases and promotions. Anything outside of that would need to be a conversation between the manager/IC and HR. My advise here is if you feel there is a deviation in your pay, get your manager to bat for you, do not go to HR yourself. And by design, management will have access to more information than individual contributors, but that's the purpose of the role. This person brings in information, priorities, and resources to the team to execute. This is where the "power" idea comes in, but anyone in this position long enough would tell you its more of a "responsibility." It's not always clear what is right and what isn't, nor even a way to really prove it ex post facto. Could it give someone enough perspective to make self-interested decisions that ICs could not? Probably. I suppose the question is, is that bad and how is it bad, and how would you eliminate it? Edit: My wishful novelist inside me says its the software program that automates resource allocation, charter, and IC development. You could essentially build an autonomously managed organization with IC roles being the only true human employees.
blackkettle 10y ago
it's absurd in any practical sense. but it's a great story to keep the rank and file mostly satisfied most of the time. politics in the end is a part of life; it should not dominate or overshadow goal oriented work, but it is a natural, unavoidable consequence of people holding different viewpoints. on the other hand, all the openness strategies they suggest are great, and these do work well in practice to mitigate conflict [but politics does not equal conflict].
elgoog1212 10y ago
It is much more of a parallel track there, in the sense that it's a completely different job from that of a software engineer. Notice that they don't say anything about the length of each of the tracks. If it's money and power you care about, by all means, become a manager. Just don't expect that your job will be easy, or that you'll be able to do a ton of coding.

0xdeadbeefbabe 10y ago

If the managers say management is a lateral move then it must be so.

neat159 10y ago
hmm

shostack 10y ago

Is that in fact the case?

dreamsofdragons 10y ago

If you set up the culture right, this isn't as big of a problem as you might think. On our team, it doesn't matter if you're the manager or not, the decisions for the product are made by consensus of the team. Sure management will still do approvals for time off and deal with the skinned knees and runny noses. But for day to day operations, it's peers working for a common cause.

chrisseaton 10y ago
Do you really work for a genuine co-operative where all decisions are made by consensus of the workers? I'd be surprised and interested to learn more if that's the case.
- devonkim 10y ago
  There's a Brazillian company (Semco) that's like this supposedly, but I have to wonder how they're doing today with so much of the company involved with energy.
  - jaeh 10y ago
    there also is the mondragon cooperative: https://en.wikipedia.org/wiki/Mondragon_Corporation https://en.wikipedia.org/wiki/Mondragon_Corporation there also is a ted talk by semco ceo ricardo semler: https://www.youtube.com/watch?v=k4vzhweOefs https://www.youtube.com/watch?v=k4vzhweOefs
boto3 10y ago
The question is who decides the annual bonus and raise?
- r00fus 10y ago
  More importantly, who decides who's manager next quarter/year? I've never seen non-managers exercise much leverage on this front. Being able to determine who works with whom is a very powerful position.
  - rhc2104 10y ago
    Actually, I planned on writing a blog post on this at some point. I work at Hired, and we had an interview process to determine who (internally) would become the next manager. This involved three interviews with engineers, and a presentation with management.
    - mymosh 10y ago
      That sounds humiliating for candidates who don't make it. Especially having to go back to work with the engineers that rejected them.
      - rhc2104 10y ago
        In the "traditional" method of selecting a manager, most engineers don't get selected either. However, the process is less transparent that way. I'm saying this as a candidate that didn't get selected. I got great actionable feedback on how to be a better leader, and I'll keep my fingers crossed when there is another opportunity available.
qq66 10y ago
Product decisions can never be solely by consensus. At some point, barring massive groupthink, there will be a disagreement on some product decision (what color should this icon be?) but the icon will ultimately be assigned a color. There is some process by which that decision is made.
- trbvm2 10y ago
  Usually A/B testing one would think
- ethanbond 10y ago
  Yeah I'm not sure why people think consensus is a good strategy. The consensus established by a group should be about who you trust to make a decision, not the content of the decision itself. i.e. when it comes down to the icon, your group should agree to trust the designer, and then trust the designer. The benefits are numerous: 1) People get to make the decisions within their realm of expertise, 2) No aimless debate, products are built faster, 3) If there was a bad decision, there is one person who made the decision, but the whole team should share accountability since they all agreed to trust the person who made that decision. The process by which that decision is made is the process by which you select a person to make that decision. Ideally, that happens at the hiring level, so once, for example, a designer is assigned to your team, you already know that s/he is good enough to pick the right color. You don't have to engage in office politics to discover whether or not you can trust him/her, and you don't have to engage in office politics to allocate praise/blame in the event of particularly good/bad decisions.
proksoup 10y ago
I've found consensus decision making to be frustrating in the environments I've encountered it. A lot of flip flopping and lack of follow through. Who made that decision? We did. Can we give up on that and try something else? Of course. I kinda like to have at least a shepherd for the day to day decisions, if not a commander. In practice in my current environment it's been the occasional PM that takes some ownership that fills that role, but in many groups I see the floundering without leadership. Internally I think they think they're making progress because everyone on the team is always happy with their decisions, I may just be the old curmudgeon that's frustrated with what I see as wasted effort.
- criley2 10y ago
  In my utterly-average agile environment, it's not hard. Your peers form an agile group to deliberate. You have non-management product owners and stakeholders to guide you (shepherd you). You have a supervisor who deals with HR business like time off, but is unrelated to your product decisions.
- specialist 10y ago
  While it can work, "consensus" usually means ad hoc, no accountability, no followthru. This essay was illuminating: Tyranny of Structurelessness https://en.wikipedia.org/wiki/The_Tyranny_of_Structurelessness https://en.wikipedia.org/wiki/The_Tyranny_of_Structurelessne...
  - tedks 10y ago
    While I've always thought that essay made good points, it's somewhat dangerous to overinterpret the thoughts of a Stalinist on groups without structure. Her solution is (obviously) to just have hierarchical structure, but this leaves you with the same problems as structureless, there's now just a channel by which people who play the game well can pretend to be accountable. Stalin himself proves that hierarchical groups aren't more accountable, even if they nominally have mechanisms to be so.
  - proksoup 10y ago
    Yes, <3 that. "Contrary to what we would like to believe, there is no such thing as a structureless group." The same essay was linked to me a previous time I made a similar public complaint :)
majormajor 10y ago
To illustrate how consensus-decision-making can be a tricky balance, I've been in a situation before where I was managing a team of a few other developers (about 50% hands-on myself) and so tried to stay away from being "the decider" since there were others closer to the code. The feedback my own manager shared with me that had been collected from my reports was that they appreciated what I was trying to do, but that they also wanted me to have a more active technical leadership/decision-making roles. What I'd failed to do was talk enough specifically with the rest of the team around what they wanted the roles to be, vs just assuming they'd want maximum autonomy. This will vary depending on composition of team, familiarity of the devs on the team with the problem area and stack, etc. It will also depend on if managers are expected to be almost-purely people-managers or if they're also expected to be domain knowledge leaders as well. There's no one-size-fits-all approach, but the thing I've seen that separates a good manager from a bad manager is being able to adjust their approach in things like that based on the situation vs sticking to a script.
specialist 10y ago
"decisions for the product are made by consensus of the team" I favor democratic decision making processes. Use voting systems appropriate for the task. Roman eval for new hires, go/no go. Approval voting for triage, new features. JADs for "visions". Creative writing exercise for post-mortems. Etc. "Democratic" does not mean winner-takes-all, which is suboptimal. "Democratic" does not mean consensus.
- jomamaxx 10y ago
  "Use voting systems appropriate for the task. " I rather don't agree with this one. 'Voting' should almost never, ever be used. For so many reasons. Rarely should everyone have an 'equal say'. You are not 'equal citizens' in this. Second - is that it leads to politics - 'I helped you last time, you help me this time' etc. Unless you get into crazy things like 'hidden ballots'. There is no substitute for leadership. Often, a mediocre decision, executed upon well, will lead to better outcomes than 'great decisions' wherein their is fudging, lack of insight etc.. In situations that require broad input, a decent moderator should be able to assess the 'consensus' and go with that. In many design situations, architects and designers should basically set the direction, absent issues brought up by team members. Things like 'should we all use the same IDE' or 'what IDE's can we use' - obviously require a lot of input from team members and maximum flexibility. But things like API design ... that needs to be really well curated and it's best left to the experts - with strong feedback from team members.
  - specialist 10y ago
    The word you're looking for is neoreactionary.
  - icebraining 10y ago
    Who decides who are the experts, and who checks their work?
  - SkyMarshal 10y ago
    >There is no substitute for leadership. Second this, true in my experience as well.
serge2k 10y ago
> Sure management will still do approvals for time off Not a peer.

mikek 10y ago

It is a lateral move salarywise, at least.

thkim 10y ago

This is very true. Hierarchy is hierarchy. Any organization can pretend they don't have such blasphemous thing, but if that was really true then there would be no "management" to begin with. What's wrong with accepting a leader as leader? You can't have it both ways - either you lead or be led. There's no equal footing there. It's not about making everyone equal at all times. What's important is how do you choose a leader and when.

kevinskii 10y ago
I don't think "leadership" is synonymous with "management". Some of my best managers have been mediocre leaders. Conversely, some of the strongest technical people I've worked with are great leaders.

m3mnoch 10y ago

we do this at my (very large) company. it's awesome. the best thing about it? engineers who aren't good at the strategic, human high-touch, or political issues, but excel at execution and implementation aren't managing teams of people -- they're busy executing and getting paid (and further promotions) based on their ability to execute, not on their ability to manage herds of programmers. as a software engineer, i love that my boss is my boss because he's good at managing teams of software engineers. not because he's the best software engineer in the house.

alexgartrell 10y ago

I think you're absolutely right, in general, but I've been at Facebook for 5 years now, and the one thing I'll say about it is that once you establish a track record of 1) doing good work and 2) making good long-term decisions, that trumps any considerations around level. The culture is definitely such that the very senior folks (Director++) will value trust over level, so it's very much "influence over authority." Personally, this has lead to me getting messed with my managers ~never, which is a very high-order bit in my work happiness.

Mithaldu 10y ago
The last time i was at a place where trust went above everything, literally all the code was the worst horrible shit, because they sold tyres and that being a solid business had run into zero trouble, ever, and thought that the developer who'd been with them for over a decade was the best, since "he has never made a wrong decision" (i.e. the company hadn't gone bankrupt yet), despite his code managing to create, just on its own, an amazing turn-over rate in developers.
- pm 10y ago
  The place I'm currently about to leave had a similar situation in times past, due to the fact they weren't a software organisation. Facebook is a software organisation, so the same situation would rarely apply. However, I think you should trust but verify. If you're unable to accomplish the verify part (for whatever reason), you'll have problems.
  - alttab 10y ago
    Yeah, a lot of people make the mistake on what type of company it is. For instance, a lot of non-software companies may pay more and provide a director or executive level title to a developer and give them a team just to get them in the door. What these people don't immediately realize is they are giving up being a "tier-1" employee at the organization. First and foremost if you are at say, a tire company, software is most likely a cost center and not central to the strategy. This means they wont attract good developers, and have to do things like above to get them in the door. If you want to work with really passionate and talented software developers, you'll want to be at a primarily software organization, or one that sees the logistics of software central to the business strategy.

zippergz 10y ago

This is true, but not everyone wants decision making power. Some people want to be promoted simply for more money, or to feel a sense of progression. While there are flaws to this approach, it's nice to let people continue to get more compensation and recognition without forcing them into managing people and making broader decisions if that's not something they want to do or have a talent for.

nv-vn 10y ago

All employees are equal, only some are more equal than others.

biztos 10y ago

Follow the money, right? If, say, a Software Architect and a Senior Director have the same pay and the same perks and the same bonus structure, and it really does take a talented person the same amount of time to climb that high from (say) Software Engineer and Manager, then they're parallel. If any of that favors one side over the other then they're not. I doubt any company is going to give access to enough data to prove or disprove the claim; but the default believability isn't very high.

tmptmp 10y ago
>>If, say, a Software Architect and a Senior Director have the same pay and the same perks and the same bonus structure, and it really does take a talented person the same amount of time to climb that high from (say) Software Engineer and Manager, then they're parallel. I have a doubt: "the same pay and the same perks" things seem okay but "the same bonus structure" seems difficult to understand. A manager has more visibility, more access to business info then he/she will have more chance to be eligible to "bonus" than an engineer has. So, it'd great if you elaborate on how a Software Engineer and a supposedly equal Manager can have "the same bonus structure".
- chillydawg 10y ago
  To be fair, he was talking about a Software Architect, who tend to work cross team and have a broader view than an engineer coding away in a given team.
- jonlucc 10y ago
  In my company (pharma, not tech), the bonus structure is based on salary and some multiplier. The multiplier is the same across the entire company and is based on key performance factors from several departments. For 2 employees with the same base salary, their bonuses will be the same regardless of job title.

tn13 10y ago

This is true. I think organizations need to create more space for developers to grow as leaders which I don't see happening. In silicon valley contacts are as valuable as money and a person with manager in his title will build contacts faster and achieve more than a developer who actually might have made more impact for his employer. People with manager in title can work from home more often, travel on company paid trips more often and in general have a better social life than developers. At the end of the day managers can make a developers life bad if he/she wants too. That is what matters.

shas3 10y ago

This is pretty standard in old industrial companies.

tlogan 10y ago

I wanted to make the same point. Many large software companies have very similar structure. Since I had personal experience working in these companies here what I found as problem: - Management has decision making power. - Management has ability to control $$ (bonus allocation, etc.) - Management has access to more information than employees on "individual contributor" track It is important to note that system work up to mid-level managers. I.e., it is works well when there is "team lead" and "manager". Manager ensures that the team is not bothered by politics and get all necessary resources while team lead ensures that things are done. But when you come to mid-level and up even if the pay is comparable, the life is much better for managers. For example, if you are in 40s it is important to have job security. Senior managers and VPs will know when are layoffs are coming or certain groups will be sacked (since they have access to more informations). They can prepare for it. If you are "software architect", you are in the blind until the day of layoffs.

alttab 10y ago
I feel good managers often delegate the decision making power to the group or team leads. This creates scale for the manager, and allows room for the development teams to develop leaders and judgement. Companies that are set up well also give minimal control over bonus allocation or salaries. These things should be controlled by HR and recruiting, along with salary and compensation policies based on role and level. Managers supposedly have the best view on IC performance, so within some band they should be able to influence rate increases and promotions. Anything outside of that would need to be a conversation between the manager/IC and HR. My advise here is if you feel there is a deviation in your pay, get your manager to bat for you, do not go to HR yourself. And by design, management will have access to more information than individual contributors, but that's the purpose of the role. This person brings in information, priorities, and resources to the team to execute. This is where the "power" idea comes in, but anyone in this position long enough would tell you its more of a "responsibility." It's not always clear what is right and what isn't, nor even a way to really prove it ex post facto. Could it give someone enough perspective to make self-interested decisions that ICs could not? Probably. I suppose the question is, is that bad and how is it bad, and how would you eliminate it? Edit: My wishful novelist inside me says its the software program that automates resource allocation, charter, and IC development. You could essentially build an autonomously managed organization with IC roles being the only true human employees.

blackkettle 10y ago

it's absurd in any practical sense. but it's a great story to keep the rank and file mostly satisfied most of the time. politics in the end is a part of life; it should not dominate or overshadow goal oriented work, but it is a natural, unavoidable consequence of people holding different viewpoints. on the other hand, all the openness strategies they suggest are great, and these do work well in practice to mitigate conflict [but politics does not equal conflict].

elgoog1212 10y ago

It is much more of a parallel track there, in the sense that it's a completely different job from that of a software engineer. Notice that they don't say anything about the length of each of the tracks. If it's money and power you care about, by all means, become a manager. Just don't expect that your job will be easy, or that you'll be able to do a ton of coding.