Inevitably, this appears as a cycle:

1. Purge all media consumption

2. Feel an incredible freedom of mind, time, and weird creativity

3. Discover an insightful essay, book, or podcast

4. Slowly start building up my media feeds again

5. Feel at capacity floating in information passively without space for boredom

6. Go back to step 1 and purge all media consumption

There’s something to learn in this cycle that’s more than just the importance of boredom and being alone with your thoughts. Somewhere in here are clues to humanity, human agency, and societal trends that contradict how we feel about AI.

In a nutshell, we disparage the way gen AI thinks while also racing to spend more time thinking like AI. Let’s get into it!

“You sound like ChatGPT” - TheVerge

If the comments section of that article are any indication, looking, sounding, and therefore thinking like AI are some of the worst things you can possibly do. Saying something sounds like ChatGPT implies thoughtlessness, laziness, lack of originality, and conformism.

The other-ing is understandable. Something was ripped away without people’s consent to create an alien brain that is eerily familiar and yet still not human. So, lines are drawn in the sand as AI-thinking is derided and humanity is coveted behind an ever-receding goal post.

But how eerie genAI feels points to real overlap between the way humans think and how machines simulate thinking.

Generative thinking 🐉

Bear with me here, let’s simplify human thinking into two halves.

Let’s imagine that half of our thinking primarily responds to external stimulus. This half of the brain is reactive to the external world, and generates thoughts and feelings based on your corpus of memories and experiences.

Generative thinking is hungry and feels good consuming any amount of input. You can imagine that this half is dominant when we listen to podcasts, scroll TikTok, read the news, get distracted by a notification, or respond to someone’s question1.

I use the term “generative” here intentionally to map roughly to what generative AI appears to do. The key is that it is a responsive process directed by external influence.

Originative thinking 🦥

What happens when I delete all of my podcasts and social media? I have nothing left to respond to and my brain just starts making stuff up. It’s as if my generative brain must be entertained, and if there’s nothing external, then some internal process wakes up to keep the generative beast fed.

Call that internal half “originative” thinking in contrast to “generative” thinking. Originative thinking is sleepy, lazy, and biologically expensive. If it detects that the generative beast is entertained by something else, it promptly falls asleep.

Thinking - specifically originative thinking - is unnatural. We evolved to conserve cognitive energy, and our brains treat deep thought like an expensive luxury. When external stimulation is available, why would we pay the metabolic cost of firing up our internal idea generator?

This isn't speculation either. Wilson et al demonstrated that people would rather shock themselves with electricity than spend 15 minutes alone with their thoughts. The discomfort we feel in unstimulated moments is our brain's energy-saving system working as designed.

Boredom becomes the painful transition between when our generative beast exhausted its external feed and our originative sloth hasn't yet awakened. In these moments, we face a choice: endure the discomfort of waiting for deeper thinking to emerge, or hit the snooze button by reaching for our phones. The phone wins because it offers immediate relief at zero cognitive cost.

When we do resist that urge, something shifts. Cognitive scientists call this the "default mode network", the neural system that lights up when external demands quiet down. It's what lets us daydream, reflect, and connect ideas when our originative thinking finally gets a chance to feed our generative hunger from the inside.

This concept also maps roughly onto Daniel Kahneman’s “System 1” vs “System 2”, Cal Newport’s “Deep” vs “Shallow”, and Robin Hanson’s “Chasing” vs “Searching” among other concepts.

A contradiction

To summarize what we have so far: AI chatbots have overlap with human generative thinking while also representing the antithesis of human thought and creativity. If we buy this framing, then a few conclusions naturally follow:

• Generative thinking is less uniquely human. It is a capability we now share with AI.

• Originative thinking might be where human agency lives.

• To preserve what makes us human, we should individually invest in originative thinking.

In other words: to be more human, reduce phone time and increase wall-staring time.

And thus, a contradiction: We are racing towards spending more of our time consuming generatively while disparaging generative AI2. Meanwhile, AI is racing towards becoming more agentic and originative, while not really caring either way.

