Team lead

Team Lead

The engineering management playbook for people who'd rather write code.

You got promoted (or promoted yourself) because you're a great engineer. Nobody taught you how to manage humans. This skill fills that gap — practical frameworks that work in real engineering teams, from 2-person startups to 50-person departments.

Core Philosophy

PEOPLE > PROCESS.     A great team with bad process will fix the process. Bad team with great process will fail.
CLARITY > CONSENSUS.  Decide, communicate, move. Don't committee-ize everything.
FEEDBACK > SILENCE.   Uncomfortable truth now beats explosive problem later.
TRUST > CONTROL.      Hire well, set expectations, then get out of the way.
GROW > RETAIN.        People leave managers, not companies. Grow them or lose them.

---

When to Activate

• Running or joining a team as lead/manager
• Preparing for 1:1 meetings
• Hiring: writing job descriptions, interviewing, evaluating
• Giving difficult feedback
• Sprint planning, retros, standups
• Dealing with underperformers
• Remote team management
• First-time manager seeking guidance
• Performance review season

---

1. The 1:1 — Your Most Important Meeting

Structure (30 min, weekly, never cancel)

First 10 min: THEIR agenda
  "What's on your mind?"
  "What do you need from me?"
  "Anything blocking you?"

Middle 10 min: YOUR agenda
  Progress on goals
  Feedback (both ways)
  Career development check-in

Last 10 min: ACTION ITEMS
  What will they do before next 1:1?
  What will YOU do before next 1:1?
  Write it down. Both of you.

Questions That Actually Work

Purpose	Question
Open up	"What's the thing you're spending the most energy on right now?"
Unblock	"If you could change one thing about how we work, what would it be?"
Career	"What skill do you want to be known for in 2 years?"
Feedback	"What's one thing I could do differently to help you more?"
Satisfaction	"On a scale of 1-10, how happy are you at work? Why not higher?"
Trust	"Is there anything you're hesitant to tell me?"

1:1 Anti-Patterns

❌ Don't	✅ Do
Status update meeting	Coaching + unblocking session
You talking 80% of the time	They talk 70%+
Cancel when busy	Reschedule, never cancel
Same questions every week	Rotate, go deeper
Skip when "everything is fine"	"Fine" often means "I'm not telling you"

---

2. Hiring Engineers

Job Description Formula

[Company — 1 line what you do]

We're looking for [role] to [impact in 1 sentence].

## What you'll do
- [3-5 concrete responsibilities, not vague buzzwords]

## What you bring
- [2-3 must-haves (be honest — only REAL requirements)]
- [2-3 nice-to-haves (explicitly labeled)]

## What we offer
- [Salary range (post it — saves everyone time)]
- [2-3 actual perks, not "fast-paced environment"]

## How to apply
[Clear instructions. 1 step, not 5.]

Interview Framework (4 stages)

Stage	Duration	What to Assess	Who
1. Screen	30 min	Communication, motivation, basic fit	Recruiter or you
2. Technical	60-90 min	Coding ability, problem-solving, technical depth	Senior engineer
3. System Design	45-60 min	Architecture thinking, trade-offs, real-world experience	You or CTO
4. Culture/Values	30-45 min	Collaboration, ownership, growth mindset, team fit	Team member

Interview Scorecard

Rate each 1-5:

TECHNICAL
  [ ] Problem-solving approach (not just answer)
  [ ] Code quality and readability
  [ ] System design and trade-offs
  [ ] Depth in their claimed expertise

COLLABORATION
  [ ] Communication clarity
  [ ] How they handle disagreement
  [ ] Do they ask good questions?
  [ ] Would the team enjoy working with them?

GROWTH
  [ ] Self-awareness of weaknesses
  [ ] Learning from past mistakes
  [ ] Curiosity / asks questions back
  [ ] Takes ownership vs blames others

DECISION: Strong Hire / Hire / No Hire / Strong No Hire

Hiring Red Flags

Red Flag	What It Signals
Can't explain a past project simply	Low communication skills
"That was someone else's fault" consistently	No ownership
No questions about the team or product	Not genuinely interested
Perfect answers, no depth when probed	Rehearsed, not experienced
Talks badly about previous employers	Will talk badly about you
Salary is the ONLY consideration	Mercenary — will leave for $5K more

---

3. Giving Feedback (Radical Candor)

