When a team tells me something is a "technical problem," I've learned to check the org chart before the codebase.
Not always, but often enough to make it a default. The bug isn't in the code — it's in who owns what, who talks to whom, and what gets rewarded.
How It Shows Up
Unclear ownership is the most common one. Two teams think the other is responsible for a service. Nobody monitors it properly. It breaks, and the incident review becomes a finger-pointing exercise. The fix isn't a better monitoring tool — it's deciding who owns the service and making that visible.
Bad incentives are subtler. A team is rewarded for shipping features, so they ship fast and skip documentation. The next team inherits undocumented code and moves slowly. The "slow team" gets scrutinized, but the actual problem is upstream.
Communication gaps compound everything. Teams that don't talk to each other build systems that don't talk to each other. Conway's Law isn't a joke — architecture mirrors org structure with uncomfortable accuracy.
What Good Leadership Does
Clarify responsibility. Not in a doc that nobody reads, but in repeated conversations that make ownership obvious and unambiguous. When something breaks, there should be zero confusion about who responds.
Simplify decisions. Most organizational friction comes from too many people needing to agree. Good leaders reduce the number of people in the decision loop without reducing the quality of the decision.
The best technical leaders I've worked with spend less time on architecture diagrams and more time on making sure the right people are talking to each other. The architecture follows.