[As an aside: a fun exercise - every now and then I’ll prompt various models to think deeply / recursively / daydream. It’s never as weird or disparate as what I feel happens to me when I daydream, which makes sense since it’s still generating against a prompt to explicitly daydream. I’d be curious to see what happens if an LLM is given a recursive output budget with no prompt (system or user), but I imagine it would just be the statistical average of the training data?]

Conclusion

Every six months, I go through this media cleanse, and each time I promise that this time it will stick. Over time I’ve actually come to appreciate the cycle. I dive deep, consume, update my internal corpus, and when it starts to feel passive, I blow everything up and force myself to reflect and connect the dots.

What’s important to me now is to feel in control of that balance. I have to remind myself that originative thinking is unnatural and that if I don’t fight for it proactively, it will be content sleeping forever. However, it also needs to be challenged and receive new information to create new ideas, so a media fasting cycle feels like a healthy equilibrium.

I’m still learning what it actually means to have human agency, but this exercise has gotten me one step closer. Perhaps to have agency is to paint the inside of your own mind with intention and direction rather than allowing someone (or something) else direct what you paint.

Apparently I’ve been thinking about humanity’s place in an AI world a good amount since this is the second essay on the topic. If you’re interested, the first is based on a silly talk I gave to some very anxious new grads entering the software industry:

Acknowledgements

Thanks to Michael, Zander, Emily, Dee, Baigs, and everyone else who gave their thoughts on early drafts.

I’ve been noodling on this idea for months, but really the shape of this essay came in response to Henrik Karlsson’s essays on sustained attention and cultivating new ideas.

I also recommend: Avoiding the Automation of your Heart, Just Think, and On Agency.

The timing of this essay is also influenced by a new adventure that starts for me tomorrow (I’m literally boarding the plane right now)! I’m not sure how my thinking and writing will change being inside the industry, but I will certainly continue writing, and hopefully continue publishing.

If you’d like to follow along on my continuous quest to verbalize ideas worth fixating on, feel free to join me.

As the technical lead for a major project that was going through launch week, my butt was clenched.

While I scrambled to assemble a coordination email, the thought occurred to me: Who else cares? Who feels impacted by the delay caused by the outage? Whose butt is also clenched?

And more cynically: who doesn’t care? Who is treating this as an impromptu vacation day?

Yes, that’s a terribly toxic thing to think about your teammates. But it struck me that especially during an outage, Slack sure looks a hell of a lot like ChatGPT:

The similarities aren’t just visual. In both Slack and ChatGPT, text goes in, text comes out. Sometimes work is done, sometimes someone looks something up, sometimes it’s high quality responses, sometimes it’s low quality, and sometimes you just don’t hear back.

I’m not the first to notice this either. This is the product thesis behind Devin.ai’s agentic coding agent.

And everyone seems to be building something similar: Cursor BugBot, OpenAI Codex, Google's Jules, etc. These companies won’t say the word “replacement”, but you can bet their sales team will certainly imply it.

So then what makes someone irreplaceable by AI? While I was thinking about this, my phone buzzed:

Message: Hey it’s Coworker, found your number in an old doc

Message: What do you think, should we delay launch?

^ This is Coworker, a coworker of mine. Coworker is a significant contributor and stakeholder for the milestones we were launching this week. Coworker is stressed that Slack is down because Coworker is partially accountable if the launch goes poorly. Coworker’s butt is definitely clenched.

AI Has No Butt To Clench

Here is the thesis in a nutshell:

As your leadership grows, so does your risk (accountability for bad outcomes).

As your risk grows, you will offload risk and responsibility to other budding leaders.

AI cannot feel risk, so it cannot own risk. You cannot offload risk to AI.

Thus, to avoid being replaced by AI, you must master the thing it cannot do: owning risk.

What is risk?

Risk isn’t just the big stuff like AI turning the world into paperclips or ordering 4 thousand pounds of meat.

It’s also smaller, personal stakes. Imagine convincing friends to see a concert that turns out to be awful. You feel that pit in your gut because you made the decision.

That’s risk. You cringe at the outcome of your decisions, AI doesn’t.

