🎯 Mục tiêu bài viết

Nếu mục tiêu của bạn là trở thành Tech Lead hiệu quả thông qua việc hỗ trợ team member, thì học leadership theo kiểu lý thuyết chung là chưa đủ. Bạn cần một operating framework để dùng hằng ngày.

Bài này tổng hợp một framework thực chiến để giúp bạn:

  • hỗ trợ đúng cách,
  • không lấy mất ownership của team member,
  • vẫn bảo vệ delivery,
  • và tăng năng lực tự giải quyết vấn đề của cả team.

1) TECH LEAD SUPPORT FRAMEWORK

                    TECH LEAD
                        │
        ┌───────────────┼────────────────┐
        │               │                │
      CLARITY        COACHING        DELIVERY
        │               │                │
        ▼               ▼                ▼
   Understand       Develop          Remove
   the problem      the person       blockers
        │               │                │
        └───────────────┼────────────────┘
                        │
                        ▼
                  TEAM GROWTH
                        │
                        ▼
                 SELF-SUFFICIENT TEAM

Mục tiêu cuối cùng không phải:

“Team member cần tôi càng nhiều càng tốt.”

Mà là:

“Team member ngày càng ít cần tôi cho những vấn đề mà trước đây họ cần tôi.”

2) CLARITY — Làm rõ trước khi hỗ trợ

Khi member nói: “Em đang bị lỗi”, đừng nhảy vào debug ngay.

Hãy hỏi 7 câu:

1. What is the expected behavior?
2. What is the actual behavior?
3. Can you reproduce it?
4. When did it start?
5. What have you checked?
6. What is your current hypothesis?
7. What do you need from me?

Flow nên đi qua:

Problem
  ↓
Expected
  ↓
Actual
  ↓
Evidence
  ↓
Hypothesis
  ↓
Next Action

Nếu chưa đi hết flow này, chưa nên jump vào solution.

3) COACHING — Đừng giải quyết thay member

Có 4 mức can thiệp:

LEVEL 1: Question
  "Em nghĩ nguyên nhân nằm ở đâu?"

LEVEL 2: Hint
  "Em thử compare DEV và QA chưa?"

LEVEL 3: Direction
  "Anh nghĩ em nên isolate FE/BE trước."

LEVEL 4: Solution
  "Root cause nằm ở frontend mapping."

Nguyên tắc cốt lõi:

Start with the lowest level of intervention that can move the person forward.

Nếu hỏi là đủ thì không cần gợi ý. Nếu gợi ý là đủ thì không cần chỉ đạo. Chỉ đưa lời giải khi thực sự cần.

4) ASK → LISTEN → GUIDE

Tech Lead giỏi không phải người nói nhiều nhất trong discussion, mà là người đặt câu hỏi tốt nhất.

ASK
 ↓
LISTEN
 ↓
UNDERSTAND
 ↓
GUIDE

Ví dụ coaching qua câu hỏi:

  • Lead: “Em nghĩ failure đang ở layer nào?”
  • Member: “Backend.”
  • Lead: “Evidence nào khiến em nghĩ vậy?”
  • Member: “API response có vẻ sai.”
  • Lead: “Sai cụ thể ở field nào?”
  • Member kiểm tra lại: “Response đúng.”
  • Lead: “Vậy backend loại trừ được rồi. Layer tiếp theo em check gì?”

Đó là coaching through questions.

5) REMOVE BLOCKERS — Lead gỡ blocker, không làm thay

Phân biệt rõ:

Difficulty ≠ Blocker

Difficulty

“Em chưa biết implement cách này.”

→ Cần coaching.

Blocker

“Backend team chưa cung cấp API.”

→ Lead cần remove dependency.

Flow xử lý:

Member
  ↓
Problem
  ├─ Knowledge gap          → Coaching
  ├─ Technical complexity   → Pair / Design review
  ├─ Dependency             → Lead removes blocker
  └─ Requirement ambiguity  → Clarify

6) OWNERSHIP — Giúp nhưng không lấy việc

Sai lầm thường gặp của Lead mới:

  • Member: “Anh fix giúp em được không?”
  • Lead: “Đưa code đây.”

