I'm a Tech Lead, and nobody listens to me. What should I do?
Technical leadership titles often fail to confer real influence, especially when new leads arrive with grand architectural plans or process overhauls before understanding the team’s context. Commenters argue that respect comes from demonstrated impact, listening, and solving concrete problems—not from hierarchy or the power to fire—while warning that some organizations are so politically or culturally broken that leaving is the only sane option. The thread also critiques trendy org models and heavyweight architectures, emphasizing incremental change, empathy, and long‑term maintainability over top‑down mandates.
Authority vs. Influence
- One camp argues hierarchy and real authority (including power over hiring/firing) are essential; without them, “tech lead” is an empty title and decisions bog down in endless negotiation.
- Others push “lead without authority”: earn trust, be right often, be likable, and avoid leaning on hierarchy. Abusing title-based power is seen as corrosive.
- Several note that even with senior titles, peers and upper management may still ignore you; influence must be built, not assumed.
Early Missteps in New Roles
- Many criticize coming into a new org and immediately proposing big architectural overhauls (e.g., hexagonal architecture, testing pyramids, new processes).
- Suggested alternative: spend time learning context, constraints, and existing decisions before adding work or complexity; first fix one painful, concrete problem to earn credibility.
Architecture, DI, and Testing Digression
- Some recount negative experiences with “hexagonal” or “clean” architecture used dogmatically, generating interfaces, DI plumbing, and untestable glue code with little benefit.
- Others counter that DI and clear interfaces can be useful, especially in ecosystems like .NET, but only when driven by real change drivers, not fashion.
- Several emphasize separating pure and impure code, testing pure functions simply, and avoiding over-mocking.
What Makes an Effective Tech Lead
- Being a great coder alone is seen as neither sufficient nor always necessary; leadership requires communication, context setting, and owning processes and outcomes.
- Opinions diverge on whether one person can be both strong IC and strong tech lead simultaneously, given meeting/people overhead.
- Good leads are described as: listening first, clarifying problems, understanding politics and context, explaining “why,” and guiding architecture without dictating every line.
Culture, Politics, and When to Leave
- Multiple anecdotes describe organizations that ignored repeated risk warnings until disaster, then reacted chaotically.
- A recurring conclusion: if leadership is careless, political, or blocks all improvement, you likely cannot change the culture—document your attempts and leave.
- Some note that “trust equations” and similar models assume good-faith actors; in political or adversarial environments, such tools can be misapplied or weaponized.