Think about who is being sued right now? ChatGPT? Nope. You can’t blame ChatGPT. Instead you blame:

• The lawyer who cited a hallucinated case

• OpenAI who scraped copyrighted content

• The engineer who failed to catch a bug in generated code

You can’t sue ChatGPT because ChatGPT can't be accountable. ChatGPT can’t feel risk, so ChatGPT can’t own risk. ChatGPT can’t clench because ChatGPT has no butt to clench.

Leadership is risk

What is all this butt-clenching about? Good question.

When:

• The CEO demos your team’s project

• You click the “launch” button

• Or something breaks in a big and public way

You can tell who the leaders are (who owns the most risk), by whose butt is most clenched.

Leaders survive by offloading risk

As leaders become more and more senior, they will own more “landscape” (as a student put it), and therefore they will own more risk.

At some point, this becomes untenable. One person cannot be responsible for everything that goes wrong on Airbnb.com.

So how do leaders survive? Typically, they look for budding leaders in their proximity to share the risk and responsibilities with. This grows leadership in others by delegating increasingly larger accountability.

So what happens when you try to offload risk to AI? Well:

AI can’t own risk

AI doesn’t cringe if it gives a bad concert recommendation.

AI doesn’t care if it’s building a demo for the CEO or just for you.

AI doesn’t stress if the button it just clicked was a “launch” vs “test” button.

AI can’t be fired or promoted. It doesn’t worry about whether its peers think it's incompetent. It doesn’t care about its reputation. It doesn’t stay up at night cringing at that dumb thing it said.

AI can’t feel the repercussions for the decisions it makes.

AI can’t feel risk, so AI can’t own risk.

AI can’t clench its butt because AI has no butt to clench.

When you delegate risk to AI, your risk actually amplifies. Not only is it unaccountable for the decisions it makes, but it can make a thousand decisions in the time it takes you to make one. Now you are accountable for those thousand decisions.

Look at where AI is useful today:

• Frontend-leaning prototypes to flesh out new ideas and capture new markets

• Summarizing information (read-only applications)

• Writing tests and building redundancy in systems

• Research and deep knowledge aggregation

• Suggesting initial ideas to get over the activation energy of starting a hard task

Do you notice the common thread? None of these require any real risk. They delegate the risk to the invoker.

Where does AI fail today?

• Real business logic complexity failures

• Wiping production databases

• Hallucinating fake legal cases

• Building anything with significant complexity to existing users at scale

• Agentically navigating anything of consequence like personal finances or travel purchases

These are all things that require an owner of risk.

Become an expert in owning risk

Until AI develops a clenchy butt, humans have an advantage.

Humans can own risk

Humans can care about things that matter more than other things

Humans have butts that can clench

So the advice is pretty simple: Seek butt-clenchy opportunities. When you feel that pit in your gut that says “people won’t like me if I make the wrong decision”, lean in.

Put yourself in situations where you are forced to be accountable for the decisions that you make. The only way to learn how to handle risk is to put yourself in situations that feel like they matter.

If you are early in your career, you’re in the reps phase. Make as many decisions as you can, as fast as you can. Find opportunities to feel that pit in your gut. You’ll only learn how to reduce, mitigate, and understand risk when you become comfortable owning it.

Is the junior engineer replaced by AI?

This essay is based on a talk I gave at CodePath.org. The audience was full of young, energetic, and anxious college grads starting to hear that “Jr. engineers will be replaced by AI”. Please excuse the goofy metaphors, they served as a lighthearted and memorable way to anchor the core idea!

If you’re similarly concerned that junior developer jobs are disappearing, I encourage you to take a look at the full presentation here where I have a bit more actionable advice.

Conclusion

I don’t even remember if we delayed the launch on February 26th or not. Isn’t that always how it goes? In the moment, it felt so risky, and yet in hindsight it barely mattered.

Risk doesn’t have to be big to be valuable. The point is to be comfortable feeling and owning it so that you can learn how to handle and mitigate it. You’ll also learn that it’s rarely as critical as it feels in the moment, so when you feel risk, lean in.

To summarize:

AI is going to replace some kinds of work.

