Engineering Principles in Practice

Learning outcomes

Engineering principles are cheap to recite and hard to live by. A senior engineer is distinguished not by knowing the slogans, autonomy and alignment, documentation as routine, hexagonal architecture, but by applying them on a Tuesday afternoon when a deadline is tight and a shortcut looks tempting. This concept teaches the principles that shape work at Trade Republic as practices with costs, boundaries, and failure modes, so that in an interview you can show lived judgement rather than memorized values.

After studying this page, you can:

• Explain autonomy with alignment as a daily discipline, not an org chart, and name the mechanisms that hold it together.
• Treat documentation as a routine engineering activity and justify why it matters in an autonomous organization.
• Apply hexagonal architecture to keep a domain core independent of frameworks and external systems.
• Use written decisions (RFCs and ADRs) to make technical choices durable and reviewable.
• Reason about money-safety as the first principle that overrides all others in a regulated business.

Before we dive in

The wrong way to hold an engineering principle is as a rule to obey. “We do hexagonal architecture” becomes a box to tick, and the moment the box is ticked the thinking stops. The right way to hold a principle is as an answer to a recurring problem, which means you understand the problem, you understand what the principle costs, and you know when the principle should yield. A senior engineer who cannot name the cost of a principle, or the condition under which it breaks, does not understand the principle, they have merely memorized its name.

The problem that forces principles into existence is scale, not of traffic but of people. A team of five engineers can coordinate in a hallway and keep the design in one head. A product-and-technology organization of roughly 280 engineers across domain teams cannot. Coordination through hallway conversations fails because most engineers never meet most other engineers, and the design no longer fits in one head. Principles are the compression scheme: they encode the decisions the organization has already reasoned through, so each team does not re-derive them and does not silently contradict them. The principles below are the ones that show up in how Trade Republic actually works, and each is an answer to a specific coordination or correctness problem.

Autonomy with alignment

The first principle is that domain teams are autonomous but the stack and the architecture are aligned. Autonomy means a team owns a business outcome end to end and can choose how to achieve it; alignment means the choices live inside a governed technology set and a written decision process. These are in deliberate tension, and the tension is the point. Pure autonomy fragments the organization into private technology islands; pure alignment strangles velocity. The discipline is to hold both at once.

The mechanism that holds them is concrete. The Tech Radar defines the recommended technology set (the adopt ring) and the experimental set (assess and trial), so a team choosing inside adopt needs no permission and a team choosing outside it writes an RFC. The architecture forum of Senior and Senior-plus engineers reviews significant decisions, so a team cannot quietly introduce a new datastore or a new language. The result is that autonomy is real inside a bounded choice space, and alignment is enforced at the boundaries, not inside every decision.

Autonomy is bounded, not absolute

The phrase “autonomous teams” misleads candidates into thinking teams can build whatever they want. The truth is the opposite: autonomy is the freedom to choose inside a governed space, and the governing mechanisms (Radar, RFCs, forum) are what make that freedom safe. A senior engineer defends the boundaries, because removing them restores the fragmentation the organization left behind.

The cost of this principle is the overhead of writing and reviewing decisions. A team that must write an RFC to add a technology pays a latency tax on innovation. The organization accepts that tax because the alternative, fragmentation, costs more in the long run: on-call engineers who cannot reason across services, security teams who cannot audit a moving target, and hiring pipelines that must support a dozen stacks. A senior engineer internalizes this tradeoff and does not resent the process.

Documentation as a routine

The second principle is that documentation is a routine engineering practice, not an afterthought. The origin problem is knowledge transfer in an autonomous organization. When each team owns a vertical slice, the knowledge of how that slice works lives in the team, and a team that does not write it down becomes a silo. New joiners ramp slowly, on-call engineers from neighboring teams debug blind, and decisions get relitigated because nobody remembers why they were made.

The principle in practice is that documentation is written as part of the work, not after it. A new service ships with its runbook; a significant decision ships with its architecture decision record; a complex pipeline ships with the diagram that explains it. Making documentation routine improves knowledge sharing across autonomous teams, which is the precondition for the whole organization functioning.

The reason this is a senior expectation is that documentation is a force multiplier that only senior engineers can wield well. Junior engineers document what the code does; senior engineers document why the system is shaped the way it is, the alternatives that were rejected, and the failure modes that were considered. That “why” documentation is what lets the next engineer change the system safely instead of rebuilding it from fear.

The diagram’s point is that documentation is not one document, it is a set of artifacts produced at predictable moments, and the predictability is what makes it routine rather than heroic.

Hexagonal architecture and ports and adapters

The third principle is hexagonal architecture, also called ports and adapters, and it answers a specific problem: keeping the domain core independent of the frameworks, databases, and external systems it talks to. The origin problem is the slow rot where business logic accretes inside a web framework handler or a database access layer, until the business rules can only be changed by touching the infrastructure and the infrastructure can only be changed by touching the business rules. The two become inseparable, and testing the business logic without the infrastructure becomes impossible.

