Tech Lead

[rogerxu]

The Effective Tech Lead is a 100x Engineer – Hacker Noon

leadership/tech_lead.md at master · webflow/leadership

[rogerxu]

What is a Tech Lead

The most important are sincere empathy, crystal clear communication, and technical excellence.

View each team member as a human being first, and a talented contributor second. Humans need relationships built on compassion and cooperation. It is the Tech Lead’s job to foster such an environment, and such environments are engendered through an attitude of service.

The Tech Lead’s job is not to micromanage, but to be a service leader, which is to say they are there to support their team, to serve them as though they worked for them (not the other way around).

1. Be direct with project needs. Do not fear to challenge your team as long as you care deeply about their welfare.
2. When successes occur, lavish your team with praise and give them credit for everything  -  without them success is impossible.

[rogerxu]

Responsibilities

1. To work closely with a Product Manager to set reasonable expectations around deadlines, and to be clear when projects are going off-track.
2. To break up projects into digestible tasks, to tie those tasks to iterative deliverables, and to keep track of those deliverables.
3. To provide ample uninterrupted work time for their team so they may frequently enter the flow state, and to act as their team’s guardian against any potential blockers and distractions.
4. To ensure your team is sufficiently supplied with work at all times so that no one “spins their wheels”.
5. To perform diligent code reviews, first-pass QA, and to contribute code where possible.
6. To be available to team members as they execute their tasks. (Windows of blocked time for heads down work is expected, but windows of team availability are expected, too).
7. To occasionally work with other departments.

Working with Other Departments

The Tech Lead is responsible for communicating their project’s status to other departments in two forms:

1. A weekly status meeting with their team in which a dedicated Product Manager or Support Liaison may also participate. This meeting is mandatory regardless of Product Manager or Support Liaison participation.
2. A weekly “All Hands” report for the entire company to see.

Tracking Tasks

A great Tech Lead knows how to break a project into meaningful and easily digestible tasks (digestible means about three days scope).

Master Tracking Issue (MTI)

The Tech Lead must take time to thoroughly review the project’s specifications and do their best to break down the specification into trackable tasks with a scope of 1–5 days of work (outside Code Review / QA), and an optimal timeline of 3 days.

Each issue (or 1–5 day task) must clearly point to the portion of the specification the issue addresses and to the concerned areas of codebase (if they exist).

1. Clearly point to the original specification the issue addresses, with any visual content that will help an engineer complete the task, including screenshots/screencasts from the specification.
2. List a best guess of TODOs to help the engineer build a mental model around the problems they must solve.

Milestones

• A major deliverable, usually with a six-week timeline.
• Responsible for driving a series of tasks/issues, and is complete when all tasks/issues have been pushed to production.
• Assigned a deadline date.

Task toward unknowns

Milestones deadlines are hard to estimate, but we asks that the Tech Lead do their best to place a realistic date on them. This constraint might seem limiting at first, but we treat deadlines more as focal points (with mitigation strategies) than immovable dead-lines.

Meetings

The Tech Lead should organize one ~30-minute project meeting per week, preferably at the week’s start and early in the day, whose agenda looks like the following:

1. Perform a Mini-retrospective that asks:
   1. What went well last week?
   2. What didn't go so well last week?
   3. How can we improve what didn't go well?
2. Ask each team member:
   1. What's the current status of your task?
   2. Are you blocked?
   3. How can I help unblock you?
3. Assign new tasks to each team member
4. Communicate the project's status to the PM
5. Answer any questions and engage in light and witter banter

Weekly Status

Every engineer is asked to report their on-track / off-track status each day to #status-frontendor #status-backend accordingly, and it is on the Tech Lead to confirm those daily.

[rogerxu]

Types of Teams

Team Size

The general rule is a team will include three members, including the Tech Lead.

An Action Team might contain seven members, including a Tech Lead who can divide the team into two groups (of three) and focus each group on parallel tasks within the feature’s overall scope. It is then up to the Tech Lead to create a single Team Lead for each group and hold them accountable for their group’s work.

Team Efficiency and Organization

There are two ways of designing a team.

• “Feature” efficiency, which favors groups that collaborate on solving closely related problems together
• “Resource” efficiency, which favors individuals working on wholly unrelated tasks that run in parallel.

We ask that the Tech Lead optimize for feature efficiency where possible.

[rogerxu]

Project Management

Rework / Defer / Abandon (Mitigation Strategies for Deferred Progress)

• Rework the deliverable
  • Can we add resources to the project to meet the deadline? => 10%
  • Can we change the scope of the deliverable to meet the deadline? => 90%
• Defer the deadline
• Abandon the project

Effort Estimation

Pad estimates for the unexpected

Instead of precise estimates, give your best guesstimate for a given task and multiply it times four, especially if that task involves uncovering an unknown.

Add up tasks toward unknowns

Be sure to identify which tasks are associated with discovery (finding unknowns), and which have more concrete definitions.

The 80/20 Rule

Just treat the 80% point in your project as the halfway marker.

Never forget QA

When you estimate deadlines, set a date for code completion so that QA can have time to discover any bugs or UX issues.

Cooldown: Bug fixes after delivery

On delivery, plan to leave some time to fix any immediate bugs before starting new milestones. The amount of time can vary based on the deliverable’s complexity, and a week is usually a good window.

Milestone

While the scope of a feature might require months and months of work, its versioned milestones should aim for six-week timelines, including QA, so each milestone is code complete around four weeks.

A six-month project’s major Milestones may then look like this:

1. Alpha Launch (6 weeks)
2. Beta Launch (6 weeks)
3. Feature Launch v1.0 (6 weeks)
4. Feature Launch v1.0.1 (6 weeks) 🏁

[rogerxu]

Code Management

Feature Branch

Do not branch off of feature-branches. Tech Leads should aim to have their team commit their feature-branches directly to dev rather than to another feature-branch that is kept up-to-date with dev. Long-lived feature-branches often introduce code dependencies and other programming patterns that require cherry-picking and other hard-to-keep-in-sync-with-other-branches issues. Instead, the Tech Lead should place their project behind a Feature Flag and continually merge it with dev.

Feature flags

We encourage all of our engineers to push code every day (if possible), and to prevent a new feature from stepping on the toes of our users, we suggest Tech Leads place those new features behind a “Feature Flag” that can be toggled.

There might be a case for a long-lived branch to which other branches commit. And by “might”, we mean maybe 1% of the time where we must refactor a critical, widely-used portion of our infrastructure. So, basically never. Please inform the entire team, your product manager, and your engineering manager of your intent.