Hacker News new | ask | show | jobs
by closeparen 2682 days ago
Two of the most under-appreciated insights in software engineering: concurrent work in progress has a productivity cost, and team size has a productivity cost (The Mythical Man Month).

If you ever want to see cognitive dissonance in action, try talking about this with engineering managers at a hypergrowth company. They will smile and nod and agree and go right back to pushing for ever increasing scope + headcount and and acting surprised when they don’t get linear-plus returns. There’s a really persistent belief that you can just grow the team faster than the backlog and everything will be fine.
2 comments
Gibbon1 2682 days ago
On the wall of my dad's office in the 1970's was the universal problem solving flow chart. And a poster that said putting more people on a project in trouble is like putting out a fire with gasoline.

I follow the former when maintaining software/hardware. And totally seen the second in action. Add more people to the project and watch the deadline slip another couple of months automagically.

Also remember first company I worked at. The shop eventually adopted a policy at my suggestion. If it isn't ready to be boxed up and shipped when people come back from lunch, it's not shipping today. That put a stop the constant Chinese fire drill of trying to get stuff out the door before UPS came. Perversely we started shipping more stuff on time.

link
xiphias2 2682 days ago
I have seen this change when I was working at Google. The key problem was that the PM to Engineer ratio increased in the company, and we were getting a lot of extra work from the PMs that looked nice on paper, were easy to understand, but didn't have a real positive impact on the customer. This extra work completely blocked us from improving the performance of the product.
link
JoshTko 2682 days ago
As a PM I'm curious what type of work that falls into this category. Also curious if this was specifically coming from the PM or if it was coming from above.
link
xiphias2 2682 days ago
It usually came from sales and other teams. The big difference that I saw is that in the past to give an engineering team work from another team meant that the other team's TL had to convince the TL of the team to take the work, and the TL had enough context to push back (which I believe is the best thing to do in most of the cases).

In the old Google PMs were working on promoting the work of engineering teams and communicating with sales/ops, but didn't have a strong power over the direction of the work of the engineering teams. Their time was a scarce resource to be used by the team, not extra bosses. In the new Google, PMs have a lot of time that they are using for fighting with each other to have some feature implemented that they are pushing.

Also the best PMs in the old Google had some engineering background, and were doing log analysis without asking help from the engineers for every question.

link