Hacker News Reader

> 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.

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."

I think engineers often say "we need more resources" but mean "we need to have hired more resources two years 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.

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.

One liner of the day. That's the best possible way to make this point.

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.

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.

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.

> 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.

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.

> 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.

> 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.

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

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