Traits of a good Tech Lead

The article opens by separating the Engineering Manager and Tech Lead roles. The EM owns people, product delivery, and process, while the TL owns architecture, code quality, and mentorship. This split clarifies where responsibility lies and why a TL must focus on technical direction rather than people management.

A TL's day revolves around three pillars. Architecture means defining key decisions, reviewing proposals, and keeping technical debt intentional. Quality covers code standards, testing, and observability, raising the bar for the whole team. Mentorship is about unblocking engineers, sharing context, and helping the team grow technically. The author stresses that a TL should not do everything but should create the conditions for others to succeed.

Good signals are concrete: writing RFCs to force clear debate, running small PoCs when discussions stall, and making technical debt explicit. A TL should involve the team in decisions, negotiate scope with the EM, and simplify solutions into incremental phases. Operating principles documented and reviewed regularly become a compass that reduces reliance on the TL and accelerates velocity.

When the EM also acts as TL, evaluation becomes harder and bottlenecks risk appearing. The solution is to delegate ownership to champions for quality, security, or architecture, spreading technical responsibility across the team. The author notes that a well-balanced EM+TL model still requires a clear definition of "good" and regular skip-level check-ins.

The piece ends with a practical offer: a free alignment toolkit containing a TL self-assessment, an EM evaluation semaphore, and an operating principles template. The toolkit is designed to turn the article's concepts into actionable artifacts that help teams move from intention to consistent, autonomous execution.