Tenets

Why they have nothing to do with Christopher Nolan but yet still matter

Introduction

Tenets? I just don’t understand why everyone in Amazon is so into that movie. Did they really understand it and just think they’re better than everybody? - anonymous

Tenets as an organizational management tool is one of the valuable things I took away from working at Amazon. Definitely more useful than the Stockholm Syndrome my wife thinks I developed there. Just something she wonders out loud about when I mention missing working there.

As often is the case with my non-professional writing, I blather around here for a bit - so if you just want to see what my main point is just jump down to the next section. Probably skip the first paragraph there for good measure. If you’re paying me I’ll get to the point directly - I promise. ;-)

You’ve probably heard people talk about tenets or read one of the below three popular takes on them. They all probably do a better job of me explaining them. Which I’ll admit demotivated me on writing on this topic at first.

• Amazon’s “official” view. Or as official as a distributed system organization like Amazon can make anything. Golly, they had three different ordering pipelines (that I know of) at one point. Taking “two is one and one is none” to a ridiculous degree. I’m sure though that if there’s another official tenets doc from Amazon, it certainly doesn’t quote Ralf Waldo Emerson

• The complete guide to tenets per Dave Anderson. I can’t read the whole thing because I’m not paying for his excellent newsletter. At least I think it’s excellent - a lot of people love it and the free content is great. Even if I only got to read part of it before I got cutoff. Dave is great, and I know he knows what he’s talking about. So I’d definitely suggest reading this. Maybe you already have, especially if you can figure out how Substack delivers on it’s tease of an offer for “one free post.” But clearly I cannot so you should take my word for it that it’s probably good - and likely worth subscribing to. But I’m not working right now and I’m already pretty sure I know what tenets are so I’m not going to pay to be 110% sure.

• Bill Carr’s book - Per the many positive reviews I’m sure does a great job describing Tenets and other weird Amazon ways of working. Bill’s well versed in this stuff, and he seemed nice enough in my short encounters with him in the office. Certainly very sharp.

As good as these other sources of information on tenets are, I’m pretty sure none of them included a Christopher Nolan¹ joke (let along 3-5 more past the point of too many). Though as I’ve established, my due diligence on this point is alarmingly low. Please decide for yourself how important that factor is. There may be other benefits of my writeup - but I’m pretty sure about the movie references part.

Now I’ll continue since I’m sure I’ve weeded out the folks less committed to reading me than my mom is. Actually I’m joking/not joking because (a) my mom is not a subscriber, but (b) my dad is and I’m sure he’s stopped reading to inform my mom how sarcastic I’m being (again). In my defense, if they didn’t want me to be sarcastic they probably shouldn’t have raised me in NY, nor been Jewish. Definitely not both.

Oh, right - Tenets!

Most folks actually have heard about this tenets thing before now. Often as;

“Just write down the key principles about how you want
to think/operate/exist and great stuff will happen.”

It’s not really that easy, getting good tenets requires work. If they’re easy that’s probably a sign you didn’t do it right. While I don’t like the phrase “doing it right” generally - there is definitely a wrong way to do Tenets. Nothing super bad may happen - but you won’t get the benefit. Some people may look at you wrote down an organizational version of the Emperor’s New Clothes. OK - not some people - just me. There will be an example shortly on what to avoid.

Tenets in Ten Bullet Points

1. Tenets hardcode the team’s core vision about themselves - how they view success, how they prioritize at a high level, and preload decisions about tough conflicts.

2. Effective tenets are debated/negotiated with others that work with your team/organization as well as very senior leadership. Tenets arrived at without conflict/pressure testing are unlikely to be valuable in the longer term.

3. Ideally, tenets should be long running - static across projects and even goals. They should be updated over time as appropriate. They’re not fixed tablets taken down from the mountaintop. Amazon is fond of tagging “unless you know better ones” to any description of tenets in keeping with point #2 and #3 of this list.

4. If the tenets are accurate and specific you should be able to predict the outcome of different practical decisions faced by the team.

5. Successful tenets result in team members citing the tenets in support when arguing about the direction the team is taking.

6. Leaders outside the team reading the tenets should feel comfortable they understand how autonomous decisions would be made in the future.

7. There should be a limited number of tenets. Personally I think around 6-7 are usually sufficient.

8. Given agreement on the tenets (vision and identity of the team) and their goals (OKR’s) the team/org should be able to operate for pretty long periods of autonomy without a concern they will get out of alignment with the company’s global goals.

9. Unless your engineering team is the product itself (say an infra org) it’s generally best to set tenets for the business unit independent of the underlying disciplines delivers business value. ie; don’t have “engineering tents” and “product tenets” and so on.

10. Writing all this stuff down ensures that everyone agrees on what they mean. Otherwise, people often use phrases that are just vague enough that reasonable people will think they agree when they do not. Capturing tenets explicitly reduces the likelihood that some assumption will “make an ass out of you and me.”

    

Tenets - the longer narrative view (with examples)