Hexagonal architecture separates the domain core from the outside world with ports (interfaces the core defines) and adapters (implementations that connect a port to a specific technology). The core knows only its ports; it does not know whether a port is satisfied by Kafka, by an in-memory stub, or by a REST client. A real-time yield service written this way has a domain core that computes yield from quotes, and a port that publishes results; the adapter that connects the port to Redis Cluster or to a Kafka topic is a separate concern.

The cost of this principle is more interfaces and more files, which feels like overhead to a junior engineer. The benefit is that the business rules become testable in isolation and the infrastructure becomes swappable without a rewrite, which pays for itself the first time a datastore is changed or a service is migrated. A senior engineer reaches for it precisely because the boundary is what makes long-term change safe.

Written decisions over verbal ones

The fourth principle is that significant technical decisions are written as RFCs and architecture decision records and reviewed by the architecture forum, rather than made verbally and forgotten. The origin problem is decision decay: a choice made in a meeting is remembered differently by each attendee, is invisible to absent engineers, and is re-litigated months later because nobody can point to the reasoning. Written decisions solve this by making the choice, the alternatives, and the reasoning durable and addressable.

An architecture decision record is not a long document, it is a short one that answers four questions: what is the decision, what alternatives were considered, why was this one chosen, and what are the consequences. The discipline of writing it forces the author to confront the alternatives they might otherwise hand-wave, and the record lets a future engineer change the decision intelligently instead of blindly.

The architecture forum adds a review step for significant decisions, so a choice that affects more than one team is examined by Senior and Senior-plus engineers who have seen the consequences before. The forum is not a gate that blocks innovation, it is a mechanism that catches the second-order effects a single team cannot see. A senior engineer treats the forum as a resource, not an obstacle, because the review surfaces blind spots before they reach production.

Money-safety as a first principle

The fifth principle, and the one that overrides the others when they conflict, is money-safety. In a regulated money business, correctness of the ledger and the position store is not a quality goal, it is the product. A missing notification is a bug; a missing balance is an incident; a duplicated debit is a regulatory event. The principle is that any design choice that risks money correctness is rejected, even if it is faster, cheaper, or simpler.

This principle shows up as concrete disciplines. A balance mutation and its event share a transaction (the outbox), so the two never diverge. An order is idempotent on a stable key, so a retry after a timeout cannot create a second fill. A reconciliation runs against the external custodian, so an internal error cannot persist undetected. A rollback is present on every failure path, so a partial mutation never survives. These are not independent good practices, they are all instances of the same principle: the system must never be in a state where money moved and the records disagree.

When principles conflict, money wins

A candidate who optimizes a money-path service for latency at the cost of transactional safety has the priorities inverted. The senior move is to make the money path correct first (atomic, idempotent, reconcilable) and then optimize latency inside that correctness budget. A millisecond saved by skipping a rollback is a future incident bought on credit.

Where principles break under pressure

Each principle above has a pressure under which it yields, and a senior engineer names the yield rather than pretending the principle is absolute.

Autonomy yields when a decision crosses domain boundaries. A team that introduces a shared dependency or a cross-team contract cannot decide alone, because the consequences land on other teams. The principle yields to forum review, and the senior engineer invokes that yield deliberately.

Hexagonal architecture yields for genuinely thin services. A service that does nothing but proxy a call to an external system does not need a domain core and six ports; forcing the pattern there is ceremony without benefit. The principle yields to simplicity, and the senior engineer recognizes when the boundary is not earning its cost.

Documentation as routine yields when it becomes documentation as substitute. A team that writes elaborate documents instead of shipping working software has inverted the practice. The principle is that documentation accompanies the work, not that it replaces it.

Written decisions yield for reversible, low-stakes choices. Not every decision needs an RFC; forcing the process onto a trivial choice taxes the team and the forum for no benefit. The senior engineer scales the formality of the decision to its stakes and reversibility, writing records for the consequential and irreversible choices and moving fast on the rest.

Common mistakes candidates make

The mistakes here are signs a candidate has heard the principles but not practiced them.

Reciting the slogan, not the cost. A candidate says “we do hexagonal architecture” but cannot name what it costs or when it should yield. The interviewer hears a fashion statement, not a judgement.

Optimizing the money path for the wrong property. A candidate makes the ledger faster by weakening its transactional guarantees. The senior move is correctness first, optimization second.

Treating documentation as a deliverable rather than a routine. A candidate describes writing docs as a separate phase after the work. The practiced engineer writes them as part of the work.

Forgetting rollback on the happy-path design. Even when discussing principles, a candidate designs a flow with no failure recovery. Money-safety requires rollback or compensation on every path.