Khi đó ownership chuyển từ member sang lead.

Cách tốt hơn:

  • “Em show current implementation và explain approach trước.”
  • “Anh thấy điểm rủi ro ở X. Em đề xuất cách chỉnh phần đó thử xem?”

Mô hình đúng:

Member
 ├─ Understand
 ├─ Investigate
 ├─ Decide
 ├─ Implement
 └─ Verify
        ▲
        │
      Lead
 supports/guides

7) CHECKPOINT — Không micromanage, không thả nổi

Thay vì hỏi liên tục “xong chưa?”, hãy đặt checkpoint theo risk.

Task Start
  ↓
Define checkpoint
  ↓
Developer works independently
  ↓
Checkpoint
  ├─ Good direction  → Continue
  ├─ Unclear         → Coach
  └─ Wrong direction → Redirect

Gợi ý timing

Situation Checkpoint
Simple task 2–4h
Normal task 1–2h
Complex debugging 30–60m
Wrong direction 15–30m
Critical issue 15–30m
New member/domain 30–60m

Nguyên tắc:

Risk tăng thì feedback loop phải ngắn lại.

8) DELIVERY — Coaching nhưng vẫn phải bảo vệ sprint

Model đơn giản:

                    TASK
                      │
             ┌────────┴────────┐
             │                 │
          Progress            Risk
             │                 │
             ▼                 ▼
         Continue          Investigate
                               │
                         ┌─────┴─────┐
                         │           │
                       Small       Large
                       risk        risk
                         │           │
                         ▼           ▼
                      Coach       Intervene

Nếu task 5 points kéo dài 3 sprint, không thể nói “cứ để bạn ấy tự học thêm”.

Cần intervention có cấu trúc:

Task → Current state → Root cause → Remaining work → Dependency → ETA → Risk

9) COMMUNICATION — Protect member, không che giấu vấn đề

Trong outsourcing, Tech Lead là communication buffer giữa team và client/PM.

Không nên nói:

“Developer X làm 3 sprint chưa xong.”

Nên nói:

“This task has taken longer than estimated. We identified an investigation issue around frontend/environment behavior, and we are validating root cause with checkpoints to reduce further delay.”

Đây là cách report fact + action + risk, không blame cá nhân.

10) FEEDBACK — Nhắm vào behavior, không nhắm personality

Tránh:

  • “Em thiếu tư duy.”
  • “Em debug kém.”

Dùng framework:

Observation
  ↓
Impact
  ↓
Expectation
  ↓
Next action

Ví dụ:

“Anh thấy em đã investigate cả backend và frontend nhưng chưa có hypothesis rõ, nên vòng điều tra kéo dài. Task sau, em cần xác định failure boundary và evidence trước khi mở rộng phạm vi check.”

11) DEVELOP PEOPLE — Mỗi member cần một growth loop

Với từng người, Lead nên nắm:

Member
 ├─ Strength
 ├─ Weakness
 ├─ Current skill
 ├─ Target skill
 └─ Next opportunity

Ví dụ:

Developer A

Strength: Coding, Angular
Gap: Debugging methodology
Goal: Improve systematic troubleshooting
Action: Lead investigation cho 2 bug tiếp theo
Measure: Tự trình bày hypothesis/evidence/root cause

Đó là leadership bằng phát triển con người, không chỉ quản lý task.

12) DELEGATION — Giao việc để nâng năng lực

Không nên luôn giao junior task dễ mãi.

Skill Level
   ↓
Easy       → Execute independently
Medium     → Execute + checkpoint
Hard       → Design together
Very hard  → Pair / lead support

Mục tiêu:

Task difficulty tăng dần theo member capability

13) KNOWLEDGE SHARING — Biến kinh nghiệm thành hệ thống

Nếu chỉ dừng ở “Issue → Solution”, tri thức nằm ở một cá nhân.

Nên chuẩn hóa thành:

Issue
 ↓
Root cause
 ↓
Why it happened
 ↓
How to detect
 ↓
How to fix
 ↓
How to prevent

Gợi ý cấu trúc Team Knowledge Base:

