So without absolving all engineering orgs of all of their inefficiencies forever, let's start with the Bus Factor.
Now, technically the Bus Factor is more about the company completely collapsing, but in an optimal organization, each person is doing something critical to the survival of the company all of each workday. They aren't spending 4 hours on Facebook or creating meaningless menu changes no one cares about. Maybe if one of them were hit by a bus the company wouldn't be completely unable to function, but their coworkers would struggle to continue to keep everything running.
This isn't really a good plan in the long run, even if it is most efficient until someone gets hit by a bus, so instead you over staff a little. You can't quite just hire N extra employees at the company level and expect them to be able to jump in seamlessly to any gaps that appear as other employees quit or retire or die, so you instead end up overstaffing by 10-20%. To every group of five or ten employees, you add an extra whose job responsibilities overlap the rest. Now if someone leaves, you have their replacement already halfway ramped up, and you can spread their responsibilities around without creating too much stress.
Now, you could just let all of your employees work 10% less hard, now that they have someone else to help lighten the load, but that's not really efficient either. Granted, some of them will find a way, and that 40 hours nominal becomes 36 hours real work and 4 hours posting on HN, but you can still add some extra work on top.
So you tell your employees that, in addition to the bread and butter work that pays the company's bills, they also have to Do Something else. Maybe there are some ideas for improving the company's core product, new types of bread, different flavors of butter to try out. Maybe you tell them to spend 20% of their time on bluesky research.
This brings us to the problem of making changes to a big, complicated engineering project. When you are just maintaining a giant piece of software, that's kind of a linear problem -- you assign a person or two to each part of the infrastructure, and they keep it in shape. When you are improving the giant interconnected pieces of infrastructure, it becomes a quadratic -- if someone on Service A comes up with a neat idea for how to make it better, they're going to need people on Database B, Backend C, Frontend D, Logs E and twelve other departments to make corresponding changes to their pieces of the infrastructure as well.
So the end result of this is that you have a piece of software that could be maintained indefinitely by 2 people, you add a third for redundancy, a fourth and fifth to iterate on new features, and three or four more to keep up with infrastructure changes in related projects elsewhere in the company.
And ta-da, your simple project is now overstaffed by 4x.
Now, technically the Bus Factor is more about the company completely collapsing, but in an optimal organization, each person is doing something critical to the survival of the company all of each workday. They aren't spending 4 hours on Facebook or creating meaningless menu changes no one cares about. Maybe if one of them were hit by a bus the company wouldn't be completely unable to function, but their coworkers would struggle to continue to keep everything running.
This isn't really a good plan in the long run, even if it is most efficient until someone gets hit by a bus, so instead you over staff a little. You can't quite just hire N extra employees at the company level and expect them to be able to jump in seamlessly to any gaps that appear as other employees quit or retire or die, so you instead end up overstaffing by 10-20%. To every group of five or ten employees, you add an extra whose job responsibilities overlap the rest. Now if someone leaves, you have their replacement already halfway ramped up, and you can spread their responsibilities around without creating too much stress.
Now, you could just let all of your employees work 10% less hard, now that they have someone else to help lighten the load, but that's not really efficient either. Granted, some of them will find a way, and that 40 hours nominal becomes 36 hours real work and 4 hours posting on HN, but you can still add some extra work on top.
So you tell your employees that, in addition to the bread and butter work that pays the company's bills, they also have to Do Something else. Maybe there are some ideas for improving the company's core product, new types of bread, different flavors of butter to try out. Maybe you tell them to spend 20% of their time on bluesky research.
This brings us to the problem of making changes to a big, complicated engineering project. When you are just maintaining a giant piece of software, that's kind of a linear problem -- you assign a person or two to each part of the infrastructure, and they keep it in shape. When you are improving the giant interconnected pieces of infrastructure, it becomes a quadratic -- if someone on Service A comes up with a neat idea for how to make it better, they're going to need people on Database B, Backend C, Frontend D, Logs E and twelve other departments to make corresponding changes to their pieces of the infrastructure as well.
So the end result of this is that you have a piece of software that could be maintained indefinitely by 2 people, you add a third for redundancy, a fourth and fifth to iterate on new features, and three or four more to keep up with infrastructure changes in related projects elsewhere in the company.
And ta-da, your simple project is now overstaffed by 4x.