4 ms·

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 understa

by kakwa_ 9y ago

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. I've also worked at former startup bought by a big company, with more than ample resources. Yet there were tons of issues. Many teams having huge difficulties to communicate with one another, tons of features in the roadmap but very few made it into production and those in production were barely working and were a pain to keep up, the core functionalities of the product were slowly rotting away, long, annoying and not understood processes just cluttered everything and pieces of knowledge/information spread more like rumors with all that entailed of inaccuracies and wrong ideas... I could not shake the feeling that with fewer people, we could actually have had a better and faster output. It may be an extreme case of scale-up (in term of headcount) gone bad, but I'm pretty sure I'm not the only one with a story like that... 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. In the end everything goes way faster and it's far more rewarding as an employee to work in that kind of environment. The issue is that past a certain headcount, flat organizations don't work anymore, however, when designing our products, maintaining the headcount as low as possible should really be a big item in the requirements. Growing the headcount for growing the headcount seems ludicrous from a purely technical point of view. But I can understand that a larger headcount might make a company more credible and valuable from an external eye. I understand it but I'm far from a big fan of it.

tormeh 9y ago
>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.
- krob 9y ago
  I feel like we have worked for the same type of company or the same company ^_^
lou1306 9y ago
> 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.
- flukus 9y ago
  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.
hvidgaard 9y ago
> 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 https://www.stilldrinking.org/programming-sucks).
mathattack 9y ago
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.

by kakwa_ 9y ago

tormeh 9y ago

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

krob 9y ago
I feel like we have worked for the same type of company or the same company ^_^

lou1306 9y ago

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

flukus 9y ago
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.

hvidgaard 9y ago

> 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 https://www.stilldrinking.org/programming-sucks).

mathattack 9y ago

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.