| Sure, but there are a lot of efficiency killers to look for before you need to worry about individual hours worked. Adding 20% more people doesn't make the software come out 20% faster because: 1) Multiple people need to work on the same critical section of the code, and then there are merge conflicts. (Or people disagree on the design, or refactoring becomes a higher priority than doing what users want, etc.) 2) People work sloppily and omit relevant tests, only for someone else to have to re-discover the bug, fix it, and write the tests (trading productivity from one person to another). 3) People work on the wrong tasks, adding 20% more technical debt but not fixing 20% of the highest-priority bugs. 4) People take 20% less responsibility so you end up with "someone else will handle that (where "that" is usually documentation, monitoring, deployment, or anything else not explicitly captured in your list of bugs/priorities). It is very interesting to me how internal software development often fails (I'm sure I've been the point of failure before), but software development CAN scale. I use AWS, for example, and I'm sure their software engineering teams are messing with products/features that my team uses. But they don't make me 20% slower. Ultimately, overly-tight coupling gets you every time. But on the other hand, too much isolation can also be a problem (time spent overengineering). If you find that balance, you can scale your team infinitely ;) |