There are a bunch of ways to describe the quality of a product you want to sell; here's three of them.
- Are most of the engineers who worked on it proud of their work?
- Are people likely to pay for it?
- Are people who paid for it likely to recommend it to others?
But I'd argue these three are a hierarchy; you can't have one, sustainably, without accomplishing the others before it. If people don't use your product, you're not going to get them to recommend it. And if your engineers aren't proud of the work... that's a bad, bad sign, and unless you know all the reasons, it's dangerous to move forward blindly.
If your engineers aren't proud of their work, they won't work as hard, they won't work at the same quality, and they'll leave the team sooner instead of later, all other things equal. If your product has any complexity - almost all do! - higher-than-normal attrition of engineers is just about the worst thing you can have happen; after long enough on any product, engineers have knowledge in their heads that's more costly to replace than their actual paychecks.
Most of the reasons an engineer lacks pride in their work fall into:
- They don't really understand the product. ("Who buys this? Reality show contestants?")
- They don't think the product is good for the users. ("This is a hot mess, and I don't want my name on it.")
- They're afraid of the technical debt that was accrued. (It's hard to fix bugs, it's hard to add functionality, and/or it's hard to scale.)
Those are things any lead can fix... if they know which one's the problem.
For the first, there's a reason you built the thing; someone understands the product. Having them communicate why this is a good idea is a great plan, on day one, and anyone new entering the group needs to hear it as well. That said, this isn't usually the failure, as they wouldn't have *joined* the team if they thought this was the case. For the latter two? There's a common strategy that can work here.
Document the difference, and have an open and funded plan for going from here to there.
If an engineer feels the product isn't good for the users, ask them to write out what changes would be needed to get to the best possible point; ask them what the minimum number of changes would be to get to a point where the product would be salable. Without saying the words, ask them to be the product manager, and ask them to define the milestones for success.
If an engineer is afraid of the technical debt that was accrued, ask them to write out what changes need to be taken on and accomplished to reduce that debt to healthy levels.
Take either or both lists, prioritize them, and build a plan forward. Set honest expectations on the plan: it will be staffed, the staffing will not be arbitrarily removed, and people staffed to it can be rewarded for strong work. Also set the expectation that the lowest priorities may *never* be started; other high-priority work will always come up, and it's usually more important to address that than it is to address the bottom-of-the-bucket in technical debt.
The team should be able to see the plan forward; which pieces of debt get addressed in which order. They should be able to see the commitment by management; that fixing the debt has some (small) amount of protected staffing, so that it's always getting better, albeit slowly. Finally, they should see that people making strong contributions there are rewarded similarly to people making strong contributions elsewhere; paying down debt makes the entire team faster, so rewarding some of your best people for doing this work accelerates everything else you do.
If you have that? Engineers will set down perfectionism if they see a viable path *to* that perfect world. You'll have their confidence - and substantially lower attrition - while pushing product updates to users at a frequency that's optimal, not favoring short term money or causing longer term stagnation. You'll have a better team for the same time and money invested, and if you liked them to start with, that's a win across the board.