But AI cannot own risk.

So you should invest in being an expert risk-owner.

Remember, you’re not an intern.

You’re a Senior Butt Clencher in training

Appendix

“Leadership is risk” as a model isn’t perfect. The best leaders look to reduce risk overall by building redundant systems, testing hypotheses, building a blameless culture, and more.

I totally get that “AI” is a very overloaded term here. In general I am referring to the agentic systems powered by generative AI, but the same could be said for any autonomous system. You can’t sue a GPU, a high frequency trading bot, or a microservice for malfunctioning.

A funny thing happens when you’re praised for something. Suddenly you’re on the lookout for more opportunities to do that thing. In fact, some things that are not that thing start to look like that thing so that you can do that thing and get praise for it because praise is nice, right?

For the past 10ish months, that thing for me was alignment.

“Driving critical alignment across platforms, orgs, cross-functional partners, and leadership”

^ this is a cornerstone of my performance review, and for good reason! Alignment work is hard, requiring you to dive deep into the gaps, build missing connective tissues, and then market the essence of your findings to everyone so that issues can be resolved before they even appear.

But also, isn’t it totally bullshit and a huge waste of time? If we have alignment, why do we have a meeting tomorrow for “Launch alignment” and one the following day for “Scope alignment”? Isn’t the point of alignment to enable autonomy? And also, why is “alignment” often the “goal”? Shouldn’t alignment be how we get to the goal?

These questions and more have haunted me for months. I’ve asked everyone what alignment is, inhaled everything I could find on the topic, and written perhaps 10 drafts of this essay.

So, here is Thesis #1 - Nobody knows what alignment is, but everyone knows what misalignment feels like.

Alignment is group flow

Nobody knows what alignment is. Sure, there are essays that define it, and everyone I asked had a coherent response to what it meant to them. But in practice, it doesn’t matter if you’re in a thousand-person company, working on a side project with a friend, or planning a wedding, the word “alignment” often feels handwavy and disconnected.

So, here’s my definition based on feeling: Alignment is flow between people. The group feels like a trusted extension of yourself. You feel fully utilized to focus, make decisions, and move.

Just like flow, alignment is hard to define, but it feels fantastic and you know when you’re in it. Another similarity is that losing flow always has a clear culprit:

• You got a text from your mom → flow broken

• You switched tabs and got distracted by a news article you saw → flow broken

• Someone tapped you on the shoulder to ask you a question → flow broken

• Your Spotify queue suddenly started playing a podcast. → flow broken

But what about getting into flow? Do you remember the last time you were in flow and why it happened? A common answer:

“I woke up early, brought my work to the library, turned off my notifications, quit all my apps, deleted Hinge, threw my phone in the trash, turned on white noise, and just stared at it until it started happening.”

Isn’t it interesting that ☝️ this isn’t how to get into flow, but how to prevent falling out of flow? Why? Because flow is mystical and hard to define, and it’s so much easier to notice what took you out of flow.

In the same way, alignment is hard to define, but it’s easy to notice misalignment - what took you out of alignment.

So let’s extend the thesis - Nobody knows what alignment is, but everyone knows what misalignment feels like. Thus, most “alignment” is just preventing misalignment (i.e. "anti-misalignment").

Anti-misalignment is lazy alignment

Anti-misalignment (noun) ​
1. The act of stamping out misalignment as a brute force strategy to achieve a feeling of alignment.
Synonyms: ​Lazy alignment, reactive alignment. ​
Antonyms: misalignment, proactive alignment

During the months thinking about this essay, I made an interesting discovery. People struggled to truthfully define alignment, but I couldn’t stop them from going on and on about misalignment. From those conversations (and my own experience) here’s what I found:

Misalignment is felt when you discover a decision that feels both surprising and harmful to your goals. Some examples:

1. Discovery: An engineer quickly builds an ugly design for an edge case. After launching, they find there is no traffic to the edge case, so they don’t bother sharing the decision with designers. Misalignment is not felt by designers because they did not discover the decision.

