DevRel Decision Making: Diagnosing Type 1 and Type 2 Decisions

Working effectively within DevRel revolves around diagnosing and dealing effectively with Type 1 (irreversible) and Type 2 (changeable) decisions

On Friday, I was presenting an internal webinar for a company’s engineering department. Although the main focus of this particular presentation was on platform engineering and API gateways, I began by framing that a large part of software engineering is about good decision-making. As I was riffing on Jeff Bezos’s famous quote about Type 1 (irreversible) and Type 2 (changeable) decisions from his Amazon shareholder letter in 1999, I couldn’t help but think about related challenges I had encountered with my DevRel and product marketing advising work over the last year.

As much as it’s beneficial to understand the difference between Type 1 and Type 2 decisions—and cultivate the appropriate decision-making process—it’s arguably just as important to be able to diagnose which type of decision you are currently dealing with.

In DevRel, it’s easy to waste a lot of work (outputs/outcomes) by misclassifying Type 1 decisions as Type 2 and waste a lot of time (energy/money) by misclassifying Type 2 as Type 1.

Type 1 and Type 2 decisions

Jeff Bezos described the major difference between the two decision types in a now famous letter to Amazon shareholders in 1999:

Some decisions are consequential and irreversible or nearly irreversible – one-way doors – and these decisions must be made methodically, carefully, slowly, with great deliberation and consultation. If you walk through and don’t like what you see on the other side, you can’t get back to where you were before. We can call these Type 1 decisions. But most decisions aren’t like that – they are changeable, reversible – they’re two-way doors. If you’ve made a suboptimal Type 2 decision, you don’t have to live with the consequences for that long. You can reopen the door and go back through. Type 2 decisions can and should be made quickly by high judgment individuals or small groups.

In my webinar, I shared experiences from my software engineering career, where I had seen Type 1 decisions treated as Type 2 and vice versa.

As examples, I riffed on having seen deeply impactful issues treated like Type 2 decisions, such as architectural style (microservices obvs!), language choice (“our investors like Rust”), and deployment mechanism (Dockah, Dockah, Dockah!). As much as I poke fun here, all these technologies are fantastic. My issue was that teams didn’t spend much time deliberating whether these were their best choices.

I also saw Type 2 decisions like logging library choices and website fonts treated as Type 1 decisions. This is often seen as “bikeshedding” or the “law of triviality”. I don’t thinks it’s an understatement to say that some of these extended deliberations probably cost tens or hundreds of thousands of pounds/dollars/euro in wasted people hours.

As my career progressed, I recognized that the failure to treat decisions correctly was often a failure of diagnosis, i.e. people did not or could not diagnose the situation.

If you can’t diagnose the situation correctly, you only apply the right process to making a decision by luck.

How does this apply to DevRel or PMM?

Just as I encountered challenges with decision-making processes in my software engineering consulting, I saw the same with DevRel.

Decision-making around defining ideal customer profiles (ICPs) and which market segments to target with DevRel or marketing efforts was often seen as a type 2 decision. I’m all for running rapid experiments and “failing fast”, but if your organisation is having trouble with driving awareness and finding top-of-funnel leads — and critically, doing so in a repeatable and sustainable way — an ill-defined or rapid shifting of the audience is not going to help you understand your challenges. Some more careful (Type 1) thought about who your ICP is and how you will target relevant personas may lead to better results.

I’ve also seen program or campaign creation being treated as Type 1 decisions. If we know our ICP and key personas and want to experiment with running a podcast, creating use cases, or live-streaming some coding sessions, getting this live should not take weeks of deliberation. If you feel you need to get approval for everything or end up in drawn-out debates on the benefits or prioritization of work, it may point to some deeper cultural issues within the organization (and here I’ll point you to Westrum’s Organization Model).

There is clearly some nuance here, and I should stress that I mostly work with early-stage companies that work (or aspire to work) relatively autonomously. These are generally the kinds of places where making an incorrect Type 2 decision won’t limit your career trajectory or have major political ramifications — and this is precisely why I like working in early-stage companies!

Learning about Type 1 and Type 2 decisions is the first step to better decision-making. The next step is to learn more about diagnosing situations and to practice accordingly.

Developing your diagnosis skills and your situational awareness are deep topics, and I encourage anyone interested to learn more about this in Richard Rumelt’s “Good Strategy, Bad Strategy”, Will Larson’s “Writing an engineering strategy”, or Simon Wardley’s “Crossing the River by Feeling the Stones”.

Have you seen these problems with DevRel decision-making?

I hope this has provided some food for thought. If you have any feedback or comments or want to share examples of bad (and good!) decision-making, please do so in the comments or via DMs.