Troubleshooting
├── Frontend
├── Backend
├── Deployment
├── QA
└── Production

14) BLAMELESS POSTMORTEM

Khi có sự cố, đừng hỏi “Ai sai?”.

Hãy hỏi:

What happened?
  ↓
Why did it happen?
  ↓
Why wasn't it detected earlier?
  ↓
What can we improve?
  ↓
What action prevents recurrence?

Ví dụ:

Bug escaped to QA
  ↓
Frontend config incorrect
  ↓
No DEV/QA comparison checklist
  ↓
Create environment checklist

15) DAILY — Câu hỏi lead nên dùng

Daily không phải interrogation, mà là alignment & risk management.

5 câu hỏi gợi ý:

  1. What changed since yesterday?
  2. Anything that could affect sprint outcome?
  3. Is there anything you cannot move forward without?
  4. Do you need anything from me?
  5. Are we still aligned with expected outcome?

16) SAFE framework để nhớ cách hỗ trợ

S — See
    Understand what is happening.

A — Ask
    Ask questions before giving answers.

F — Facilitate
    Remove blockers and guide decisions.

E — Empower
    Give ownership back to the developer.

Ví dụ ngắn:

Bug xảy ra
  ↓
SEE: "What exactly is happening?"
  ↓
ASK: "What is your hypothesis?"
  ↓
FACILITATE: "Let's isolate FE/BE."
  ↓
EMPOWER: "You take the next step and update me at checkpoint."

17) 5 tầng phát triển của Tech Lead

Level 1: Good Developer
  → Solve my own problems

Level 2: Tech Lead
  → Help others solve problems

Level 3: Team Lead
  → Build capable developers

Level 4: Engineering Leader
  → Build effective teams/processes

Level 5: Technical Leader
  → Build scalable engineering organization

Trọng tâm thực tế trong 6–12 tháng đầu thường là Level 2 → Level 3.

18) Daily operating system cho chính bạn

Mỗi sáng (10 phút)

Who is blocked?
Who is at risk?
Who needs support?
Who can work independently?

Trong ngày

Observe → Checkpoint → Coach → Remove blocker → Delegate back

Cuối ngày (5 phút)

1) Hôm nay tôi solve thay bao nhiêu lần?
2) Vấn đề nào đáng lẽ nên coach thay vì solve?
3) Có ai đang blocked mà tôi chưa thấy?
4) Pattern nào đang lặp lại?
5) Bài học nào cần đưa vào knowledge base?

19) Leadership maturity

"I solve the problem."
        ↓
"I help you solve it."
        ↓
"I teach you how to solve it."
        ↓
"I build a system where you can solve it yourself."
        ↓
"You teach others."

Đích đến của Tech Lead không phải trở thành người được hỏi nhiều nhất, mà là xây đội ngũ tự chủ để bạn tập trung vào bài toán leverage cao hơn:

  • architecture,
  • risk,
  • delivery,
  • people development,
  • stakeholder management,
  • technical direction.

20) Team Member Support Loop (áp dụng ngay)

              TASK ASSIGNED
                    │
                    ▼
             Understand task
                    │
                    ▼
             Start execution
                    │
                    ▼
          ┌──── Checkpoint ────┐
          │                    │
       On track              Off track
          │                    │
          ▼                    ▼
       Leave              Ask questions
      ownership                │
          │                    ▼
          │                 Coach
          │                    │
          │              ┌─────┴─────┐
          │              │           │
          │            Clear       Still stuck
          │              │           │
          │              ▼           ▼
          │           Continue    Pair / Guide
          │                          │
          └──────────────┬───────────┘
                         ▼
                    Verify result
                         │
                         ▼
                    Capture learning
                         │
                         ▼
                    Build capability

Nếu giữ loop này đều trong 2–3 sprint, bạn sẽ thấy team member chuyển từ:

“Em phải làm gì?”

sang:

“Em đã check A, B, C; evidence là X; em nghĩ root cause là Y; em định làm Z — anh confirm giúp em approach này.”

Đó là dấu hiệu rất rõ rằng bạn đang trở thành một Tech Lead hiệu quả.