2. Surprise: Every week you share with your team lead that engineers are struggling with a certain “non-essential” feature. Eventually, you decide to cut the feature from scope. The lead doesn’t feel misalignment because while this decision is harmful to their goals, it is not surprising.

3. Harm: After launching an email campaign you notice that the graphic is different from what you expected. Apparently, this new graphic performed better in testing. As an engineer, this decision was surprising but not harmful to your goals, so you do not feel misalignment.

From this misalignment-focused lens, here are some bad ways to achieve alignment:

1. Reduce the discoverability of decisions. For example, make sure that all decisions happen in secret, with no record, in private invite-only forums. If people never discover what decisions are being made, they can't feel misalignment.

2. Make decisions less surprising. For example, all decisions must be democratically agreed on by every member of the project. Or, only the lead can make decisions. Everyone else just brings the decisions to the lead. If people can’t make decisions on their own, you can’t feel misaligned.

3. Make decisions less harmful to your goals. For example, only work on projects that <1% of users will use. If you launch something nobody can possibly want then no decision can be harmful.

4. Stop making decisions. If nobody makes any decisions, then nobody can feel misaligned!

Hopefully none of these obviously ridiculous examples hit too close to home, but if they do, you might be on a project more focused on stamping out misalignment than finding true alignment!

“Anti-misalignment is lazy alignment” is the title of this section and I don’t mean that pejoratively from an individual’s perspective. I literally mean that any organization which doesn’t proactively and intentionally strive for true alignment will default instead to cauterizing the symptoms of misalignment. This is especially true the larger an organization gets.

Let’s once again expand the thesis: Nobody knows what alignment is, but everyone knows what misalignment feels like. Thus, most “alignment” is actually “anti-misalignment”, which is less effective than true, proactive alignment.

Alignment is more than anti-misalignment

We’ve talked about what alignment isn’t. But what is it, really? Well, let’s return to the previous answer for “how did you achieve flow?”:

“I woke up early, brought my work to the library, turned off my notifications, quit all my apps, deleted Hinge, threw my phone in the trash, turned on white noise, and just stared at it until it started happening.”

Now let’s consider a new answer to “how did you achieve flow?”:

“I hopped on the pottery wheel and found flow”

Doesn’t the pottery answer feel more authentically “flow” in some way? When you read that you say, “yeah, that’s flow, the library answer is some weak diluted knock off flow.”

Flow requires more than just preventing distractions. You can’t delete all your apps and hope to find it. You have to actively connect some deep part of yourself to the core of the work.

Alignment is the same. Just preventing misalignment (“anti-misalignment”) is a weak knockoff compared to finding true, deeply connected alignment. The group has to connect some deep part of itself to the core of the work to actually be aligned.

Let me see if I can illustrate this:

In this example, it doesn’t really matter what decisions we make and whether people disagree. What matters is that we deeply understand where we are (the context), what the destination is (the goal), and what the boundaries are (strategy & priorities). Since that is deeply clear, we’re all fully empowered to make our own decisions, disagree & commit, and move!

Anti-misalignment doesn’t aim for clarity—it aims for control. Since no one understands the strategy well enough to act independently, the only way to stay “aligned” is to move in lockstep. Every decision is a potential landmine. Disagreement isn’t something to commit through—it’s something to avoid entirely.

(Examples included in the appendix at the end)

Now What? Policing Terminology?

"There are only two hard things in Computer Science: cache invalidation and naming things" ​- Phil Karlton

Your instinct may be to jump straight to being the "alignment police", but I have found that this is not effective.

The problem with “alignment” is it means everything and nothing at once. Sometimes it means "alignment", "agreement", "decision", “strategy”, “context”, or sometimes it's a filler word. Everyone has a different idea of what it means, so questions like “are we in alignment?” rarely lead anywhere useful.

However, I’ve found that getting everyone to agree to a new idea of what alignment is adds more confusion than clarity. In the few rooms where I prototyped a distinction between “alignment” from “agreement,” it just led to a confusing tangent about terminology. Most people tuned out. Remember that misalignment is painful, so if you suggest that we aren’t actually in alignment, the fear of another meeting kicks in and people might defend that in fact, we do have alignment.