The Framework

                    CARE PERSONALLY
                         |
         Ruinous     |   Radical
         Empathy     |   Candor ←── THE GOAL
                     |
    ─────────────────┼───────────── CHALLENGE DIRECTLY
                     |
         Manipulative|   Obnoxious
         Insincerity |   Aggression
                     |

Radical Candor = Care Personally + Challenge Directly. Both. Always.

Feedback Formula: SBI (Situation, Behavior, Impact)

"In [SITUATION], when you [BEHAVIOR], the impact was [IMPACT]."

Example (corrective):
"In yesterday's code review [situation], when you dismissed Sarah's 
suggestion without explaining why [behavior], she felt her input 
wasn't valued and stopped contributing [impact]."

Example (positive):
"In the client demo this morning [situation], when you handled 
that unexpected question with a clear, honest answer [behavior], 
the client's confidence in our team visibly increased [impact]."

Feedback Timing

When	How
Positive feedback	Public (in Slack, standup) or private. Both work.
Corrective feedback	ALWAYS private. Never in front of others.
Timing	Within 48 hours. Stale feedback loses power.
Frequency	Weekly minimum. Don't save it all for reviews.

Having Difficult Conversations

1. STATE the issue clearly (SBI format)
2. PAUSE — let them respond
3. LISTEN — really listen, don't plan your rebuttal
4. AGREE on the problem (or understand their perspective)
5. CO-CREATE a plan to fix it
6. SET a follow-up date
7. DOCUMENT what was agreed

---

4. Sprint Planning & Agile (Practical)

Standup That Doesn't Suck (10 min max)

Each person, 2 minutes:

1. What did I ship yesterday? (not "worked on" — "shipped")
2. What will I ship today?
3. Am I blocked? (if yes, who can unblock me?)

Rules:

• Stand up (it really helps keep it short)
• No problem-solving during standup — "let's take that offline"
• Start on time even if people are missing
• If remote: cameras on, async updates OK for simple days

Sprint Planning (2 hours max for 2-week sprint)

1. Review: what shipped last sprint? What didn't? (15 min)
2. Priorities: what MUST ship this sprint? (from PM/product) (15 min)
3. Breakdown: split each priority into tasks ≤ 1 day (45 min)
4. Estimate: rough T-shirt sizes — S (half day), M (1 day), L (2-3 days) (15 min)
5. Commit: team agrees on sprint scope (15 min)
6. Buffer: leave 20% capacity empty for bugs/emergencies (always)

Retrospective Template (45 min, end of sprint)

1. WHAT WENT WELL? (10 min)
   Each person: 1-2 things that worked
   
2. WHAT DIDN'T GO WELL? (10 min)
   Each person: 1-2 pain points (no blame)
   
3. ROOT CAUSE for top 2 issues (10 min)
   "Why did this happen?" (ask 5 times — 5 Whys technique)
   
4. ACTION ITEMS (10 min)
   For each issue: WHO will do WHAT by WHEN
   Max 3 action items per retro (more = none get done)
   
5. CHECK last retro's action items (5 min)
   Did we actually follow through?

---

5. Managing Underperformers

The 3-Strike Framework

Strike 1: Feedback conversation

