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.

This is why I built out a Shadow Sessions program for our internal tooling teams at my BigCo.

The users are right there, go make friends. Learn what they're doing day to day. And how it fits into the larger picture.

These sessions are lightweight, and auto schedule every three weeks with no required action items and people come out of it amazed every time, lots of little bugs have been fixed, and connections are being made.

The culture of not engaging with the end users when they're so readily available is an odd one to me. And you can really get to say 80% of macro picture understanding and user experience design fundamentals with a fairly low lift.

To do this I created a sign up form and an auto scheduler that interacts with the Slack API. The scheduling and getting folk on board is the hardest part. Also finding time if you do things outside the product road map.

You might be ducking the hypothetical. It's not just communication.

> Unlike acne, it won't get better if you don't pick at it.

Actually, that's exactly what technical debt is: stuff that's better left alone for the moment. The problem is that those decisions pile up and bury you.

> Engineers aren't engaged with the product vision or the customer base,

> It's engaging people on the same goals and making sure each of them knows how their part fits with the others

You don't get 15 years of technical debt in organizations where it's possible for everyone to know everything. Your solution increases coordination costs, but that's exactly what blocks decisions on the merits, when people who know little or have little stake have the same say.

The solution is accountability, but I've never seen that introduced successfully on a large scale to a corrupted organization. Typically instead it starts in a small team, and that team grows to manage the entire stack; sometimes they start internally, but more commonly they come via merger or spin-out.

More generally, technical debt is a self-replicating attractive nuisance. Anyone can see and complain about it and use it as an excuse. Very few can fashion a solution, and those who do it without throwing out the system are rarer still. So the culture evolves to sustain it, selecting for people who know just enough to avoid it but not enough to fix it.

I think it’s because companies don’t incentivize people listening to each other. Management doesn’t listen to the underlings and the underlings have to compete to get noticed.

I have only a few people with whom I can discuss something in depth without anybody pushing an agenda. With most people it’s just about pushing through what you want to do.

I am just going through a bunch of sessions where a director has engaged consultants to change our stuff to use a new platform. Nobody who works on the system thinks it makes sense but it can’t be stopped because of the director and a few yes men. Nobody listens.

"Better people" solves a lot! But definitely not everything. But a lot!

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

How to do that? Genuine question.

And all communication problems involve one or more senders and one or more receiver. The issue is you only got to be in control of one side. And even flawless massaging won't save you from incapable or unwilling receivers.

As someone who has worked in IT support I have seen users habitually click away clearly formulated error dialogs that told them exactly what the cause of their problem was and how to address it. Only problem? They did not read it, as became clear when I asked them what it said.

I have had people who I repeatedly had to explain the the same thing, made sure they got it by having them do it twice and a week later they would come again with the same question like sheep, not even aware they asked that one before.

Some problems are communication problems. Others are actual people problems that could indeed be solved by getting better people. Anybody who says otherwise is invited to do first level support for a year.