7 ms·

> The truth is that a majority of tech companies don't need 50%+ of their employees. Totally agree. The problem is, nobody knows how to tell which ones. On th

> The truth is that a majority of tech companies don't need 50%+ of their employees. Totally agree. The problem is, nobody knows how to tell which ones. On the ground it's obvious. I'm sure everyone here knows who on their team is crucial to their current production stack, and also knows others who would have no impact (or even positive impact!) if they left. One level up - the direct EM - has most of that context too, but some is already lost. At the next level (Sr. EM or Director usually), almost all of it is gone. At that point, cutting 50% is just guessing. Keep going up and eventually the risk becomes too high that you'll sacrifice your key players along with the rest. Bath water, baby.

adam_arthur 4y ago
No heuristic is perfect, but it's fairly easy to quantify empirically from activity/records. Developers who are productive (actually write and ship large amounts of quality code) tend to be valuable and those that don't, aren't. That being said there are some intangibles, like morale etc. It's possible there are people that benefit the team while having low personal productivity. But anyway, no need to approach in that way. There are probably entire branches of google that could be laid off without any material impact to revenues/profitability, thus all layoffs concentrated in single arm. Crypto divisions could be cut at many companies without affecting their core businesses. Did Square need to rename itself to Block and add all kinds of crypto functions? How many hundreds of developers are working on that. I don't think X% headcount cuts horizontally across the org are ever a good idea. Cut non-essential functions. And cut in core branches opportunistically based on low performance.
- kingcoleman 4y ago
  > No heuristic is perfect, but it's fairly easy to quantify empirically from activity/records. Developers who are productive (actually write and ship large amounts of quality code) tend to be valuable and those that don't, aren't. https://www.folklore.org/StoryView.py?story=Negative_2000_Lines_Of_Code.txt https://www.folklore.org/StoryView.py?story=Negative_2000_Li... ... large amounts of quality code? How many lines of code a week constitutes a large contribution?
  - adam_arthur 4y ago
    The most prolific people at my startup were doing 20k/month. The worst performers were doing 500/month. No, the people doing 500/month didn't compensate for it in other ways. Of course this was a company that needed to build a product and enhance it to survive, not a pseudo-monopoly daycare. Even up to a few hundred developers, its quite obvious who's a strong contributor and who isn't. The people who produce the most code are almost uniformly also the most theoretically strong/capable. Though there was a case where somebody was quite prolific but produced pretty poor/buggy code. It's obvious from how smooth the features they developed go when shipped to production. In most workplaces you'll find that 80% of the results are produced by the top 20% of contributors
- sumedh 4y ago
  > (actually write and ship large amounts of quality code) What about Dev leads who mentor/architect stuff instead of writing code day to day. How will you measure that?
  - dominotw 4y ago
    > architect stuff how can someone be good at architect-ing stuff if they never code or code very little. seems like the method GP is describing would be good to weed out such imposters.
    - dougk16 4y ago
      They've coded for 10 or 20 years, and now just sit back and design interfaces, write specs, evaluate technologies, mentor juniors, do code review, and of course the ultimate mind blow when you're trying to figure out who to fire: they remove code instead of add it. Unfortunately for the company, these "imposters" do indeed get weeded out in preference to the recent college grad copy/pasting thousands of lines of StackOverflow answers. I usually escape before all that drama though!
      - flohofwoe 4y ago
        > they remove code instead of add it If you can remove code from your code base without hampering the functionality, that's usually a much better time investment than writing new code.
        strix_varius 4y ago
        Yes, that was OP's point.
    - chronid 4y ago
      I am in that condition, so personal experience here: - i do most meetings with internal stakeholders to understand needs and changes, and document them - i do most "architecting", as i have most context on the systems my team is responsible for (also I am the oncall escalation point all the time as I am the senior person) - i write about 10% of the code, usually what other colleagues aren't comfortable with (legacy systems mainly these days) "Development" is not only writing code, and senior roles tend to code far less because we get wrapped up with the rest of the company so other folks can code and deliver. My team, manager and customers seem very happy about the whole thing (but hey, maybe everyone hates me!). I do want to code more, maybe with a good PM i would be able to, but I have no illusions about that.
