Hacker News new | ask | show | jobs
by OliverGilan 2115 days ago
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
5 comments

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.

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

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

That can happen too, though I think you're saying the opposite of the parent comment.
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.
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.

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.

Then you just end up with the first team continuing to produce garbage, and leaving it up to the 'fixers' to clean it up.
And the innovation team will have stellar resumes while the people who fix things will look like outdated dinosaurs.
That is an instant morale problem.