Tenets are a functional definition by a group/team/org as to how they operate (prioritize, make decisions, etc). Well done tenets are extremely useful tools. Half baked tenets can be an unhelpful, time consuming distraction.

Tenets make explicit core assumptions about how an org/team sees themselves and how they make decisions. Also it lets outside teams and leaders inspect that thinking and agree or disagree early on. Getting the shared assumptions out in the open and codifying the agreement in a way that scales beyond 1-1 conversations helps even if things aren’t perfect.

Tenets can speak to what the team views as important, ways of working, and how to prioritize things when issues conflict. For example a team may state in the tenets that our goal is to improve the customer experience for buyers on amazon and sellers on Amazon, but when they're forced to choose they will bias toward the buyer. This makes clear that they view buyer experience as the most important part of their flywheel. You may not agree - but if you read the direct statement there’s a chance to debate this position up front.

Most writing on this topic accurately emphasizes the value of focusing the tenets on issues/elements that are controversial vs. things everyone agrees on. You don't really need tenets to guide areas of easy agreement².

Next, I share two examples of tenets that I think are pretty useful, and one that is not. I don’t have a lot of verbatim descriptions of great Tenets from Amazon. I wish I had a copy from my early trust and safety/seller performance days where we wrestled over many thorny issues with the S-team. Sadly, I was pretty diligent on not accidentally swiping anything on the way out of Amazon. So I’ll share some tenets I wrote to help organize my thoughts in other places - less litigious places hopefully. ;-)

Convoy Marketplace Demand tenets

At Convoy I wrote down some draft tenets for one of the later orgs I worked with. Actually - rereading I think I wrote some drafts of this initially but I don’t think I was the sole author. I can’t recall how far we got on operating against them. Please correct me ex-Convoy folks. Totally not a test as to whether you actually read what I write - definitely not that. :-)

The Demand Marketplace team focused interacted with shippers to see all the freight demand that existed, interface with it at scale, and bid on the the demand that made sense to drive Convoy’s overall flywheel. This involved bidding on long term opportunities (freight RFP’s), short term spot market opportunities, as well as ongoing yield management. Once a relationship was established you didn’t have to take all work offered, and sometimes shippers grossly underdelivered opportunities against your agreement which was good to know. The team was a multidiscipline pod with product, engineering, and science roles - and a close partnership with finance and operational teams.

Draft Marketplace Demand Engineering tenets … unless you know better ones

1. Our product innovation addresses shipper problems at the root cause: In the long term we prioritize relieving foundational shipper pain points to growth. For example: contracts today at best have the relationship status of “it’s complicated.” We view that both as a present reality to navigate and an opportunity to in the future make offers to shippers they can’t refuse.

2. Bad data is the bane of great decisions at scale: We prioritize fixing defects and eliminating uncertainty in our data as a priority second only to customer trust. Our focus is on continual improvement driven by constructive skepticism and deep dives.

3. Our decisions account for value both now and in the future: We invest in estimating the impact of choices to ensure we are identifying and acting on growth bottlenecks. A shared framework for value decouples pods to optimize with a global purpose.

4. Automation is not an end in itself: Data and technology driven demand acquisition, in the long term, will trump human decision making. However, we will defer to and enable human intervention in the short term, if the path to automation doesn’t exist or doesn’t lead to improved decision making, scale, or lower operational costs.

5. Broken systems cost us money and customer trust: they aren’t worth the “benefit” of doing something new: Before we ask “how can I build one more thing?” we consider “have I thought about how to prevent existing things from going wrong, and knowing something is broken asap?”

6. We continually look for areas to improve performance: We deliberately look to reduce defects and inefficiencies in our models and systems to remove waste and unlock value.

7. Make “future us” happier: Invest with a focus on velocity of learning and building - supported by infrastructure that supports technical fearlessness.

Tenets example from Stitchfix supply chain and purchasing teams

Another example of tenets come from my work at Stitchfix. We were responsible for the Procure to Payment end to end system. We built products that enabled buying of merchandise (via AI/ML as well as human experts), took delivery of those items (deciding which warehouse to use along the way), stored the product in the warehouse, enabled running the warehouse itself (including picking and fulfillment) and ensure all of this was reflected in pricing, and catalog systems. I’m not saying we 100% used these tenets as written - but it’s (like the Convoy ones) something I had that felt like a useful example.

Some of the tenets may seem very specific to a problem that might have been taking place at the time. In general, tenets should be durable. But that doesn’t mean they should be super abstract (disconnected from real problems). If you’ve had an issue, such as accepting all work without prioritizing (ie; saying “no” productively) to ensure focus, then it’s my view it’s valuable to encode that in your tenets. There are folks who will argue this for sure. Saying that it’s not unique to your team/business area, and while it’s important now you likely won’t be forever focused on the problem. As opposed to the evergreen: buy great stuff, utilize the great stuff you bought as effectively as possible, ensure you’re focused on great customer outcomes.