- nfiedel 4y ago
  Lines or amount of code written is a terrible, and easily gamed metric. Some of the very best engineers write the fewest lines of code, often making fewer yet better abstractions that fulfill more business use cases more simply. They might also help others write less code. Some of the most prolific coders are great. And some are terrible. The challenge is discerning the two. Coaching a prolific yet bad coder to slow down can be as challenging as coaching up a slower / not yet confident coder. And the slower coder will do vastly less damage in the interim.
  - bpodgursky 4y ago
    I understand this as theoretical possibility, and it could lead you astray if you're trying to tell a 40% developer from a 60% developer... but in practice I have never met a superstar IC who doesn't also ship a ton of code (even while they help out others). If you fire the 10% of ICs who push the least code, to within a rounding error you're extremely unlikely to regret it.
    - Foobar8568 4y ago
      Your best engineers are facilitators, not coding monkeys.
      - bpodgursky 4y ago
        Your best engineers are both.
        Foobar8568 4y ago
        You can't do both unless you are one in your team. The more people, the less code you'll do. Software engineering goals is to solve human problems, you can't escape human relation, which eventually means facilitating stuff.
      - manigandham 4y ago
        Those are not engineers then, they're managers. It's strange to see this confusion when it comes to software. Any other discipline and you wouldn't say engineers that don't do any engineering are the best engineers.
- saagarjha 4y ago
  I’m going to respond to the second half of your comment because the first part is trivially false and the others have already spoken to that: do you think Google should cut all teams but those involved in advertising? Because the rest aren’t making money. Why keep them around?
  - hnfong 4y ago
    Ironically that might not be such a bad idea. If the assumption is that Google is unlikely to make further gains beyond online advertising, shareholders would gain more profit in the long run by cutting the teams, and talented people might move to companies that are better at making money in the other areas. The problem is that upper management don't want to be the one declaring that they're giving up on growing the company. Especially that they have billions of dollars to spend/waste every year.
- twawaaay 4y ago
  > No heuristic is perfect, but it's fairly easy to quantify empirically from activity/records. Developers who are productive (actually write and ship large amounts of quality code) tend to be valuable and those that don't, aren't. If you are factory line worker, yes. If you are a developer or a manager (a "knowledge worker") -- what you could be observed to be doing has usually little correlation with result for the company. I know people who are busy producing total crap, managers completing tons of projects achieving bad results, very energetically with huge fanfare. And I know admins that have everything so well automated and working reliably that they are watching youtube whole day, their managers none the wiser about what could have been. Or people who do nothing and have one brilliant idea a year that saves the company tons of expenses. And every other type inbetween. In a lot of teams it is usual for senior developers to produce relatively little code compared to juniors, when looking at the value they are creating. Maybe because they spent most of their time doing other things like helping juniors, doing code reviews, designing new solutions, talking to clients. Or maybe because they are getting the most complex problems. If you can measure this you would deserve Nobel Prize. A more likely explanation, though, is that you have no idea how complex the problem is. In those cases I like to remind people of this famous little story: https://www.folklore.org/StoryView.py?story=Negative_2000_Lines_Of_Code.txt https://www.folklore.org/StoryView.py?story=Negative_2000_Li... In my experience working many decades, in most teams there are few individuals who are making things go and frequently not even their direct managers understand how people are exactly contributing to productivity.
  - kingcoleman 4y ago
    I didn't read your entire comment and realized you suggested the same link. What's old is new again.
  - twawaaay 4y ago
    I don't like to respond to my own posts but I forgot to include something which I think is important. Unfair "heuristics" create unhealthy incentives that are typically way more damaging than having little clarity. 1. People feel treated unfairly and their engagement drops off a cliff at that point in time. People can be happy even accepting a punishment AS LONG as they FEEL they are being treated fairly. 2. People feel pressed to do things for show, just to appease measurements even if they don't believe it is right. Soon they are fine doing substandard or even completely shoddy work even in areas that are not measured, because that's what people do. People do not just selectively resign from doing good work -- if they feel they are asked to do bad work somewhere they will also do it in other areas and find a rationale for it. 3. People who will not accept bullshit and would want to do right regardless of unfair measurements, will evaporate from your company. They usually leave on their own. This will leave your company worse overall -- with no people who will tell managers the truth when it is needed the most. 4. The corporate, thinking they have measurements, stop looking to actually do better. The measurements become everything. It is frequently better to not pretend you solved the problem and accept the problem is hard and try to do best anyway.
