One thing I've realized is that people in different roles have different levers to solve problems, and they naturally skew to using that lever to try and solve all problems, even if that lever can't solve the problem and could make it worse.
A manager, to which directors, CEOs, and so on are all included in, have this lever which is that they can hire more people and create new roles/re-organize teams. And they skew towards it for many problems...
We want to deliver features faster, what can I do, me, a manager?
- I could hire more engineers!
- I could reorganize my engineers so each one works on a specific type of issue
It becomes really hard to accept that, maybe, as a manager, you can't do anything about it, except support and encourage those that can, like the engineers themselves. How could you help them deliver features faster?
I'm picking at managers, but every role has this issue. Engineers have this lever of "technical ingenuity". And they skew to it as the solution to all problems.
We want to deliver features faster, what can I do, me, a software engineer?
- I could rewrite this in a more productive language/framework
- I could redesign this to make it simpler and easier to work on
I was listening to a podcast with Joel Spolsky recently. He told a story that when he went to Microsoft, they had done internal research (and experiments) to debunk some of the theories from Fred Brooks' "Mythical Man Month". At the time, he generally believed in the "rules" from "Mythical Man Month", and was pleasantly surprised to learn about this further research. In short: Adding more developers does help, up to a certain point.
Fred Brooks never said that adding more developers does not help -- he was stating that solving the single problem of being late will only be exacerbated by adding more people.
To use the infamous analogy that "nine women can't make a child in one month": it is still true, but if your goal is to have more children (as opposed to having one child be born sooner), adding more women would certainly help.
It’s been a while since I read it, but I thought the “actual” rule as articulated was. “Adding people increases communication overhead. At a certain point, more people cannot increase speed but actually makes things slower”.
Hence the more pithy “Adding people to a late project will make it later”. The assumption being that you’ve already maximised the number of people that could work on the thing (trying to get it out the door on time).
> Adding more developers does help, up to a certain point
Did it mention any insight on what that point is? And did it contrast against any other approach in the studies? Like look at opportunity cost of this versus other ways to deliver faster?
P.S.: And I didn't mean that those levers are always wrong, more that I've noticed this bias towards the main levers each person has at their disposal. If there's no check on that bias, you, for example, end up in a company that keeps hiring at a furious pace and keeps rewriting all their services all the time in new languages or alternate designs to no end, because everyone just uses their obvious lever as much as possible with the good intent of trying to solve all the problems in the way they can.
The main thing a good manager can do is act as a wall between the engineers and everyone above them, which is hard to do politically because it exposes a whole subtree of the org chart as useless.
I think that's a little myopic because that subtree is providing the comfortable fiction that you can just go into work, do engineering, go home, and get a paycheck. I'm not saying I don't want to blow my brains out dealing with them but it's comparably a small amount of pain in return from being completely insulated from all of the realities of operating a business and the messiness that entails.
And sometime you really can't do anything except but waiting and letting the potatoes to grow, so to speak ("We plant potatoes in the spring, and harvest them in the autumn" — "Well, we plant potatoes in the morning and harvest them in the evening" — "Wow, do they really grow that fast at yours?" — "No, we just become really hungry by the evening").
I believe that the GP's point was that different roles have different tools in the box that are more efficient in their particular areas, and tend to rely on these rules even when solving problems in other areas.
It is very common to see engineers trying to solve non-engineering problems using the "technical ingenuity" to attempt resolving social issues; sometimes it works well enough (e.g. timezones), and sometimes it fails pretty miserably (e.g. OLPC).
Exactly, and I'd claim this is even true in their area as well. "Technical Ingenuity" is the obvious arsenal in an engineer's bag, and that's why it will bias engineers as the solution to all problems, even engineering problems.
For example, on a previous team we had an issue where configuration was littered in too many places. It was confusing, and people didn't know where to change what in order to onboard a new client, and they'd always forget something.
Well, most engineers went directly to re-architecting/refactoring as the solution. We should centralize all config in some new central config store, and have all systems pull their configuration from there. Once it's all in one place, it'll be clear what to change and we can't forget to change any.
One engineer though said, we just need a good wiki that clearly describes all the steps. Well, that took about 2 days, and it solved the problem. No technical ingenuity needed.
A manager, to which directors, CEOs, and so on are all included in, have this lever which is that they can hire more people and create new roles/re-organize teams. And they skew towards it for many problems...
We want to deliver features faster, what can I do, me, a manager?
It becomes really hard to accept that, maybe, as a manager, you can't do anything about it, except support and encourage those that can, like the engineers themselves. How could you help them deliver features faster?I'm picking at managers, but every role has this issue. Engineers have this lever of "technical ingenuity". And they skew to it as the solution to all problems.
We want to deliver features faster, what can I do, me, a software engineer?