The 8 Principles

The principles that guide value-driven engineers. Use them to evaluate decisions, guide your team, and challenge processes that don't add value.

01

Why before what

Don't build until you understand the purpose. The best engineers question the problem before solving it.

  • Ask "what problem are we solving?" before "how do we build it?"
  • Push back on requirements that don't have a clear "why"
  • Dig into context, don't just take tickets
02

Ship value, not activity

Busy isn't productive. Shipping code is not the goal. Shipping value is. Measure what matters to customers, company, team, and yourself.

  • Judge work by impact, not by lines of code or tickets closed
  • Ask "what changed for the user/business?" not "what did we ship?"
  • Beware of busywork disguised as productivity
03

Evaluate decisions through four layers of value

Every decision affects customers, company, team, and you. Consider all four or make the trade-off explicit.

CustomerDoes this solve a real problem for users?
CompanyDoes this create business outcomes?
TeamDoes this build capability and sustainability?
PersonalDoes this grow my skills and career?
04

Business language first

Your default should be understood by anyone. Go deep only when depth is required.

  • Clarify the impact first, then the implementation
  • Translate technical concepts for non-technical stakeholders
  • Save the jargon for conversations with other engineers
05

Every shortcut is a bet

Short-term wins matter. So does not burning down the house. Know which mode you're in and why.

  • Be explicit: "We're taking a shortcut here because X"
  • Set tripwires and safety nets: "If Y happens, we revisit this"
  • Don't let "move fast" become an excuse for permanent hacks
06

Reduce friction, eliminate empty rituals

Optimize your tools, communication, and routines for smooth flow. If a process doesn't add value—kill it or fix it.

  • Audit recurring rituals (e.g. standups, sprints, reports) for the value they actually create
  • Fix the tools that slow you down
  • Question inherited processes: "Why do we do it this way?"
07

Own the outcome, not just the task

Your job isn't done when the code ships. It's done when the problem is solved. Care about whether it actually worked.

  • Follow up after launch: did it solve the problem?
  • Take responsibility beyond your ticket
  • Think like an owner, not just an executor
08

Keep evolving

Self-reflection is a skill. Honest feedback is a gift. Build habits of deliberate improvement such as retrospectives, postmortems, skill-building.

  • Schedule time for reflection (personal and team)
  • Give and seek feedback to grow, not to criticize
  • Treat mistakes as learning opportunities, not failures
  • Document what you learn so it compounds

Principles are not rules

These are guides, not laws. Context matters. Sometimes you'll violate a principle deliberately—that's fine, as long as you know you're doing it and why. The goal isn't rigid compliance. The goal is better judgment.