home

Principles, Trade-offs and Rules

I recently caught up with the CTO of a scale-up. Over the past years his team grew, shrunk and is now expanding again. The current architecture, technology stack and the direction of the product are clear. He would like his team to make more decisions, so that he can focus on the next frontier.

Talking about the challenge made us slide into the more generic topic of spreading tech culture and fundamentals. It started with the question: How do I transfer my architecture knowledge and reasoning?.

The first thing that came to mind is a quote of Andy Jesse, now CEO of Amazon, before that CEO of AWS: There is no compression algorithm for experience. You can short track people by making them experience, but you can’t skip the work and gift only the knowledge. The best you can do is create an environment where people make decisions, make mistakes, make their own choices and have their own arguments.

But how do you ensure they don't burn the building in the process? As a leader you remain responsible for the overall outcome.

In our conversation 3 tactics came to mind that have helped me shape architectures and tech culture.

  1. Principles
  2. Trade-offs
  3. Rules to be broken

Principles

Principles are gestures towards goodness. When picking a technology, designing rituals, implementing patterns, components, libraries, monitoring etc. people should take a moment to reflect how it holds up against the principles.

Principles generally span across teams and products. Some of them will probably apply to your organisation at large.

Some of my staples:

  • Don't wake me up at night - Especially relevant for ETL and batch systems. Engineer your data pipelines in a way that if something goes wrong in the middle of the night, you can calmly think - I’ll look at that tomorrow morning - and go back to sleep.
  • the holiday rule - If you pick any technical component and there are no 2 colleagues available that can support it, you’re not allowed to go on holidays. I wrote about this principle in the holiday rule.
  • bias for action - If the choice is between waiting or doing something. Pick something. You have to ask yourself, what new information waiting provides. What are you really waiting for? How much better will the extra information make your decision?

Trade-offs

Trade-offs are a special breed of principles. They indicate trade-offs you want people to be aware of including an indication what tips the scale. They function as guides in conversation. They provide weight to arguments when you are not there and are often tie-breakers when all options seem equally good.

Trade-offs are often specific to a product or section of architecture. A B2C front-end team will see trade-offs that are the opposite of a back-end ETL team.

The most well known trade-offs in the industry can be found in the agile manifesto. Examples of other trade-offs are reliability over speed and lazy over eager loading.

Rules to be broken

Rules are petrified principles. A principle is a gestures towards good, rules indicate explicitly where the boundaries are. They indicate unambiguously what you expect. I have a rule: never use MongoDB in production and another one don't use FIFO queues. I have my reasons, you have yours.

So what’s up with the to be broken part? If rules can’t be broken, they become dogmas and those are dangerous. You want your people to grow and achieve “senior engineering” status. They will at some point break your rules. Let them be rebels, as long as they know that they have some serious convincing to do when their POC works.

How to start

Sit down for an hour or two.

  • Create a page in confluence, Notion, wiki etc. where you list your principles, trade-offs and rules.
  • Provide each of them with 1 or 2 paragraphs with a description.
  • Share the page with your teams.

Take note of the questions your colleagues ask and the objections they bring. These indicate what the next paragraphs are to write. You will find yourself providing examples in conversations, write those down as well.

Fairly quickly you’ll have a living document. Over time this document will stabilize. That’s OK. Take a good look at the result and realize that there's a lot of you in there.

What are your go-to principles, trade-offs and rules? Find a comment section where you found this post, or tag me in a tweet (@wvduinkerken) and let me know!

Hope it helps!

– Wilco