Core Principles¶

These are not values. Values are aspirational. Principles are operational.

A value says "we care about quality." A principle says "we don't merge PRs without tests, even under deadline pressure, because debugging in production costs more than prevention."

These eight principles are the decision lenses I use—and that I expect leaders on my teams to use—when faced with trade-offs. They are not exhaustive, but they cover the ground where most engineering decisions live: psychological safety, clarity, ownership, delivery cadence, reliability, decision transparency, communication patterns, and inclusion.

Each principle includes:

• Why it matters—the reasoning behind the principle.
• What good looks like—observable behaviors you can adopt tomorrow.
• When to bend—because principles are not dogma.
• A real example—something concrete, not abstract.

1. Psychological Safety First¶

Why it matters¶

The research is clear—teams with high psychological safety outperform on nearly every measure that matters: innovation, learning from failure, early problem detection, and retention. This is not about being nice. It's about building an environment where bad news travels fast, where "I don't know" is acceptable, and where failure is treated as data, not blame.

When safety is absent, people hide problems until they become crises. They avoid risks that might help the team. They optimize for not being wrong instead of finding what's right.

Google's Project Aristotle confirmed it: psychological safety was the single biggest predictor of team effectiveness—more than talent, resources, or org structure.

What good looks like¶

Leaders model vulnerability. Say "I don't know" and "I was wrong" out loud, in public. If you never say these things, your team will learn that admitting uncertainty is not safe.

Postmortems are blameless. The focus is on what the system allowed to happen, not who made a mistake. The question is always "what made it possible for this to happen?" not "who did this?"

Dissent is welcomed and rewarded. When someone raises a concern—especially a junior person challenging a senior decision—thank them for the risk they took. Protect people who surface uncomfortable truths.

Experimentation is encouraged. Create space for spikes, proofs-of-concept, and reversible bets. Make it clear that thoughtful failure is a valid outcome.

When to bend¶

Safety is not a shield against accountability. If someone consistently underperforms or behaves in ways that harm the team, psychological safety doesn't mean you avoid the conversation. It means you have the conversation with respect and clarity, focused on behavior and expectations, not personal attack.

Safety enables high standards. It does not replace them.

Example¶

A team is evaluating a risky database migration. Two engineers—both relatively junior—raise concerns about the timeline and the rollback plan. Instead of dismissing the concerns or pressuring them to get on board, the tech lead says: "These are legitimate risks. Let's add a spike to test rollback, and let's build a feature flag so we can revert without a full deployment."

The migration is delayed by a week. It ships without incident. The engineers who raised concerns are publicly thanked in the postmortem for improving the plan.

2. Clarity Before Speed¶

Why it matters¶

Speed is not the goal—sustainable pace is. And nothing destroys pace faster than building the wrong thing, or building the right thing the wrong way because requirements were unclear.

Clarity is not just about documentation. It's about ensuring that before work starts, everyone involved understands: what we're building, why we're building it, what success looks like, and what we're explicitly not doing.

I've watched teams burn weeks building features that weren't needed, or that solved the wrong problem, because someone was in a hurry to start coding before the problem was understood. The rework cost was always higher than the time it would have taken to clarify upfront.

What good looks like¶

Documents start with context and a clear ask. Every proposal, every design doc, every issue starts with: What is the problem? What do you need from the reader? This is the "Bottom Line Up Front" approach borrowed from military communication—because it works.

Definition of Done is explicit. Before work starts, the team agrees on what "done" means. Does it include tests? Documentation? Observability? Feature flag? If it's not written down, it's not agreed.

Non-goals are stated. It's as important to say what you're not doing as what you are. This prevents scope creep and misaligned expectations.

Owners, interfaces, and review criteria are named. Who decides? Who implements? Who reviews? What are the criteria for approval? If these questions don't have answers, the work will stall or thrash.

When to bend¶

For truly reversible decisions with low blast radius, bias toward doing and documenting after. Not everything needs a design doc. A small refactor, a copy change, a minor bug fix—these can move fast.

The test is: if this goes wrong, how hard is it to undo? If the answer is "easy," move faster. If the answer is "weeks of cleanup," slow down and clarify.

Example¶

Before starting a new feature, the team writes a one-page brief:

• Problem: Users can't find their past orders on mobile.
• Success metric: 50% reduction in "where's my order" support tickets within 30 days.
• Non-goals: We're not redesigning the entire order history—just improving discoverability.
• First slice: Add a persistent "Recent Orders" link in the mobile nav.

The team ships the first slice in 3 days. Support tickets drop. No one asks "wait, what were we building again?"

