Autonomy and guardrails

We trust people and teams to decide how they work. In return we expect them to know the boundaries, and we keep those boundaries few, explicit and open to challenge.

Autonomy

1. Make suggestions. If you think there is a better way, say so. An autonomous environment depends on everyone contributing ideas, and on reflecting on how past suggestions landed.
2. Experiment. Try new things. Treat each experiment as a chance to learn, whether it succeeds or fails.
3. Set your own direction. Own your path, aligned with the department's goals and values. Make sure it is purposeful.
4. Anticipate and act. Spot challenges, opportunities and needs before they arrive. Do not wait for instructions.
5. Challenge. Question assumptions and norms, with curiosity and a commitment to finding something better. Progress usually starts with someone asking why.
6. Keep yourself informed. Understand the boundaries you work within. You are accountable for meeting our standards, and staying informed lets you make better decisions.

Guardrails

A guardrail is not a rule about what you can and cannot do. It is a signal: a prompt to slow down, reflect and have a conversation. It encodes something we have learned, a risk we want to manage, or a way of working we want to encourage.

Take our guardrail that a change should normally touch fewer than ten files and two hundred lines. Its intent is incremental delivery, lower risk, and changes that are easy to review and test. The numbers are a proxy for risk, not the goal. Treated as a hard rule, a guardrail gets gamed (work split along unnatural lines) or ignored (one giant change anyway), and either way it stops working. Treated as a conversation trigger, it leads to better outcomes: engineers talk about other ways to approach the work, reviewers know to look harder, and genuine exceptions, such as a large rename, are consciously accepted.

A good guardrail is explicit about its intent, encourages discussion rather than compliance, allows sensible exceptions, surfaces risk early, and creates a feedback loop. When one is crossed, we ask whether it is still fit for purpose. Guardrails that stop evolving become obstacles.

Guided, not forced

Where several approaches exist, we may name a default: the way we expect teams to work unless they have a clear reason not to, such as the nature of their current problem or a deliberate experiment. We prefer defaults and guidelines to "best practices", because best practice implies the best way is already known, which discourages the improvement we depend on. Teams are expected to document their own working agreements, and to change them as they learn.