3 ms·

Most of these, I think, relate to a single kinda-meta-problem. Managing software orgs is hard, and most orgs can't do it well. Using additional management meth

Most of these, I think, relate to a single kinda-meta-problem. Managing software orgs is hard, and most orgs can't do it well. Using additional management methods, more managers, and more engineers can make the software org less efficient. Software production is weird. Efficiency of software orgs is extremely plastic. An effective 15 person team can outperform a 150 person team and this is normal. Very extreme compared to most fields employing such numbers. Software can be really important & high value. Value can be utterly disconnected from the cost of producing it. I say "less efficient" purposely rather than "worse." It might actually make sense to go from an efficient 25 person team to an inefficient 500 person team. The additional cost of might be dwarfed by the benefits of marginally more higher output. That might be better economically (even socially), but less efficient. If you're in one of these orgs, you will not be more happy though. Efficiency feels good. Inefficiency feels bad.

pid-1 4y ago
> If you're in one of these orgs, you will not be more happy though. Efficiency feels good. Inefficiency feels bad. I think there's a sweet spot that's particular to each project and collective skill set. Being in a small team and feeling anxious due being responsible for way too much stuff isn't fun as well.
- dalbasal 4y ago
  IDK. If you're in one of these too-small-high-pressure teams, and then all these extra "resources" get poured in... It can go quite badly too. IMO, engineers themselves are sometimes responsible by leaning on "we need more resources."
  - mr90210 4y ago
    Same thing happening at the small team I am part of, we have just hired a fifth engineer, while the business often struggles to define what’s a priority.
  - nevinera 4y ago
    I think engineers often say "we need more resources" but mean "we need to have hired more resources two years ago".
    - ratww 4y ago
      True. In some cases it can also mean that the team needs to limit the scope and focus on what really matters. Sure, there's lots of startups burning the midnight oil to finish that MVP. But especially on more mature teams, it's incredibly easy to lose focus when doing software and spend several days on shitty features that don't really matter at all to customers, but are being prioritised due to inertia or capricious management.
    - dalbasal 4y ago
      One liner of the day. That's the best possible way to make this point.
    - therealdrag0 4y ago
      Yap, I’m leading a project that could use more engineers (just two of us) cuz it’s going to be tight to hit an upcoming scaling deadline. But the thought of spending my time ramping up other engineers at this point doesn’t sound good.
  - computronus 4y ago
    This sounds like a variation of Brooks's Law - adding people to a late software project makes it later. In this case, now you need to take time to help the new resources ramp up, and the new resources themselves can't make meaningful contributions right away. So the pressure isn't alleviated for a while, and in fact goes up.
