# Engineering Leadership > Apply Raunak's engineering leadership principles to engineering projects, sprint planning, architecture decisions, code reviews, incident response, data analysis, and team discussions. Use when planning, building, reviewing, operating, or explaining engineering work. - Skill: `raunakkathuria/engineering-leadership` (Agent Skill) - Install (CLI): `npx skillmds@latest add raunakkathuria/engineering-leadership` - Raw SKILL.md: https://api.skillmd.com/api/skills/raunakkathuria/engineering-leadership/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - License: MIT - Author: raunakkathuria (https://skillmd.com/u/raunakkathuria) - Updated: 2026-09-22 - Page: https://skillmd.com/skills/raunakkathuria/engineering-leadership --- # Engineering Leadership Principles These are Raunak's 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 Zoom 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:* PostHog claimed 100% deposit completion — actual data showed 35% fiat failure rate because only success events were tracked **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 --- ## Content Themes When writing about engineering leadership: - Use real (anonymised) examples from engineering work - Challenge conventional wisdom — find the counterintuitive truth - Acknowledge trade-offs honestly — no silver bullets - Make it practical — the reader should be able to apply it Monday morning --- ## 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)