engineering-leadership

name	engineering-leadership
description	Engineering leadership principles and decision-making framework. Use whenever working on engineering projects, sprint planning, architecture decisions, code reviews, incident response, or team discussions. Apply these principles proactively.

This is the one real, worked example in this template. It is one person's engineering philosophy, written out in full. Read it for the depth a skill should have — then replace it with your own field and your own principles.

Engineering Leadership Principles

Distilled principles for how to approach every engineering project: sprint planning, PR reviews, architecture decisions, funnel analysis, incident retrospectives, data analysis, feature scoping, CI/CD setup, test strategy, and project kickoff. Apply them proactively — don't wait to be asked. If a proposed solution violates one of these principles, flag it.

---

Part 1 — Execution Principles

01 · Data Before Decisions

Never analyse before validating the data source. Contaminated or incomplete instrumentation produces wrong conclusions regardless of analysis quality.

• Fix tracking/event gaps before the sprint starts
• State assumptions explicitly when data can't be verified
• Contaminated data is not a minor issue — it is a blocker

02 · Averages Lie — Segment Everything

High-level metrics hide the real problem. Always break down by method, geography, user type, and traffic source before drawing conclusions.

• A 35% overall conversion rate could mean 60% in one cohort and 5% in another
• The fix for each sub-segment is usually completely different
• Lead with the insight, not the raw table

03 · Ruthless Prioritisation

Rank problems by failure rate or revenue impact. The highest-impact problem gets full attention — nothing else competes until it is resolved.

• 44% of failures from one root cause = that root cause is the sprint
• The most impactful fix is rarely the most interesting one
• No parallel war rooms — splitting focus halves the speed of both

04 · Ship, Measure, Adjust — Daily

Short feedback loops beat big-bang delivery. Monitoring is part of Definition of Done, not a post-launch task.

• If you can't measure it in production, it isn't shipped
• Run experiments instead of debates — ship the test, read the numbers
• Daily metrics check during sprints; call experiments early on clear signals

05 · Focus Multiplies Effort

Ten people on one problem beat ten people on ten problems. The War Room model works because there is no coordination overhead.

• One priority at a time during sprints — protect the focus
• Co-locate or keep a permanent call open — remove the lag between question and answer
• Time-box aggressively to force cutting the non-essential

---

Part 2 — Engineering Craft Principles

06 · KISS — Keep It Simple

Complexity is a liability. Every unnecessary abstraction adds maintenance cost and cognitive load to the next engineer.

• Prefer the boring, obvious solution
• Challenge complexity at review: "What is this buying us?"
• Applies to copy, UI, and APIs too — a confusing modal is a bug
• Test: Can a new engineer understand this without asking anyone?

07 · YAGNI — You Aren't Gonna Need It

Build for today's requirements, not tomorrow's hypotheticals. Premature generalisation adds complexity with zero benefit.

• Build what the ticket requires — not the "flexible version"
• Write it twice before abstracting it; the second use reveals the right abstraction
• Delete speculative code in reviews — if it's for an unscheduled future case, it doesn't merge
• Applies to infrastructure too — don't provision for scale not yet reached

08 · TDD — Test-Driven Development

Write the test first. The code is just making the test pass. TDD is a design practice, not a coverage metric.

• Red → Green → Refactor
• Tests define behaviour, not implementation — don't couple tests to internals
• Non-negotiable for business logic: payments, auth, data transforms
• Hard to test = design is wrong (function is doing too many things)
• 80% line coverage minimum; covering critical paths and failure modes is the goal

09 · Quality Gates in CI/CD

Broken code never reaches the next environment. Every environment promotion must pass all gates — no manual overrides without documented approval.

Gate	What it checks
1 · Build & Syntax	Compiles, imports resolve, no syntax errors
2 · Lint & Format	Style guide, no unused vars, no prod console.logs
3 · Type Check	No type errors, no unannotated any
4 · Unit Tests	All pass, ≥80% coverage, coverage can't decrease without sign-off
5 · Integration Tests	Auth, payments, data writes end-to-end; contract tests
6 · Security Scan	No critical CVEs, no secrets in code, OWASP top-10, least-privilege IAM
7 · Staging Smoke Tests	App starts, key flows respond — gate 7 fail = no prod deploy

09b · Ownership — Name on the System

Every system has a person (or team) accountable for it. No orphaned services, no "someone else will fix it."

• You build it, you own the uptime, the bugs, and the docs
• Create systems that work without you, not systems that depend on you
• Ownership includes on-call rotation, incident response, and playbook updates

---

Part 3 — Quality & Observability

10 · Build for Observability First

Define the success metric before building. Instrument failures, not just successes — survivorship bias in analytics is dangerous.

• Structured logs with consistent schema (machine-parseable)
• Alert on symptoms: conversion drop in 5 min > CPU at 80%
• Example: an analytics dashboard once showed 100% success on a checkout flow. The real completion rate was far lower — only success events were instrumented, so every failure was invisible.

11 · UX Quality is Engineering Quality

User experience issues are product defects, not design preferences.

• A button that says "Ok" when accepting legal terms is a legal and UX bug
• A checklist referencing an address not yet visible is a logic error
• Consistency across flows is a hard requirement — users build mental models
• Review the actual user journey end-to-end, not just the happy path

12 · Document and Distribute Learnings

Institutional knowledge must be explicit. Write retrospectives for methodology, not just outcomes — write for someone who was not in the room.

• If the same approach worked twice, document it as the default for the third time
• Reusable patterns become playbooks
• Blameless postmortems: fix the system, not the person
• Write for someone who wasn't in the room, not just for those who lived it

---

Part 4 — AI-Native Development

13 · AI-First by Default

The question is not "how can AI help here?" but "should a human be doing this at all?" Repetitive tasks, test generation, security scanning, and deployment validation are candidates for full agent ownership.

• Structure prompts, docs, and pipelines for agent readability
• AI agents own quality gates — not just assist them
• Start with low-risk, high-volume tasks; build confidence before expanding scope

---

Leadership Philosophy

• Lead by example — stay hands-on, review code, ship features
• The best engineering leaders are still engineers
• Build systems, not dependencies on yourself
• Hire for slope (growth rate), not just intercept (current skill)
• Transparency builds trust — share context, not just decisions
• Challenge conventional wisdom with evidence, not opinion
• "I don't know" is a valid answer; "I'll find out" is a better one

---

How to Apply This Skill

When reviewing a proposal or PR, check against:

• Does it add speculative complexity? (YAGNI)
• Are tests written first or alongside? (TDD)
• Can a new engineer follow this? (KISS)
• Is the data clean before we analyse? (Principle 01)

When starting a project, confirm:

• Success metric is defined and measurable (Principle 04, 10)
• Instrumentation and dashboards are in scope (Principle 10)
• CI/CD gates are configured (Principle 09)
• Scope is limited to current requirements (Principle 07)

When analysing data, always:

• Verify the data source before drawing conclusions (Principle 01)
• Segment before averaging (Principle 02)
• Instrument failures, not just successes (Principle 10)

When writing retrospectives, always include:

• The methodology, not just the outcome (Principle 12)
• Specific metrics: before and after (Principle 04)
• System fixes, not blame on individuals (Principle 12)