zlacker

>>moored+(OP)
And most people problems are communication problems. Engineers aren't engaged with the product vision or the customer base, and are allowed to silo themselves. Product doesn't see the point of engineers being engaged and feed the engineering team like an in-house outsourcing shop. Sales and CS fail to understand the cost of their promises to individual customers to the timelines of features they're hungry for from the product plan. Goals and metrics for success fail to align. And thus everyone rows in their own direction.

The solution usually isn't "better people." It's engaging people on the same goals and making sure each of them knows how their part fits with the others. It's also recognizing when hard stuff is worth doing. Yeah you've got a module with 15 years of tech debt that you didn't create, and no-one on the team is confident in touching anymore. Unlike acne, it won't get better if you don't pick at it. Build out what that tech debt is costing the company and the risk it creates. Balance that against other goals, and find a plan that pays it down at the right time and the right speed.

>>jeffhe+Gs
> Build out what that tech debt is costing the company and the risk it creates

How to do that? Genuine question.

>>_def+du
If there's a legit, measurable performance or data integrity problem, start with that. If most of your production bugs come from a specific module or service, document it.

If it is only technical debt that is hard to understand or maintain, but otherwise works, you're going to have a tougher time of building a case unless you build a second, better version and show the differences. But you could collect other opinions and present that.

Ultimately you have to convince them to spend the time (aka money) on it and do it without making things worse and that is easiest to do with metrics instead of opinions