I’ve never gone to “official tenets university’ and maybe I’m off-base. But we were having some areas where we wanted to reinforce a culture shift from every direction possible. Due to this I felt (and feel) pragmatically justified in their inclusion. Tenets encode key ways of working so that there’s 360 degree agreement on how we want people to make decisions. If the leaders of the group know there’s been a tendency to make decisions with approach A and we want people to strongly use approach B then I feel it’s a valuable tenet to include. When things become second nature and no one would dream of not doing B then maybe that’s a good time to update things.

If folks are interested I have specific events that explain the inherent conflict we were trying to surface with many of the tenets below. It might be fun to explore them in a future post.

Digital Supply Network Tenets (unless you know better ones…)

1. DSN is the engine of Stitchfix - it must run smoothly without heroics. Keeping the lights on is job one and we will invest rigorously in (i) making sure things aren’t broken, (ii) if they are broken that they don’t stay broken for long, and (iii) ensuring they don’t break the same way twice. This is achieved by reducing root cause risks, not by doing lots of heroic work to keep things running.

2. We take as an article of faith that minimizing work in progress and technical decoupling of systems maximize throughput. In practice that means we focus on completing work on a smaller number of leveraged things and investing so easy things can be built quickly, and hard things are possible.

3. Our priorities are transparent and we say “no” directly and constructively. When forced to choose we prioritize in this order; high uptime systems, accuracy of data inputs, maximizing available - selectable inventory, keeping delivery promises, reducing cost structure as measured by $/order, and the ability to quickly and fearlessly deliver new features.

4. We do not start work without defining what the intent of the work is and how to judge success. Doing the most useful thing is more important than doing the “fast” or “easy” thing even if that means going slower in the short term. This allows our teams to align on intent and take broad autonomy as to “how” that intent is achieved.

5. Better inputs make better decisions: We prioritize accuracy of and timeliness of inputs whether they be data accuracy or the fullest possible early (probabilistic) view of where our inventory will be before it’s even there.

6. We exploit our Algo advantages³ by using them at 100% of their intended use cases. Every system that could benefit from an existing algo capability but does not due to our architecture is a defect we should work to eliminate.

7. Choose to make “future us” happier: We invest with a focus on velocity of learning and building - supported by infrastructure that supports technical fearlessness.

This was a work in progress, and reading this set of tenets I see things I want to debate. Things to remove, and some things to tweak. I’m going to not give in to that and leave potential improvements as an exercise to the reader. :-) The “unless you know better ones” label Amazon sticks next to every set of tenets is a fantastic reminder that tenets engender consistent debate, driving continual improvement.

An example of not super helpful tenets

I’m not looking to find a bunch of tenet examples to beat up on. Any attempt to write out key assumptions on what’s important and how you’ll make decisions is worth doing.

I did stumble across a set of working tenets that were in place when I joined a team. I’m not identifying where these are from, and it’s hard to guess from them. That “what team is this for?” quality is a sign that they could benefit from more work.

It’s not that I disagree with the statements. They’re mostly best practices that hopefully fall into the “mom and apple pie” category of things. My concern was that they’re not sharp enough to cause the sort of conflict that’s helpful in prioritization and decision making.

The ones that seem like someone might say “hey! wait! I don’t agree with that” also leave unanswered what it means to “cost more” or “take longer.” The reader wouldn’t be sure how to expect a decision around that to be made. I’d suggest the authors engage in some debates with people who might disagree (specifically seeking out that disagreement). Listening and asking questions narrowing down areas of the disagreement. Finally, documenting in new tenets where they wanted to fall on on each of the points in a very specific way

Tenets from org X:

1. Deliver value frequently, even if that means costing more, or taking longer.

2. Simplify & scale our technology, preferring to build where we are differentiated and partner or buy wherever we can with an eye towards long-term opportunities

3. Break org boundaries and ensure collaboration, even if that means going slower.

4. Continue to run the business while making long-term investments, even if that means separating teams and dealing with the knowledge transfer challenges.

Summary

Thanks for reading my take on Tenets. I suggest reading as many perspectives on the topic as possible. Definitely the three listed at the start of the article. You never know what’s going to be most helpfully resonant with you or your team.

Appreciate you taking the time to read my minor contribution to the genre. And just one more cartoon for the Nolan super fans.

1. I’m just being goofy. I really like many of Christopher Nolan’s film including the very different Memento, and Dunkirk. I didn’t really fully get Tenet though I appreciate how bonkers it is. I just want to be sure to be clear I AM NOT MAKING FUN OF CHRISTOPHER NOLAN. The Nolan fanboys are a bit scary - if you could still read the IMDb forums you’d know what I mean. OK - I’m kidding once again, I’m sure there was stuff way worse in those forums or they wouldn’t have been taken down. Not being able to keep them alive is one of my professional regrets from my time at IMDb.

2. This desire for disagreement highlights another aspect of Amazon culture that has helped them win continually. A constant fear of confirmation/agreement biases resulted in mechanisms and culture that reward constructive disagreement. Even if having those disagreements with less empathy than ideal is why in the market ex-Amazonians have a reputation as being jerks.

3. “Algo” at Stitchfix is what many other companies refer to as “Science” teams. So this is a reference to ML/AI or OR (operations research) capabilities.