[montagg]

Well, yes, I am saying from a business perspective this worked. but I also think we got lucky. Around five years ago, a little before the high profile failure, we were starting to lose marketshare, and though we've been able to claw most of it back, I think it's far more due to missteps of our competitors than our own performance. Had we invested in more sustainable development earlier, I think we would have been able to move faster to take advantage of new opportunities, diversify our revenue streams earlier (adding to them now is hamstrung in large part because of tech debt), and head off competitors faster.

In fact, once we started investing in that kind of development, we did do that with a successful new feature that we developed much more quickly than we could have in the past, and it's because of that success that leaders are finally starting to prioritize building standardized and reusable infrastructure.

EDIT: I think another way to say this is, once we knew our strengths and how we'd be successful in the future, we should have operationalized that and hardened it, so we'd have a sustainable advantage over competitors. Instead, we kept the "move fast, be flexible, and throw man-hours at problems" mentality too long, and it put us at risk.

[OliverGilan]

Could there be a hybrid approach? Have teams that focus on being a first mover and shipping and then once there's a product on the market, you have a secondary team focusing on fixing the tech debt early while the other team continues to iterate

[wastedhours]

At my old company we had an innovation consultant come in and tell us that kind of approach was nearly impossible to manage in the longer term. Apparently teams dedicated to holding the fort grew bitter and had much lower retention than teams on greenfield work.

Paying back the debt, he said, usually requires too much knowledge of a system to cycle teams in and out consistently enough to ensure everyone gets a piece of the new versus the old to keep them engaged.

Whether or not that was backed up by hard data, I'm not sure. It was an interesting angle I hadn't previously thought of though.

[spockz]

Calling it “just holding the fort” would indeed be disadvantageous. If instead the teams would be empowered and rewarded for also keeping things running and improving on them it will attract the right kind of people which do grow the product and don’t get bitter. However, I have yet to meet an engineer who is comfortable maintaining a sunset product and in the mean time getting only flak about the performance of the old sunset application/feature or their own performance.

[dane-pgp]

> Apparently teams dedicated to holding the fort grew bitter and had much lower retention

As someone who found themself in the "holding the fort" team, I can confirm that this analysis is at least anecdotally true, although the terms I preferred at the time for the two teams were Morlocks and Eloi.

[spaetzleesser]

“Apparently teams dedicated to holding the fort grew bitter and had much lower retention than teams on greenfield work.“

Very true. The good performers will be “rewarded” doing the things that are really important: keeping things going. And then you have low performers and interns doing the new stuff.

[nitrogen]

That can happen too, though I think you're saying the opposite of the parent comment.

[r0ze-at-hn]

Worse than the fact that those holding the fort would leave, the best of those would leave (either to another company or just as often to the exciting new projects) leaving behind those that can't leave and very rapidly you end up with a not that great group which management doesn't notice or deal with.

[montagg]

Early on, I don't think so. You need all hands on deck to move fast. But I do think you need to start establishing those Good Habits way earlier than they might be immediately valuable. For example, getting good at product and technical documentation before you have a huge company. It's so much harder to establish those habits with more people, so you want to have that built in so new folks join, and doing that stuff right is just part of the culture. A little effort today saves a ton of effort to establish those habits later. You also end up with more flexibility: Person A doesn't need to constantly support Feature A because they built it and they're the only one who knows how it works, so you're getting more value out of their time.

In the long-term, I do think product-wide you always have teams at different levels of maturity. Some know more about the problems they're solving and how best to solve them, others know less. Some will move fast, some will build to last. The more a team knows about their problem, or the more a problem cuts across teams, the more I think they should build to last, so investment in those areas scales over a large group or important areas of the business.

[coredog64]

Other people are also commenting, but IME, completely disassociating “making the think from “making the thing so that it can be supported” is a recipe for trouble.

There’s not an easy fix though, as most of the time I see orgs just punt at some point and allow the dev shop to write off all their tech debt by reassigning responsibility to an ops team.

[sundbry]

Then you just end up with the first team continuing to produce garbage, and leaving it up to the 'fixers' to clean it up.

[spaetzleesser]

And the innovation team will have stellar resumes while the people who fix things will look like outdated dinosaurs.

[JackFr]

That is an instant morale problem.

[RandoHolmes]

> Had we invested in more sustainable development earlier, I think we would have been able to move faster to take advantage of new opportunities, diversify our revenue streams earlier (adding to them now is hamstrung in large part because of tech debt), and head off competitors faster.

While that's probably true, it's a difficult balance to know when exactly you should start moving back towards the better development practices. Too soon and you die, too late and you can no longer move because you're too inefficient.