Instead, here are three strategies I’ve found useful in making alignment less painful (and more effective) day to day

Strategy 1: Use Different Words

First, the most useful strategy is to just stop using that word. Just pick another one. “Strategy” is a good one. “Context”, “motivation”, “priority”, “clarity”, “approach”, “agreement”, all good words. Prefacing them with “high level” is helpful if the conversation is too in the weeds. If “alignment” is vague and not helpful, switching the word can shake out a new perspective.

Whether we have “alignment” is not actually the goal because remember, nobody knows what “alignment” is. Instead, make sure people have clarity. Make sure they understand the strategy. Make sure they know our priorities and the context behind the decisions we make. If the goal isn’t “alignment”, then the goal is progress, flow, movement, autonomy.

Strategy 2: Treat Alignment as Variable

Second, don’t expect alignment to be static. I know this essay implies that alignment could be set once and then enable a glorious era of autonomous productivity, but in reality, it changes. New stakeholders and variables weigh in, priorities change, people leave, and new information can be discovered.

Instead of aiming for one perfect alignment artifact at the start, focus on enabling group flow right now, and be ready to adjust as things evolve.

Strategy 3: Advocate for Autonomy

Finally, advocate for autonomy. This especially helps with understanding the line between “alignment” and “agreement”. Ask “what kind of situations would require us to have this conversation again?” Sometimes, just asking that question will reveal something that prevents that conversation from being needed in the future.

Here is an example that tries to capture all 3 strategies:

Meeting host: the goal is to align on what to do about issue XYZ that came from our project colliding with a new company initiative.

Group: (discusses, arrives at a decision)

You: Sounds like we made this decision because Y priority now outweighs Z. Do you think that tradeoff holds more broadly? If so, we could share it with our partner teams to help them make similar decisions without needing to sync every time.

Great job avoiding the word “alignment”, understanding that alignment can change, and advocating for autonomy 👍!

Conclusion

The thesis again:

This is roughly three ideas on alignment. According to my notes, I have ~75 more snippets tagged with “alignment.” Now admittedly, most of them are probably garbage, but I definitely cut some good ones from this essay (with much difficulty).

So if you’re also interested in the topic, I think I roughly know what I want to say in a second and third part on alignment. Just give me six more months and 20 more drafts and I’ll get them straight to your inbox!

More about me (Mr. Boots Too Big): I fixate on ideas, and this project helps me distill them into concrete artifacts. Originally, I hoped to write about ideas discovered on my journey to a Staff promotion, but well… it happened! So I hope to publish something probably once a quarter. Nothing timely, nothing monetized. If that sounds interesting to you, feel free to follow along:

Appendix: Agreement vs Alignment

Some examples:

We know from past projects that this page is really sensitive. Small changes often lead to really big results (both good and bad). So, we prioritize testing assumptions iteratively over launching big bundles of features all together.

• This is a high level strategy. It gives the group a way to make decisions in the future.

Let’s align on the process of communication between our two teams for how we will operate.

• This is an agreement, not a strategy. This doesn’t help determine how to make changes in the process in the future, just agreeing on a decision right now. Agreement isn’t a bad thing and is probably what is necessary in many cases for speed. The purpose of drawing the distinction is not to discredit "agreement", but to encourage people to actually seek alignment after the agreement is made.

• How this could be alignment: "Let's align on what the goals are for our teams and derive a process that matches those goals. Hopefully we can preempt some of the gaps that emerge, but if not, let's discuss how we will adjust and improve our process over time”. You can see that this takes more depth, so a short agreement could be appropriate depending on the context.

We are in a phase of discovery to find our next big thing. We should use data, research, prototypes, and quick experiments to try every idea and see what sticks. We should not be afraid to take a slight brand hit by launching something unpolished. We also should not be afraid to end an experiment that is working, but won’t be a huge opportunity

• This is also a high level strategy. It provides clear priorities and tradeoffs to give a wide breadth of autonomous decision making.

Here is what we are launching next quarter! Notice that XYZ is not in the build, but ABC is in the build. The reason is 123, but we’re happy with that trade off. If we’re in alignment, let’s lock it in and finalize the roadmap!

