Tenets: supercharging decision-making

“Once you make a decision, the universe conspires to make it happen.”

– Ralph Waldo Emerson, essayist & philosopher

Thinking is hard; energy intensive even. Perhaps that’s the reason we obsess about food. One estimate indicates we make over 200 food-related decisions a day. Another popular internet statistic boldly states that the average human makes 35,000 decisions a day. I’m skeptical but it illustrates a point: decision-making consumes a significant part of our day.

Part of the complexity is that each of us interprets the data related to decisions differently, consciously and unconsciously, informed by our own biases and experiences. In the workplace the added pressures of multiple priorities, career aspirations, and politics further complicates the problem. So it’s not surprising that decision-making in organisations contribute massively to delays, misunderstandings, project failures, and conflict. One officer at my previous company found that in some cases, “technology projects” deemed slow were often preceded by business decisions which dragged on for a decade or more.

I see the same with many cloud migrations and initiatives today. The cloud inherently allows teams to make decisions, try experiments, and course correct, quicker. This fails though if decisions are not being made at the same speed. Indecision and unhealthy conflict can be minimised by taking the time to create a common framework and language for making decisions. This is where tenets excel.

What is a tenet?

A tenet is an organisational belief that accelerates decision-making. Tenets clarify and align people on what is important and what, by extension, isn’t. Tenets can be applied to teams, products, services, or even whole organisations. Architects will be familiar with tenets as they are the essence of good architecture: deciding what trade-offs need to be made as I’ve discussed previously.

A good tenet concisely and clearly articulates a single idea, acting as a tie breaker in decisions. Take the following tenet:

“We optimise for speed. Speed enables us to learn quickly, pivot if needed, and to scale quickly.”

What does this mean to a decision-maker? It advocates that getting new ideas into the hands of customers to measure efficacy is more important than a hypothetical perfect solution stuck in a deployment backlog. It acknowledges that ideas might not work, and that changing direction based on learnings is healthy. In McDonald’s we adopted a similar approach to accelerate digital deployments, using the tenet “progress over perfection.” It was powerful because it made imperfection permissible, avoiding the never ending planning cycles in a futile hope of avoiding any potential problems.

Tenets are useful

To be effective a tenet needs to have an opposite which could be acceptable to an organisation. It helps prevent blindly obvious statements being turned into tenets. A tenet such as “we optimise for value” doesn’t help with decision-making. After all, would you really optimise to deliver useless features quickly? Similarly “We should not build unsecure software” is both common sense and does not have a defensible alternative.

Corporate mantras (“We will think outside of the box”) and actual decisions (“The team will only use Java”) also make for poor tenets. They don’t fulfill a key role of a tenet: to help make decisions on where time and effort should be spent. Let me illustrate this with a tenet from our Principal Engineering community:

“Exemplary Practitioner – Principal Engineers are hands-on and lead by example. We deliver artifacts that set the standard for engineering excellence, from designs to algorithms to implementations. Only by being close to the details can we earn the respect needed to be effective technical leaders.”

It’s a tenet that helps ensure principal engineers retain their engineering disciplines and are capable of deep diving into issues to help and coach their teams. Similarly, the hybrid architecture tenets we use recognise and promote the need for consistent control planes, tools, SLAs and APIs regardless of your deployment model. They promote ease of deployment, management, and support over cool but inconsistent functionality.

Tenets are durable

As I write this, there is an argument exploding on social media about whether microservices are good or bad. Aside from a plea for the CTOs involved to stop treating technology as a religious, binary debate, it illustrates how the application of tenets may change over time but the actual tenets stay relatively stable. For a product or service team, tenets should be applicable from ideation through to scaling, and beyond, into subsequent releases. A particular feature may fail, but the underlying tenets should remain true. With the current debate, using serverless to accelerate time to market for a particular service achieved the rapidity of learnings a team needed, but a different architecture was more appropriate as the service scaled massively.

Tenets create tension

The previous point also illustrates the need for high judgement when applying tenets as there will typically be tensions between tenets.  Take an example of a complementary tenet to the one promoting optimising for speed:

“We continue to drive the cost of transactions down as we scale. Optimising costs enables us to build new differentiating features.”

Do I perhaps spend more to deliver value faster, or do I focus on reducing cost? Well, it depends. There are the natural trade-offs as I’ve discussed in my previous blog post. Initially the focus might be on moving fast and learning quickly. As an application scales, this second tenet aligns us all that we want to continue to learn fast, but to do so we need to attract more customers and/or drive down the average transaction cost to free up investments. This might mean rearchitecting to or from, say, serverless or a particular database. These aren’t holy debates; they are objective considerations to achieve a mission given the current point of time, informed by your tenets.

Tenets are concise

The general rule of thumb is to have no more than 7 tenets, in descending order of priority. This helps avoid the natural temptation to try to cover every eventuality. Keeping the tenet itself and the subsequent description short forces a level of precision and discipline that helps makes them useful and meaningful even to new starters on a team. It helps eliminate weasel words and hedging that dilute the impact and the intent of each of the tenets.

Tenets promote trust

Tenets help talented teams take decisions faster and with less conflict, particularly in high judgement situations. They may reinforce an existing belief or establish a new convention such as automating undifferentiated work, or building software only where it is a competitive differentiator.

Well-written and used tenets promote trust. If I know how one of my teams is intending to make decisions through clearly articulate tenets, I’m less like to feel the need to get involved in every decision. As a leader I can spend more time ensuring the decision-making framework is right, not every single decision, leading to more trust, more speed, and less conflict.

Unless you know better ones

Any set of tenets in AWS is followed by the phrase “unless you know better ones.” It invites debate and an open mindedness on whether one or more tenets remain appropriate as an organisation or product evolves. It is itself a tension within tenets: creating tenets which are both durable and changeable.

If, like me, you believe leadership is about creating a framework in which your teams can operate with autonomy and clarity, tenets are a natural tool to help on this journey. Consistently I find that investing time in developing tenets surfaces and resolves differences of opinions, ultimately leading to a more conduicive environment to delivering value faster. Less wasted time and energy, and more time for you to really think about what you want for dinner, for pleasure not fuel.

Phil