Hacker News Reader

> When management finally released that the said deadlines could not be met, they hired really fast, and not carefully, a bunch of people [...] In the end it put us even more behind schedule than before.

Nothing new under the sun. This is from the Tao of Programming (1987):

A manager went to the Master Programmer and showed him the requirements document for a new application. The manager asked the Master: "How long will it take to design this system if I assign five programmers to it?"

"It will take one year," said the Master promptly.

"But we need this system immediately or even sooner! How long will it take if I assign ten programmers to it?"

The Master Programmer frowned. "In that case, it will take two years."

"And what if I assign a hundred programmers to it?"

The Master Programmer shrugged. "Then the design will never be completed," he said.

It was well known by then even, from the Mythical Man-Month (1975):

> adding manpower to a late software project makes it later

More then 4 decades later it seems like we still have learned.

>Well, at least for the purely engineering part (aside from sales), I've seen the contrary more often than not.

>Earlier I my career, I've seen projects understaffed with tight deadlines. When management finally released that the said deadlines could not be met, they hired really fast, and not carefully, a bunch of people to try to reach that deadline. Those new people needed to be on-boarded, trained, and sometimes put aside because they didn't have the required competences. In the end it put us even more behind schedule than before.

The parent is talking about enterprise software, where costs per customer are very high. These companies live on contracts. They may have a core product, but each new customer requires a lot of development. These kind of organizations can scale linearly because each customer basically gets its own team. Consulting is the extreme version of this.

I feel like we have worked for the same type of company or the same company ^_^

Having these rule of thumbs as guidelines doesn't mean that they're actually followed. :-)

One thing I've seen in tech companies is they invest heavily in engineering at the beginning, justifying it as a fixed cost. As the company grows, they stop growing the so called "fixed" cost, and hire more in sales, services and support. (So called "variable" costs) The reality is these salespeople sell custom deals to hit their revenue #s (especially in tough quarters) so the engineering work goes up. If staffing doesn't go up, you wind up with tremendous technical debt.

> I'm a fervent believer that flat organizations are way better, you can discuss directly with people, the pain points and challenges are clearly identified and solved together.

You don't want it entirely flat, and you don't want it rigorously hiarical. You have touched on too hiarical, but too flat is a thing as well. Someone with the skill and time needs to make descisions, and someone needs to keep track of things and coordinate. Both of those things are important even for small teams for 5-6 people, otherwise you end up with "The Bridge"(https://www.stilldrinking.org/programming-sucks).