Team Lead Mindset cheat sheet

1. Goal: "We needed to ..." (the need, not the tool).
2. Options: "I looked at A, B and building it."
3. Choice and reason: one to three facts, not feelings.
4. Risk: what could go wrong, and how you reduce it.
5. Plan B: how you go back, and what it costs.

Right now I'm trying to [goal].
I know [fact]. I don't know [unknown].
My guess is [x]; I'll check it by [step].
If that is wrong, I'll try [other idea].

Watch out: "Because it is popular" is not a reason alone. Stuck? Try 30 to 60 minutes, then ask with notes of what you tried.

1. Need: can the platform or 20 clear lines do it? Dates, parsing, crypto deserve a library.
2. Alive: last release, unanswered issues, maintainers, security contact.
3. Fit: TypeScript types, framework and runtime support.
4. Cost: bundle size, transitive dependencies, license.
5. Exit: wrap it in one small module of your own.
6. Support: more than one person can read it.

npm view PKG time.modified

When the package last changed

npm audit

Known vulnerabilities

npm outdated

Current vs Wanted vs Latest

npm explain PKG

Why this is installed

• Give a range, name the unknowns, include tests, review and deploy. Split pieces over 2 to 3 days.
• Slipping? Tell the lead the same day: done, left, why, options (cut scope, move date, add help).
• Keep estimate, target, commitment and plan apart.

Tip: A good comment: what you see, why it matters, an option. Comment on the code, not the person.

1. Stop the damage first: roll back, flag off.
2. Name one coordinator. Send updates on a schedule.
3. When stable, hold a blameless review: how did the system allow this?
4. Write a few actions with an owner and a date. Check they were done.

Watch out: Measure the process, never rank people. Rewarded numbers get gamed.

# Title: the decision
Status: draft | accepted | replaced
Owner, Reviewers, Decide by: <date>
## Problem  ## Goals / Non-goals
## Proposal  ## Alternatives
## Risks  ## Rollout / rollback
## Test plan  ## Open questions

1. Talk first, then write a short draft with an owner. Give at least two alternatives and why not.
2. Set a date for comments. Answer every one.
3. Decide, record the reasons and rejected ideas.

• Language or framework: problem, team skills, hiring, ecosystem, running it at 3 a.m., how hard to undo.
• Boring by default: about three innovation tokens. Try new tools in a small spike.
• Skip the doc for tiny, reversible choices.

• Debt is a loan with interest: take it on purpose, write it down, state the cost in business terms.
• Pay first where code changes often or breaks. Refactor in small steps with tests.
• Watch latency, traffic, errors, saturation.

1. Their topics first.
2. Blockers: what do you need from me?
3. Growth, then feedback both ways.
4. Write 2 to 3 actions with names and dates.

I saw:   [one specific fact]
Effect:  [what it caused]
Ask:     "How do you see it?"
Try:     [one change], then check in

Goal / Owner

What "done" is / one name

Limits

Deadline, budget, approvals

Check-ins

When and how

Support

What you give

Tip: 70/10/80: pick someone who can do 70%, teach 10%, accept 80%. Disagree before the decision, commit after.

• Mentor: ask "What have you tried?", give the smallest hint, say why.
• Hiring: write 4 to 6 points first, same kind of questions for all, score before the group talks.
• Prefer work-like tasks. Keep take-homes short.

Status: on track | at risk | blocked
Done: <one line, in user terms>
Next: <one line>
Risk: <what, how likely, what we do>
Need from you: <decision, with a date>

• Why before what. Ask: "If we ship this, what number changes?"
• Meeting: purpose, owner, agenda first, only deciders, actions with name and date.
• Cancel it if you can live with the outcome.

Tip: Change: talk to affected people one by one first, try small with a measure and a way back, set a review date.

• Can it make someone say no? If not, it is a wish list.
• Roadmap = bets with date ranges: Now, Next, Later. Firm near, loose far.
• Buy common plumbing, build the core. Keep your own interface in front.

Watch out: Migration: tests first, run old and new side by side, set an end date, delete the old path.

• Moving up means bigger scope and wider influence, not more output. Management is a different job, not a promotion.
• Promote what the person already does for several months.

Tip: "Not yet": name the exact gap and a next step. Promotion case: scope and impact with numbers, dated examples, feedback, honest gaps.

• 30-minute threat model, then mitigate, eliminate, transfer or accept. Make tickets.
• npm ci in CI, npm audit, check new package names. Leaked secret: rotate first.
• AI tools: you commit it, you own it. Small changes, read every line, no secrets in prompts, agents in a sandbox.

• Team borders are an architecture choice. Keep teams small, split along the work.
• One owner per service in a catalogue. Bus factor one: name a second person.
• Page only for user-visible symptoms, one runbook per alert.

1. Retro: process, not people. Check last time's actions.
2. Collect in silence, group, vote.
3. End with 1 to 3 actions: owner, date, check.