3 ms·
The author is writing about the common story of how to grow and scale. Each team gets a product, spinning off teams, etc. What if like most products there is a
by r0ze-at-hn 2y ago
The author is writing about the common story of how to grow and scale. Each team gets a product, spinning off teams, etc. What if like most products there is a ramp up period where you need a full team (or teams) and then a few years later the product needs at most a fraction of the people to maintain the product? All of these people are going to "do stuff" because they are paid to do stuff further increasing the maintenance burden. You run head first into the common problem of:
"I have 1000 engineers and I can't get anything done!"
In the worst case the CEO solves this by doing lay offs. Been thinking about this problem for over a decade, making effective engineering organizations that can not only grow, but change shape is difficult, but can also be very rewarding when done successfully.
- marcosdumay 2y agoI dunno. The obvious answer is that then you make another product. and another, and another. But very few companies are able to do this for some reason.
- wavemode 2y agoCreating products is very easy. Creating products that generate a profit is very hard. If a company could do so on demand, it would be an infinite money glitch.
- osigurdson 2y agoI don't think it is really like that. Growing a code base at first is very fast, but then slows down entirely due to the human "context window" being limited. So unfortunately, you need more people to maintain a million line code base than a 1000 line one.
- vasco 2y agoYou declare things under maintenance mode and you stop work on them other than to solve incidents or implement the postmortem improvements. If you do this all the time for "finished" bits and instill a culture of "getting to done" in your engineering, it'll just be normal every quarter to move some stuff into maintenance and free up time.