Invoking autonomy as a shield against review. A candidate frames a risky choice as “the team decided autonomously.” The senior framing is that autonomy is bounded, and consequential choices yield to forum review by design.

Mastery Questions

Question

Explain autonomy with alignment as a daily discipline rather than an org-chart description. What mechanisms enforce it, and what does it cost?

Question

Why is documentation treated as a routine engineering practice rather than an afterthought, and what distinguishes senior documentation from junior documentation?

Question

What problem does hexagonal architecture solve, and when should a senior engineer decide not to apply it?

Question

A candidate optimizes the ledger service for latency by moving the event publish outside the transaction so the commit returns faster. What principle does this violate, and what is the senior framing?

Question

What four questions does an architecture decision record answer, and why does writing it force better engineering?

Question

Each engineering principle has a pressure under which it yields. Give two examples of a principle yielding and the condition that triggers the yield.

Question

Why is money-safety described as the first principle that overrides the others, and what concrete disciplines does it produce?

Answer

Domain teams own a business outcome end to end and choose freely inside the Tech Radar's adopt ring, but choices outside it require a written RFC and significant decisions pass through an architecture forum of Senior and Senior-plus engineers. The mechanisms are the Radar (the governed choice space), RFCs and ADRs (durable written decisions), and the forum (cross-team review). The cost is the latency tax of writing and reviewing decisions, which the organization accepts because fragmentation (the alternative) costs more in on-call reasoning, security auditing, and hiring.

Answer

In an autonomous domain-team organization, the knowledge of how a slice works lives in the team, and a team that does not write it down becomes a silo: new joiners ramp slowly, neighboring on-call engineers debug blind, and decisions get relitigated. Routine documentation (runbooks shipped with the service, ADRs shipped with decisions, postmortems shipped with incidents) feeds a shared knowledge base. Junior documentation records what the code does; senior documentation records why the system is shaped that way, the rejected alternatives, and the failure modes considered, which is what lets the next engineer change it safely.

Answer

It solves the rot where business logic accretes inside framework handlers or data-access layers, making the business rules untestable without infrastructure and the infrastructure unchangeable without touching the business. By defining ports (interfaces) in the domain core and connecting them with swappable adapters, the core stays pure and testable. A senior engineer should not apply it to a genuinely thin service that only proxies a call: there the boundary earns no benefit and becomes ceremony. The principle yields to simplicity when the core has no real domain logic.

Answer

It violates money-safety as the first principle. Moving the publish outside the transaction recreates the dual-write problem: the balance can commit while the event is lost, leaving money moved and records disagreeing. The senior framing is correctness first: make the money path atomic, idempotent, and reconcilable (the event shares the transaction via an outbox), then optimize latency inside that correctness budget. A millisecond saved by skipping transactional safety is a future incident bought on credit.

Answer

An ADR answers what the decision is, what alternatives were considered, why this alternative was chosen, and what the consequences are. Writing it forces the author to confront the alternatives they might otherwise hand-wave and to state the tradeoffs explicitly, which catches shallow reasoning before it reaches production. The durable record also lets a future engineer change the decision intelligently instead of blindly relitigating it, which is the knowledge-transfer payoff in an autonomous organization.

Answer

First, autonomy yields when a decision crosses domain boundaries: a team introducing a shared dependency or cross-team contract cannot decide alone because the consequences land on others, so the choice goes to forum review. Second, written decisions yield for reversible, low-stakes choices: not every decision needs an RFC, and forcing the process onto a trivial choice taxes the team for no benefit. The senior skill is scaling the formality of a decision to its stakes and reversibility, invoking the process for consequential irreversible choices and moving fast on the rest.

Answer

In a regulated money business, ledger and position correctness is the product: a missing notification is a bug, but a missing or duplicated balance is an incident or a regulatory event. Money-safety overrides other principles when they conflict, so latency or simplicity cannot be bought at the cost of correctness. The concrete disciplines are all instances of one rule that money and records never disagree: the outbox (balance and event share a transaction), idempotency keys (retries cannot create a second fill), reconciliation against the external custodian (internal errors cannot persist undetected), and rollback on every failure path (partial mutations never survive).

Question

Explain autonomy with alignment as a daily discipline rather than an org-chart description. What mechanisms enforce it, and what does it cost?

Answer

Domain teams own a business outcome end to end and choose freely inside the Tech Radar's adopt ring, but choices outside it require a written RFC and significant decisions pass through an architecture forum of Senior and Senior-plus engineers. The mechanisms are the Radar (the governed choice space), RFCs and ADRs (durable written decisions), and the forum (cross-team review). The cost is the latency tax of writing and reviewing decisions, which the organization accepts because fragmentation (the alternative) costs more in on-call reasoning, security auditing, and hiring.

Prev1 / 7Next