Principles vs Standards

There are many ways to codify good practices in an engineering team. Standards and Principles can be an effective way to agree and implement these shared practices but operate in very different ways. As I've gained more experience from managing teams, I've become increasingly a bigger fan of using Principles over Standards.

Standards are an agreed set of rules or conventions that the team commit to following. These are often concrete and specific, and stipulate HOW something should be done. They are usually fixed in stone and specify the minimum allowable standard. You could go higher, but you must not go any lower. For example a Standard for introducing new work into a codebase could stipulate: all code must be reviewed by one other person through pull requests, all comments must be addressed and all tests must be passed. This means that any code to be added to a repository must be reviewed formally by one other person. Any member of the team must follow this process if they wish to contribute to the codebase.

Principles on the other hand are guidelines or outlines for the team to follow but are more permissive and stipulate WHY we do something. Rather than specifying what must happen, Principles describe the desired outcome and leave it to individual team members to work out how to apply them. Using the previous example, a Principle could restate the Standard as: all code should be reviewed by someone else. This opens the way for different styles of review such as pair programming, mob programming and even automated AI review (depending on the complexity of the pull request). Here the intent is that someone else other than the author is involved in the process but it is left up to the individual to decide what that looks like.

You may ask why this distinction is important? For me it's part of fostering a team culture which treats engineers as adults who should be given some autonomy in choosing how they work. By continuously falling back to Standards, it denies engineers the opportunity to exercise creativity in solving problems and developing skills to challenge accepted dogma or practices. For this to work however, it does require a high trust and ownership environment and of course a positive feedback culture will be important to ensure individuals are open to feedback when a solution or process doesn't meet the agreed set of Principles.

Like Standards, it's also important that Principles are well understood by the whole team. Just because they are more 'abstract', it doesn't mean that a thorough vetting system isn't required to add Principles to a team's Ways of Working. Actually because Principles may be contradictory, there should be a higher benchmark for introducing Principles into a team. For example the Principle of YAGNI (You Aren't Gonna Need It) is contradictory to Designing for Future Proofing. These are competing principles and finding a path through both requires the engineer to make clear design choices in their code. Both Principles are valid, however they may be more or less valid in different circumstances. The joy of working in a team is navigating these Principles and creating a solution that chooses the most appropriate Principal for the task at hand.

I used to be a huge proponent of standards as a way of agreeing a set of working practices and using these to drive improvement. However this really sits against my preference for also pushing for maximum agency for developers. With some maturity, yes, I can also admit that there is no one way to achieve a goal. Principles allow maximum flexibility for teams to achieve a desired outcome in a way works best for them.

Now I'm not saying there isn't a place for Standards. They can be really useful if they have been agreed democratically (rather than forced upon them centrally) and universally accepted by the team. This also works best if adherence to Standards can be verified automatically such as adopting code formatting standards backed by automated checks before code approval but is less useful when addressing high order concerns such as how one deals with stakeholders.

For me the number of Standards vs Principles within an engineering team also gives an insight into how much trust there is within the team and between the management structure. In high trust environments, there's less requirement for a set of rules, because everyone has internalised agreed Principles. In low trust environments, Standards are used to specify how the team operates and how the work should be done. I know which type of team I'd prefer to be a part of and that's why Principles can also help create a shared ownership of Ways of Working.