akg_67 4y ago
> The problem is, nobody knows how to tell which ones. I guess there is no leetcode BS for firing. May be someone create one so that circle of sucks can be completed.
- aiisjustanif 4y ago
  I worked somewhere that did this. They restructured the same teams with new managers, mandatory tests to get into your same “new” team. Strangler Fig Pattern style.

adam_arthur 4y ago

No heuristic is perfect, but it's fairly easy to quantify empirically from activity/records. Developers who are productive (actually write and ship large amounts of quality code) tend to be valuable and those that don't, aren't. That being said there are some intangibles, like morale etc. It's possible there are people that benefit the team while having low personal productivity. But anyway, no need to approach in that way. There are probably entire branches of google that could be laid off without any material impact to revenues/profitability, thus all layoffs concentrated in single arm. Crypto divisions could be cut at many companies without affecting their core businesses. Did Square need to rename itself to Block and add all kinds of crypto functions? How many hundreds of developers are working on that. I don't think X% headcount cuts horizontally across the org are ever a good idea. Cut non-essential functions. And cut in core branches opportunistically based on low performance.

kingcoleman 4y ago
> No heuristic is perfect, but it's fairly easy to quantify empirically from activity/records. Developers who are productive (actually write and ship large amounts of quality code) tend to be valuable and those that don't, aren't. https://www.folklore.org/StoryView.py?story=Negative_2000_Lines_Of_Code.txt https://www.folklore.org/StoryView.py?story=Negative_2000_Li... ... large amounts of quality code? How many lines of code a week constitutes a large contribution?
- adam_arthur 4y ago
  The most prolific people at my startup were doing 20k/month. The worst performers were doing 500/month. No, the people doing 500/month didn't compensate for it in other ways. Of course this was a company that needed to build a product and enhance it to survive, not a pseudo-monopoly daycare. Even up to a few hundred developers, its quite obvious who's a strong contributor and who isn't. The people who produce the most code are almost uniformly also the most theoretically strong/capable. Though there was a case where somebody was quite prolific but produced pretty poor/buggy code. It's obvious from how smooth the features they developed go when shipped to production. In most workplaces you'll find that 80% of the results are produced by the top 20% of contributors
sumedh 4y ago
> (actually write and ship large amounts of quality code) What about Dev leads who mentor/architect stuff instead of writing code day to day. How will you measure that?
- dominotw 4y ago
  > architect stuff how can someone be good at architect-ing stuff if they never code or code very little. seems like the method GP is describing would be good to weed out such imposters.
  - dougk16 4y ago
    They've coded for 10 or 20 years, and now just sit back and design interfaces, write specs, evaluate technologies, mentor juniors, do code review, and of course the ultimate mind blow when you're trying to figure out who to fire: they remove code instead of add it. Unfortunately for the company, these "imposters" do indeed get weeded out in preference to the recent college grad copy/pasting thousands of lines of StackOverflow answers. I usually escape before all that drama though!
    - flohofwoe 4y ago
      > they remove code instead of add it If you can remove code from your code base without hampering the functionality, that's usually a much better time investment than writing new code.
      - strix_varius 4y ago
        Yes, that was OP's point.
  - chronid 4y ago
    I am in that condition, so personal experience here: - i do most meetings with internal stakeholders to understand needs and changes, and document them - i do most "architecting", as i have most context on the systems my team is responsible for (also I am the oncall escalation point all the time as I am the senior person) - i write about 10% of the code, usually what other colleagues aren't comfortable with (legacy systems mainly these days) "Development" is not only writing code, and senior roles tend to code far less because we get wrapped up with the rest of the company so other folks can code and deliver. My team, manager and customers seem very happy about the whole thing (but hey, maybe everyone hates me!). I do want to code more, maybe with a good PM i would be able to, but I have no illusions about that.
