Your Engineers Know How to Code. Do They Know What You Stand For?

Every engineering organization has coding standards. Most have a style guide. A few have documented their CI/CD practices.

In most engineering organizations, what the team actually believes about how software should be built is still undocumented: what "done" means, what they will not compromise on, what a new engineer should know on their first day that they cannot find in any technical document.

That document is the engineering manifesto. Its absence is more costly than it appears.

What an Engineering Manifesto Is

An engineering manifesto is not a list of values. Values are aspirational. They live on the about page and get quoted in all-hands meetings. "We value quality." "We move fast." "We are customer-obsessed."

An engineering manifesto is a working document, owned by the engineering team, that defines behavior. It answers the questions that values leave open.

"We value quality" is a company value. "We review our own code before asking a colleague to review it" is a manifesto principle. One sets a tone. The other changes what happens on a Tuesday afternoon.

"We move fast" is a company value. "We deliver in small increments and avoid failing twice for the same reason" is a manifesto principle. One is a slogan. The other is a practice.

The manifesto lives where people actually work. It's referenced in onboarding, in code reviews, in sprint planning, and in post-mortems. It is the operational translation of what the organization claims to believe.

What Goes In It

A good engineering manifesto has three sections.

Delivery principles cover how the team ships software. Not the tools, but the beliefs behind the tools. Examples of principles common in strong engineering teams:

• We always start with why. Before any piece of work begins, we know what problem it solves and what success looks like.
• We prefer continuous integration and small, frequent releases. Code that sits in a branch is a liability.
• We keep it simple. We don't build for imagined requirements. We build for what is needed now, and we plan to refactor as understanding grows.
• We define done as: documented, tested, reviewed, and observable in production. Not "merged" or "deployed." Observable and working.
• We fail fast when the approach is wrong. We treat failures as learning opportunities, use blameless post-mortems when warranted,2 and ensure we can roll back at any time.

Quality principles cover how the team thinks about the code itself. Not the testing framework, but the standard.

• We leave the code cleaner than we found it. Accumulating small improvements over time is how large refactors become unnecessary.
• We avoid over-engineering. A solution that works and is understandable is better than a solution that is theoretically elegant and practically obscure.
• We continuously tackle technical debt. It is part of normal work, not a separate track that happens when there is time. There is never time.

Process principles cover how the team makes decisions and handles problems.

• We validate assumptions early. A day spent testing whether an approach works is worth a week of building something that doesn't.
• We challenge processes that don't serve us. A retrospective that doesn't produce change is just a meeting.
• We avoid failing twice for the same reason. The post-mortem exists to produce action. Not just documentation.

---

Figure 1. The difference between company values and engineering manifesto principles. Values set direction. Manifesto principles define behavior.

---

How It Differs from a Company Mission

This distinction matters because the two documents serve different audiences.

A company mission is for everyone: employees, customers, investors, recruits. It has to be broad enough to resonate with all of them. Its breadth is a feature, not a bug. It needs to survive ten years of changing products and markets.

An engineering manifesto is for one audience: the engineering team. It can be specific because it doesn't need to generalize. It should be specific enough that a new engineer, reading it on their first day, knows exactly how to behave when they encounter an ambiguous situation. If they can read the manifesto and still not know how to handle the question in front of them, the manifesto is too vague to be useful.

What It Does for the Organization

For mid-market software companies, the manifesto punches above its weight.

Large companies have senior engineers in every team who carry institutional knowledge informally. A new engineer sits next to someone with five years of context and absorbs the culture through proximity. Mid-market companies rarely have that density. The knowledge lives in fewer heads, the turnover has more impact, and onboarding a new engineer without documenting what the team believes is expensive.

A well-written manifesto does what the senior engineer does informally, at scale and without requiring that person to be present. It answers the questions new engineers are afraid to ask. It gives experienced engineers language for pushing back on shortcuts. It gives leadership something concrete to point to when the team drifts.

Google's Project Aristotle highlighted psychological safety as a critical driver of team effectiveness.1 Clarity about expected behavior can support psychological safety. A manifesto helps create that clarity.

---

Figure 2. The three sections of a functional engineering manifesto and the questions each one answers.

---

How to Write One

The manifesto should come from the engineering leadership team, not a committee. A committee produces a document that pleases everyone and challenges no one.

Start with what you actually believe, not what sounds good. If your team doesn't actually follow a practice, don't put it in the document. A manifesto that describes an idealized team rather than the actual team loses credibility quickly. Write what is true, and use the gap between the manifesto and current practice as a target rather than a starting point.

Make it specific enough to be actionable. "We value testing" is not a principle. "We write tests before we ask QA to review" is a principle. The test of a good principle is: could someone who doesn't know us figure out what to do in a concrete situation by reading this? If yes, keep it. If no, rewrite it.

Review it annually. A manifesto that isn't updated becomes archaeology. When practices change because the technology changes or the team learns something, the document changes with them. That act of revision is itself a signal to the team that the document is a living operating guide, not a relic.

The First Step

If you don't have one, you already know what the manifesto should say. Your senior engineers know. The patterns you reinforce in code reviews, the shortcuts you push back on, the practices you require before a release. Those beliefs are already in your organization. The manifesto is the act of writing them down.

Write them down. The conversation that produces the document is often as valuable as the document itself. Teams that write one together tend to surface disagreements they didn't know they had. Those disagreements are the whole point. A manifesto only matters if the team uses it when it's inconvenient to do so.

---