• Clear SBI feedback
• Ask: "What's going on?" (sometimes there's a personal issue)
• Co-create improvement plan with specific, measurable goals
• Timeline: 2-4 weeks
• Document the conversation

Strike 2: Formal warning

• Progress check: did they improve?
• If not: escalate to formal PIP (Performance Improvement Plan)
• Specific goals, weekly check-ins, 30-day timeline
• Document everything in writing
• Involve HR if you have one

Strike 3: Exit

• If no improvement after PIP → it's time to part ways
• Do it respectfully: "This isn't working for either of us"
• Provide notice, help with transition
• Don't drag it out — it hurts everyone, including them

Common Causes (and actual fixes)

Symptom	Possible Cause	Fix
Missing deadlines	Unclear expectations	Be more specific about what "done" means
Low quality code	No code review culture	Implement PR reviews, pair programming
Not participating	Feeling unheard	Ask them directly in 1:1. Make space.
Constant conflicts	Cultural mismatch	Mediate once. If pattern continues → exit.
Good work, bad attitude	Burnout or personal issue	Have an honest conversation. Offer support.

---

6. Delegation

The Delegation Matrix

Task	Urgency	Who Should Do It
Critical + only you can do	High	You — now
Critical + someone else can do	High	Delegate with clear deadline + check-in
Important + develops someone	Medium	Delegate as growth opportunity
Routine	Low	Delegate permanently — this isn't your job anymore
Shouldn't be done at all	—	Delete it

How to Delegate Well

1. WHAT: Clear deliverable ("deploy the new API endpoint", not "work on the API")
2. WHY: Context ("this unblocks the mobile team's sprint")
3. WHEN: Deadline ("by Thursday EOD")
4. HOW MUCH AUTONOMY: 
   - Level 1: "Do exactly this" (junior)
   - Level 2: "Research options and recommend" (mid)
   - Level 3: "Decide and tell me what you decided" (senior)
   - Level 4: "Decide and do it" (trusted senior)
5. CHECK-IN: "Let's sync on Wednesday to see how it's going"

Delegation Anti-Pattern: The Boomerang

If every delegated task comes back to you → you're not delegating, you're just creating extra steps.

Fix: Give more context upfront. Accept 80% quality. Let them fail (small stakes) and learn.

---

7. Remote Team Management

The Remote Playbook

Challenge	Solution
Isolation	Weekly team social (non-work). 15 min. Optional but encouraged.
Miscommunication	Write it down. "If it wasn't written, it wasn't said."
Time zones	Define overlap hours (4h minimum). Async for everything else.
Trust	Focus on output, not online status. Judge by results.
Onboarding	Over-document. Assign a buddy. First week = 100% guided.
Camera fatigue	Cameras on for 1:1s and team meetings. Off for focus time.

Async Communication Guidelines

For your team, establish:
1. Response time expectations: Slack = 2h, Email = 24h
2. "Urgent" channel for real emergencies only
3. Meeting-free blocks (e.g., no meetings before 11 AM)
4. Friday = low-meeting day
5. Document decisions in shared doc, not chat (chat is ephemeral)

---

8. First 90 Days as New Manager

Day 1-30: Listen

- 1:1 with every team member (learn their goals, frustrations, strengths)
- 1:1 with your manager (understand expectations)
- 1:1 with adjacent team leads (understand dependencies)
- Read all existing docs (architecture, runbooks, retro notes)
- Don't change anything yet. Earn trust first.

Day 31-60: Diagnose

- Identify the top 3 problems (team will have told you by now)
- Pick ONE to fix (not three — one)
- Propose your plan to the team (not decree — propose)
- Start weekly 1:1 rhythm if not already happening
- Begin giving feedback (both positive and constructive)

Day 61-90: Act

- Ship the ONE fix you proposed
- Measure: did it actually improve things?
- Start on problem #2
- By now: team trusts you, you understand the system, you've earned credibility

The #1 mistake: Changing everything in week 1. You don't have context yet. Listen first.

---

9. Performance Reviews

Review Template (Quarterly or Semi-Annual)

## Performance Review: [Name] — [Period]

### Summary (2-3 sentences)
[Overall assessment: exceeding / meeting / below expectations]

### Key Accomplishments
1. [Shipped X, resulting in Y impact]
2. [Led Z initiative]
3. [Grew in area W]

### Areas for Growth
1. [Specific skill/behavior to improve]
2. [With concrete next steps]

### Goals for Next Period
1. [Measurable goal #1]
2. [Measurable goal #2]
3. [Development goal — skill to build]

### Compensation (if applicable)
[Raise / promotion / no change — with clear reasoning]

The No-Surprises Rule

Nothing in a performance review should be a surprise. If you've been doing weekly 1:1s with regular feedback, the review is just a summary of conversations already had.

If someone IS surprised → you failed at giving ongoing feedback, not them.

---

Output Standards

When giving management advice:

• Be practical: Templates and scripts, not theory
• Be direct: "Fire them" when that's the answer, not "consider realignment"
• Acknowledge discomfort: Management is emotionally hard. It's OK to feel uncomfortable.
• Context-aware: Startup with 3 people ≠ scale-up with 50
• Reference frameworks: SBI, Radical Candor, RACI — but explain, don't just name-drop
• Defend IC time: Managers who never code lose technical credibility. Protect some maker time.

---

Because the hardest bugs to fix aren't in the code — they're in the team.

Contributing: Engineering managers, tech leads, CTOs with battle scars — your playbooks are welcome. Open an issue or PR at github.com/sanada123/openclaw-skills.