3. Ownership with Guardrails¶

Why it matters¶

Micromanagement doesn't scale, and it destroys motivation. But pure autonomy without boundaries creates chaos, inconsistency, and risk.

The solution is not more control or less control—it's clarity about where freedom lives and where constraints exist.

Ownership means teams are accountable for outcomes, not just outputs. They build, run, and measure their work. They own the full lifecycle—from design to production support.

Guardrails mean there are non-negotiable standards: security practices, observability requirements, accessibility gates, deployment procedures. These are not bureaucracy—they're the rules that let everyone move fast without breaking things that matter.

What good looks like¶

Teams own outcomes end-to-end. You build it, you run it, you measure it. This creates feedback loops that pure handoff models cannot.

Guardrails are published and explicit. Every team knows what the non-negotiables are: SLO basics, security checks, code review requirements, deployment gates. These are documented, not tribal knowledge.

Disagree-and-commit is practiced. After a decision is made, the team executes as one—even those who disagreed. Relitigating decisions mid-implementation is expensive and demoralizing.

Escalation paths are clear. When a guardrail conflicts with a critical outcome, there's a defined way to propose a trade-off—not just ignore the guardrail.

When to bend¶

Guardrails can be bent with explicit risk acknowledgment and a time-boxed follow-up. If you're shipping without full observability because of an urgent customer need, that's a conscious choice—documented, with a ticket filed to close the gap within a defined window.

The key is making the exception visible and temporary.

Example¶

A team needs to ship a critical fix but doesn't have time to add the full dashboard their observability guardrail requires. They:

1. Document the exception in the PR.
2. Add basic alerting (the minimum viable observability).
3. File a ticket to complete the dashboard within one week.
4. Flag the exception in standup so the team knows.

The fix ships. The dashboard is completed five days later. The guardrail was bent, not broken.

4. Small, Steady, Shipped¶

Why it matters¶

Large batches hide risk. They delay feedback. They create integration hell. They require heroic efforts to land, and heroics are not sustainable.

Small batches—thin vertical slices that can be deployed independently—reduce risk, accelerate learning, and create a sustainable pace. This is not new thinking. It's the core insight of lean manufacturing, codified by Toyota decades ago, and proven repeatedly in software delivery.

The research backs this up. The DORA metrics show that elite teams deploy more frequently with lower failure rates. They achieve this not through heroics but through small, reversible changes with good rollback capabilities.

What good looks like¶

Work is sliced into thin vertical increments. Each slice delivers some user or system value. Each slice is deployable. If a "story" takes more than a few days, it's probably multiple stories.

PRs are small enough to review well. A 400-line PR is hard to review carefully. A 50-line PR gets thoughtful feedback. Review quality degrades rapidly with size.

Progressive delivery is the default. Feature flags, canary deployments, percentage rollouts. Changes are introduced gradually and can be reverted without a full deployment.

WIP is limited and visible. Work in progress is a form of inventory—it has carrying cost. Limit it. Make it visible. Finish things before starting new things.

When to bend¶

Some changes genuinely cannot be sliced—a database migration, a fundamental architecture shift. When this happens, invest heavily in the rollback plan, add extra review, and don't pretend it's a normal change.

But challenge the assumption. Most "can't be sliced" claims don't survive scrutiny. There's usually a way to introduce changes incrementally with adapters, feature flags, or parallel implementations.

Example¶

A large refactor is proposed: replace the legacy payment processor integration with a new one. Instead of a big-bang swap, the team slices it:

1. PR 1: Add the new payment adapter behind a feature flag. No calls yet.
2. PR 2: Wire up the new adapter for one payment method (credit cards).
3. PR 3: Gradually increase the rollout to 10%, 50%, 100%.
4. PR 4: Remove the old adapter and the feature flag.

Each PR is small, reviewable, and reversible. The migration takes three weeks instead of one, but ships without incident.

5. Reliability Is Product¶

Why it matters¶

Users don't experience your architecture. They experience whether the thing works when they need it. Reliability is not a technical concern separate from product—it is the product.

Every outage, every slow response, every error message erodes trust. And trust, once lost, is expensive to rebuild. Meanwhile, your team burns roadmap capacity fighting fires instead of building value.

This is why reliability work is not optional and not second-class. It competes for resources on equal terms with features. And when reliability is poor, it wins that competition until stability is restored.

What good looks like¶

Error budgets inform release pace. You have a defined reliability target (SLO). When you're within budget, you can ship faster. When you're burning budget, you slow down and stabilize.