kqr 4y ago
This is a great point. I've never thought about it in these terms before, but whenever I've transitioned from organisations that feel like they're "run by engineers" into organisations that feel like they're "run by administrators" I've taken a hit in happiness.
quantum_state 4y ago
Very much true but not really recognized by management in general.
Jare 4y ago
> If you're in one of these orgs, you will not be more happy though. Efficiency feels good. Inefficiency feels bad. Depending on your outlook, character and experiences, the magnitude of the results can make it worth your while; there's certain objectives that you can't hit without massive throughput (and waste). And reducing or keeping under control the amount of waste in a large scale project can also be incredibly satisfying.
iancmceachern 4y ago
I would argue it applies to most engineering disciplines, not just software.
Buttons840 4y ago
> An effective 15 person team can outperform a 150 person team Which is subtly different than saying a 15 person team can do the same job as a 150 person team. The full story is the first 15 people (be they developer or project managers) will determine whether you need 150 people in the future. Naturally, all of my jobs have been at 150 companies (since that's where most of the jobs are), places where the earlier developers and PMs have balloon the amount of work to be done is a very unhealthy and inefficient way. Then I'm hired and continue to do the same. I learned about R0 ("r not") in the pandemic, the number of other people someone infects on average, and I've imagined a "W0" at my jobs. How much work does a developer, on average, add or remove from the future of the company? Unfortunately, I believe I am a >1 W0 developer in my current job, my current work will only create more work in the future, and the company will have to hire more and more developers forever. I don't consider this my fault, but the fault of project management. It's also why I'm not worry about future job security.
- Jensson 4y ago
  People who want to be managers tend to create solutions where you need to assign more reports to them. I don't think this is incompetence, it is a reasonable way to advance your career at the expense of the company, similar to how engineers tend to choose frameworks that helps their careers etc.
hcarvalhoalves 4y ago
> Efficiency of software orgs is extremely plastic. An effective 15 person team can outperform a 150 person team and this is normal. "Software is eating the world", but most companies where software is either the product or a central part of the strategy (as opposed to a cost center) are still managed by people who either don't understand, or refuse to accept, that software is primarily _creative_ work, with a strong _collaborative_ component. In an attempt to reduce risk of an inherently risky creative endeavour, the management will over-hire and over-manage. Biggest example is open-source: collaborative work done by random strangers on their own time and budget is competitive, and not rarely _way better_, than software produced by well-funded companies with competent people.

pid-1 4y ago

> If you're in one of these orgs, you will not be more happy though. Efficiency feels good. Inefficiency feels bad. I think there's a sweet spot that's particular to each project and collective skill set. Being in a small team and feeling anxious due being responsible for way too much stuff isn't fun as well.

dalbasal 4y ago
IDK. If you're in one of these too-small-high-pressure teams, and then all these extra "resources" get poured in... It can go quite badly too. IMO, engineers themselves are sometimes responsible by leaning on "we need more resources."
- mr90210 4y ago
  Same thing happening at the small team I am part of, we have just hired a fifth engineer, while the business often struggles to define what’s a priority.
- nevinera 4y ago
  I think engineers often say "we need more resources" but mean "we need to have hired more resources two years ago".
  - ratww 4y ago
    True. In some cases it can also mean that the team needs to limit the scope and focus on what really matters. Sure, there's lots of startups burning the midnight oil to finish that MVP. But especially on more mature teams, it's incredibly easy to lose focus when doing software and spend several days on shitty features that don't really matter at all to customers, but are being prioritised due to inertia or capricious management.
  - dalbasal 4y ago
    One liner of the day. That's the best possible way to make this point.
  - therealdrag0 4y ago
    Yap, I’m leading a project that could use more engineers (just two of us) cuz it’s going to be tight to hit an upcoming scaling deadline. But the thought of spending my time ramping up other engineers at this point doesn’t sound good.
- computronus 4y ago
  This sounds like a variation of Brooks's Law - adding people to a late software project makes it later. In this case, now you need to take time to help the new resources ramp up, and the new resources themselves can't make meaningful contributions right away. So the pressure isn't alleviated for a while, and in fact goes up.

kqr 4y ago

This is a great point. I've never thought about it in these terms before, but whenever I've transitioned from organisations that feel like they're "run by engineers" into organisations that feel like they're "run by administrators" I've taken a hit in happiness.

quantum_state 4y ago

Very much true but not really recognized by management in general.

Jare 4y ago

> If you're in one of these orgs, you will not be more happy though. Efficiency feels good. Inefficiency feels bad. Depending on your outlook, character and experiences, the magnitude of the results can make it worth your while; there's certain objectives that you can't hit without massive throughput (and waste). And reducing or keeping under control the amount of waste in a large scale project can also be incredibly satisfying.

iancmceachern 4y ago

I would argue it applies to most engineering disciplines, not just software.

Buttons840 4y ago

> An effective 15 person team can outperform a 150 person team Which is subtly different than saying a 15 person team can do the same job as a 150 person team. The full story is the first 15 people (be they developer or project managers) will determine whether you need 150 people in the future. Naturally, all of my jobs have been at 150 companies (since that's where most of the jobs are), places where the earlier developers and PMs have balloon the amount of work to be done is a very unhealthy and inefficient way. Then I'm hired and continue to do the same. I learned about R0 ("r not") in the pandemic, the number of other people someone infects on average, and I've imagined a "W0" at my jobs. How much work does a developer, on average, add or remove from the future of the company? Unfortunately, I believe I am a >1 W0 developer in my current job, my current work will only create more work in the future, and the company will have to hire more and more developers forever. I don't consider this my fault, but the fault of project management. It's also why I'm not worry about future job security.

Jensson 4y ago
People who want to be managers tend to create solutions where you need to assign more reports to them. I don't think this is incompetence, it is a reasonable way to advance your career at the expense of the company, similar to how engineers tend to choose frameworks that helps their careers etc.

hcarvalhoalves 4y ago

> Efficiency of software orgs is extremely plastic. An effective 15 person team can outperform a 150 person team and this is normal. "Software is eating the world", but most companies where software is either the product or a central part of the strategy (as opposed to a cost center) are still managed by people who either don't understand, or refuse to accept, that software is primarily _creative_ work, with a strong _collaborative_ component. In an attempt to reduce risk of an inherently risky creative endeavour, the management will over-hire and over-manage. Biggest example is open-source: collaborative work done by random strangers on their own time and budget is competitive, and not rarely _way better_, than software produced by well-funded companies with competent people.