A principle is only worth writing down if a team can point to it mid-argument and it settles the thing. Otherwise it is a poster on the wall. The ones below map to arguments every team eventually has: whether to ship a half-finished change, whether a one-line patch really needs a review, who carries the pager when it breaks.
Good principles remove guesswork. They set a shared baseline for what good engineering looks like and make it easier for teams to move fast without creating chaos. Different organizations favor different ones, but the job is the same: turn taste into something a team can agree on before the pressure hits.
Here are the principles I find most useful.
Engineering Principles
Ship Frequently
We ship on a regular cadence to keep the feedback loop with the customer short. The bias is toward action: get something real in front of people rather than polish it in private. Ship frequently, but not carelessly.
Shipping frequently reduces risk. Smaller changes are easier to test, easier to review, and easier to roll back. They keep momentum high and prevent work from piling up into large, fragile releases. Frequent shipping also exposes real feedback earlier, which helps teams make better decisions and avoid building the wrong thing for too long.
Conduct Incident Debrief
We learn from our mistakes. When an incident occurs, it deserves an incident debrief meeting. The intent is to uncover a class of defects that stop us from delivering robust and reliable services. We want to analyze incidents in detail and implement procedures to prevent future occurrences. We conduct meetings blame-free.
A good incident debrief isn’t about finding who caused the issue but understanding why the system allowed it to happen. Most failures come from gaps in process, clarity, assumptions, or tooling. It's rarely from individuals. A blame free environment makes it easier for people to be honest about what went wrong.
Design in Public
We use the collective intelligence of our engineering team. We have a great pool of talent with different expertise. Designing in public gives opportunity to polish our design through constructive feedback. Capitalizing on expertise ultimately helps us deliver better software. We learn from our peers and clear out potential problems.
Designing in public is about making decisions visible so the right people can spot risks, challenge assumptions, and contribute their knowledge. Hidden designs often miss simple improvements that someone else could have caught in minutes.
Hire, Grow and Retain The Best
We want to hire the best talent, set them up for success, and provide an environment to retain them. In Steve Jobs’s words, “Go after the cream of the cream. A small team of A+ players can run circles around a giant team of B and C players.” Hiring is the beginning. We help engineers grow and give them opportunities. We provide fast feedback and accommodate needs where possible.
Great teams don’t happen by accident. They come from deliberate hiring, consistent coaching, and an environment where people are trusted to do meaningful work. Retaining great people matters just as much as hiring them.
Review all Code
We ensure consistency in our code, improve our implementation, learn from each other, and strive for quality by reviewing code. Scripts, patches, and project code should go through a code review process regardless of their size or purpose. A portion of production incidents come from small yet critical changes. We want to transfer knowledge as well as share expertise.
Code review is one of the simplest and most effective quality gates a team has. It catches mistakes early, strengthens shared ownership of the codebase, and spreads context across the team. Even tiny changes can introduce big issues, which is why every change deserves a second pair of eyes.
Good reviews are fast, respectful, and focused on clarity, correctness, and maintainability. They are not about personal style.
Build CI/CD Pipelines
We enable ourselves to release frequently and confidently with continuous integration and deployment. We add necessary testing and coverage to find defects and bugs before they hit production. Automating the process helps us deliver value at scale.
A strong CI/CD pipeline reduces manual work, shortens feedback loops, and lowers the risk of introducing regressions. When pipelines are reliable, engineers trust the process and focus their energy on solving real problems rather than managing releases.
Run What You Build
We are accountable for the services and systems we build. We think about the observability of the components from day one. Accountability pushes engineers to release services responsibly. On the flip side, it gives teams autonomy and decentralization. Each team can build as many services or systems and then run them.
Running what you build creates a natural feedback loop. When engineers operate the systems they design, they feel the real impact of their decisions, good or bad. It also encourages teams to invest in proper monitoring, alerting, and documentation, because they will be the ones responding when things go wrong.
Write Definition of Done
Definition of Done (DoD) can require different things depending on the work. Some work is longer such as initiatives. Some are small such as a task. In both cases, writing the definition of done gives us clear goals and a finish line regardless of the size of the work. DoD ensures expectations and prevents jobs from lingering without ever completing. For initiatives, scope creeping can occur in the absence of DoD.
A clear Definition of Done removes ambiguity. It aligns everyone on what “finished” actually means, and it protects teams from endless polishing or shifting expectations. Writing the DoD upfront also clarifies requirements and surfaces hidden dependencies before they bite.
When They Collide
These principles don’t sit in harmony. Ship Frequently pushes against Review All Code and Definition of Done every time a deadline is close. Run What You Build is the reason someone argues to skip the debrief at 2am. That tension is the point of writing them down. When two of them collide, the argument stops being about who is more careful and becomes about which principle wins this time, and why.
If I had to keep three, they would be Run What You Build, Review All Code, and Conduct Incident Debrief. The first makes people careful, because they carry the consequences of what they ship. The other two are how a team turns one person’s mistake into something everybody learns. The rest of the list gets easier once those three are real.
Good Reads
Blog: Is ‘you build it, you run it’s living up to the hype?
Article: Attracting and retaining the right talent