• This is an agreement on what we are building, it doesn’t enable individuals to make tradeoffs and decisions. What happens if an issue is discovered and another feature can’t make the build? We would have to “align” again.

• It is close though! If you add "we're happy with that trade off because priority X takes precedent over priority Y for our goal to Z", then that could enable future decision-making.

Thinking in options might help.

Desire paths

Imagine an urban planner itching to slap pavement on the ground after months of swimming through email hell. Her team can't agree on the right path to take, but she knows the answer and takes the initiative to hire a construction company. Every day the road goes a little further and she becomes more convinced that it’s moving in the right direction. At some point, the road is long enough that there’s really no choice but to finish it. 3 months later she has a beautiful paved road to stand on proudly. Then a couple days later she sees this:

It's easy to get stuck when we think that our choices are "I'm building something" and "I'm stuck building nothing". That's definitely the case if we weigh our value by how much pavement we put in a straight line. But what if it’s not just the final road that is valuable? What if we also value the work that improves our options along the way? We’re not really “stuck”, we can:

1. Expand our options - get approval to build bike lanes just in case we discover that bikes are the best solution.

2. Enhance all options - invest in a road-building machine that improves road-building time by 50%.

3. Prune our options - plant some grass.

Number 3 is well illustrated by a classic example about college footpaths. Campus planners plant grass to learn what the desired commuting paths are.

We are builders, and want to stand proudly on what we have built and declare "I made this". Along the way, we should also proudly find opportunities to improve the project’s optionality.

Optionality

A lot of ideas develop naturally as an accumulation of experience. These kinds of ideas are evidence that you've earned valuable perspectives through growth.

Every now and then, you read something that slams you head on like a truck, pressurizing years of unlinked experiences into a single, cohesive diamond.

“Tidy First?” by Kent Beck did this to me with its explanation of the value of optionality. Briefly — builders often believe that their value comes from what they make. An urban planner stands on a road and says "I made this" and is fulfilled by the value she provided to society.

What Kent proposes is this: often the value we provide is not what we build, but what we enable to be built in the future. If you've ever felt stuck in an ambiguous problem space, you may be familiar with the itch to do something useful — to finally ship something to users instead of writing investigations, spinning up proof of concepts, and ferrying messages between teams. What Kent is saying is that your value is not just what you build at the end, it's also all of the doors you open along the way.

What does building this way look like?

In my case, I'm about a year into navigating an ambiguous multi-year project that will probably deliver something next year. During this last year I've been faced with many decisions, but there's one in particular that I'm quite proud of. Last year, we knew we wouldn't get serious design direction for 6-12 months given the size of the project and its ambiguous nature. So two primary options stood out to us:

Option 1: Wait for designs - Focus on advocating for getting designs sooner, and use a waterfall-ish development cycle to build from scratch after we get designs.

In this option, only the end result is seen as having engineering value. It asks: why start building now if we’re not sure what will be shipped to users?

Option 2: Build to enable any design direction - Invest in upgrading our existing infrastructure to unblock building any of the features we think we may need, regardless of design specifics. As the designs get clearer, we build more specifics and apply more constraints.

In this option, the work along the way is seen as having value, even if it doesn’t actively contribute to the final pixels sent to the user. Optionality-increasing work could include broad infrastructure upgrades, prototyping, and identification of constraints. Constraint-applying work could include pixel-perfect UI and inter-team integrations.

After much deliberation, we chose option 2. Truthfully, it’ll take at least 6 months until we find out if we made the right choice, but at the very least, there have been plenty of times in the last year where I've been really glad we didn't pick option 1. Option 2 is not a silver bullet — it requires more net engineering time. This made sense for our project because we knew designs needed time to float around the ambiguous product space.

Unstructured ideas

The essay is over, so you're welcome to leave if you want! There are a couple unconnected ideas that I've found quite interesting from the lens of optionality. A better writer would have found a way to connect them into a cohesive essay, but here we are.

