Incidents, Team Health and Growing as a Lead

This lesson is about the part of leading that is not code: incidents, feedback, juniors, team health, mistakes, and your first weeks as a lead. It gives the simple habits and the model answers. Read Lesson 0 first for the answer shape. For a full incident story see Debugging, Lesson 10; for conflict, mistakes and offers see Full-Stack Lesson 38 (coming soon).

Everything here is common practice and opinion, not law. Teams differ. Use the ideas, not the exact words, and always use your own true examples.

Words used in this lesson

• A postmortem is a written review after an incident. Blameless means it looks for causes in the system and the process, not for a person to punish.
• Bus factor is how many people can leave (or be sick) before the project is in trouble. A bus factor of one is a risk.
• Technical debt is a shortcut that saves time now and costs time later, like a loan with interest.

When things go wrong: the leader's mindset

A lead is judged most on the bad day. Habits to copy:

• Fix first, explain after. During an incident, the first job is to stop the pain (roll back, switch the flag off). Find the deep cause once users are safe.
• Give the incident one coordinator. The incident reading list points to Incident Response at Heroku, which describes an Incident Commander role (an idea borrowed from disaster response). One person coordinates, the others investigate, so people do not duplicate work or all talk at once.
• Tell people early and plainly. "We have a problem with checkout. We are rolling back. Next update in 15 minutes." Silence makes things worse.
• Be blameless, not careless. Google's SRE book describes blameless postmortems: they focus on the causes in the system and the process, and assume people acted reasonably with what they knew. The reason is practical: if people are punished, they hide problems, and then the same incident returns. Blameless does not mean "nobody is accountable". It means you ask "how did our system let this happen?" and not "who do we blame?". Etsy's debriefing guide comes from the same idea: it builds on the "New View" of human error from safety science.
• Ask "how", not only "why". The reading list recommends The Infinite Hows, which criticises the "Five Whys" habit and suggests asking "how" questions that bring out more of what really happened. ("How did the deploy get approved on a Friday?" opens a wider story than "Why did you deploy on Friday?".)
• End with actions, not just words. Each postmortem should have a few concrete follow-ups with an owner and a date: a test, an alert, a safer deploy step. A simple outline from the same list: summary, impact, timeline, root cause, lessons learned, action items.
• Read a real one. The list points to GitLab's 2017 database incident postmortem as a detailed, public example of how to write honestly about a bad day.

For a full incident story and examples see Debugging, Lesson 10.

Measuring a team without hurting it

Leads are often asked "how is the team doing?" The DORA research team describes four keys for software delivery. The definitions below are the ones in the DORA team's own Four Keys project:

• Deployment frequency: how often a team successfully releases to production (daily, weekly, monthly).
• Lead time for changes: the median time from a commit to it running in production.
• Time to restore service: for a failure, the median time between the deployment that caused it and the fix, measured by when the related bug or incident is closed.
• Change failure rate: failures divided by deployments. For example, one failure in four deployments is 25%.

The first two are about speed, the last two about stability. The useful idea is that good teams improve both, not one at the cost of the other. Small, frequent releases are usually safer than big, rare ones. The Four Keys page says its purpose is measuring a team's delivery performance, for example to set a baseline or to see the effect of new tooling. (DORA's own reports have used slightly different names for the recovery measure over the years, so check the current wording before you quote it.)

What makes a good manager? Google's Project Oxygen research (published on its re:Work site) started with eight behaviors, such as coaching, not micromanaging, caring about the team's success and well-being, communicating clearly, supporting career growth, and having a clear vision. Later it added collaborating across the company and being a strong decision maker. I know this from news and web summaries of the research, not the re:Work pages, so treat the wording as approximate.

Growing into the lead role

When you start to lead (even without the title), the job changes from "write code" to "help the team make good decisions". Habits that help:

• Give context, not only tasks. Say why the work matters and what "done" looks like. People make better choices when they know the goal.
• Delegate with a clear owner. One name per task. Say how much freedom they have and when to check in. Do not take the work back at the first sign of a mistake.
• Teach, don't rescue. When a junior is stuck, ask "what have you tried?" first. Then give the smallest hint that helps.
• Make decisions, and write them down. Waiting for 100% certainty is itself a decision, and usually a slow one. For reversible choices, decide quickly. For hard-to-reverse ones, take more time, ask for opinions, and write a short decision record.
• Say "no" with a reason and an option. "We can't do this by Friday without skipping tests. We can ship the basic version on Friday and the rest next week. Which do you prefer?"
• Protect the team's focus. Fewer parallel tasks, fewer surprise changes, honest priorities.
• Take responsibility up, share credit down. When something fails, you say "we" and own it with your manager. When something works, you name the people who did it.
• Keep learning in public. Say "I was wrong about that" when it is true. It makes it safe for others to do the same.

Interview questions

Key takeaways

• In an incident: stop the damage first, name one coordinator, send short regular updates.
• Blameless means "how did our system let this happen?", not "nobody is accountable".
• End a postmortem with a few actions that have an owner and a date, and check they were done.
• Use delivery measures (frequency, lead time, failure rate, recovery time) to find process problems, not to rank people.
• Give context, not only tasks. Delegate with one clear owner.
• Teach before you rescue: ask "what have you tried?" and give the smallest helpful hint.
• Give hard feedback soon, in private, about a specific thing, and agree one change to try.
• In your first weeks as a lead: listen, learn why things are as they are, fix one daily pain, and change little at once.
• This is common practice and opinion. Adapt it to your team.

What's next

Next: Design docs, RFCs and writing things down, Lesson 5, then technical debt, laws, people, hiring and stakeholders in Lessons 6 to 10, and the sources in Lesson 11. Practise out loud first: record yourself on three questions from Lessons 0 to 4 and listen for "everyone uses it", "I just felt" and missing risks. Then revisit the story shapes in Experience round, Full-Stack Lesson 14.