Ask HN: How do you work as a tech lead?

Hacker News Discussion ↗

Newly minted tech leads often struggle to balance writing code with guiding a team, and commenters offer contrasting strategies on meetings, communication, and oversight. Many advocate lightweight, purposeful rituals—short standups, regular 1:1s, clear goals, and minimal meta-work—while others push for more asynchronous updates to protect deep work time. A recurring theme is that effective technical leadership is less about rigid process and more about mentoring (especially juniors), prioritizing code review and documentation, and adapting style to the specific people and project risks involved.

Role of the Tech Lead

  • Acts as glue between ICs and management; responsible for progress, clarity, and risk management, not just coding.
  • Often codes significantly less (20–60% of time) as mentoring, planning, and coordination grow.
  • Enabling the team (unblocking, code review, mentoring) is repeatedly described as core work, not a distraction.

Communication with the Team

  • Frequent touch points recommended: daily or near‑daily standups or syncs, plus ad‑hoc pings via Slack/Teams.
  • Some suggest 1:1 or small-group sessions instead of large “holding court” meetings.
  • Open chat channels, office hours, and drop‑in voice rooms help surface issues quickly, especially for juniors.

Communication with Manager & Stakeholders

  • Common patterns: weekly or bi‑weekly 1:1s with manager; weekly lead–product sync; occasional cross‑team or stakeholder reviews.
  • Push concise written updates when possible; avoid unnecessary status meetings.
  • Several emphasize understanding business goals, customer value, and involving real users early and often.

Meetings, Agile, and Standups

  • Strong disagreement on daily standups:
    • Pro: fast surfacing of blockers, especially for junior teams; team cohesion; predictable check‑in.
    • Con: context‑switching cost, perceived micromanagement, and “agile theatre.” Some prefer weekly iteration meetings or fully async text updates.
  • Consensus: any meeting needs a clear agenda, tight scope, and limited attendees; cancel if no agenda.

Documentation

  • Agreement that some documentation is essential; at minimum: onboarding, architecture/PRD, and key workflows.
  • Practices: “documentation as code,” wikis, generated docs, rebuild days to test instructions, documenting FAQs.
  • Warned that over‑documentation decays and wastes time; focus on high‑ROI docs.

Managing Juniors & Mentorship

  • For junior-heavy teams, many recommend very hands‑on mentoring: frequent micro‑reviews, pairing/mobbing, structured training, and design sessions.
  • Some worry this can feel like micromanagement; others argue early, continuous feedback is more humane than late rework.

Time Management & Focus

  • Common tactics: block daily “focus time,” batch meetings into specific days or times, explicitly account for meetings in sprint capacity, minimize personal task load as lead grows.
  • Emphasis on reducing context switching and prioritizing code reviews over individual coding.

Alignment & Planning

  • Use planning sessions, clear goals, visible boards, and regular retrospectives to keep everyone moving in the same direction.
  • Encourage feedback loops: from ICs up to leadership, and from users back to the team.