3 ms·

Hiring and building fast can lead to huge costs, loads of bugs and performance issues Hiring and building slow leads to multiple rounds of performance tuning e

Hiring and building fast can lead to huge costs, loads of bugs and performance issues Hiring and building slow leads to multiple rounds of performance tuning early on, which can also lead to lower costs, and gives you a chance to focus on improving the product by focusing on your user experience because you're not in panic mode to raise funds, overhire and conquer the world We could have many more good software products if companies were focused on long term quality and didn't obsess over growth

jordanbeiber 4y ago
Conways law. The teams and management structure will immediately become a technical debt. If we let the product ”decide” where boundaries actually exist and team up accordingly there’s a chance to scale and maintain a bit of velocity. It requires constant introspection, monitoring and scrutiny though. Something I’m constantly thinking about is how to scale that beyond 20-25 developers. Gitlab have a nice section[0] in their handbook on releases and flow of small bits and pieces, and internalizing something like that together with clear domain boundaries could be a ticket. Basically - never try to resource optimize, always figure out what good flow looks like and find ways to keep it flowing. [0]https://about.gitlab.com/company/culture/#freedom-to-iterate https://about.gitlab.com/company/culture/#freedom-to-iterate