Rollback is the first resort, not the last. When something goes wrong in production, the first question is "can we roll back?" not "can we fix forward?" This requires deployments to be reversible by design.

Runbooks exist before scale-outs. If you're adding capacity, spinning up a new service, or introducing a new dependency, the operational playbook is written before—not after—it's needed.

On-call is humane. People are not paged for noise. Escalation is clear. Support is available. Rotation is fair. Burning out your on-call engineers is a reliability problem, not a cost of doing business.

Incidents are practiced. You run tabletop exercises. You simulate failures. You test your recovery procedures before you need them for real.

When to bend¶

For time-critical, low-risk fixes, you can move faster—but still keep mitigation and rollback ready. The urgency doesn't remove the need for a safety net.

Example¶

After a dependency upgrade, error rates spike. The burn rate shows the team will exhaust their monthly error budget in three days if the trend continues.

The engineering manager declares a stability window: no new feature deployments until the issue is resolved. The team focuses entirely on diagnosis and fix. A regression is found and rolled back within 6 hours.

The stability window ends. Feature work resumes. The error budget—and team morale—remain intact.

6. Transparent Decisions¶

Why it matters¶

Every consequential decision has a half-life. The people who made it will forget the reasoning. The people who need to live with it weren't in the room. The context that made it right will change.

Without a written record, decisions get relitigated endlessly. New team members don't understand why things are the way they are. Old decisions become tribal knowledge that no one can articulate.

Architecture Decision Records (ADRs) solve this. Not because they're bureaucracy, but because they're the cheapest form of organizational memory. A few hundred words now saves hours of repeated debate later.

What good looks like¶

ADRs exist for meaningful choices. Design decisions, process changes, technology selections, policy shifts. Not every PR needs an ADR, but every decision that will outlive the sprint does.

Each ADR names consequences and a review date. Decisions are not permanent. They should include: what we expect to happen, how we'll know if we were wrong, and when we'll revisit.

One-pager is the default. ADRs should be short. If you can't explain the decision in a page, you probably don't understand it well enough. Longer is acceptable only when truly needed.

Decisions link back to ADRs. PRs, issues, and follow-up work reference the ADR that spawned them. This creates traceability.

When to bend¶

For reversible, low-impact decisions, a decision snippet in the PR is enough. You don't need a formal ADR for every choice. The test is: will someone ask "why did we do this?" in six months? If yes, write the ADR. If no, a comment is fine.

Example¶

The team decides to use gRPC instead of REST for inter-service communication in a new service. An ADR is written:

• Context: High call volume between services A and B; latency matters.
• Decision: Use gRPC with proto3.
• Alternatives: REST with JSON (simpler, higher latency), GraphQL (overkill for this use case).
• Consequences: Requires protobuf tooling; stronger contracts; ~40% latency reduction expected.
• Review date: 6 months after launch, or if we need to expose this API externally.

A year later, a new engineer asks why gRPC was chosen. They read the ADR. Question answered in 3 minutes.

7. Default Async, Meet for Conflict or Creativity¶

Why it matters¶

In remote-first teams, synchronous time is expensive. It requires coordination across time zones. It fragments deep work. It scales poorly.

Writing, on the other hand, scales beautifully. A well-written document can be read asynchronously by anyone, at any time, without requiring the author's presence. It creates a record. It forces clarity of thought.

This doesn't mean meetings are bad. Meetings are essential for high-ambiguity, high-emotion, or high-creativity situations. But status updates, information sharing, and simple decisions should not require everyone in a room at the same time.

What good looks like¶

Status is written, not presented. If the information can be consumed asynchronously, send it as a document or message. Reserve meeting time for discussion, not presentation.

Meeting invites state the purpose and ask. Every meeting has a clear "Bottom Line Up Front": why we're meeting, what decision is needed, and what pre-reading is required. No agenda, no meeting.

Pre-reads are sent 24 hours in advance. If you want people to come prepared, give them time to prepare. Sharing a document at the start of a meeting is not a pre-read.

Meetings produce written outcomes. Decisions, action items, and owners are captured in writing and shared immediately. If it's not written down, it didn't happen.

Live time is for alignment and exploration. When you need to resolve conflict, build shared understanding of something ambiguous, or brainstorm creative solutions—meet. These are synchronous activities.

When to bend¶

High-ambiguity and high-emotion topics often need synchronous time even if they could theoretically be handled async. When trust is low, when stakes are high, or when nuance matters—meet. Then document the outcome.

Example¶

A product trade-off needs resolution: should we prioritize performance or new features in Q2?