Optionality reduces the need for alignment — I plan to write more about alignment, but something interesting that I've discovered is that when you reduce your options, you need to make sure all of your cross functional partners agree that the reduction is safe. When you expand or enhance your options, you only need to align on the resources spent, not the outcome itself.

Infrastructure — all infrastructure investments are investments in enabling future functionality. The best kinds of infrastructure investments apply constraints in select places to enable optionality in the right areas. If you are building infrastructure, your job is to consistently provide productive optionality. That could be enabling scale, enabling new features, freeing up engineering resources, etc.

Multiple value of software — Software moves fast and has zero marginal cost. That means the things that can be accomplished with software are massive — i.e. the optionality of software is massive. It's interesting to see a software engineering concept supported by the financial market — the value of a software company as a multiple of revenue is vastly higher than any other kind of company specifically because software represents the potential to do almost anything for almost no cost.

Go read Tidy First? — I did my best to reinterpret what Kent wrote, but there is absolutely no substitute for his explanation. He ties value of software to money and uses the options market to illustrate how engineers can value optionality. A quote:

Thinking of software design in terms of optionality turned my head backwards. When I focused on balancing creating options & changing behavior, what used to scare me now excited me.

Less than a year later, I found myself hiding from my team in a wooden boat tucked away on the top floor of the office. My newest project had just doubled in size for the third time that month as “solve Brexit” was added to the growing list of expectations. All progress ground to a halt, three new teams were added as highly opinionated stakeholders, and my PM left the project — transferring his responsibilities to me.

I felt lost. It wasn’t the growth that worried me, it was how ineffective I suddenly felt. For the first time, the harder I worked, the more people got involved, and the slower things moved. I felt the pressure of failing my teammates, who I had confidently convinced to bet a year of their career on me.

I just needed a moment — alone, in a boat — to bang my head against the technical design to see if I could shake out any answers for why nothing I tried was working.

As a freshly minted “Software engineer II”, I was eager to immediately prove myself as “Senior”. But wow was I staggeringly unequipped.

It wasn’t even clear to me what the problem was. The engineering had been designed, proven out, and successfully rolled out to half of our countries. Since then, our 3-step country rollout grew to over a dozen steps including a handoff to an external third party company.

We went from launching 3 countries a week to a country a month. My job was no longer to write code but to drop uninvited into meetings and beg teams to unblock whatever step we were stuck on that day.

After sputtering for months, the project eventually wound down and I took it pretty hard. This was my project, my fault, my failure.

Boxing Wizard

In hindsight, it’s clear what happened — I was blindly playing the role of “Staff engineer”.

My entire career up to that point I had trained to be a boxer. I went to boxing school, took classes on all the boxing punches, and won boxing championships and boxing accolades. Then one day I had unknowingly signed up for a wizarding league without having heard of magic before. I felt lost because all of my experience was suddenly irrelevant, and I couldn’t bring myself to abandon the tools that had brought me success so far.

What had I needed to hear in that moment on the boat? I needed to know that this job is different and that almost none of the tools I’d used so far would be the right one here.

The technical design wasn’t the problem — I had failed to advocate for clear leadership sponsorship. Honestly, I didn’t know what leadership sponsorship was at the time, which is kind of the theme here. The lessons that had gotten me success so far were the wrong ones for this job. Briefly:

• Communication — I had strong individual relationships. What was needed was for teams to believe that this project’s success was also their success, not the individual’s.

• Technical design — I had a strong technical perspective backed by investigation and early success. What was needed here was flexibility so that teams were invested, understood the problem space, and expressed their priorities through design contributions.

• Ownership — I was constantly rewarded for taking on as much as possible and working hard to pay it off. What was needed here was escalation of the gaps. When our PM left, that should have been a gap that I filled only temporarily and with a clear long term plan in mind.

It’s been 4 years since that project wound down and I’m finding myself about a year into tech leading a different kind of project again. This time I want to be ready. I intend for this newsletter to be a journal to keep me honest and help me synthesize my thoughts, readings, and mistakes.

Feel free to follow along and who knows, maybe by the end of 2025 or so I’ll find myself confidently navigating the world of Staff engineering 🧙‍♂️