Who owns what

Titles vary by company; write down who owns each row in your team so nothing falls between two people. At Mangrove, Nadia is tech lead for the Store app team and Ken is its engineering manager (Tech lead role, Manager's job, Department head).

1:1 template

Weekly or every two weeks, 30 minutes, never cancelled twice in a row. It is their meeting: they bring the agenda first, you add yours after. Keep shared notes so commitments do not get lost (1:1s and feedback).

## 1:1 Ken / Nadia, 2026-03-04
Their topics (first):
-
My topics:
- Feedback on Tuesday's design review (SBI)
Check-ins (pick one or two, not all):
- Energy this week, 1 to 5? What would make it a 5?
- What is slowing you down that I could remove?
- Anything you are worried about that we have not talked about?
Growth (once a month):
- Progress on the goal: lead the GRN offline sync design
Actions:
- [ ] Ken: get Nadia into the payments architecture review, by Fri
- [ ] Nadia: draft the sync design doc, by next 1:1

Questions that open people up

Feedback with SBI

Situation, Behaviour, Impact, from the Center for Creative Leadership. Describe what you saw, not what you think the person is. Then ask, and agree on what happens next. Give praise the same way, so it says what to repeat (1:1s and feedback).

Situation:  In Tuesday's design review for the Partner app sync,
Behaviour:  you cut Leila off twice before she finished her point about offline carts,
Impact:     she stopped contributing, and we missed the conflict case she raised later in chat.
Ask:        How did that meeting feel from your side?
Next:       Next review, let each person finish, then respond.

• Give it soon, in private for anything corrective, and in public only for praise the person is comfortable with.
• One point at a time. A list of ten is a performance review, not feedback.
• Avoid "always", "never" and guesses about intent.
• Ask for feedback on yourself first and often; it makes giving it easier.

Delegation levels

Say the level out loud when you hand something over. Most frustration comes from one person thinking it was level 3 and the other thinking level 7. These seven levels come from Management 3.0's delegation poker (Delegation).

Hiring loop

Decide what "good" looks like before you see any candidate. Every interviewer gets different competencies to assess, writes their notes before the debrief, and scores against the same rubric (Hiring).

Scorecard rubric, one competency

Competency: Breaks down ambiguous work
1 = Needs tasks fully specified
2 = Splits a clear feature into steps with help
3 = Splits a feature into thin, shippable slices alone   (bar for this role)
4 = Slices cross-team work and spots risks early
Evidence (quotes and facts only): ...
Score: _   Hire / No hire for this competency: _

Performance and growth

No surprises: nothing in a review should be news. Write expectations per level in a career framework, check progress monthly in 1:1s, and keep a running document of evidence for both strengths and gaps (Performance).

Team health signals

• People disagree openly in meetings and still commit afterwards. Silence is a worse sign than conflict.
• Work in progress stays small; nobody is on five things at once.
• On-call pages per week are tracked and trending down; nobody is paged most nights.
• Unplanned work is under about a fifth of the sprint, or you plan for it.
• Knowledge is spread: every critical system has at least two people who can change it.
• Regrettable attrition, overtime and sick days are watched, not guessed.
• Retros produce one or two actions, and those actions get done.

See Team health and Toil.

Delivery metrics: DORA

The four key metrics from the DORA research programme measure a team's delivery system, not individuals. Use them to find bottlenecks, never to rank people or teams. DORA later added reliability as a fifth area, and in 2023 renamed time to restore as failed deployment recovery time (Operating model, Shipping).

Other numbers worth watching

Pair speed metrics with quality and people metrics so one is never bought with another. The SPACE framework (satisfaction, performance, activity, communication, efficiency) is a good checklist. Useful ones: PR review time (aim for the same working day), time from ticket start to done, escaped defects, on-call pages per week, SLO attainment, onboarding time to first PR, and a quarterly team survey. Never use lines of code or commit counts (Operating model, SLOs and budgets).

Managing up and across

Incident comms: roles and cadence

Separate fixing from talking. The incident commander coordinates, an ops or tech lead fixes, and a comms lead keeps everyone else informed so engineers are not interrupted (Incident command).

Status update template

[SEV1] App checkout failing, update 3, 19:40 UTC
Impact:   About 40% of checkouts in the Mangrove app fail since 18:55.
          Stores and tills are not affected.
Status:   Cause found: a payment provider certificate expired on our side.
          Fix being deployed now.
Next:     Expect recovery by 20:00. Next update 20:10 or sooner.
Ask:      Support: use the macro "checkout-issue-0304" for customers.
Contacts: Incident commander Ken, comms lead Imran. Channel #inc-checkout

• Say what users see, not what the system does. "Orders fail" beats "502s on the payments service".
• Never guess a cause in public. "We are investigating" is fine.
• Always give the time of the next update, and keep it.
• Close with a resolved message and the date of the postmortem (Postmortems).

Postmortem in one breath

Blameless: ask what in the system let a reasonable person make that change, not who made it. Write the timeline, impact in user terms, contributing causes, what went well, and three to five actions with owners and dates. Share it widely and track the actions like product work (Postmortems).

Design doc outline

Write one when work takes more than a couple of weeks, crosses teams, or is hard to reverse. Two to six pages. Share early as a draft; the review is for finding problems, not for approval theatre (Vision and design docs, Design reviews).

# Offline GRN receiving in the Store app
Author: Nadia. Reviewers: Ken, platform team, Ama (store S-014). Status: Draft
1. Problem and goal: receiving takes 51 min, 21 on workarounds; target under 35.
2. Non-goals: supplier portal changes.
3. Requirements with numbers: works 2 h offline, 1,000 scanners, no lost GRNs.
4. Proposed design: diagram, data, API, sync and conflict rules.
5. Alternatives considered and why not.
6. Risks, rollout plan, metrics, rollback.
7. Open questions.

Slicing work

• Slice vertically: each slice is usable end to end by a real user, even if small. "Receive one GRN offline at S-014" beats "build the sync layer" (Slicing work).
• Ship the riskiest unknown first, as a spike or a thin slice, before polishing the easy parts.
• Aim for slices that finish in a few days; if a ticket takes more than a week, split it.
• Hide unfinished work behind feature flags instead of long-lived branches.
• Every slice has acceptance criteria and a way to know it worked in production.
• Estimate in ranges and update them as you learn; share the range, not just the midpoint.

Tech debt: decide, do not just complain

Budgets for heads of department and CTOs

People are usually the biggest line in an engineering budget, followed by cloud and software licences. At Mangrove an engineer costs about $5,000 a month (Budgets, Budgets).

• Model headcount by month with start dates and a ramp-up, not as a full year from day one.
• Split run (keep the lights on) from change (new capability), and show the ratio over time.
• Show cloud cost per order or per store next to the total, so growth and waste can be told apart (FinOps).
• Keep a small contingency and say what it is for; hidden padding destroys trust.
• Link every big line to a strategy bet and a measure of success (Tech strategy).
• Report security and reliability as risks with likelihood, impact and the cost to reduce them (Risk and security).

Glossary

Plain definitions of the terms used across the Leadership line.

Tech lead

The engineer accountable for a team's technical direction and quality, usually still writing code. Tech lead role

Engineering manager

The person accountable for a team's people, health and delivery. Manager's job

1:1

A regular private meeting between a manager and a report, driven by the report's agenda. 1:1s and feedback

SBI

Situation, Behaviour, Impact: a way to give specific, factual feedback. 1:1s and feedback

Delegation level

How much decision power is handed over, from "I tell you" to "you decide". Delegation

Scorecard

A written definition of a role's outcomes and competencies used to judge every candidate the same way. Hiring

Structured interview

Every candidate gets the same questions, scored against the same rubric. Hiring

Career framework

Written expectations for each level, used for growth, promotion and pay. Performance

Performance improvement plan

A written, time-bound plan with clear expectations and support for someone below the bar. Performance

Psychological safety

A shared belief that people can speak up, ask and admit mistakes without being punished. Team health

Bus factor

How many people would have to leave before a system has nobody who understands it. Team health

DORA metrics

Deployment frequency, lead time for changes, change failure rate and recovery time. Operating model

SPACE framework

Five dimensions of developer productivity: satisfaction, performance, activity, communication and efficiency. Operating model

Managing up

Keeping your own manager informed and aligned so they can help you and your team. Managing up

Decision memo

A short document that asks for one decision with options, a recommendation and a deadline. Decision memos

Incident commander

The person who coordinates an incident response; they direct, others fix and communicate. Incident command

Severity level

A label such as SEV1 to SEV3 that sets how urgent an incident is and who must be told. Incident command

Blameless postmortem

A written incident review focused on causes in the system, not on who to blame. Postmortems

Design doc

A short written proposal for a piece of work, reviewed before building. Vision and design docs

Vertical slice

A small piece of work that delivers something usable end to end. Slicing work

Spike

A short, time-boxed experiment to answer a technical question before committing. Slicing work

Tech debt

Shortcuts or outdated choices in code that make future change slower or riskier. Quality and debt

Toil

Manual, repetitive operational work that could be automated and grows with load. Toil

Run versus change

Splitting spend between keeping systems running and building new capability. Budgets

Operating model

How a department is organised, plans, decides and measures itself. Operating model

Courses on Kolom

• From Engineer to Tech Lead: design docs, slicing, delegation, quality and debt.
• Engineering Management: 1:1s, feedback, hiring, performance, team health and managing up.
• Leading a Tech Department: Head of Engineering to CTO: strategy, operating model, budgets, risk and the board.
• Communication & Leadership: decision memos, exec updates and stakeholders.
• Site Reliability Engineering: incident command, postmortems and toil.

What to read next

• The Manager's Path by Camille Fournier. Every step from tech lead to CTO, with what changes at each.
• An Elegant Puzzle by Will Larson. Systems thinking for engineering management: team sizing, planning and org design.
• Accelerate by Nicole Forsgren, Jez Humble and Gene Kim. The research behind the DORA metrics; current reports at dora.dev.
• Radical Candor by Kim Scott. Caring personally while challenging directly.
• Staff Engineer by Will Larson, and his writing at staffeng.com, for the senior technical path.
• Google's SRE books, free at sre.google/books, for incident management and postmortems.