The product manager writes a one-page options document with the pros, cons, and her recommendation. It's shared 48 hours before a 45-minute decision meeting.

The meeting focuses on the two contentious points—not on explaining the options. A decision is reached. An ADR is published the same day.

Total synchronous time: 45 minutes. Decision quality: high.

8. Inclusion Is a Leadership Skill¶

Why it matters¶

Diversity is a fact. Inclusion is a practice. You can have a diverse team that doesn't perform because voices are not heard, credit is not shared, and opportunities are not distributed fairly.

Inclusion is not about being nice. It's about creating conditions where everyone can actually contribute. Diverse teams make better decisions—but only if the environment lets that diversity surface. That's the work of inclusion.

This is a leadership skill, not a personality trait. It can be learned, practiced, and measured.

What good looks like¶

Facilitation rotates and is structured. The same person shouldn't always run meetings. And meetings should have structure that creates space for quieter voices—round-robins, written input before discussion, explicit invitations to contribute.

Credit is public and accurate. When work ships, the people who did the work are named. Managers don't take credit for their team's ideas. Contributors are visible.

Opportunities are distributed. High-visibility projects, stretch assignments, speaking opportunities—these are tracked and distributed intentionally, not given to whoever is most visible or most vocal.

Hiring uses structured interviews and rubrics. Unstructured interviews amplify bias. Structured interviews with clear criteria and diverse panels reduce it.

Sponsorship is intentional. Senior leaders actively sponsor—not just mentor—people from underrepresented groups. Sponsorship means putting your reputation behind someone, advocating for them when they're not in the room.

When to bend¶

Never. Inclusion is not optional.

What can be adapted is the specific practice. Different teams, different cultures, different contexts may require different approaches. But the principle—that inclusion is a deliberate leadership practice, not an accident—does not bend.

Example¶

In a design review, a junior engineer makes a suggestion that gets talked over. The facilitator notices and intervenes: "Wait—Priya, you were saying something. Let's hear the rest of that thought."

Priya finishes her point. It's a good idea. It gets adopted.

The senior engineer who talked over her apologizes after the meeting. The facilitator notes this in their retro as something to watch. The team agrees to try a round-robin format for the next design review.

Putting the principles into practice¶

These principles are useless if they only exist in a document. Here's how to make them operational:

Quarterly Principles Review (30 minutes)¶

Pick 2–3 principles to focus on this quarter. For each, define 2 observable behaviors your team will adopt. Set a review date.

Principle-to-Decision Tagging¶

Every ADR includes a "Principle upheld" line. This forces you to connect decisions to principles explicitly, making trade-offs visible.

Weekly Retro Hook¶

Pick one principle each week. Ask: "Where did we uphold this principle? Where did we violate it? What one behavior will we try this week?"

Design Forum Gate¶

Proposals must include: context, alternatives considered, rollback plan (if applicable), and a clear ask. This enforces "Clarity Before Speed" structurally.

Templates¶

One-Screen Proposal¶

**Title:** [Change or decision]

**Context:** Why now? What constraints?

**Options (2–3):**

- Option A: [pros/cons/risks]
- Option B: [pros/cons/risks]

**Preferred & Why:** [Trade-offs acknowledged]

**Bottom Line & Ask:** [Decision needed by date]

**Principle upheld:** [Which principle does this honor?]

Weekly Retro Principle Prompt¶

**Principle focus this week:** [Name]

- Where did we **uphold** this principle?
- Where did we **violate** it?
- What **one behavior** will we try this week?

Further reading¶

• The Fearless Organization by Amy Edmondson — The definitive work on psychological safety and its impact on team performance.
• Accelerate by Nicole Forsgren, Jez Humble, and Gene Kim — Research-backed evidence on what drives software delivery performance.
• Turn the Ship Around by L. David Marquet — A practical guide to leader-leader structures and distributed decision-making.
• Thinking in Systems by Donella Meadows — Understanding systems behavior and why focusing on structure matters more than blaming individuals.
• The Toyota Way by Jeffrey Liker — The principles behind lean manufacturing, including small batches and continuous flow.
• Team Topologies by Matthew Skelton and Manuel Pais — How team structure affects ownership and delivery.

Related chapters¶

• Decision Making & ADRs — The system for making and recording decisions.
• Vision & Strategy — How to translate direction into bets and portfolio choices.
• Ethics & Responsibility — Doing the right thing when consequences matter.
• Team Ops: Working Agreements — Turning principles into team-level contracts.
• People: Feedback Frameworks — Operationalizing psychological safety through feedback habits.