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.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: sanada123
• Source: sanada123/openclaw-skills
• License: MIT
• Homepage: https://skillsmp.com/?q=lifestyle-optimizer

Install and usage instructions live in the source repository linked above.