This is a very interesting post, but I'm not sure I agree with this one: > K. Progressively overload the team: Pick goals for the team that are ambitious and j

This is a very interesting post, but I'm not sure I agree with this one: > K. Progressively overload the team: Pick goals for the team that are ambitious and just a little bit impossible. This has two effects: one, it forces the team to prioritize ruthlessly, where you cut out anything inessential for success; and two, it pushes the team to somehow find leverage through system design, where you find new ways to deliver the same result without as much code / complexity because you literally don’t have cycles to write the code / manage the complexity. This can be effective, but so often (especially with skunkworks and greenfield development in general) you pay a price for this in the form of tech debt. In some cases the tech debt can be iterated out of later, but in the vast majority of the cases I've seen that does not happen. IMHO the biggest disservice that most managers do to the company and the future engineers of the team is oversubscribe the team and push them to cut corners or make bad assumptions in order to get something shipped. It can easily 10x the cost of developing/maintaining the product down the road, whereas with a project that is well managed/developed can eventually go into a pseudo maintenance mode with a fraction of the manpower required to keep it alive. It's more an art than a science and you'll never get the balance perfect, but I would strongly suggest you go for "balance" rather than following the almost universal approach in our industry now of, "ship it now, fix it later." By the way, if you want to know why so much modern software sucks and is buggy as hell, I would humbly suggest that this is the reason!