Most technical problems are people problems

Outdated Technology, Careers, and Hiring Practices

• Several argue “outdated” usually means “no longer fit for purpose” (scale, bugs, missing features, lack of ecosystem), not simply “old.”
• A big practical factor: job market demand. Working in COBOL or similarly niche tech can narrow future opportunities; some devs refuse legacy stacks for this reason.
• Others report successfully switching stacks on the job and being hired without exact-match experience, but several note this is harder in the current market and HR often keyword‑filters resumes.

Tech Debt as a People/Management Problem

• Many agree technical debt often stems from people issues: unclear requirements, overpromises by sales, reactive leadership, stubborn devs, and poor cross‑functional communication.
• Some leaders describe how, as CTOs, they must constantly trade off refactoring vs. shipping, prioritizing debt that blocks strategic goals and feature velocity.
• Others push back: not all tech debt is avoidable or someone’s “fault”; evolving requirements, uncertainty, and time pressure can make compromises rational.

Work Pride, Alienation, and Capitalism

• Long subthread debates why many see work as “just a paycheck” and care less about craftsmanship.
• Reasons cited: stagnant wages, rising living costs, layoffs, lack of ownership, weak employer loyalty, management taking credit, inequitable rewards, and viewing workers as disposable “resources.”
• Counter‑voices stress personal pride, professional reputation, and skill growth as intrinsic reasons to care, arguing that doing the bare minimum is risky and self‑limiting.
• Others connect this to Marx’s alienation, unionization, and broader critiques of capitalism vs. state control; there’s sharp disagreement over Marx, communism, and historical outcomes.

Communication, Organization Design, and Process

• Many say “people problems” are really communication and organizational problems: Conway’s Law, feudal silos, feuding departments, misaligned incentives, PMs treating engineering as an internal agency.
• Examples: data teams drowning in ad‑hoc requests and schema changes; management responding with more meetings, dashboards, and “sources of truth” that nobody uses.
• Some advocate for engineers shadowing users, rotations with feature teams, monorepos, boring tech, and small, empowered teams as practical mitigations.

Is “Everything Is a People Problem” Useful?

• Several note this framing can become a cliché: most issues have both technical and social causal chains; you can intervene at either layer.
• Overemphasis on “people problems” can be used to denigrate technical skill; overemphasis on “tech problems” ignores politics and incentives.
• Consensus: real progress usually requires both solid engineering and deliberate work on culture, incentives, and communication.