nfiedel 4y ago
Lines or amount of code written is a terrible, and easily gamed metric. Some of the very best engineers write the fewest lines of code, often making fewer yet better abstractions that fulfill more business use cases more simply. They might also help others write less code. Some of the most prolific coders are great. And some are terrible. The challenge is discerning the two. Coaching a prolific yet bad coder to slow down can be as challenging as coaching up a slower / not yet confident coder. And the slower coder will do vastly less damage in the interim.
- bpodgursky 4y ago
  I understand this as theoretical possibility, and it could lead you astray if you're trying to tell a 40% developer from a 60% developer... but in practice I have never met a superstar IC who doesn't also ship a ton of code (even while they help out others). If you fire the 10% of ICs who push the least code, to within a rounding error you're extremely unlikely to regret it.
  - Foobar8568 4y ago
    Your best engineers are facilitators, not coding monkeys.
    - bpodgursky 4y ago
      Your best engineers are both.
      - Foobar8568 4y ago
        You can't do both unless you are one in your team. The more people, the less code you'll do. Software engineering goals is to solve human problems, you can't escape human relation, which eventually means facilitating stuff.
    - manigandham 4y ago
      Those are not engineers then, they're managers. It's strange to see this confusion when it comes to software. Any other discipline and you wouldn't say engineers that don't do any engineering are the best engineers.
saagarjha 4y ago
I’m going to respond to the second half of your comment because the first part is trivially false and the others have already spoken to that: do you think Google should cut all teams but those involved in advertising? Because the rest aren’t making money. Why keep them around?
- hnfong 4y ago
  Ironically that might not be such a bad idea. If the assumption is that Google is unlikely to make further gains beyond online advertising, shareholders would gain more profit in the long run by cutting the teams, and talented people might move to companies that are better at making money in the other areas. The problem is that upper management don't want to be the one declaring that they're giving up on growing the company. Especially that they have billions of dollars to spend/waste every year.
twawaaay 4y ago
> No heuristic is perfect, but it's fairly easy to quantify empirically from activity/records. Developers who are productive (actually write and ship large amounts of quality code) tend to be valuable and those that don't, aren't. If you are factory line worker, yes. If you are a developer or a manager (a "knowledge worker") -- what you could be observed to be doing has usually little correlation with result for the company. I know people who are busy producing total crap, managers completing tons of projects achieving bad results, very energetically with huge fanfare. And I know admins that have everything so well automated and working reliably that they are watching youtube whole day, their managers none the wiser about what could have been. Or people who do nothing and have one brilliant idea a year that saves the company tons of expenses. And every other type inbetween. In a lot of teams it is usual for senior developers to produce relatively little code compared to juniors, when looking at the value they are creating. Maybe because they spent most of their time doing other things like helping juniors, doing code reviews, designing new solutions, talking to clients. Or maybe because they are getting the most complex problems. If you can measure this you would deserve Nobel Prize. A more likely explanation, though, is that you have no idea how complex the problem is. In those cases I like to remind people of this famous little story: https://www.folklore.org/StoryView.py?story=Negative_2000_Lines_Of_Code.txt https://www.folklore.org/StoryView.py?story=Negative_2000_Li... In my experience working many decades, in most teams there are few individuals who are making things go and frequently not even their direct managers understand how people are exactly contributing to productivity.
- kingcoleman 4y ago
  I didn't read your entire comment and realized you suggested the same link. What's old is new again.
- twawaaay 4y ago
  I don't like to respond to my own posts but I forgot to include something which I think is important. Unfair "heuristics" create unhealthy incentives that are typically way more damaging than having little clarity. 1. People feel treated unfairly and their engagement drops off a cliff at that point in time. People can be happy even accepting a punishment AS LONG as they FEEL they are being treated fairly. 2. People feel pressed to do things for show, just to appease measurements even if they don't believe it is right. Soon they are fine doing substandard or even completely shoddy work even in areas that are not measured, because that's what people do. People do not just selectively resign from doing good work -- if they feel they are asked to do bad work somewhere they will also do it in other areas and find a rationale for it. 3. People who will not accept bullshit and would want to do right regardless of unfair measurements, will evaporate from your company. They usually leave on their own. This will leave your company worse overall -- with no people who will tell managers the truth when it is needed the most. 4. The corporate, thinking they have measurements, stop looking to actually do better. The measurements become everything. It is frequently better to not pretend you solved the problem and accept the problem is hard and try to do best anyway.

akg_67 4y ago

> The problem is, nobody knows how to tell which ones. I guess there is no leetcode BS for firing. May be someone create one so that circle of sucks can be completed.

aiisjustanif 4y ago
I worked somewhere that did this. They restructured the same teams with new managers, mandatory tests to get into your same “new” team. Strangler Fig Pattern style.