I never touched a line of code. That was handed off to my team and I wrote about it here:

Over the past few months that App has been fully built out and prepped for production by a tiny team of two people (MD and YA, I see you guys ❤️. Congratulations and Thank you!) and today it’s live in the Play Store.

Check it out now!

https://play.google.com/store/apps/details?id=com.peloton.draper

The team that took it from my initial commit to launch are technical but neither are professional mobile engineers. It’s worth mentioning we also had ad-hoc participation from time to time from Android SMEs to keep the ship on the right course.

We did this as an experiment. When I started the project my mindset was “what is the bare minimum work I can do in this loop and still deliver value”. Fast forward to today the App is live in the Play Store. Amazing!

Something exists that couldn’t have existed before because we changed how we’re working and some great people leaned in.

Thinking in Systems

How was it possible that people that aren’t professional mobile engineers were able to bring an entire app to life in their spare time? The answer is Guardrails, Specifications and Systems Thinking.

1. Design System - we have a robust design system at my job. It describes our UX tokens, layouts, spacing, behaviors and more in an accessible manner that’s re-usable to all.

2. Detailed Specification - we had all the required functionality already specified in working code through the existing iOS app. “The ultimate spec” hiding in plain sight.

3. Loosely Coupled Systems - our API ecosystem is composed of services split across domains. Those are all tended to with strong Ownership, accountability and re-use in mind by dedicated teams with deep domain expertise.

4. Tooling - We’re still working on this but we built tools to help us verify our progress; linters and code conventions that the agent could adhere to. Tests and code coverage to avoid regressions. Automated screen grabs that verified the new app against the existing from a users’ standpoint, side-by-side to verify the direction.

5. Dog-food - We used it! We dog-fooded the app internally and beat it up until we were happy with it.

More than ever our engineering teams’ default posture is focused around re-use, systematizing our ways of working and building things in a modular, composable, loosely coupled manner.

Roads already Paved

Netflix's CPTO, Elizabeth Stone, said something on Lenny’s podcast recently that stuck with me: the skill Netflix is hiring for now is increasingly “Systems Thinking” over deep/narrow specialization. People who can look across a business and define the shared building blocks that everything else, including agents, can operate against.

That’s what made this possible. A design system, a spec, loosely coupled services, verification tooling. “Paved Roads” and infrastructure. That’s not a new idea in software engineering, it’s how we’ve always worked going back to Grady Booch, UML, the Blue Book and more. Agents have just accelerated the need.

In order for Agents to realize their potential in the workplace we need humans thinking in terms of systematizing tasks and building checks and balances into the workflow. A moment spent here is worth 10x later when it comes to the re-use it can unlock.

The Easiest Person to Fool

Agents have zero Accountability. They are stateless, blameless, garbage in garbage out machines with zero accountability. They can’t “own” a solution in the same way an engineer can. They can’t envision the unusual things that will go wrong when the system scales whereas an engineer has that lived experience.

A working demo is one data point, gathered under the friendliest possible conditions, by someone who not looking for the ways it could fail. We’ve all seen incredible prototypes but it’s easy to confuse an Agent’s output with production ready software.

Richard Feynman had a name for this, from his 1974 Caltech commencement address: “Cargo Cult Science”. Islanders in the Pacific who'd watched planes land during the war built their own runways afterward, right down to the bamboo control towers, mimicking every visible step, and then waited for planes that never came. As Feynman put it, the form was perfect but no airplanes would ever land, because the islanders lacked the fundamental understanding of how the system worked.

Don’t be like the islanders.

The Evolving Role of Engineering

Roles are changing but deep expertise in engineering, data science, and design remains scarce and essential even as AI accelerates delivery. Lean on your engineering fundamentals. Build jigs and fixtures (like a wood worker). Measure what matters and draw from real-world lessons learned, the Outage and the pager going off at 3AM, to build and plan the solution in a systematized way that scales and is extensible for the future.

We brought something from idea all the way to production. In doing so we were forced to think differently about our work. Just a few tickets, no sprint planning, barely any engineers in the loop. A solid specification and existing guardrails helped keep the ship on course. We had a “smol” core team and some contributions from people with day jobs (like me). The guardrails kept us pointed the right direction.

The result is a brand new app targeting a different platform and empowering members everywhere.

What are YOU building in this Brave New World?

Zoom out with me for a second — If you take a steel-man approach to your developer workflow you will eventually ask yourself what’s the best Requirements document possible? Or in the context of AI you might ask “What is the best Specification you could write?”

Last time I talked about the need to move towards Specifications and getting clear on what you want to build. If you take that to its extreme what’s a better specification than already working code? It doesn’t get any better than that right?

With that in mind I took an App written for iOS for which we had no Android equivalent. Using the existing iOS Swift codebase as a Specification combined with existing Android codebases from other apps as reference material (context) I was able to orchestrate creation of the Android equivalent of the iOS App.

By the time we landed I had the bones of the app complete. By the end of that weekend I’d ported 70-80% of the existing iOS app to Android. And that was whilst I was working part-time with my mind focused on playing video games (Crimson Desert).

My spec in this case was technically perfect. Steel-manned. Every screen, every interaction, every API call. Documented literally in code.

More detail than you’d ever get from a human. Each edge case. Every animation. All the error states, color tokens, every UX choice. Every single decision that dozens of engineers and designers had made over months of development — all of it, encoded in Swift, sitting right there in the repo.

Your code is no longer just a product. It’s a specification.

Documents in Prose are human-centric deliverables. They help humans understand ideas but they’re never going to be as detailed as what a machine needs.

Orchestrating in the Dark

Here’s what’s interesting — I had no idea what I was building. I carry an Android phone and don’t use an iOS device so I had only a basic understanding of the App I was trying to recreate. That didn’t matter.

I didn’t need to describe what the app should do. Any ambiguity or missing requirements I could locate in the repo and point Claude at it. The working application was the spec.

My job was orchestrator; I set the objective (recreate the App in Android) and established the guardrails and the breakage criteria for my contrarian agents to pass or fail the progress.

Context and Avoiding Slop

The iOS codebase alone wasn’t enough. I also fed my agents the Android codebases from other existing applications. It already knew what to build, but it needed to understand how we build on Android. Our team’s conventions and idioms, architecture patterns, etc.. There’s no point porting an app if the team won’t adopt it or it uses obscure patterns.

When people say “the models aren’t good enough yet”, and I hear this a lot, what they usually mean is they haven’t figured out how to give the model sufficient context and specificity. I wrote about this in my last piece on Ambiguity; AI doesn’t expose skills gaps, it exposes clarity gaps.

The iOS app was the what. The existing Android codebases were the how. Between the two of them, I had enough “specification” than any PRD I could write.

This material would be impossible for a human to grok in a reasonable timeframe but Claude can read and internalize everything from what I gave it and synthesize this information far better than I could ever describe in prose.

Have I mentioned my laziness is a Superpower?

Brain Fry and the “No Effort Involved” Fallacy

80% of the application came together in about 20% of the time because I used an Agentic workflow and paralleled a lot of it with my Claude buddies.

Vilfredo Pareto is laughing at us from beyond the grave because then the other 20% shows up and it takes 80% of the effort. The fit and finish. The edge cases. The platform differences between iOS and Android that no amount of specification can fully capture. I had to weigh in on all of that.

The other thing I noticed is that by the end of the week I was completely mentally exhausted. Running multiple agents and constantly tending to them so they are productive and not stepping on one another takes a toll. Context switching is hard on the human brain. I’ve heard this referred to as “Brain Fry”.

It makes sense though; compressing months of original work from a team of people into a multi-tasked weekend or two is gonna wear you out.

Building with AI doesn’t mean there’s no work to do. It compresses a ton of the work so dramatically that you actually have time for the hard parts. And if you’re not careful it’ll burn you out quicker than you’ve ever seen.

By the following weekend I needed a long run outdoors to reset.

The Organ Transplant

With my weekend over I showed this to my team the following Monday.

Now…this wasn’t on the roadmap. I hadn’t looped anyone in. I’d accidentally run ahead of my group and produced an Android port of an application that we hadn’t prioritized, using a workflow that most of the team hadn’t experienced yet. My goal was never to ship this, rather more of an exploration what’s possible with the best possible spec I could think of.

This is what’s going to happen at every company across the world as this workflow takes hold. Someone is going to go off and build something unexpected but valuable in a fraction of the time, and the organizational immune system is going to kick in.

I don’t have a clean answer for this yet. I’m still figuring it out.

Activate the Swarm!

Turns out a lot of people got excited so we spun up a smol team. These were passionate folks who didn’t ask for permission or wait for a sprint planning session. They just started contributing.

Some team members were working through our homegrown Agent orchestrator. Others, like myself and a few managers who knew the codebase, worked locally with their own setups. All of us asynchronously. None of this was anyone’s day job and many of the folks involved had never touched Android development before. Again…it didn’t matter, for this type of thing Claude’s pretty capable.

We kept everything on track by adopting our team’s standard best practices, running things like Detekt scans and checking for code smells along the way and avoiding regressions with automated testing.

Within two weeks we had an internal beta that’s now in the hands of employees.

2 Bagel teams and the Dunbar Number

With everyone pitching in we quickly realised Scrum and Sprints are no longer viable. We moved to a Kanban model and processed tickets in “Flow” rather than scrum.

The more people that got involved the harder the coordination — the Dunbar number hints that there is a theoretical limit to the number of people that can meaningfully work on a project before the coordination needed to keep everyone aligned becomes greater than the actual work involved in the task.

It turns out the hardest part of shipping software was never the code — it was the coordination. And now with LLM super-powers the tickets are processed so fast you spend all your time keeping people aware of what’s happening.

In a recent discussion with a field architect from Anthropic he shared they don’t have 2-pizza sized teams of 7-8 or so. They have 2-bagel sized teams. Let that sit for a minute. 2 people, one bagel each. A team of 4 would be considered “large”.

Less people = less coordination, faster/smoother progress.

So What Do You Do Next?

Look at your existing applications differently. That “legacy” codebase your team dreads working on? It’s the most detailed product specification in your organization. All the business rules you need are locked in the repo.

Some things to consider:

• Stop writing specs from scratch — If you’re building something that’s a variation on something that already exists — a new platform, a new market, a new form factor — start with the existing implementation as your specification. Let the AI read the code, understand the patterns, and generate the variant.

• Brace for the burnout — The amount of work possible has expanded geometrically but there is a very real human toll to this. You will experience burnout. Get proactive with your People team and start building in breaks and pauses and touch-grass moments for your team. It’s hard to read the label from inside the bottle so they won’t come to this conclusion on their own. You need to lead from the front.

• Invest in your codebase as documentation — Clean, well-structured code is no longer just easier for humans to maintain. It’s a better input signal for AI. If your code is a mess, your AI-generated output will be a mess. Garbage in, garbage out still applies — the scale of the garbage just got bigger.

• Pair your “What” with your “How.” — The iOS app told the system what to build. The existing Android codebases told it how we build. You need both. A specification without style guidance produces technically correct but culturally alien code that will not be adopted. The body will reject the organ if the DNA doesn’t match.

• Embrace Pareto. — Plan for 80/20. The AI will get you most of the way there shockingly fast. Budget your human effort for the last mile — the fit, the finish, the judgment calls that still require a person. This is where your team’s expertise actually matters most.

In Closing

We used to say “the best code is no code.” Maybe now the best code is code that’s already been written — not because we’ll run it forever, but because it teaches the next system what to build.

The past 6 months have changed how I think about software development entirely, from Vibe Coding to Vibe Orchestrating and now inference from Specifications. The specification is the product and vice versa.

It’s a few weeks later. The Android app that was born on a plane at 35,000’ over the midwest is all grown up and slated for field testing in the coming weeks. And the PRDs and Word docs? Those were just for us humans the whole time.

Francis here, thank you for reading. If you found this useful, consider sharing with your team. We’re all figuring this out together and I’d love to hear your stories in the comments — have you used existing code as a specification? What happened?

“The Models aren’t good enough yet” — I’ve heard this a bunch over the past year. The models are pretty darn good at this point. My team is shipping fully generated code without edits. It’s not the models. If you’ve heard this recently the issue may be something deeper.

The teams that struggle the most with these tools don’t lack for intelligence or skills. They are often overburdened with both. Their problem isn’t resources, it’s clarity of intent. Knowing what they are trying to accomplish and being able to articulate it clearly.

This isn’t new, software has always been a pursuit of precision but it’s being exposed by artificial intelligence and the new ways of working.

Meet Bruce the Cheese Plant

There are huge picture windows almost floor to ceiling in my apartment (the ceilings are 9’ high). I’ve been growing plants next to one of them for a while now, houseplants, vines, even some pineapple plants!

The window is flooded with light during the day. I think about the journey those photons have been on. They’ve each survived somewhere between 100,000 and a million years inside the fusion reactor we call the sun before escaping and traveling their final eight minutes and twenty seconds to Earth, where they finally wink out of existence after donating their energy to the plants. Thanks photons.

One plant in particular loves this arrangement, my cheese plant — Bruce.

Bruce’s limbs contort toward the light so that his leaves can absorb as much of it as possible. Some leaves never respond. Others seem to crave the light and crane themselves toward the window.

Bruce’s cells are opaque to me. I can’t control which leaves respond. I can’t explain why. All I can do is create the conditions for the plant to thrive.

LLMs work the same way1 - we cannot look inside the model to figure out which Perceptrons, Weights, Features, Embeddings, etc. caused it to zig when it might’ve zagged.

When the shade is fully open the room fills with light. It reflects off the walls and becomes ambient, coming from every direction. Bruce grows every direction.

But when I close the shade and let only a narrow beam through, something interesting happens; Bruce focuses. The plant strains toward that single bright signal.

If the plant is the agent then the light is the objective. All I control is the environment and hence the signal.

When the signal is vague and diffuse, the behavior is vague and diffuse.
When the signal is precise, the plant aligns itself accordingly.

An Uncomfortable Mirror

When one of my colleagues recently started working with Claude her first reaction was

“What do I tell it?”

I said: “Anything you want.”

She paused for a moment and then said something prescient.

“Gosh… I’m going to need to improve my communication skills.”

Her first instinct was to look inward. That level of humility is pretty rare.

Humans are story tellers and pattern matchers and we are very good at filling in missing intent. When instructions are vague, a good engineer infers what you meant. The word “good” here is doing a lot of work. A “good” engineer, understands their job, has context, knows the environment, understands their dependencies upstream and down, understands the Quality bar that’s required to ship and much more besides.

Agents don’t do that. Agents start from a blank slate and execute what you said, literally and hopefully precisely but precision is hard when dealing with probabilities.

In a human-led workflow there’s an easy back and forth between colleagues to clarify what’s needed. When AI is in the loop and expected to work autonomously that makes ambiguity impossible to hide. Interview-mode and Planning are essential to set the task up for success.

Writing Forces Clarity

In my time at Amazon (almost 8 years) I hardly ever saw slides. Slides are simple to put together but they restrict your thinking to surface level bullets. They are easy to hide behind. Bullets on a screen let you gesture at a thought without ever finishing it. Writing a document on the other hand forces you to think deeply about a problem.

The famous six pager. Single spaced. No fluff. Long FAQ. That’s hard. You can’t write a document like that about something you don’t understand.

When we teach we learn twice. I think I know something, then I go to explain it to you and that explanation exposes the gap in my own understanding. Working with AI does the same thing. It holds up a mirror…and the mirror doesn’t lie.

You can’t get what you want….if you don’t know what you want.

A Lack of Clarity not Skills or Smarts

This transition is hard, in part, because it’s shining a light on things that were broken to begin with. That can be genuinely painful to reckon with. Especially if you’re the one responsible for why things are broken.

I’ve talked about it before in Burn the Boats — AI won’t fix what’s fundamentally broken in your org.

It’s worth noting this is not a critique at all on Intelligence or your skills as a person. This workflow change is like a spotlight that shines brightest on organizational dysfunction and a lack of Clarity.

I’m Living It too (even before AI)

My first draft of this article was all over the place, it had five metaphors and almost no concrete examples.

That was my first clue.

I felt the intuition of what I was trying to say, but I hadn’t yet forced myself to articulate the mechanism. Writing forces your thoughts through the sieve of your fingers into the keyboard and they stare back at you from the screen. Sometimes they don’t look so great.

Engineering Is Shifting Toward Specification

Software engineering has traditionally been limited by how fast humans could produce code but that’s no longer the constraint.

I’ve talked before about the need to switch roles — from pair programmer to Orchestrator. The pushback I get is “yes but we still need humans in the loop” and I agree at least for now but the more we work in this new paradigm the more moments I see calling out that humans in their traditional roles are holding things back.

By letting go and assuming higher-order functional roles we start to see a step function improvement in Quality.

Some recent real-world examples;

1. Accidental Bug Discovery — The other day we set an Agent a task to change how we were processing some data. In the course of its work it found an undiscovered bug in the code through static analysis and offered to fix it. That bug was a corner case but legitimate and had existed unbeknownst to us for over a year. This code had been reviewed many times by our team. We took it up on its offer to fix it.

This makes me wonder and it’s an uncomfortable question; Does that human/manual code review really find the things you think it does?

2. Launch Readiness — A while back a team member (BB) made an awesome little fitness test during a hackathon. Everyone loved it, including our Instructors but we never felt it was launch-ready. Just as a thought experiment I sent an Agent on a mission to evaluate the launch readiness of this test through analysis of the code in Github. It produced a full detailed report across 13 different dimensions, including UX and Accessibility, Security etc. and we were much closer than we thought. That feature’s going to be live in the next month (hold me to it).

3. The Zero-Developer Code Change — We’ve recently started seeing full tickets driven to PR without a developer involved. The most recent complex example was an algorithm change but we’ve had success with UX Fit and Finish, Infosec and similar isolated and well defined tickets. This is an example of how software is proliferating through the org.

4. Agent Orchestration - In the past few weeks our team has prompted an Agentic Orchestration Platform into existence. Two people (TK and TM) pair programmed the first MVP to the point where it could spin up an Agent on access Github…and then turned it on it’s own codebase. This thing deploys Claude to K8s on demand and because it’s internal and we wrote it, it’s connected to all our relevant systems internally through MCP. With the MVP functional the engineers turned it on itself and afer a wild couple of weeks orchestrating and delegating it had written the remaining 80% of its own PRs.

This last example is how we’ve scaled access to AI within our group, alleviating the burden of setup for folks that don’t need it whilst simultaneously forcing collaboration and a shared common context. Maybe more on this in a future article.

What Good Specification Looks Like

Here’s where I’d start:

1. Lead from the front — About a month ago I literally drew a Miro with our entire SDLC lifecycle on it, from User Research, Product, Design, Development to Production Deployment and beyond and annotated and rewrote every place I thought we could simplify the process and leverage Agents, either synchronously or autonomously. Then I implemented a few examples (see previous examples). The diagram was nowhere near accurate but it was enough of a guide that it combined with the examples made the whole thing real for people. Asking teams to “use the tool” is not enough guidance and frankly not the point.

2. Define your Objective Function — Be Specific. Remove the ambiguity. You don’t even need to be good at writing prompts — I’m certainly not. I have Claude write precise prompts for me based on my loose articulation of what I’m trying to achieve. But that articulation has to be real. Concrete. If you can’t explain your goal, no amount of clever prompting will save you.

   1. e.g. “make sure the implementation will scale” might be an ok heuristic for a human but not nearly enough guardrails for an LLM. Versus “use an asynchronous call pattern with Kafka in the middle. Use Kafka Topic “xyz”... Use the team’s existing Service template. Make sure subsequent calls are idempotent. Assume no state on the server-side”, starts to be come much more directed and constrained.

   2. Optimize for:

      1. Functionality (highest priority)

         • No regression in existing functionality

         • All edge cases handled (nulls, retries, partial failures)

      2. Performance

         • P95 latency increase ≤ 5%

         • No additional synchronous blocking calls on critical path

      Tradeoffs:

      • Prefer reliability over performance

      • Prefer simplicity over cleverness

3. Measurement — Define your evals and break conditions. What you want cannot be hand-wavy. It must be measurable. If you can’t articulate what good looks like the agent won’t know either. Neither would a new employee. You wouldn’t hire someone and tell them “just make things better” — don’t do it to your agent.

   1. If an LLM is generating a service change, an eval function might include:

      • passes unit tests

      • preserves API contract

      • uses approved service template

      • handles retries idempotently

      • does not introduce new P1 security findings

      • latency increase < 5%

4. Provide Context — The agent is a blank slate. It doesn’t know your business, your team’s goals, your constraints, your history. Conduct a longitudinal assessment of your organizations knowledge base and internal documentation. How can you use that as context for the Agent before it attempts your directive? This should be a living set of documents that your whole group can iterate on over time.

Context; New Ways to use Old Knowledge

Machiavelli2 took the historical texts available to him and did something no one had done before: he read them longitudinally, across time, looking for patterns. Of all the battles fought near rivers, what did commanders do, and what were the outcomes?

That meta-analysis gave us political science. A generation later, Galileo et al did the same with knowledge of the natural world. We got the Scientific Revolution and the Renaissance.

Your organization has so much institutional knowledge that can serve as powerful Context for your Agent. Confluence, Slack channels, GDocs - it’s easy to expose all of this through MCP — your job is to think about how to synthesize it in a new way so that it serves a new purpose in your Agentic workflow.

Don’t forget the untapped sources of insight, e.g. call transcripts from member support. Returns and Warranty claims. Social Media sentiment. These are all ripe for meta-analysis and easy to accomplish with LLM capabilities.

Survival of the “Fittest”

There’s a common misconception that by “fittest” Darwin meant the strongest or most athletic or physically robust. He actually meant most Adaptive; those that can “fit” into the given situation the best.

This moment is not going to be won by the people with the most impressive résumés, or the longest tenure, or the most polished slide decks. Curiosity and Humility win the day — be willing to look at the mirror and say “okay, I need to get better at this.”

Sunshine on a Cloudy Day

Louis Brandeis said that sunlight is the best disinfectant. He meant it about government transparency. I think it applies here too.

This moment is a genuine equalizer. The person who couldn’t attend college can now compete with the MIT graduate. The person whose career was derailed by circumstance, by a pregnancy, by an illness, by a layoff at the wrong time, can get caught up in a new field in a timeframe that would have been unthinkable a year ago.

The artificial advantages that used to compound silently in the background are losing their grip.

Bruce loves the sun and pursues it relentlessly. So close the shade. Narrow the beam. Give your team whether they’re Human or Agent one clear signal to grow toward … “and let’s be careful out there.” 3

Subscribe now

How are YOU navigating this time? Have you found the secret unlock? Share your wisdom in the comments and let’s support each other through this time of change.

What can you say in a moment like this? This was someone…we all looked up to.

I even aspired to be like them at one point.

We used to talk about them in the halls their reputation grew across the org, from Engineering to Marketing and even up to the C-Suite.

When there was a problem…this was the person we could always call upon. And they never failed to come up with solutions and ideas we could try.

The 10x engineer built the platforms and systems that made this moment possible. This isn’t a rejection of that craft — it’s its next chapter

Yes…they were the best of us. Some would even say our Highest Performer. But…it’s time to move on.

Subscribe now

The 10x engineer as we knew them has evolved into something different.

Say hello to the 0.001x engineer

That’s not a typo—0.001x, not 10x. They manually write less code but they create 1000x the impact. How?

Vibe Orchestrating! They’re no longer a musician playing in the band, they’re now the Conductor directing the Orchestra.

We spent decades hunting for developers who could write more code but we were measuring the wrong thing all along.

Getting Stuff Done

The 10x engineer mythology went like this: find someone who “gets stuff done”…writes more code, faster than others and ships 10x more features. Measure them by commits, PRs, velocity. Send the toughest gnarliest problems their way. Leave a case of Jolt and a pizza by the door, slide JIRA tickets under the door, knock loud and then walk away. Celebrate their output.

It worked because code was the bottleneck. Execution was scarce. Speed meant competitive advantage. More output meant more value.

I drank a lot of caffeine but I was never a 10x engineer, not even close, but I’m stubborn and I like problems and given enough time I could figure stuff out.

Nowadays I have a CTO day job at a public company, I travel, I’m training for a race, my schedule is crazy, but I’ve built more stuff in the last six weeks then I have in the last six years. Well I didn’t build it…I “produced” it meaning I orchestrated it. I framed the problems, made the judgment calls, and let AI handle the mechanics. It’s a different kind of building.

We got it backwards. Speed is now less relevant and execution starts to become cheaper. We need to shift our focus upstream. The shift isn't about choosing between humans and AI. It's about engineers doing what we've always done when the tools change: we adapt, we learn, and we focus on the parts that still require human judgment.

Vibe Orchestrating

I started out vibe coding but nowadays, stealing tips from Boris Cherny I’m Vibe-Orchestrating — you heard it here first ;) .

By Vibe Orchestrating I mean that like Boris I’m not coding in an IDE anymore, I’m chatting with agents at the terminal, planning their work, answering questions and then updating Agent, Task and Role definitions.

Last time I talked about multi-agent configurations, but for most situations Claude Code or your favorite terminal based LLM interface, used correctly, is more than sufficient.

“Used correctly” matters a lot in that sentence.

I don’t mean adding an AI assistant to your existing human workflow. Let’s be honest: humans and computers are good at different things. Humans are creative and emotional. We have life events, relationships, shifting energy levels and more.

Speaking for myself — I’m inconsistent. My focus fluctuates. My performance varies depending on sleep, stress, or what else is happening in my life. I’m human.

We are not deterministic systems.

And to be clear, I’m not anti–human-in-the-loop. I’m advocating that we focus on what we’re actually exceptional at — framing problems, employing high judgement and expressing good taste — and let AI and agents handle the repeatable, process-heavy mechanics.

Adding an AI assistant to an unchanged workflow will help. But the real question is: can we reimagine the process from the ground up with AI as a first-class citizen and the human shifting left — toward intent, judgment, and strategic direction?

Engineering Roles don't shrink — they spread

Everyone’s concerned for their jobs and career paths, it’s a real concern. But I have good news. Let me tell you why engineering roles ultimately expand into the whole organization;

If it hasn’t happened already your entire C-Suite is trying to figure out how to use AI either in their Product or their Operations. Software teams are going to increasingly get pulled in to solve problems w/LLMs in places you never needed to think about software before. E.g. Alice from Legal or Bob from Accounting or Pat from Marketing.

Agents are infiltrating across the entire organization and the problems we need to solve are of a different nature.

This week (yesterday) I spoke with Harrison Chase, CEO and co-founder of Langchain. Sorry for name dropping but it was a privilege to speak with him and to hear his point of view first hand and the conversation w/Harrison highlighted some issues I’ve been thinking about for a while...

Soon we will see agents proliferate through all of corporate America. Enterprise IT groups are going to be plagued with new problems as a result. E.g. with teams collaborating on group-tasks involving multiple agents and sub agents how do you manage context? How do you avoid leakage of privileged information? How do you debug or replay a decision in a non-deterministic system so that you can improve your process over time? Do you need version control of enterprise level agent definitions? Do you need a way to delegate access tokens and credential management? How do you enforce Token limits? And Audit control. And so on…

What happens when your finance department is trying to close the quarter and their AI Agent runs out of tokens! These are real operational problems, and someone needs to own them.

How soon before the first court case where the defense is “It wasn’t me. It was the LLM?” And what does legal discovery look like in that scenario?

You’re gonna need to know which LLM instance, and which model type and what context caused what decision. Regulatory compliance, safety and security are nuanced and hard problems to solve. But the good news is there are smart people like Harrison already thinking about it.

And like as not they’ll all need Software support.

The bottom line is every part of your organization is going to need more engineering in the short term, not less. Over time, these skills won’t be confined to engineering teams alone — they’ll become part of how every function operates. I’m being dramatic to emphasize the point, but it’s hard to see how any organization doesn’t function without the support of engineering in the New World.

The Questions That Matter

Legendary music producer Rick Rubin famously stated he has "no technical ability" and knows "nothing about music" in terms of playing instruments or operating soundboards, admitting in a 60 Minutes interview that he brings "taste" rather than technical skill. He acts as a "reducer," focusing on stripping songs to their core, emotional essence.

As the world is shifting realtime what do we need to focus on? A 10x engineer assumes they are the driving force and so would ask:

• How do I build this faster?

• What’s the most elegant solution?

• How do I enforce DRY principles but also make this perform? etc.

The 0.001x engineer is thinking far more abstract. They want to be OUT of the loop and instead asks:

• Let’s make a plan, what are we actually trying to achieve? Let’s pressure test that plan (see Contrarian Agents).

• Is this the right problem to solve?

• How can I frame this to remove all ambiguity?

• How might this initiative fail?

• How do I make the agent self sufficient and if it makes a mistake how do I teach it for next time?

• How do I improve the overall SDLC process for everyone?

The difference: 10x thinking optimizes for coding. 0.001x thinking optimizes for continuous improvement across the entire workflow.

For example…

Shifting Left (Preventing Waste)

The earlier you stop a bad idea, the bigger your impact.

• The Engineer: Gets paged for a bug in production, fixes it. Impact: 1 bug fixed.

• 10x engineer: Spots the pattern, prevents 10 similar bugs. Impact: 10 bugs prevented.

• 0.001x engineer: Uses Agents to steel man the PRD and review the feature. The Contrarian agent pattern determines that the initiative is focused on the wrong metrics. That the primary success criteria of the initiative will move in correlation with the project but is not actually a causation metric. It reframes the entire project. Saves months of effort and time from lots of people.

Be like Rick!

How to Become 0.001x

The transition is uncomfortable. So far we assume the human is in the loop but this week I asked some team members… “what would need to be true in order for you to ship code without reviewing the PR or looking at it?”. What must be true: deterministic builds, automated rollback, reproducible context logs, token budget controls, versioned agent definitions, etc. The team is still thinking about that…

We’re closer than you think; Here are some concrete things you can start/stop this week…today!

• Stop optimizing for commits — Your manager isn’t counting them. Impact doesn’t live in a PR or a diff. Does your human review really add what you think it adds?

• Resist the instinct to code — I know that’s what you’re trained for but “How can I build this” is no longer the right question. “How can I orchestrate this so that it gets built whilst my team’s workflow improves” changes your impact from tactical to strategic whilst reducing your effort! That’s 0.001x!!!

• Start questioning everything — If it’s repetitive, if it’s something you dread doing and takes your time, can you automate it? If not why not? Can you move upstream and automate that too?

• Can you use background agents to pickup the busy work? Can you use an Agent or Skill to augment or improve the input into your process? e.g. JIRA Ticket enhancement or Figma design review?

• Start sharing your discoveries with your team members and then literally start sharing Claude.md files or your LangGraph/LangChain/CrewAI role and task definitions.

• Start connecting the dots through MCP — MCP is how your agents talk to your existing systems — Salesforce, Jira, Slack, whatever you’re already running. Don’t build it yourself, everyone has a connector now.

Any Final Words

Anyone can build anything. Wasn’t it Archimedes I think who said something like “with enough Tokens I can move the world”? The bottleneck has shifted. It’s not “can we build this fast enough?” anymore. It’s “should we build this at all?”

I wrote about what’s broken in how we build…Taste and High Judgment are the future. Read more here…

And so in closing….

We once again bow our heads and look upon the 10x developer…

Let us join hands and merge their final PR into mainline…

Let us close the final JIRA Ticket, and scale down their last K8s instance and release it back into the pool of eternal reserved instances.

Does anyone have anything they’d like to add?

Only this… Thank you 10x — your craft built the foundation we stand on. But now your watch has ended.

And until we meet again in that great Data center in the sky “go gcoinní Claude i mbos a láimhe thú” …may Claude hold you in the Palm of its Hand.

“Drop a note in the comments — what’s the biggest unlock you’ve found this year? How much time did it save? I want to hear your 0.001x moments.”

Each member on a Research team plays a role. The Principal Investigator, the Statistician, the Literature Specialist and so on. But watch any good research team work and there’s always that one person who tears down weak hypotheses. They’re not being difficult—they’re being rigorous. That’s their role!

The Scientific Method is built around the notion of tearing a hypothesis down to its core through Peer Review. That’s why scientists publish papers. Not to boost their ego and profile (although this can be a side effect) but to ensure their work is tested through rigorous review and criticism by their peers. The team member pre-empts this before publishing and forces the team to pressure test their ideas.

Last week, sitting on my couch as usual, I wondered: what if I gave AI agents those same roles? What if instead of trying to get AI to agree with me, I made it disagree with itself?

By the next morning I had a fully operational team of agents humming away producing a Product Vision, Business Justification, Go to Market Strategy, Feature and Screen definitions and more…whilst I played Clair Obscur: Expedition 33!

The output was so rigorous that Windsurf was able to one-shot the code for it with no intervention. No more endless cycles of prompting focused on the code. And no human in the loop!

It was a radical departure from how I’d approached this in the past.

“The pattern is simple: steel-man first, attack second, iterate until the best version survives or dies fast.”

Let me show you why this works.

Stealing from the Ancient World

Plato, Aristotle, Socrates focused on meta-cognition—thinking about thinking. The Socratic Method uses cooperative argumentation to discover truth. Turns out, making ideas fight to find better ideas is timeless.

Most of you will be familiar with ChatGPT and its ilk, where the human and the LLM participate in a back and forth until the human is satisfied.

Swapping the human out for a 2nd AI we move to into the “Agentic” space and there a plenty of frameworks out there that facilitate this; CrewAI, LangGraph, OpenAI Agent SDK and so on. That’s your choice, in this article let’s just focus on the concepts for now.

We Proved This Works (A Decade Ago)

In 2014, Ian Goodfellow introduced Generative Adversarial Networks—GANs. The breakthrough was simple: pit two neural networks against each other.

One creates and the other critiques. A Generator and a Discriminator. They compete, and through competition, both improve.

GANs gave us photorealistic faces and breakthrough image generation. The quality didn’t come from making AI smarter. It came from making AI argue with itself.

Here’s the pattern:

**Generator:** “Here’s my output”  
**Discriminator:** “Not good enough, try again”  
**Loop until:** The discriminator can’t tell real from fake  
**Result:** Quality emerges from tension, not consensus

We’ve known for a decade that adversarial dynamics improve output quality at the neural network level. Every AI-generated face you’ve seen online is a product of this competitive process.

I just wondered: does this work at the application layer too? With LLM agents collaborating on ideas instead of neural networks training on images?

It turns out: YES!!! But I needed to add something GANs don’t have—intellectual honesty through steel-manning. More on this in a minute.

Agent + Agent = AI Slop

With a naive configuration Agents can be assigned roles, e.g. Subject Matter Expert, Coder, Tester, UX Expert, Product Owner and so on and they will produce an output. You might even build into the prompt things like “be rigorous in your thinking” and “no sugar coating” but this will only take us so far. Left unchecked you’ve just assembled a team of “yes men”.

Imagine a research team who never questioned each other. They might reach a conclusion and publish a paper but chances are it would vaporize under the intense heat of public peer review. No more grant money for you!

Enter the Contrarian

We need an agent in the pipeline whose express role is to pressure test the others’ work. This can take many forms based on what you’re trying to achieve, e.g.

• Strategist (PM / GM / Exec Sponsor) vs Operator (Eng Manager / Program Manager) - The Strategist thinks big, focuses on Vision and unconstrained Ideation whereas the Operator brings in real-world practicality, logistics and ongoing running concerns.

• Builder (Engineer / IC) vs Breaker (QA / SRE / Security)
  The Builder owns implementation details and trade-offs. The Builder explains why things were done a certain way whereas the Breaker actively tries to fail the system—edge cases, abuse cases, penetration testing, does the system meet WCAG compliance and so on.

The roles you need will vary based on your goal and it’s up to you which adversarial relationship you focus on. We’re not replacing Humans…we’re augmenting people with additional capabilities powered by Agents.

Pitfalls of this Approach

So now we have our Adversarial Agents but this doesn’t set us up for true success. Not yet.

Sadly we know from walking the earth that arguments are often non-productive. The system must be designed to produce a productive criticism and rather than devolve into endless nit-picking. From my Amazonian days the phrase “unless you have a better idea” applies here.

Left undirected the workflow may converge to the lowest common denominator instead of the optimal outcome. I once had a boss who used to say “when you ask everyone what we should cook for dinner you end up eating franks and beans”. His point was it’s not the best food, it’s just the common ground. We want something better than Common Ground.

How can we avoid this unintended consequences?

Straw-Man and Steel-Man

This is where the School of Athens can help us with some techniques from the Socratic Method (your classical education finally pays dividends).

Straw-manning; A technique aimed at shutting down an argument by deliberately misrepresenting or oversimplifying an opponent’s argument to make it easier to attack, creating a weak “straw man” to knock down instead of the real argument.

Steel-manning: this one’s a more modern technique with the intent to build stronger ideas by stress-testing them against their best possible representation, rather than just winning the argument as in straw-manning. Here the critique articulates the opponent’s argument in its strongest, most compelling form, even better than they presented it, to fully understand and genuinely engage with their viewpoint.

• Straw man: Focuses on winning by weakening the opponent’s case.

• Steel man: Focuses on understanding and strengthening the discussion by clarifying the opponent’s best case, leading to better outcomes.

And so we build these concepts into the behavior of the agents in the pipeline, particularly the Contrarian agent.

If the idea is steel-manned and the contrarian can still tear it down…it’s a non-starter and should be abandoned.

Show Me How This Works

Here’s an example of two simple agents working together in this manner. (I use the CrewAI style definition but you can use any framework you prefer).

# agents.yaml
steel_man_agent:
  role: “Steel-man Advocate”
  goal: “Present strongest possible version”
  
contrarian_agent:
  role: “Contrarian Critic”  
  goal: “Find fatal flaws in steel-manned version”

“The steel-man agent goes to work first, strengthening the proposal. The Contrarian agent receives that strengthened version and attacks it. If the Contrarian says ‘APPROVED’, we stop. If ‘REJECTED’, we iterate. Maximum 5 attempts.”

steel_man_task:
  description: |
    Take this proposal and present it in its strongest possible form:
    
    PROPOSAL: {proposal}
    
    Your output must:
    1. Address obvious objections preemptively
    2. Present the best-case scenario
    3. Strengthen any weak points
    4. Make the most compelling argument possible
    
    Present the STRONGEST version this idea could be.
  
  expected_output: |
    A strengthened version of the proposal that presents the best possible case, addresses objections, and articulates clear value.
  
  agent: steel_man_agent

contrarian_task:
  description: |
    Review the steel-manned proposal and find fatal flaws.
    
    STEEL-MANNED PROPOSAL: {steel_manned_output}
    
    QUALITY BAR: {quality_bar}
    
    Your analysis must:
    1. Acknowledge this is the STRONGEST version (not a straw-man)
    2. Identify fatal flaws even in this best-case scenario
    3. Find wrong assumptions or missing considerations
    4. Determine if it meets the quality bar
    
    Respond with:
    - “APPROVED: [reason]” if it survives scrutiny and meets quality bar
    - “REJECTED: [fatal flaws]” if fundamental problems exist
    
    ITERATION: {iteration_count} of {max_iterations}
  
  expected_output: |
    Either “APPROVED: [reason]” or “REJECTED: [fatal flaws numbered]”
  
  agent: contrarian_agent
  context: [steel_man_task]

(These artifacts are aligned with a CrewAI implementation.)

Don’t let the YAML intimidate you. Any LLM can generate this config for you. The pattern matters, not the syntax. Your job moved upstream— from writing code to orchestrating systems that write code.

And finally here’s what an actual iteration output might look like;

Goal: Evaluate adding “social sharing” to a product analytics dashboard

[INITIAL PROPOSAL]
“Add social sharing buttons so users can post their metrics to LinkedIn and Twitter. Increases viral reach.”

[STEEL-MAN AGENT OUTPUT]
“Best case: Users with impressive metrics (high growth, strong engagement) naturally want to share wins. LinkedIn posts showing real data build credibility. Free marketing through authentic advocacy. ROI: viral coefficient boost at zero acquisition cost.”

[CONTRARIAN AGENT OUTPUT]
“REJECTED
Fatal Flaw #1: Only users with good metrics will share. You’re advertising competitor success stories, not yours.
Fatal Flaw #2: Exposes sensitive business data. Most B2B users won’t share internal metrics publicly.
Fatal Flaw #3: Solving wrong problem. Users aren’t leaving because they can’t share—they’re leaving because analytics aren’t actionable.
Verdict: Build better insights first. Viral features don’t fix weak core value.”

[ITERATION 2 - REVISED PROPOSAL]
“Add ‘Industry Benchmark’ feature showing how user’s metrics compare anonymously to similar companies. Shareable without exposing sensitive data.”

[STEEL-MAN AGENT OUTPUT]
“Much stronger. Benchmarking provides actual value (competitive context). Users can share ‘We’re in top 10%’ without exposing numbers. Creates FOMO for non-users. Solves privacy concern while maintaining viral potential.”

[CONTRARIAN AGENT OUTPUT]
“APPROVED
Addresses fatal flaws: Provides value before asking for distribution. Privacy-safe. Benchmarking is core product improvement, not just marketing gimmick. Ship it.”

That’s It - Two Iterations
What happened:

V1: Naive social sharing → REJECTED (wrong problem)
V2: Benchmarking with sharing → APPROVED (adds value)

The pattern:
Steel-man makes the best case. Contrarian finds fatal flaws even in best case. Iterate until contrarian says APPROVED or hit max iterations.

Stop/Breaking Conditions and Quality Bars

So when will it end? When will the team stop iterating? For this type of workflow we need to define a “stop condition” - something that once it’s met the team will stop refining and trying to improve and we can imagine different types;

• “A target user would replace an existing solution with this.” or “A credible target user says “I would uninstall X for this.””

• “The team would personally bet on this.”

• The value proposition is strong enough to overcome inertia.

Stop when further thinking won’t materially change the conviction — only contact with reality will.

Sometimes the condition is never met so we can build in a “max-iterations” setting aswell. I recommend you do both.

Meta-Cognition: Thinking about Thinking

As I spoke about in my last piece when it comes to artificial intelligence I am going back to first principles.

I’m not focused on the tools themselves (CrewAI, LangChain, LangGraph etc) you can mix and match and tools will come and go. The fundamental shift for me has been how my thought process needs to change. I’m not thinking about how to get coding solutions out of AI. I’m thinking about Orchestration— about Agents thinking. And then how I can replicate that in an agentic toolset. That’s the true power of these tools.

With this revelation I’ve shifted left in the development cycle. I’m no longer “Vibe Coding”… I’m “Vibe Orchestrating”! (trademarked Shanahan industries 2025)

What This Teaches Human Teams

The contrarian agent taught me something uncomfortable about myself: I’d been too focused on getting AI to agree with me. Too eager for validation. Too quick to accept the first good answer.

But the best thinking comes not from trying to be right, but from trying to disprove your hypothesis. Try to figure out how you’re Wrong! That’s the Scientific Method in action.

Small teams with clear quality bars, rapid iteration, and intellectual honesty beat large teams with vague goals and consensus-seeking. Every time. And that applies to human teams AND Agentic squads.

Share

Your Job Just Moved Upstream

The ground has shifted. Your new skill isn’t writing better prompts. It’s orchestrating adversarial dynamics to force quality. In AI systems. In human teams. In your own thinking.

Stop trying to get AI to agree with you. Make it disagree with itself— productively. Steel-man the idea first, attack the strongest version second, iterate until it survives scrutiny or dies fast.

Try It This Week

This week, try the two-phase pattern. Steel-man an idea, make it the best it can be and then attack the strongest version. Do it with AI. Do it with your team. Let structured disagreement make your output better. If even the best version of your idea can’t survive scrutiny, you just saved yourself months of building the wrong thing.

The scientists and philosophers were right all along. Make your ideas fight. The best ones will survive.

I’d love to hear if you’ve pushed this concept even further or perhaps you’ve found something even better along the way. Drop a note in the comments and let’s talk about it.

The industry is scrambling to predict what AI is going to mean, but it’s already too late. It’s already here. The ground has shifted…but we’ve been here before.

We’ve Been Here Before

Remember when we went from Client-Server to Distributed Computing (1995-2005). Remember the shift from SOAP to XML-RPC to REST (2000-2010)? Then “Cloud Native” (2010-2018). Or Mobile-First (2010-2014)? Or the great Javascript Wars from Server Side to Client-side rendering and then back to Hybrid (2010-2020). Each time, people feared obsolescence. Each time, the work changed but didn’t disappear. The people who adapted thrived.

Here is my incomplete list of everything that is already broken and everything I’m doing to embrace the change.

What’s Broken in How We Build

Kabuki Code Reviews

Pull requests and code reviews are largely performative. Linters and Intelli-sense style tools made syntax review irrelevant years ago. Now LLMs summarize logic changes into natural language and although human verification is still necessary your test automation and code coverage (which can also be generated) should provide better assurance than any human review.

The real review is: “Should we even be building this?” But most organizations haven’t caught up to this shift. They’re still doing line-by-line reviews because that’s what “rigorous engineering” looks like. It’s cargo cult behavior.

Documentation is Noise

ADRs, technical documentation, API specs, architecture diagrams - when AI reads and summarizes the code directly these become pointless. The documentation that matters is “why we’re doing this” not “how it works.”

Most of what you invested in writing is waste. If you’re in a heavily regulated industry where attestations and documentation is the currency…it’s time to start thinking about a new job.

Estimation is dead (but we’re pretending it’s not)

My team is using a lot of new tools these days. We’re exploring everything and keeping what works and throwing away what doesn’t. Velocity is spiky and unpredictable yet project managers and stakeholders still want estimates, so we go through the motions but everyone’s engaged in a shared hallucination (see what I did there?). Anything that takes longer than 6 weeks in my view needs a double-click.

What’s Broken in How We Hire & Develop

The Career Ladder is Breaking

AI is providing ways to fast track or even re-route on this path so what to do about it?

The same thing I would’ve said 10 years ago; Focus on Impact! Engineering has always been about impact. As a Manager you need to re-examine how you develop your team as the traditional playbook is obsolete. Junior and Senior engineers alike now have more opportunities to outperform each other and the gap between the rest-and-vest crowd and the bias-for-action get-sh1t-done community is only widening each day.

The Technical Interview is Broken (but we won’t admit it)

Assessing candidates through algorithm puzzles or system design questions assumed you were testing relevant skills.

The reality is we probably don’t know what to test for at this point. I’m placing increased focus on behavioral skills; Curiosity. An ability to learn. A bias for action. These traits coupled with a clear track record of delivery is what signals a hire to me. So how do we re-write the interview to test for those? Drop a note in the Comments if you’ve figured it out. I’m still working on it.

Team Size - who cares?

For me team size has never really mattered. It's always been about team impact and impact can come from the individual or from the team. AI is lowering the bar to produce results so you don't necessarily need an engineering degree. Access is being democratized and whatever engineering bits you do need to know you'll pick up along the way. For engineers, the productivity benefits are the largest gains. For Managers the ability to hire, onboard, and manage people matters less than the ability to ruthlessly prioritize and make fewer, better bets.

The net effect is the scales are tipping to favor more fully rounded individuals who can see about the product vision, understand their members, but also understand the engineering side and connect the dots to deliver value even more than ever before.

What Actually Matters?

Spoiler alert—it’s what’s always mattered

Good Taste

We are drowning in a sea of AI slop. When the tools will generate whatever you want, knowing what you want and what you don’t want becomes crucial. Understanding what a great user journey looks like, having the good taste and restraint to craft something elegant and memorable whilst solving the customer problem is what matters most.

Customer Understanding Isn’t Optional

No kidding, right? But here’s what’s changed: cycle time has collapsed. No more six-week user studies that lead to ambiguous results. You don’t have time. It’s a race and your competitors are already barking at your door.

You need a system for developing and testing hypotheses quickly with well constructed experiments in an efficient manner. Figure out what data supports your hypothesis and how to collect it efficiently. No new ideas here, this is product management 101.

Principles Over Process

A team needs to understand their mission, but understanding the rules of the road is just as important. Tenets and “Ways of Operating” have traditionally been cascaded to the team through basic management practices, stand-ups, retros, etc. but the truth is your “ability to manage” might actually be slowing things down.

Giving the team clear direction and then a clear set of tenets to guide their work, ideally baked into the culture, not through org-hierarchy and “Approvals” will unlock their true potential.

Data Informed, Not Data Driven

Jeff Bezos said it: “When the data and the anecdotes disagree, the anecdotes are usually right.” In a world of AI-generated everything, the ability to find patterns and synthesize intuition from data becomes crucial.

Numbers tell you what happened. Stories tell you why it matters and Human Storytelling becomes a super power.

What’s Not Broken Yet (But Watch This Space)

“The Hunch”

When an Incident happens tribal knowledge and human know-how is still the most effective path to mitigation. AI is providing tools to make that human insight quicker and more precise but we still need to know what to measure. Tooling to diagnose and root-cause in realtime are not far off but for now operational excellence, telemetry, observability and resiliency stills need the human touch.

Hardware is Still Hard

I mostly talk about software here, but it’s worth mentioning experience with physical device development, mechanical engineering, moving pieces of iron that work in sync with software is still very much the domain of the human engineer. I think for now we’re at the early stages but it’s exciting to see how AI can help shorten the development cycle for physical devices. Developers that understand this intersection will be at an advantage in the years ahead.

The Real Shift

The things that made you a valuable contributor are changing. Engineers are no longer the bottle neck. Prototypes can come to life in a weekend.

The skills that made you valuable were largely about managing scarcity—scarcity of labor, scarcity of compute, scarcity of time. AI is breaking all these constraints simultaneously.

It’s not about the lines of code you write. It’s about the code you DON’T write.

The next wave is all about Judgement. It’s about Influence and Risk. The choices you make and how you get to the the data-supported answer as quickly as possible. Measuring Quality by outcomes and impact versus approvals, processes and documentation.

I’m focusing on the fundamentals that don’t change. Customer problems. Clear thinking. Good taste. Communication. The technology stack has always been disposable. The fundamentals aren’t.

I’ve shared my list but what are YOU focused on? How has YOUR role changed? What tools are YOU throwing away and what new things are you picking up? Drop a note in the Comments and let’s help each other.

In a few days we will be live with OpenAI and we’ll start learning from our experiment. I’m grateful for the small but mighty team who drove our idea to this point. After almost thirty years for me in this game I still get a kick out of launching stuff and I’ve learned the more things change, the more they stay the same. It’s still smart, motivated and curious people doing the hard things. Driving change and bringing the Impact.

This isn’t the first time the ground has shifted. It won’t be the last. The only mistake is pretending it’s not happening.

It’s Friday afternoon in the mountains and Dad has one more gift to pass on.

Ever Tried, Ever Failed?

Modern culture avoids failure. It’s treated as a character flaw. It’s not OK to be struggling. If you failed, you mustn’t have known what you are doing. What a fool.

Meanwhile Social Media highlight reels celebrate the finished product whilst hiding the thousands of attempts it took to get there. We are conditioned to expect success without setbacks. That’s not how life works.

Growing up in Dublin I was encouraged to explore. To try things that probably wouldn’t work. They usually didn’t. But it was fun to try and maybe learn something new. And Dad was always there to encourage me and give me new ideas.

The Divide 200

Dad and I got into Crowsnest at 10PM MDT on Wednesday night after a long day of traveling from the East Coast. Camp was dead quiet and I followed the instructions on how to self-check in. We were staying at Castle Mountain campgrounds which would serve as the Start/Finish of the Divide 200, a two hundred mile ultramarathon in the remote backcountry of Alberta. This is the 3rd year of this race and they’re still ironing out the kinks.

5AM Thursday morning I went outside to check the temperatures. It felt fine in just pants and a t-shirt on this empty night. I hiked up into the hills nearby. The moon was waning gibbous and there was plenty of light. The sun would be up soon.

The forest shifted as I hiked down the trail. Something was staying just out of reach. I soaked up the peace by a nearby stream and tried to imagine the nights to come.

“It’ll be grand” said Dad and I agreed.

We walked back without a word as the camp slept and went back to bed.

No breakfast!

Race Day arrived and I went down to the race HQ to have breakfast. We’d received emails, even pre-paid for the food. When I asked Brian the race director where breakfast was, he told me “they’d forgotten to make it.” I didn’t realize it then, but this would be the first domino.

Ultrarunning is no different than life; small preparation failures can compound into major disasters.

I put the lack of food behind me and wandered around nervously for the next hour, checking my gear and chatting with other runners and crew.

A single butterfly landed on the sunlit corner of a wooden picnic table and warmed its wings in the dawn.

The Race Begins

8AM Friday - We took off into the hills. I set out running and just tried to settle down. The start of races is always full of anxiety and tension, it’s nice to just get the body moving and let everything settle.

“Take it handy” said Dad. And I probably should’ve listened.

Dad was an accomplished cross-country runner in his day having been raised on the hills of Thurles, Tipperary. He grew up pushing a boneshaker through the winding roads of Upperchurch and had visited Alberta Canada and these very mountains back in 2005 so this was nothing new for him.

I did NOT take it handy. Without realizing it I was racing, something you never want to do on the first day. I was running 9 and 10min miles across fairly smooth trails and feeling good. It felt nice to be out in the woods after a year of anticipation for this event. I reached the first climb and started bombing up the hill. But this was not a hill, it was a mountain. The grade was 20% with spikes up to 40% and it lasted miles.

After about an hour of climbing we broke out above tree-line and saw for the first time the ridge above Crowsnest and Castle Mountain. I was hungry and blood sugar was low. My stomach and heart rate collided and I threw up for the first time. It was morning still, just a few hours into the race.

“Not to worry” says Dad. “Not a bother” says I and continued to push further into the race.

We climbed. And climbed. And within another hour I’d thrown up again. I decided I’d better eat so I forced some calories down and pressed on. I won’t bore you with the details but for the next 24 hours I repeated this process of throwing up, forcing calories down, feeling good for 5 mins and then it came back up. Continuously.

I got up on top of one of the peaks and took a rest. Here on this peak scree and shale and rock overlooking all of Alberta I met the most ambitious spider I’d ever come across. He (or she) had spun a web inside a hole in a rock, hoping to catch some insect or some such at 8,000’.

I said out loud “he won’t catch too many flies up here”. And Dad agreed.

We continued on, back down the ridge and sliding and surfing the shale and the scree and I realized the game; Climb a peak, throw up, enjoy the incredible view and head back down into the saddle, climb up the next peak and continue. We’d be up and down these all day.

A Long Way from Donnycarney

Up on the ridge line, death is cloaked in beauty. Course markers sit feet from cliff walls where the edge rolls back so you can’t see how close you are to meeting your maker. It would’ve been so easy to just step off into The End.

“It’s just like the Dublin mountains,” joked Dad, hearkening back to days when we’d cut turf in Wicklow to heat the house for the winter. Dad would coax the Renault 4 as it struggled through Enniskerry and the Sally Gap with the trailer bouncing along in tow.

Here in the Canadian Rockies, I said the thing that’s become my personal cliché: “Jaysus we’re a long way from Donnycarney” and Dad gave a quiet chuckle.

This terrain is remote and Safety and Rescue would need to hike in. There’s no helicopter if things take a turn. No one is coming to save you. I was a long way from my comfort zone but managing risk is part of my life and thankfully I had Dad along for the ride.

The Failure Point

We climbed through the night, up Whistler and Table Mountain and back down. I couldn’t take any calories in and things weren’t improving so at checkpoint 4, I finally called for the medic. They took blood pressure, then blood sugar. After pricking my finger, no blood would come out. I was dried up. It took five minutes of coaxing for the tiniest drop to collect.

As I sat motionless, trying not to throw up, the sun moved across the sky and warmed my legs. Another tiny butterfly lit upon the grass, maybe the same one from the morning? and here, with my body broken and my spirit fully emptied out I thought life doesn’t get any better than this does it?

I had reached my Failure Point. My race was over. After 24 hours, I couldn’t continue without putting other people at risk for my safety and that’s where I called it. I took a ride back to camp and informed the race officials I would be DNF’ing.

A Thousand Goodbyes

In 2012, I got the call that Dad had passed away. We carried him from the church to the graveyard in Upperchurch and we lowered him down. My cousin thrust a shovel in my hands. I felt like I could see through the lid of the coffin. It felt wrong but I took the shovel and did what was expected and it wasn’t 5 minutes before he was covered by the cold. And the dark.

As immigrants, we lose our families not in death but in small tiny pieces. In the Goodbyes. When we walk out the front door to the airport. When we board the plane and again when the call comes to “come home as soon as you can”. The funerals aren’t real, just part of another visit, another plane, and a thousand more “goodbyes.”

Dad was never the center of attention in life, but he found ways to let you know he was there if you needed him. And he still does. This trip and the race and experience overall genuinely scared me but I felt him close. In all the little things.

The Point of Failure

This was a failure. I didn’t finish the course. I made mistakes. I wasn’t fit enough, wasn’t prepared, Etc. Etc. It’s part of the process. And when the goal is huge, reaching Failure is kind of the point.

Failure is a tool I can use if I can accept it. If I’m not failing occasionally, it probably means I’m not choosing hard enough goals. If I lean in I can make the failure productive. Through Introspection I can learn. Rebuild. And maybe come back stronger or with a new approach next time.

Dad led by example and taught me that the point isn’t to avoid failure—it’s to fail at things worth failing at. To take your idea and make it real. To build webs in impossible places because sometimes, when the wind is right, you catch something extraordinary.

No Matter, Fail Again, Fail Better

What’s been your biggest failure? Is it something you regret? Or revel in? Did it break you? Or did you learn from it? Share your biggest failure in the comments - not the sanitized LinkedIn version, the real one that left you sitting in the dirt wondering what just happened.

I know myself. I have good people around me. And I have my father’s legacy. Dad and I will go back to those mountains and on to new mountains. We will try again. And we’ll fail again. Fail better.

A great friend (PC), one of my oldest and best reminded me when I got back, “the only failure is in the not-trying”. He’s not wrong.

For now, I’m just happy to live in the little things—butterflies on grass, ambitious spiders in unlikely places and the echo of a quiet chuckle whenever I feel like I’m a long way from home.

Dad, I would send you this post but I don’t know your forwarding address.*

*With thanks to Richard Feynman

I was raised to think that “smart people are to be respected because they are usually right" and I built my own version of this, which was “when you’re right the other person is wrong so their point of view doesn’t matter. They need to change, not you”. This, my friends, is how you grow up to be an asshole.

"We're going to scale the database to the moon”

Some years ago, I sat in a meeting where the team made this proclamation. We had a big event coming up and needed to scale up to support the l

oad. I had concerns that this would not solve our issue. The fundamental problem was deeper and scaling up might buy us some breathing room but it didn’t actually solve the issue. It just shifted the failure point downstream from A to B.

I was new to the team and everyone seemed in agreement with this scaling-to-infinity notion but I couldn’t let it go. This was either going to be a career-limiting move that would turn the entire team against me or a pivotal moment for our engineering culture overall.

I threw out: "I'd like to understand the specific problems we're trying to solve before committing to a solution."

It turned out to be the latter—what followed was a smaller discussion with some like minded engineers that eventually led to a completely different approach that in turn served as the foundation for a host of changes in the years ahead.

Why Engineers Are Bad at Disagreeing

Engineers have a complicated relationship with disagreement. We pride ourselves on logical thinking, yet we become emotional when our technical decisions are challenged. The reasons are somewhat consistent:

• We conflate our ideas with our identity. When someone challenges our technical approach, it can feel like they're challenging our competence. This creates an instinctive defensive response, and the conversation shuts down.

• We optimize for being right as an individual rather than finding right as a team. Engineers are trained problem-solvers. We're rewarded for having the answers. This creates a culture where being wrong feels like failure rather than an opportunity for learning.

• We lack a shared framework for productive disagreement. Computer Science education doesn’t cover how to navigate conflicts in the workplace, despite it being a daily reality in our work.

These themes can lead to an avoidance of disagreement, better to keep things amicable if only on the surface, however, the cost of avoiding tough conversations can be enormous.

“Disagree and Commit”

At Amazon, we had a leadership principle: "Disagree and commit” - it means “I disagree with this decision but I support it from here on out because I am committed to making us successful as a team”. The emphasis was always on the “Commit” half, moving forward as a team. The first part, how to Disagree, was left as an exercise for the engineer.

How to Disagree Without Becoming the Enemy

Effective technical disagreement can follow a consistent pattern:

Frame disagreement as Collaboration, not Opposition.

In our opening story I didn't say "this is dumb, we need a different approach". That would’ve shut the conversation down entirely. Instead, I tried to reframe the conversation around understanding problems before committing to solutions—something no reasonable engineer could disagree with. Try phrases like:

• "I want to make sure I understand the problem we're solving..."

• "I'm curious about what alternatives we considered..."

• "Could we walk through the specific constraints driving this decision?"

Focus on the idea, not the person.

It’s important to separate technical ideas from personal identity. When disagreeing, talk about the approach, the implementation, or the architecture—not the person who proposed it. For example you might reference"the code" rather than "your code" or "my code." This small shift in language creates space between the person and the technical artifact.

Build from shared values rather than contrasting opinions

The ultimate tie breaker is often the Customer. When you are Customer Obsessed it defines a common ground from which you both can build. Other examples of common ground might be

• "I think we both want to optimize for maintainability here..."

• "Since we agree that user data security is paramount..."

• "Given our shared goal of shipping on time..."

Think about and acknowledge where you can flex your point of view in favor of the other person. This demonstrates Empathy and builds trust.

• “I acknowledge we’re going to create some technical debt here…let’s accept that and move on. “

Every technical disagreement becomes more productive when it's anchored to shared principles.

Your Secret Weapon: Curiosity

The most disarming approach to disagreement is authentic curiosity. Rather than stating an opposing position, ask thoughtful questions that highlight potential issues while demonstrating respect:

• "How would this approach handle failover scenarios?"

• "I'm curious how you're thinking about the operational complexity here?"

Building a Culture That Survives Disagreement

Disagreeing is not a sign of an ineffective team. Quite the opposite. It’s a signal that your team is operating with psychological safety. When it’s safe to disagree, especially across levels, the best ideas will surface. Individual skills matter, but capital-C “Culture” determines whether disagreement becomes a feature or a bug in your engineering organization. Here's what I’ve seen work:

• Be transparent and vulnerable. If the leader can be wrong and can be convinced to pivot make it widely known when that happens.

• Reward those who change their minds. The strongest engineering cultures explicitly celebrate people who publicly update their viewpoints based on new information or persuasive arguments. I’ve written about this previously:

• Create formal space for technical disagreement. Design reviews, architecture forums, and RFC processes provide structured environments for disagreement that reduce personal friction.

• Document decision context, not just decisions. When you capture the "why" behind decisions, including alternatives considered, you depersonalize future disagreements by focusing on changed circumstances rather than past judgment.

• Normalize phrases that de-escalate without conceding. Teach your team language like "That's an interesting perspective I hadn't considered" or "You've given me something to think about" to create space for reflection without immediate resolution.

Are we Square?

Technical disagreement is inevitable in engineering. But career-limiting conflicts, broken relationships, and suboptimal technical decisions are not. By mastering the art of technical disagreement, you transform what could be a liability into one of your most valuable professional skills. That's the ultimate competitive advantage but also…it’s how to NOT be an asshole.

P.S. With thanks and attribution to Maya Angelou.

Engineering is easy if you don’t have to deal with people ;) Have you witness a barn-burner of an argument? What have YOU seen work to de-escalate things and move the conversation forward? Drop a note in the Comments, I'd love to hear how other leaders have figured things out.

I haven't written production code professionally in years, but I still code in my spare time. I expect continuous learning from my team, so how do I hold up my end of that bargain?

Executive Distance

In my line of work, I'm often assumed to be LESS hands-on. There's this notion that getting into the weeds makes you less strategic, that knowing implementation details clouds your judgment.

I call bullsh1t!

While I certainly don't trust myself to write production code anymore, I have yet to find a better way to grasp certain concepts than with hands-on experimentation. As an engineer when I have to take things on faith, I struggle. And if I struggle to understand what my teams are building, how can I effectively support them?

Transfer Learning

You'll hear about "transfer learning" in the AI space—it's when a model trained on one task applies that knowledge to a related but different task. Humans do this naturally. The mathematical concepts I learned decades ago didn't disappear when I became a manager; they became the foundation for understanding today's technologies.

Here's a concrete example from the current AI hype cycle: “Embeddings” (this post has been sitting in my drafts so maybe not as fresh as it was a year ago).

What Are Embeddings, Really?

ChatGPT tells us "An embedding is a vector representation of data in a high-dimensional space. They serve as a bridge between the raw, often non-numeric data and the numerical algorithms that process them."

Said simply: an embedding is a mathematical way to represent any kind of data—words, sentences, emotions, images, sounds, concepts—as numbers that computers can work with.

But understanding the definition isn't the same as truly grasping the concept. Let’s dig deeper.

Learning by Building: A Photo Mosaic Story

A long time ago, before embeddings were even a thing, I built a photo mosaic generator that creates images from thousands of other images. This project is a great example of a concept, in this case Embeddings, being used outside its context.

Now enjoy this Rainbow…

Here's how I built it:

1. Source Material: I wrote a web crawler and let it cook for a few hours. The result; hundreds of thousands of random photos.

2. Target Division: Took my target image (the rainbow) and divided it into tiles.

3. Feature Extraction: For each source image in (1) I transformed it from a 2D image into a 1D vector using the Discrete Cosine Transform. This index became the raw material I’d use to create the final mosaic image.

4. Matching: For each tile in the target, I computed the DCT of that tile, then found the source photo with the closest vector match using Root Mean Square comparison.

5. Assembly: Repeated until every part of the rainbow was matched with an appropriate photo.

This process—extracting features, creating vector representations, and finding similarities—is exactly what embeddings do in modern AI systems.

Math FTW!

The technical details matter here. I extracted "features" like contrast, color histograms, and areas of high/low detail. These became the dimensions of my vector space. The Discrete Cosine Transform (similar to the Fast Fourier Transform you might know from audio processing) broke down each image into its essential mathematical components. DCT is great for identifying areas of high-contrast in an image and to the human eye contrast is the key piece in making the new image appear like the original.

In today's ML/AI world, the model does this comparison automatically e.g. Inference, but the fundamental concept remains: transform complex data into vectors, then use mathematical methods to find relationships and similarities.

Idle Curiosity?

Cool so you can draw a Rainbow or anything from a source image. Why does that matter? Understanding embeddings at this level isn't just intellectual curiosity—it's strategic advantage. When my team talks about:

• Recommendation systems that understand user preferences across multiple dimensions.

• Semantic search that grasps meaning beyond keywords.

• Translation services that map relationships between languages.

• Computer vision that recognizes patterns and objects.

If I understand the foundations I can ask better questions, spot potential issues, and make more informed decisions.

The Gemba Walk

The Gemba walk is a Japanese practice of going to the actual place where work happens to understand it deeply. For engineering leaders, the "actual place" isn't the office; it's the development experience itself.

I'm not trying to be the strongest individual contributor on my team, that’s not my job. I’m looking for balance and aiming to maintain enough technical depth to:

• Ask informed questions and understand trade-offs when teams propose solutions.

• Spot patterns across different technologies and domains.

• Translate between business needs and technical constraints.

• Credibly advocate for technical investments to non-technical stakeholders.

Concepts Are Evergreen, Implementation Changes

The beautiful thing about mathematics and computer science fundamentals is their longevity. The matrix/vector math I learned in high school still applies to modern embeddings. The signal processing concepts from my early career transfer directly to audio/video ML applications. The statistical methods I picked up along the way inform how I think about A/B testing and data analysis.

Technology stacks come and go, but the underlying concepts persist. An understanding of these fundamentals becomes more valuable over time, not less.

The Practical Benefits

If it’s not already obvious this approach has concrete advantages:

• Better Hiring: I can evaluate candidates more effectively when I understand what they'll actually be doing.

• Improved Planning: Technical complexity estimates become more accurate when you grasp the underlying challenges.

• Enhanced Communication: I can translate between technical teams and business stakeholders.

• Risk Assessment: Potential architectural problems become visible earlier when you understand the foundations.

• Team Credibility: Engineers respect leaders who understand their craft, even if those leaders aren't writing production code.

A Challenge

When did you last write code? When did you last dig into a new technology because you were curious? When did you last experience the developer workflow your teams navigate daily?

The excuse that you're "too strategic" for implementation details is exactly that—an excuse. Strategy without implementation understanding is just expensive guessing.

Stay Curious

You don't need to become the strongest coder on your team. You don't need to commit to production, but you do need to stay curious, stay learning, and stay close enough to understand what you're asking your teams to accomplish.

Pick a side project. Learn a new language. Build something small but complete. Experience the friction your developers feel. Understand the abstractions they work with. Feel the satisfaction of solving a tricky problem with elegant code.

Your teams will notice. Your decision-making will improve. Your strategic thinking will be grounded in reality rather than Powerpoints and sales pitches.

There’s a lot of talk about Vibe Coding and some of it derogatory but we're all just trying to solve problems with technology. The moment we stop understanding how that technology actually works is the moment we stop being effective leaders in this field.

The best engineering leaders I know aren't the ones who've transcended the technical details—they're the ones who've never stopped being fascinated by them.

Have you found ways to stay technical while leading teams? What concepts from your past have transferred to new technologies in unexpected ways? Share your stories—I'd love to hear how other leaders navigate this balance.

“I wish I was good at math…but I was born without the math gene.”

“I wish I could play music but…I don’t have a musical brain.”

Sound familiar? I call this “Learned Helplessness” - a state where we've convinced ourselves we cannot do certain things or overcome certain challenges, so we stop trying altogether. What's worse is we don't question it. We just move on.

This infiltrates corporate life too: “We tried that, it didn't work”, “Legal won't allow that” or “Customers won't want that, it's too difficult, we don't think it's worth it.” This attitude has killed more innovation and good ideas than probably anything else in business.

Corporate Learned Helplessness: A Case Study

During my interview at Audible, I asked a question: “I've noticed the content you deliver is download-only. How come you guys don't stream your content?”

The response surprised me. It wasn't that they hadn't considered streaming - they wanted to implement it but claimed they “just couldn't get there.” When I dug deeper, I uncovered the organizational learned helplessness:

When I asked the Engineering team, they said, “That'd be great, but Legal wouldn't approve it.”

When I asked the Legal people, they said, “That'd be great, but we don't have the tech to protect the content.”

When I asked the Content group, they said, “That'd be great, but the rightsholders would never agree to it.”

When I asked the Senior Leadership, they said, “That'd be great, but this is how we've always done it, and our current method is not broken.”

It was clear that a download-only approach was a legacy technique with numerous drawbacks:

• The audiobooks were downloaded to a device that needed enough storage to store the content, versus a streaming model, which would rely less on storage.

• They weren't using industry standards. Content only played on the proprietary device or devices that had the proprietary logic to decode the content.

• Downloading meant members had to plan ahead and load books onto their devices while connected to WiFi. The company hadn't anticipated where broadband, cellular connectivity, and user expectations were heading.

• Customers were increasingly expecting instant access to content. e.g., at that time, Netflix was already moving away from DVDs to a streaming model (anyone remember the Quickster debacle? 🤦).

Every department responded with some version of “That will never work here.” And so, streaming had to wait. This pattern of organizational resistance reveals the deeper psychology behind why we so often choose inaction over innovation.

The Psychology Behind Opting Out

Why do we fall into these patterns? Because it's comfortable. Because humans are frail, and our preference is to protect our egos.

We create self-protective mechanisms that shield us from potential failure. It's more comfortable to opt out and do nothing than to try, risk failure, and feel incompetent. We give ourselves excuses we can't control e.g. “I wasn’t born with the talent I need”, even though we know that hard work and persistence typically outperform raw talent. The path of wishing without trying spares us from confronting our limitations and the effort required to overcome them.

Breaking the Cycle

The other day, someone asked me, "How do you have so many interests?"

My response: "I'm old!"

Throughout my life, I've tried electronics, woodworking, painting, pen and ink, running, guitar, plumbing, carpentry, and recently, piano. I'm currently (very slowly) learning Mandarin (hěn guo shi ren shi ni). In each case, I've led with curiosity. Something sparked my interest, and I wanted to learn more about it. When that happens, it's hard for me to put it down. I think, subconsciously, my curiosity has outweighed my lack of confidence. I'm ok with being a beginner.

Each new skill or endeavor started with accepting that I wouldn't be good immediately, but I could improve with practice and persistence. It kills me when someone says, "Yeah, but I can't draw". Bernie Wrightson was one of the world's best pen and ink artists, but he wasn't born that way. If you can hold a pen and make a mark on a page you can draw. You literally can draw!!!

Get used to saying “I can’t draw…just yet”.

Steps to Break Free from Learned Helplessness

1. Question Everything

Things change - what was once a valid assumption can become invalid. That blocker you thought was a solid immovable rock might actually be crumbling with time. Push on it!

Take note: Every time a new team member joins your group you get this “question everything” attitude for free. Embrace new team members’ perspectives. They bring new ideas that aren’t influenced by your baggage.

2. Be Willing to Fail Publicly

There's no shame in trying. Visible failure often inspires others to take risks, too. As I discussed in my previous article on Accountability, making your attempts visible creates powerful motivation.

Social media is filled with "perfection" but hides the multiple attempts it took before nailing things. Hiding the attempt hides the reality that mastery only ever comes through thousands of failures.

3. Create a Safe Environment for Risk-Taking

Support others when you see them trying something outside their comfort zone. Celebrate the attempt as much or maybe more than the success.

4. Don't Be Afraid to Ask the "Stupid" Question

Stupid questions are hardly ever stupid. They normalize learning. Sharing your thought process might reframe the entire problem you're trying to solve.

5. Challenge the Status Quo

When you hear “We tried that, it didn't work” or “That's how we've always done it, why would we change,” recognize these as red flags of organizational learned helplessness.

Walking the Talk

I spent last week in Taiwan and made a complete fool of myself every day and at every opportunity by speaking Mandarin. I don't speak Chinese, but I've been learning the last 180 days, and I have a few phrases. My pronunciation is bad. I use the wrong words. I say “Bù kèqì (you're welcome)” when I should say “Duìbùqǐ (I'm sorry)”.

I'm happy to be a novice because on the other side lies competence and maybe one day mastery. And it’s just fun! The appeal of being able to speak to my team and relate to their culture is too great not to try.

The most dangerous phrase in business isn't "we're going to fail" - it's "we can't even try." Whether in your personal development or your organization's growth, recognizing and challenging learned helplessness opens doors to innovation, growth, and fulfillment that otherwise remain firmly shut.

Dreaming of Streaming…

As for Audible? Well, we did finally implement streaming audio. I spoke to Legal, Content, the C-Suite and Engineering and in each conversation addressed their concerns. That capability unlocked a vast array of business opportunities. We integrated Audible into the first Echo devices, and it became a Hero feature on that platform. Even today, you can listen to Audible in your Tesla…all through Streaming.

Are there areas of your life you been telling yourself “I can’t, it’s not possible”?

Imagine what you would achieve if you didn’t know it was impossible.

When you join a meeting at Amazon it’s not uncommon to spend the first 15 minutes in complete silence as each person around the table reads the “One-pager” or, “the Six Pager” or some other form of documentation. If you’re not used to this it can be the longest few minutes of your life as you sit wondering what everyone’s doing or thinking…wondering when the silence will end.

Once everyone’s ready the questions come. This is when the meeting actually starts. If you’re the author it’s like defending your dissertation. If you’ve written a good document your job is simple. If it’s poorly constructed you’re now facing an uphill battle and the likelihood of a second or third meeting with the same group.

Foundations in Writing

The art of writing a well-structured document is something I have yet to master but it’s foundational to the Amazon culture.

In my early tenure, I needed executive buy-in for a set of changes I was driving. A colleague recommended I write a one-pager to help frame the discussion with senior leadership.

"Just one page?" I asked naively.

He smiled knowingly. "It's probably the hardest page you'll ever write."

He wasn't kidding. That single page became three days of distilling complex technical concepts into their essence, removing fluff, and ensuring every word earned its place. But when the discussion finally happened, I was shocked at how effectively it focused the conversation on the core issues.

What Makes Amazon's One-Pagers Special?

An Amazon one-pager isn't just a short document—it's a carefully crafted artifact designed to do several things at once:

1. Force clarity of thought: When you only have a page, every word must count.

2. Eliminate PowerPoint theater: A pure focus on the message. No hiding behind fancy animations or distracting visuals.

3. Create a shared understanding: Everyone starts with the same information.

4. Drive to decisions: The format demands recommendations and clear next steps.

5. Document the decision for posterity: With a well-crafted document, future teams can look back and understand the information the team had when they made the decision.

Why Engineers Should Master Writing

Engineers who advance aren't necessarily the strongest coders—they're the ones who can communicate complex ideas simply. When you can write a solid document it reflects clarity of thought that separates senior engineers from truly exceptional ones. The one-pager is your secret weapon.

Common Pitfalls to Avoid

1. Burying the lede: Don't make the reader hunt for your main point.

2. Technical jargon overload: Can a smart person outside your team understand what you’ve written?

3. Weasel words: “Many people believe”, “as many as”, “a lot”, "might," "could," and "possibly"—these are all non-specific and should be avoided. They only serve to undermine your narrative. Write with conviction.

4. No clear recommendation: A one-pager without a recommendation is just a report. Can you read the document and still say “So what?”. If so you’ve failed.

5. Solutions in search of problems: Start with the customer's problem and work backward, not your cool technical solution.

How to Write a One-Pager Like an Amazonian

In the spirit of up-leveling our little community here, I offer the following as a roadmap to think about when you're writing your next document. Most of this is “one-pager” specific but for a full-blown design document, these pointers can still help. Use your judgment.

1. Writing is Reading - When you think you’ve finished, take a step back and read what you've written. Imagine the reader has no context on the problem or the solution. Did you write this for a specific person, imagining what they’re familiar with? That's generally bad. Or did you write it for the population at large? That's good! Does the document provide them with all the information they need to understand it? Or are there implicit assumptions of the audience you've baked in? If you’re not sure a simple test is to ask a colleague to read it. They should be able to tell you if it stands on its own or not.

2. Set the readers' expectations - State up-front what your document is and is not. What will they gain by reading this thing? Give the reader a reason to read further.

3. Start, Middle, and End - Give your document a logical progression - E.g. Start by laying out the context and what problems exist. Explain relevant constraints and then move to the Middle which outlines how you’ll address the issues in the "Start". Close with any additional assumptions, dependencies, or risks that remain even if you are successful. This is the End.

4. A “Strong” Edit - Remove any unnecessary or duplicative language. Don't use colloquialisms or flowery language. Remove any "personality" prose. Remove Weasel Words and non-sequiturs. Remove language that is imprecise or superfluous. Make the document as short as possible but no shorter. Stick to the facts.

   1. A meta point to the astute reader: this last paragraph could’ve been shorter if I’d followed my own advice.

5. Formatting - Stick with the defaults. Remove any unnecessary spacing, headings, or formatting if it’s distracting. Word docs are not PowerPoint so for me, a good doc should look dense on the page. Apply your judgment here, sometimes formatting can really help the structure but don’t go overboard.

6. TL;DR and BLUF - Consider adding an executive summary at the top of the document. If the reader reads nothing else what is the key message you want to convey? That message needs to be heard loud and clear so put it up front.

7. FAQ - When one page is not enough… add an FAQ. Include any additional questions or relevant info in an Appendix. This is typically an FAQ but could also be supporting data that is relevant to the main document.

A poorly structured doc reflects poorly on you as the author and will likely not be read.

When should you think about this level of diligence? For a One Pager almost always. If it's an informal set of notes or a conversation starter then I probably would take a looser approach but these rules are still generally how I would organize my thoughts.

The Excellence Paradox at Work

Remember The Excellence Paradox? This is one of the places it shows up. Top-performing engineers will agonize over their one-pagers, drafting and redrafting until every word earns its place. They'll worry the document isn't good enough, but that concern is what produces quality.

Just like I mentioned about getting that 98% on a test, you'll find yourself obsessing over that last 2% of clarity. Embrace it. This is the price of excellence.

Start Small and Practice

I created this Substack to get better at writing. I write, I read, I re-write, I delete, I re-organize and I repeat. It’s still a work in progress but just know that you don't need a major architectural decision to practice this skill. Start by writing one-pagers for smaller decisions, share them with trusted colleagues, and ask for honest feedback.

Like any skill, this improves with deliberate practice and Introspection on the feedback you receive.

The Ripple Effect

Mastering the one-pager improves your thinking in other contexts. You'll find yourself speaking more clearly in meetings, writing more efficient emails, and cutting through ambiguity faster.

Communication isn't separate from technical excellence—it's an essential component of it. The one-pager isn't just a document format; it's a thinking tool that will serve you throughout your career.

So the next time you're facing a complex decision, challenge yourself: Can you explain it on a single page? Your future self—and your colleagues—will thank you.

Builder: ”My lord, limestone’s not nearly as strong; the weight of the upper chambers won’t hold! We’ll have cracks within a generation!”

Stakeholder: “But the Pharaoh will never know the difference. Just ship it!!!”

Witness the earliest Technical Debt conversation between a builder and a stakeholder. I’m taking some creative license here but anyone who’s seen the famous “Bent Pyramid of Sneferu” might wonder how the standup went on that day when the team realized they were building on an unstable foundation.

Let me take you to a scene that plays out in engineering teams every day:

The Sprint is humming along nicely and a request comes from a stakeholder (could be a Product Manager, could be an Executive etc.) "We need this feature by XYZ date. Can we just hardcode these values for now and clean it up later?"

You know the answer should be "no" but you also know the quarter is ending, the feature is important, and you know there’s a hacky way to get it done that while it won’t be pretty will probably work. So you slap something together, your teammate writes "LGTM" on the PR and it’s approved. You promise yourself you'll fix it properly next sprint.

You just took out a high-interest technical loan, and the payments will come due at the worst possible time.

What is Technical Debt?

It’s a broad term but I think of it as anything that wasn’t done right the first time. It might be a hardcoded value that should’ve been read from a config. It might be a piece of code you wrote really inelegantly, e.g. tightly coupling references instead of dependency injection. It might be just a piece of code that doesn’t have good coverage.

These all add up over time to make modifications and maintenance of the code harder than it needs to be. That’s Tech Debt.

How do you define it? Drop a comment below with your worst example.

The True Cost

How do you explain to someone that this 'simple change' would require updating 23 different services, each with its own precarious set of dependencies? That modifying one seemingly innocent parameter would cascade through layers of technical debt accumulated over five years of “we'll fix it later”?

Technical debt isn't just about messy code or outdated dependencies. It's a compound tax on:

• Your time - figuring out how something works instead of building features.

• Your speed - when something’s designed well it’s easier to maintain. When it’s band-aided together you’re afraid to touch it.

• Your reputation - do you want to be known for moving slow and maintaining legacy systems or innovation?

• Your learning - if you can’t update your codebase easily you’ll end up stuck using outdated patterns and technologies.

• Your job satisfaction - who wants to live that high cyclomatic complexity life?

• Your frustration level - you know things could be simpler but feel powerless to stop the never-ending layering of workaround.

A Lived Example

Probably the greatest test of any organization is saying “Hello World” meaning how quickly can you push a change to production?

When I joined Audible/Amazon I noticed our team was all working in a single jar (these were Java days, don’t judge me). The codebase was huge (hundreds of thousands of lines) and developers had turned off unit testing as it took too long to run.

This was crippling tech debt that the entire organization had normalized. Everyone complained about it but no one wanted to take on the task of splitting up the library into smaller more manageable components. It was clear what needed to be done so as a fun little side project I took on this task and over the next few weeks broke that library down into more manageable pieces.

I worked across the group and got to know the team, and slowly areas of domain ownership emerged; Content, Identity, Account, and so on. This effort became known as “The Package Split” and gained its own momentum. When I was done we had about 15-20 much smaller libraries, many of which were rarely touched so we could leave them alone and focus on code coverage for the more frequently worked code bases. It was a thankless task but everyone thanked me 😀 and I got to learn the codebase pretty well as a bonus.

A Lifestyle Change

Managing Tech Debt is a lifestyle. You can’t just "refactor aggressively" or "write clean code." Would you tell someone in financial debt to "spend less." The reality is more nuanced:

1. Measure - It always starts with data. Track time spent on bug fixes vs new features. Document which parts of the system generate the most support tickets. Quantify the onboarding time for new team members. These data points can help you make your case to leadership that you need to pay down your debt.

2. Learn to “Speak Business” - Every deprecation needs a story. Don't say "We need to upgrade the database." Say "Our current data infrastructure costs us $X in support hours and limits our ability to handle Y% more traffic, which directly impacts our Q4 growth targets."

3. The Power of Small Wins - The Boy Scouts say “Leave the campsite cleaner than you found it” so in our world try to "leave the codebase better than you found it." Every ticket, every feature, every bugfix is an opportunity to pay down a small amount of debt. It's the engineering equivalent of paying an extra $50 on your mortgage each month.

4. Envision your Future Regret - What’s the worst-case scenario? Imagine the system has failed. What types of questions would you ask yourself in the retro? How would you feel in that moment? e.g. “We knew this would happen, why didn’t we address it?”. I don’t want to live with that feeling. Model what the customer impact would be should your system fail and convey this to your team. Is it really something you want to end up in the Wall Street Journal over?

The Career Benefits

Engineers who can successfully navigate technical debt often accelerate their careers. Why? Because technical debt is really about making trade-offs, communicating effectively, and thinking long-term – that’s Engineering. It’s all trade-offs and knowing where to compromise is a key skill for senior engineering roles.

A Call to Action

It’s your turn - Where is your systems’ debt stored? Where are the pain points? What's the interest rate? Think about your team - what skills aren't they learning because they’re maintaining legacy systems? Drop a comment below and let’s talk about it.

Can you create a "debt payment plan" that aligns with business objectives?

“Don’t Let the Pyramid Bend.”

Technical debt, like financial debt, isn't inherently bad. The problems come from pretending it doesn't exist. Sometimes you have to hit your debt ceiling before you learn to manage it properly.

Technical debt doesn’t mean you’ve failed as an engineer, it just means the solution isn’t as elegant as it could be. Engineers who thrive are those who learn to make choices strategically and who can then communicate effectively about those trade-offs. Entropy should decrease over the long term (but the Universe will fight you at every turn).

4,500 years later the Bent Pyramid’s still bent and although the ancient Egyptians did manage to “Ship It” I’m sure the stone masons were bothered by it for the rest of their days…and it probably bugged the Pharoah too.

On this particular day, I think we were turning hay and my cousin decided I was ready to run the tractor. This wasn’t a little ride-along John Deere mower, this was a full-sized Massey Ferguson with thousands of pounds of torque, no safety features, and a PTO1 that would flay you alive. My cousin thought it would be cool if I drove it and I completely agreed.

I had driven tractors before this but in very controlled conditions and I certainly wasn’t ready to be let loose on this one. Nevertheless, I was brimming with adrenaline and confidence and eager to impress my cousin so I felt very much ready for the job. How hard could it be?

I climbed up into the seat, threw it into the first available gear, let off the clutch, and proceeded to drive that tractor straight into the ditch almost tipping it over to 45 degrees sideways. If it had rolled I would’ve easily been killed. Or worse; we might’ve lost the hay!

My cousin saved the day and no one ever found out but I didn’t drive again for a good long while…

When Should You Be Promoted?

In most cases, you should be promoted only after having already operated at the next level for a sustained period. Think of the promotion as a confirmation that you’re already there. I don’t recommend promoting someone into a role if they haven’t already shown that they are competent with the core responsibilities of the next level. I would argue that promoting someone too early will set that person up to fail and it will be very hard for them to recover.

The goal is not growth at all costs but to set the person up for long-term success.

Confidence is King

Sad to say but I’ve found the world is not that welcoming. To make your way through life you need to advocate for yourself and believe in yourself. Without some degree of self-confidence, it can be tough to make progress. Even as I’m saying this I’m reminded of my struggle with Imposter Syndrome and I acknowledge this is a challenge for so many of us. Don’t be afraid to believe and advocate for yourself.

It’s your mentor/manager’s job to build up that confidence when it’s lacking and to knock it back when it’s over-loaded. I wish someone would’ve told me I wasn’t ready for that tractor! I still have flashbacks to that moment even now.

How to Talk about Promotion

Share your career aspirations with your manager. Don’t be afraid to discuss your vision for where you want to go. Be specific! “I’d like to be a CTO, a Principal Engineer, a VP of Eng”, whatever aligns with your goals. These are all great places to start the conversation and from there you can develop a plan to reach your goal.

Introspection and the Importance of Writing Things Down

How do you view yourself? What’s your mental image? Have you ever written it down?

Part of the reason I write this SubStack is to calm down and formalize my thoughts. The act of writing is almost like an extrusion machine wherein all the ideas and fleeting images in my head are forced through the keyboard into black and white on the screen. Then I read. Then I re-read. Then I re-write and I re-read again. It’s hard.

Objectivity and your Autobiography

If you were to write your one-pager biography what would it look like? What are your accomplishments? Have you sat down and listed them out? Go beyond just the details of what you did and examine what was the outcome. Are you solving the right problems? Are you having the right impact? Sometimes we do great work but its impact is minimal. And sometimes the reverse.

Think of this as your “Brag" Sheet. It can serve as a way to get a sense of where you stand backed by data and evidence2. Before you engage in a career/promotion discussion take a moment to baseline where you are today. Write it down. No really, write it down. (yes it’s hard)

Once you’ve done your homework the next step is to compare your perception to the world’s. Ask your manager to write down their view on your contributions. This is a great exercise if they’re willing to do it and then together you can examine the gaps.

What do they see in you that you didn’t think of? What are you doing that they are not aware of? What are you each expecting of each other?

Are We There Yet?

Once you’ve compared notes with your lead you can discuss the expectations for the next level. What opportunities do you need to explore to develop those muscles and continue your growth?

Always drive the conversation with data - Reference your group’s Career Ladder or Leveling Guide so you have a common set of expectations. Here’s a handy reference if your Org doesn’t have one:

The Searing Spotlight of Early Promotion

When you get promoted the team notices, the organization notices, and your peer group notices. Hopefully, they’ll all congratulate you because they see your impact and support the promo. But if that’s not the case it can lead to problems.

At every stage in your career people hold different expectations of you. It’s complex and nuanced but you should expect to be implicitly compared to others already operating at that level. It’s just human nature.

You will be called upon to do things you’ve never done before. You will be pushed and it will be hard, even if you’ve been operating at the new level for a while.

Let’s Learn from Each Other

Now, it's your turn to share. Have you ever found yourself in over your head? Or perhaps you've experienced a moment when you realized you were truly ready for that next big step in your career? Drop your story in the comments below – whether it's a close call, a triumph, or a lesson learned the hard way.

We all need a support network. Let's learn from each other. Your successes and your stumbles might be the insight another reader needs to hear.

“Oh the Places You’ll Go” - Dr Seuss.

In this life, you need a bottomless reservoir of confidence to try new things. To go beyond your limits. When you succeed at something you’ve never done before it becomes the new “floor”. Confidence builds. You try bigger things.

When you stretch too far you fail and it can be humbling. Even humiliating (e.g. public speaking). Confidence takes a beating. It becomes harder to try again. If that becomes a trend you may never recover and THAT is the negative cycle you should avoid at all costs.

My task was simple, drive the tractor in a straight line from here to there. But I wasn’t ready and no one held me back. I failed epically but I was lucky. We didn’t lose the hay and no one ever found out (except my cousin and I guess all of you reading this).

Don’t drive your career into the ditch. Take your time. Life is long. Enjoy the ride and above all, protect the hay.

Me: “I think the company is awesome, but I don’t want the job and you don’t need another manager. “

I slide an 8x11” piece of paper across the table.

“I think this is what you need….and I think I can help”.

The room goes quiet as he picks up the paper and reads it. The situation is polarized at this point - I will either walk out of here with a new job, one that I made up from whole cloth the night before or we’ll part ways.

How did we get here?

I’ve always identified as an Engineer, and like most engineers, I’ve railed against management. I studied Computer Science because I wanted to make video games and work on computers. The idea of managing people never entered into it.

Despite this after about 5 years out of school I found myself managing a team in the technology group of a large bank that you have definitely heard of. They provide city bikes in New York City and you can ride them to their big green “field” in Queens. I did this for 7 years and they were very good to me. In my time there I got promoted and my team grew to over 100 people. But as an engineer, I felt my tech chops slipping away.

The Side Gig(s)

To maintain my chops I did a lot of programming stuff on the side. I wrote a few tech articles for MSDN Magazine and that turned into writing a programming book for Wiley publishers based on a little eCommerce company called Amazon and their emerging web services platform (ISBN 0470097779). I knew I couldn’t get as technical as I wanted in the bank so I went looking for a new gig.

Amazon was an amazing place but I didn’t want to move to Seattle so that was off the table. A friend (DV) was working at a company in Newark that was an Amazon subsidiary. He invited me to their happy hour and I met a few other folks there (TO’D and DR). They were welcoming, kind, and super smart. They were working on interesting stuff. So I interviewed there for a random manager position, after all that’s what I’d been doing at the bank right?

Interviewing for the Job I didn’t want

There were two full rounds of interviews, maybe ~16 sessions altogether, including tech-screens and coding exercises. I remember I messed up the recursion problem at the whiteboard and there was one other problem I screwed up but I went home and just emailed them a working solution in Javascript that night. That still bugs me to this day.

By the time they were done, I was fairly convinced the company didn’t know what to do with me. I was too technical to be a manager but I had too much management experience to be an IC (individual contributor). Or maybe they just didn’t like me?

Every Problem is an Opportunity in Disguise - John Adams

After about 3 weeks I had spoken to every part of engineering and some of the business leaders and had been noting things down that I felt the company needed. This list was holding the business back in a significant way. These weren’t particularly great insights so I couldn’t understand why they hadn’t solved them.

E.g. Customers used separate credentials from their Amazon account, even though the company had been an Amazon subsidiary for 4 years. They had a home-grown DRM system that protected their content but that meant very few devices could actually play the stuff. Content had to be delivered dynamically instead of using a CDN. They didn’t stream anything and the list went on and on.

I asked about these issues in the interviews; “why aren’t you streaming your content?” It was no one’s fault. The tech team was focused on the short term and the business didn’t understand where Amazon/industry was going or what engineering could offer. No one was thinking strategically about the engineering roadmap and what was possible technically. It was a vicious cycle.

Good news for me though! These were things I either knew how to do or I could figure out with the added bonus that delivering this stuff could be really fun.

If you don’t know where you’re going, any road will take you there.

No one knows what you want better than you (even when you don't know what you want). I wanted something radically different from what I’d been doing at the bank. I felt like the biggest value I could provide in this situation was to solve these problems and I knew I didn’t want the job I’d interviewed for.

Looking at my list I realized it described a different kind of role. This stuff needed an individual contributor along the lines of a Principal Engineer to envision, design and engineer the solutions. They didn’t have any people like this and they weren’t hiring for one so my path was clear - I would stay at my job in the bank. Just kidding!!! I would write up a new job description, pitch it to the CIO, and see what happened.

Tough Questions

If you want to feel great about your job you need to ask some tough questions.

1. Figure out what you really want. Or don’t want. What are your “non negotiables”? What are you willing to compromise on? I was willing to give up leading a big team and title because I wanted to be closer to the tech. What are you willing to compromise on and what is really important for you?

2. “Know thyself”. Think deeply about what it is you’re good at. I’m not a great manager. I’m not that great an engineer either but I’ve had good success by connecting the dots. And dealing with Ambiguity. I can muddle through pretty much any situation and that’s something I’ve realized through running ultra marathons. You gotta keep moving forward. What are YOU good at? What’s your super power?

3. Find a Problem and Solve it. Look around. “Be Useful” as Arnold Schwarzenegger says. Don’t wait to be handed a problem - ask questions. Dive Deep. Look across disciplines. Connect the Dots. Your job is not to just solve problems. That’s table stakes. Identifying the Problem itself AND the Solution and then figuring out how to deliver it. This is where the real value is created.

This last one is important. It’s not realistic for a CIO to present me the perfect list of problems that match my skillset and then appoint me as the person to solve them. They’ve got a million other things to do. Instead I presented a neat package of value to them wrapped up as a job description. All they had to do was approve it. Let’s head back to see how it ended…

Back to the Boardroom.

After a long silence, the CIO put the paper down, looked up, and said

“This is great, we need all of this”.

We shook hands and he recast the role based on the one page I’d drafted. I joined a few weeks after that and spent almost the next 8 years working on these problems and many more.

That was the beginning of a transition back to being an individual contributor. I was back coding again and it felt great. As an IC I could learn the Amazon internal developer systems and tools. I built relationships across Audible and Amazon. I lived the developer process. It gave me a unique insight that other leaders didn’t have. It made it easy to identify and prioritize areas that were slowing teams down because I was experiencing them firsthand!

A simple example: Early into the gig I split up our monolithic Java codebase into modules. This was thankless work but it cut build times down massively. All the while I was getting to know people and slowly building trust, credibility, consensus and support for major step-function changes in our business which we would eventually deliver.

After a few years, I ended up back as a manager but with a completely different set of tech-chops, and the experience I’d gained as an IC paid off in spades.

Career Paths are never Straight Lines.

What has YOUR path been? How did you arrive where you’re at? Do you know what you want? I definitely didn’t and probably still don’t. I got incredibly lucky. What I want is something I have only a few fuzzy notions on but I have very strong feelings on what I don’t want.

Avoid Lock In.

It’s so easy to get stuck into a trajectory - you’re either an IC or a Manager and you stay within the guardrails or risk losing a step. You take what’s offered or stay where you are. But you can be an active participant in your own career.

We each create our jobs every day. You don’t have to stay where you’re planted. Keep an open mind and look for the biggest problem. Don’t be afraid to deviate or blaze a new trail. When you look back you’ll see you were on the right path the whole time.

Engineer #1: “We’re fully down, you’re going to have to tell them.”
Francis: “I would but the Secret Service have the whole floor locked down, I don’t even think I can even get down there. ”
Engineer #2: ”Dang, you’re right, you can’t get down there without the background check.”
Francis: ”Ok, let’s just make sure? pull up that graph one more time.…and you said we added hosts?”
Engineer #1: “Yep. They just keep falling over.”
Engineer #2: “I don’t understand, there’s not even that much load right now. "
Engineer #1: “Let’s just bounce the cluster….”
Francis: “Ok, time’s up, I’m going to have to let them know”

How did we get here?

In 2017 Joe Biden (yes that Joe Biden) was visiting our offices to announce the launch of his new book “Promise Me Dad” - the heartbreaking story of Beau Biden and his battle with a malignant brain tumor. Beau was the son of Joe and Joe’s late wife Neilia Hunter. Biden was scheduled to be interviewed in our offices that day and the employees who would be near him had been pre-screened by the Secret Service weeks in advance. It was a big moment.

The morning had started much like any other and we were prepped and ready to go. Joe’s book had racked up a respectable number of pre-orders and everyone who had already purchased the book would have it delivered automatically to their libraries at the release time early that morning.

The appointed hour arrived, the system clock ticked over, and…our system fell over. Alarms started going off. Pagers began paging; We were experiencing a rolling outage. Joe Biden was on the floor below us, being interviewed by our CEO. Since Joe was onsite the entire floor of the building had been locked down by the Secret Service but somehow we had to work the issue and restore service.

The internet wasn’t too happy with us either…

How Can Outages Help You?

Outages and Incidents in general can be a source of great learning, both technically and in terms of leadership, so it’s worth reflecting on them.

When I interview people, especially senior folks I usually try to have them explain an outage they experienced. It’s one of my favorite interview questions. Weak folks (ironically) will play off the question to feign strength “I can’t recall” or “I’ve never really had that bad an incident” - a huge red flag.

Strong candidates are readily able and willing to take you back to that moment and recite chapter and verse. Being able to dive deep and explain an outage is a good sign they’ve thought about what went wrong and hopefully conducted a retrospective. It’s also a sign that they come from a culture where it’s ok to talk about incidents. This last part is foundational.

Tips to Help Manage Through an Outage

Experience is what you get when you don't get what you want. Here are some things to consider the next time you find yourself in the middle of an incident.

• Stay Calm & Don’t Panic - remain composed. If you freak out everyone will freak out and in a crisis that’s not helpful.

• Work the Issue - When stuff’s broken you have to focus on getting things back to normal. It’s not the time to assign blame or try to “fix” the process breakdown that got you there. Just work the issue.

• Follow the Data - Walk the mental model of how the system should work, consult your graphs and instrumentation to verify and trace the issue back to the root cause. The more things you can rule out through concrete data the more cycles you can devote to productive triage.

• Don’t Ignore Your “Hunch” - engineers will often have an intuition for how things work or don’t work. Doctors have a similar intuition - “this smells like a heart attack” even though they don’t have definitive data. These hunches can be helpful so don’t ignore them. Use high judgment and chase them down. If the data correlates maybe you’re on the right path.

• Don’t Start the Retrospective During the Triage - it’s easy to start talking about “if only we’d done XYZ” in the moment. That’s not helpful. When the system is down your primary focus should be on restoring service.

• Be Positive and Avoid Blame- as a leader, it’s your job to proactively counteract the negativity of the moment. Blaming people will shut the conversation down. That’s not what you want in the middle of an issue.

• Ensure people feel safe - it’s a crisis, recognize that people are feeling their most vulnerable. This is an opportunity for you to lead. Don’t miss it.

• Assign an Owner for the Retro - do this after the incident has been mitigated but BEFORE the call is closed and be sure to set a reminder somehow. (most of the tools out there will do this for you).

This Biden incident was triaged by just a handful of folks, 4 or 5 of us total. As a team we kept focused on the outage and the resolution. The details are interesting but wouldn’t be appropriate to share here. If you see me in person I’ll be happy to dive deep. I think the whole thing was mitigated by about 2PM that day and I never did have to give Joe Biden the bad news.

Through this incident it became obvious there were some design flaws in our API so we conducted a retro and prioritized the refactoring to avoid this in the future.

Celebrate your Outages and Learn from them.

In my time at Amazon I experienced an open culture where the incidents that stand out in the history of the business are shared transparently. These “Great Disasters” are a part of onboarding. Some examples include the “Hulk Hands Incident” that overloaded the order delivery system or the time a single pipe symbol brought down all of S3 in US-East. Or the cat who fell asleep on the keyboard and…well that’s another story.

In Conclusion

No career is free of blemishes and I deeply value the incidents I’ve been involved in and accountable for. That sounds weird to say but it’s true.

Incidents and Outages come at the worst times; high-profile or high-pressure launches, or when you’re out enjoying your kids’ birthday party. In the moment, they’ve all felt horrible, but I’d like to think I’ve learned something from each one and that they’ve made me a better engineer overall.

What is the Cocodona 250?

“Cocodona” is a 250-mile point-to-point ultramarathon (footrace) from Black Canyon City to Flagstaff in Arizona, climbing about 40,000’ elevation and descending 36,000’ as it winds through the backcountry. The terrain is a mixture of mountains and desert ranging in elevation and generally “technical” meaning lots of rocks. Runners are allowed crew and pacers along the route but I would be running unsupported/solo.

Some Context for Road Runners

An Ultramarathon is any foot race longer than 26 miles. A regular marathon is a smooth, manicured road, and usually flat as a board. E.g. “Heartbreak Hill” in the Boston Marathon is notorious for stealing souls but the reality is it’s an 89’ rise over half a mile! Ultras are…different.

Most ultras are on trails over uneven terrain with roots, branches, stones, rocks, dry river beds, water crossings, and rolling hills. Depending on the distance and terrain your pace can vary from 12-14mins a mile (considered very, very fast) to 1 hour per mile or more. I’ve done a bunch of 100+ mile distances, including iconic races like Moab 240 and Leadville 100 and they all hit different but NOTHING I’ve experienced compared to Cocodona.

Race Prep

I would be running solo, with no crew or pacers (support runners). In some ways, solo is a disadvantage but for the type of experience I was looking for it was perfect.

Sunday May 5th I had a 3 AM ET wake time, 6 AM ET flight, and arrived in Phoenix 9:30 AM PST. From there I made my way to the race start line and dropped all my stuff off around noon. The race was just setting up. I spent a few hours sleeping and then left my motel (not hotel) at 2:30 AM PST Monday 6th morning. There was a bit of a delay getting SPOT devices assigned and a lot of standing around but by 5:10AM we were off and running.

Let’s Goooo!!!

We filed out of Black Canyon into the backcountry in a long conga line through the hills. The trail was beautiful. We ran silently, observed by massive saguaro cacti; ancient sentinels granting us access to the sacred lands of the old West. I breathed the dry air and stayed present as the sun rose. The worries and stresses of the 21st century fell away and our adventure had begun.

From the start line the trail wound into the first aid at Cottonwood (mile 7.5): The day would be hot (90-100F) and the trail would be steep so we had a mandatory 4 liters of water as the minimum carry. I drank what I could, loaded everything up and left Cottonwood with a liter to spare (5L or 11 lbs of water). My pack at this point was about 22 lbs, more than I’ve carried in any race ever. This would be a huge factor in the miles ahead.

Getting Punched in the Face

Over the next 12 hours, we climbed +9,518’ gain and -4,856’ descent on the route to Lane Mountain. This was an absolute kick in the teeth. It was hot (90F+). It was rocky, uneven, and overgrown and it never seemed to end. I got behind in electrolytes, hydration, and nutrition and before long became nauseous. My clothes developed a white line of salt throughout my gear and it was an easy guess that I was dehydrated.

By late afternoon my pace was slowed to a crawl and I eventually threw up. The miles wound on and the sun was unrelenting and…I threw up again. I tried to reset with salt tabs and that only made matters worse. By the time I reached Lane Mountain (mile 32), I had thrown up 3 times and looked like death warmed up. The medic at Lane sought me out and quizzed me. I got the feeling that if I hung around she would cut me from the race, so I slammed some broth, got out of there, and started the trek to Crown King.

Don’t Panic!

This first section was a punch in the face. I felt like I’d jumped in the deep part of the ocean and my body was going into shock. Despite the initial assault, my mind was steady and I knew if I just hung in there my body would bounce back. It was going to suck but it’d get there. I was still in control and could make it happen. I pressed on and arrived in Crown King (mile 37) pretty late about 3 hours before the cutoff.

At Crown I tried some food, took care of some basics, and picked up my puffy coat.

I left Crown King with a new friend (Wes) and we hiked into the night. The trails were freezing cold at this point. Daytime temps had been in the 90Fs but nighttime in the Bradshaw mountains was cold. Probably 40Fs. I had to push the pace just to keep warm and soon lost Wes and found myself running solo through the mountains. I reached Arrastra Creek (52miles) after a hard push and was ready for a rest but there wasn’t much there, just a fire, some broth and other shivering runners so I didn’t stay long.

The next section was daunting - a 9-mile unrelenting climb 2,700’ up to Camp Kipa. I knew there was no point shivering at Arrastra so as soon as I’d chugged some broth I headed out solo. The night was as cold as iron. I knew it was only going to get colder so I settled into a weak shuffle in an effort to stay warm.

You Have Time…in a 250 mile race to fully die and come back to life.

Somewhere along this trail, I threw up for the fourth time. This was the entire contents of my stomach and pretty scary. I hadn’t lost my composure but I was starting to get concerned that my body was shutting down. If I got into trouble here my race was basically done but moreover, I could end up in hospital.

At this point I was pretty much at the mercy of my body. Things were out of control and it would’ve been easy to freak out but I focused on staying present and moving through the course. I could still see a narrow path forward but this was a reminder - in no way was I in charge out here. The trail demands respect.

I remember being alone in the forest that first night, flowing through the mountains with the cold and the doubt. The path took on an almost ghostly feel. I felt the trees around me and the loose trail ahead and a deep connection to my father. So much of my life is about control and managing outcomes but this was a time to let go.

Whatever happened, whatever the universe’s plan, I would allow it to pass through me but I was not going to quit.

I reached Camp Kipa (62miles) shortly after dawn broke over the ridge, an epic display, and decided to get some rest. I was about 4 hours from cutoffs at this point and Camp was pretty desolate. I lay on my back on the ground with my feet elevated on a chair and fell asleep in that position for 45mins. I woke, grabbed some food, and moved out of camp, alone.

From here I reached Camp Wamatochick (69miles) and then down into Whisky Row (78 miles) and as the afternoon wore on the Arizona sun played its part. This section was HOT and by the time I reached the aid station, I’d been dreaming of air conditioning and a bit of sleep. I was still carrying about 3L of water, god knows why as I wasn’t able to drink it.

A Bed at Whisky

The Whisky Aid station is next to a hotel and at this point, you’re allowed to go off course so I took full advantage. I booked into the hotel ($160) and slept in an actual bed for 2 hours. It was amazing. And hard to leave. I awoke in the same position as I’d laid down in and got back on the road with 4 slices of pizza in my hand. I still wasn’t sure if the food would stay down but I needed calories so I slammed it back and hoped for the best. My body answered; I was done throwing up.

This next section wrapped around town and out into the Granite Dells (pictured above). They are beautiful to behold but TERRIBLE for foot travel. Giant boulders with tiny white blazes that are impossible to find, especially in the dark. GPS doesn’t really work there either. I somehow navigated these in the dark by headlamp and after an age I climbed out and got on the road to Iron King. Here I met Natalie and her pacer Lourdes. We shared some miles and they entertained me with tales of their derpy heeler dog. I was glad of the company.

From Iron King (mile 90.9) through Fain Ranch (96.1) and up to Mingus Mountain Camp (mile 108)) we had about 11miles through flat fields which I thought would be great but there was no trail. Just a GPS route cut through miles of little cacti and thistles with barely any markings. The path had been well marked with flags during the day but the cows in the field had eaten them all so this made navigation by GPS the only option. Despite navigating pretty well I still stabbed my feet a bunch with cacti and had to stop and pull spines out. This was painful. Welcome to ultra racing!

An Insignificant Milestone

In this section, we crossed the 100-mile mark. For most folks 100 miles would be a major milestone but we weren’t even halfway and I barely looked up when I passed the little marker. I was grateful for the progress but it didn’t register as a celebration.

I arrived at Camp Mingus (108.5) after a long climb in the early morning of Wednesday and had already decided to get some sleep there. To put things in perspective it had taken almost 48 hours to cover 108 miles. By contrast, I’ve run 101 miles in 22 hours under different conditions. Cocodona was not screwing around.

Note to future runners, Mingus is a GREAT place to catch some sleep. They have a dedicated building and it’s relatively cool and quiet. I ate what I could, did some foot maintenance, and bedded down for a welcomed 90 minutes of sleep. I awoke before the alarm went off in the EXACT same position I’d closed my eyes in. Thank you Mingus. It was time to move.

Leaving Camp I was blessed with the incredible view down into Jerome. We were at about 8000’ of elevation here and you can see all the way into across the Verde Valley to the red rock walls of Sedona and the peaks of Flagstaff beyond. Some of the most spectacular of the course.

The climb down into Jerome is…not nothing. In the Moab 240 there is a short but treacherous climb called '“Jacobs Ladder” that brings you from the canyon rim down into the desert plane itself. It’s super sketchy and you need eyes and ears open but it lasts about 20 minutes.

The descent into Jerome was Moab on steroids. Long miles of single track, rocky and at times VERY exposed. One slip and it could easily be game over, especially if you’re solo like me. I took my time, focused on hydrating, and scrambled down as best I could.

Everybody Struggles

After endless switchbacks, I got to some double-track which was safer but just as rocky. Here I met another runner Brandon and we blew through the trail chatting like old friends and sharing stories of what drove us to these types of events.

Life’s a funny thing but everyone is struggling and there is a shared suffering in the ultra world that never fails to bring people together. I so enjoyed the conversation with Brandon and after endless rocks, we finally broke out into a road and I shuffled on down into the town of Jerome. Thank you Brandon!

Halfway time for Bonus Miles!

The Jerome Aid (mile 125) is near an old copper processing facility. Aid station volunteers were amazing and were blasting some horrendously offensive trap-house music! The vibe here was surreal! By far the sexiest aid station on the route. Thank you Jerome aid workers! You made it memorable.

Leaving Jerome I picked up a STACK of watermelon that was giving me life. I munched on it for about half a mile down the road until I realized I’d left my poles back at the aid station. Doh! About-face and back I went. These are called “bonus miles”.

I had already made some friends at the aid station and when I saw the same people twice these gracious folks offered to go grab my poles whilst I rested. I sat with the rest of their crew who were supporting their runner Davey - bib #205. Mine was #204 which made us Bib Brothers. That crew (from Connecticut) was so fun and we traded impressions of David Goggins whilst waiting for my poles. Stay Hard!!!!

On the way out of Jerome, I linked up with Jackie and Walt. These guys were amazing and we quickly fell into a great conversation. They made the miles fly by. We made our first legit water crossing on the course together just as the sun was setting (I think this was the Verde River). We took off shoes and socks and the water felt AMAZING so we paused for 5-10minutes sitting on the bank in the twilight and enjoyed it.

From there we reached Dead Horse (mile 134) and refueled. I was starting to feel a slight bit more human by now. Food was staying down and more importantly, water was also staying down. That had been my focus since the previous day and I knew if things kept going I’d be able to continue the race. I was less confident about the cut-offs but we’d made some time on the road into Dead Horse. After about 30mins we decided to head out and I took the lead and set the pace. It was here I came across a mean-looking scorpion, a good reminder of the dangers on these trails.

After some time the trail trended uphill and I was in the zone so without realizing it I lost the string of runners behind me, including Walt, Jackie, and Brandon. I figured they’d catch up when I stopped but sadly they never did. The trail wound up and over countless hills and the night was black as pitch.

“Where Do You Sleep?”

I could sense the red rocks of Sedona out on the horizon and this section would’ve been incredible to pass through in the daytime. As it was I was struggling to stay awake and took two 10min trail naps. People ask me “Where do you sleep on an ultra” and the answer is “Anywhere you want”. The stops were a chance to turn off my headlamp, let my eyes get accustomed to the dark, and stare up at the night sky. I was cold but I didn’t care, I just lay there on the trail, staring up at the endless black stars, and was thankful.

Back Running Again

Somewhere along this trail, I panicked - I was too close to the cutoffs. The reality was I was fine but my hazy brain and trail math told me otherwise so after traversing 130 miles I forced myself back running. I passed a bunch of runners and their pacers along the last few miles into Deer Pass (mile 147). The aid station was pretty desolate. Everyone was shivering and freezing. I sat down for about 10 minutes for no reason at all and then stood right back up again and headed out. I knew I had to keep moving or risk hypothermia.

The trail out of Deer was pretty runnable but I had nothing left. Lack of calories and sleep were catching up to me and I again had to pause for a dirt nap. A runner and her pacer (Katerina and Jeff I think) passed me and I latched onto them. They were moving at a good clip and I zeroed my gaze in on Jeff’s heels. Without the mental pressure of navigating I just had to move my body and I felt like I had a chance to keep up. I followed them until about 2 miles out of Sedona when they pulled over. I pressed on and eventually, I reached the Red Rock High School water station down into Sedona just as the sun was cresting the rocks. Incredible.

Next came some beautiful single-track trails that wound around town and up to the ridge right above Sedona. This was pretty exposed which meant some amazing views. It was dawn and I was surrounded by the Red Rocks, physically exhausted but mentally in thrall by the landscape. I sat for 10 minutes as the sun rose against Cathedral Rock. The stillness of the desert and the peace of that moment will be with me for a long time.

After what seemed like an age I arrived at the Sedona-Posse Grounds Aid Station (mile 161.4) and it was again time for some sleep. After about an hour I started gathering myself up and again bumped into Walt and Jackie. They were just about settling down and I hoped we would see each other again.

Heading out of Sedona I filled my hat and my hood with pure ice and this was a game-changer. The ice kept my core temps down in the heat of the day and meant I was able to move smoothly through some of the most brutally hot sections on the course.

The trail finally led down into Casner Canyon where Howie Stern and Mischa were waiting to snap a pic as we crossed the river at Oak Creek.

I left the river with no clue what was ahead but if I’d known how tough it would get I might’ve stayed a bit longer. The next section was a prolonged overgrown climb over 7 miles straight up out of the canyon. Looking back every few minutes onto the red rock monoliths of Sedona as the desert landscape slowly gives way to Ponderosa Pines. Sublime but Punishing. I reached the top of the climb hoping for a full aid station but sadly it was water-only and completely deserted.

There is no Plan B

From here I wound on to Schnebly Hill (mile 178) and I did some mental math; cut-offs were way too close for comfort so I resolved to get moving ASAP. I’d been frustrated that running had been so hard. We were were at altitude but it shouldn’t have been that tough so I decided it was time to shed weight. I dumped the 3 liters of extra water I’d been carrying. Pouring that out felt like a one-way door, there was no going back, no Plan-B. I figured worst-case I’d make it to the next aid. Shortly after that I started shuffling, then jogging, then running.

“I Don’t Understand It Either”

Within a few miles, I had dialed it up to running 10-11mins pace and it felt amazing. This section was a lot of downhill into Munds and I saw no reason why I wouldn’t run the entire distance. Pretty soon I was passing people. We were 180+miles into the race and people were understandably dead on their feet but I was moving. I passed a runner with her pacer and she yelled “You are hauling ASS!!!” to which I replied “I know! I don’t understand it either!”

I arrived in Munds (190 miles) and it was buzzing with activity. I had moved through the field and caught up to a LOT of runners so I tried another 45mins of sleep here and then got back on the road. By now it was well into the night and we were heading into the Coconino Plateau (around 7,000’) - the temperature had dropped significantly. I estimated it around 35F. I could see my breath and as soon as I stopped running I felt a bitter chill sink into my bones.

The reality of how people die of exposure struck me and again the Trail demanded respect. I’m out here solo. In shorts!!! If you see a sleeping runner the etiquette is to leave them be so if I fall asleep other runners will think I’m fine…but I might not wake up! I decided to keep moving at all costs. Since I didn’t have crew I was packing minimal and had no leg covering. Forward movement and generating body heat would be critical.

After running a bunch more I came upon some incredible ladies from the Navajo Nation. They had a great energy, gracious and welcoming and we traded stories of growing up and our respective cultures. The Long Walk/Trail of Tears in their history and the displacement of the Irish by Oliver Cromwell: “To Hell or To Connacht”. They talked about their relationship with the land and I shared some of Ireland’s pagan beliefs and how ancient Celts worshipped the earth goddess Danu. How cool to see the parallels in our cultures despite thousands of miles and years in the difference. I felt fortunate to share these miles as we wound on toward Kelly Canyon and mile 200.

Leaving Kelly I was at around 7,000’ elevation and it was still freezing cold. The day before there’d been a controlled forestry burn and the air was thick with smoke. Visibility was less than 10’ and it was difficult at times to breathe or even stay on the road! I linked up with Mike (pictured below) and his pacer Andrew whom I’d met at Fain and we pushed on to Fort Tuthill. Andrew couldn’t understand how I didn’t have any pants and only a single pair of shoes for this thing. Solo Bolo baby!!!

I left Mike and Andrew on the road and arrived at Fort Tuthill (mile 209) where I lay down for my final 45min nap and it was here that something incredible happened.

A Visit from my Trail Guardian Angel

I was laying on the cold ground of a big concrete building - just a typical nap, actually pretty upmarket compared to the trail. After a solid 45mins my alarm went off.

I awoke to find someone had wrapped a warm blanket around my legs as I was asleep! I was so dead I never noticed. After asking around I discovered my “trail angel” who’d cared for me - a gift from a blessed lady I’d chatted with only briefly upon entering the aid station. She’d noticed I had no crew, no pants, and no nothing! and had taken it upon herself to find a blanket and lay it on me! I couldn’t have been more touched. I never did get her name but I am forever grateful. Thank You!!!

*** UPDATE *** - Through the wonders of the Interwebs I have since learned my angel’s name is Dori Smith Troutman. A beautiful caring spirit who went out of her way with a random act of kindness that left a huge lasting impression. THANK YOU Dori!!!

The Final Push

I left Tuthill with a spring in my step, it was a really cold morning, we could see our breath and without running I would’ve ended up shivering. I was also concerned about the climb up to 9,000’ at Elden Crest - people had been warning me of the cold and that I’d need pants or some kind of cold weather gear so I resolved to make it up there and back down before the sun went down. That meant busting out some miles so after 209miles and four days on the road I was back running 11 and 12-minute pace.

Then the Wheels Fell Off

Somewhere before Walnut Creek(mile 227) my right quad cramped HARD and I had to pull over. With about 3 miles to the aid station I was reduced to a limp. I tried all sorts of things to work out the cramp but nothing worked and I hobbled into the aid station a broken husk.

At Walnut Creek I drank probably a pint of pickle juice and ate a ton. Things improved but this would be the end of running. I was frustrated as for the past day I’d been gaining tons of places in the overall standing and felt great. I felt good enough to run but my leg was just not happy. I would find out later that my quad had not just cramped but had a low-grade tear and that would be the only real lasting injury from the race.

I sat down on the way towards Elden Crest and refueled but in my exhausted state I forgot to zip up my pack. This was a potentially dangerous mistake as my headlamp and a bunch of essential gear fell out and was lost! I moved on down the trail oblivious and eventually caught up with two new friends, Shannon and her pacer Erica. I didn’t know it then but they would end up saving my race.

Unsupported but with Unending Support

I explained to Erica/Shannon that my quad was busted and could I latch on to them to share some of the miles? They graciously agreed. After a short while Shannon noticed that my pack was open and after checking I realized that I’d lost my headlamp. This would’ve been a disaster but Shannon had a spare and without hesitation offered it to me which of course I accepted and we pressed on. I was in no shape to move past them and so we shared the miles up to Elden Crest.

I say I ran this race un-supported since I didn’t have crew or pacers but if you’ve read this far you already know I got so much support from other racers, from Aravaipa, from volunteers and Aid Stations, and from the course itself. This experience met me at every turn and provided for me throughout. Shannon and Erica are the perfect examples, the perfect people right when I needed them. Without bumping into them at that point in the race there is no chance I could’ve finished.

Elden to Flagstaff (mile 250).

Elden Crest is an insane vertical climb of 2,000’ over just 2 miles. Straight up in the air! It’s 3 points of contact in many places but somehow this climb suited my busted quad. I was able to keep my right leg straight and use my left leg exclusively to lift my body up over the rocks and Shannon and Erica were again so gracious that they let me set the pace for this section. After a long afternoon, we reached the lookout tower at 9,000’ with about 45mins of daylight left and it felt AMAZING.

From here we had one more aid station where I enjoyed some incredible tri-tip steak and a beer. What race has Steak and Beer at the aid stations??? It felt amazing. With this last insane climb done, we had 10 miles remaining down into the finish line in Flagstaff at mile 250. The sheer enormity of the race hit me. I had been broken down in the first couple of days, emptied out, humbled, and then slowly replenished.

With the descent from Elden Crest, the weight of the challenge began to lift from my shoulders. We hit the finish line at about 10:30 PM and I cannot put into words the feeling. If there is a state of oneness, a state of absolute balance and flow, a state of peace that we can find in this life, even for the briefest moment, this was it.

Last month I wrote about Accountability - what it is, why it’s important, and some tricks I used to force myself into it. I hope this closes the loop on that post. My accountability to you all but more importantly to myself. I could not quit this thing. It was never an option.

I also need to drop a huge thank you and shout out to all my “virtual” support system - to my family, friends and colleagues who sent texts, notes, slacks and messages throughout the race. Who tracked me day and night for 4.5 days and who cheered me on from thousands of miles away, you guys are the best. It really made a huge difference. Thank you all.

I hope this illustrates not just the physical but the mental and dare I say it spiritual journey this adventure represented for me. I’ve only captured a small fraction of the full adventure here, there is much more I could say and a lot happened on the trail. By sharing a little of the story I hope it will encourage you to get out there and assault your own impossible goal.

I was drawn to Cocodona because it was beyond my known limits. It called out to me and at the same time, it scared me. I was genuinely not sure if I could finish it. Now that it’s done I’m good…for now.

Thanks for reading. I hope you find your own challenge out there. It doesn’t have to be an ultra race or even a physical thing at all. Just something that scares you. Don’t let fear hold you back from your goals. Accept it and move through it.

Let the trail provide what you need and the journey might just change your life.

Accountability vs Responsibility

Google teaches us that Responsibility is task-oriented and speaks to what you contributed toward a given outcome, what were you responsible for?

Responsibility is task-oriented. Every person on a team may be responsible for a given task that is required to complete a massive project. Accountability is what happens after a situation has occurred. It is how you respond and take ownership of the results.

Accountability speaks more to the actual Outcome and your Ownership thereof. It's about owning the outcomes of your actions and decisions, for better or worse and it’s a cornerstone for effective leadership, team cohesion, and personal development.

Sh1t runs downhill

I tell my team “The successes are yours, but the failures are mine”. I’m accountable for their outcomes. The mental image is an inverse pyramid and I’m at the bottom. I resist terms like terms like “Cascade” and “Manage down” as my job is to elevate and support the team.

How does this manifest day-to-day? I work a lot on planning/forward thinking but I’m still on call like everyone else. The teams have a Pager Duty and on-call rotation but I am ALWAYS on pager duty. I join as many retros and incident bridges as possible. When the outages are serious (rare) I update the stakeholders as if it’s my name on the door (because it is). It’s important to own the failures so the team can focus on delivery and racking up the wins.

Embracing the Suck

An ultramarathon is any distance greater than a marathon (26 miles). Signing up for that kind of race can be intimidating. Many folks will bring a crew and a set of pacers and I respect that. Ultras can be incredible experiences that you want to share with others…but ultimately…it’s your name on the bib.

When you’re out on the trail, in the middle of the night, with no one around you for miles and miles, you’re going to face some hard truths. No one is coming to save you. No one is going to run the next 5, 10, 50 miles for you. No one is going to fix this. There’s no one to blame if you fail. Just you. How are you going to react in that situation?

You don’t have to run an ultra to join this conversation. Maybe you’ve sat in the quiet of your house/apartment late at night, contemplating a tough meeting or an event the next day. Maybe you’re hosting a town hall or Q&A? Maybe you’ve had an outage and you need to regroup? In times like these you’ll make a decision; will I “embrace the suck” or will I deflect and look for an excuse? Will I lean in and own the outcome? Will I take the lumps and learn from it? or will I gloss over it and move on down the road? Another bullet dodged?

Tricking your Tricky Mind

The mind’s a slippery thing - it will look for ways to save face, protect the ego, and avoid the hard truths. At least mine will. To prevent that I play little tricks with myself. Here are some tips I use to maximize my potential for accountability:

1. Burn the Boats: Give yourself no option but to succeed. Remove all scenarios that would allow you to quit. For me, this translates into an accountability post like this one. If I don’t finish I’ll have a lot of humble pie and months of explaining to do. I will try to complete Cocodona…because I have no other option.

2. Fully Commit - you can’t half-ring a bell. Either ring that sucker or don’t. Go all-in. Commit to what you’re going to do and then do it. Fully.

3. Set S.M.A.R.T. Goals - Specific and Measurable are the keywords here. If the goal is fuzzy it’s going to be easy to weasel out of it. Time Bound is also important. Don’t worry about the “Achievable” or “Relevant” - to me these are less important because the goals I get most excited about are where “Achievable” is an unknown.

4. Introspection - take the time to reflect and have a frank conversation with yourself. What did you do well? What went wrong? What could be improved? and how you can make those improvements. Don’t fall into the Excellence Paradox!

Get Comfortable with being Uncomfortable

We can’t exceed previous high watermarks without accepting that Failure is a very real possibility. In some cases, it’s more likely than success. For Cocodona it’s going to be 250miles in the desert and mountains on a course I’ve never seen with no crew and no pacers. A lot can happen—mechanical injury, blisters, nausea, nutrition, salt imbalance, exhaustion, emotional and mental stress. Failure is a very real possibility but I’m excited to experience it all.

Accountability and the Team Dynamic

Accountability is contagious. When you see someone transparently sharing progress and setbacks or speaking openly about something they’re struggling with it permits you to push your own boundaries. Over time you attack larger and larger goals both personally and as a team. When failure is no longer something to be feared the team can be more ambitious. The psychological benefits, including increased commitment and motivation, are profound, fostering a culture where innovation thrives.

Career Progression

Being accountable can significantly impact your career trajectory. Delivery especially at scale is often long and complex. How you show up signals to leaders and peers alike that you are reliable, capable of learning from setbacks, and determined to cross the finish line, no matter the obstacles.

”Superpowers”

When we see others succeed it’s easy to think “If only I was graced with their gifts” - to me, this is a form of excuse. I’ve been writing about these superpowers; “Resiliency”, “Introspection”, “Gratitude” and now “Accountability” not because they’re reserved for the super-human but because they can unlock super-results. They exist in all of us and can unlock incredible outcomes.

Call to Action

What has your experience been? Think about your last setback. How did it play out and how did you show up? Consider setting a goal, ideally something that scares you. Something where failure is not just possible but more likely than success. Then share it with someone. Swing for the fences.

You will be AMAZED at the results.

Understanding the Excellence Paradox

The Dunning-Kruger effect posits that individuals with lower ability at a task overestimate their ability, while those with higher ability underestimate it. I’m a huge fan and active practitioner of the Dunning-Kruger effect! Based on my level of expertise (which is low) I _should_ be very self-critical, but thanks to DK and my chronic over-confidence and lack of humility I'm good! I can feel all of you out there who know me slowly nodding right now.

The Excellence Paradox is a cousin to this concept but focuses on self-criticism. High performers tend to scrutinize their work, decisions and progress much more harshly than those who perform at lower levels. I’m surrounded by high-performers (MH, SY, BW I’m looking at y’all) and I have noticed they routinely kick themselves over silly stuff. Why is that?

Why does this happen? High performers are not just working; they're constantly striving for mastery. They set loftier goals, and with each achievement, the bar rises. I guess this self-critique, while painful, is also a driving force behind their success.

The 98% paradox

When you got 98% on the test, did you bask in the glory of a great score? Or did you kick yourself for losing that 2% somewhere? In my case, it was my family who pushed for the missing 2% and now as an adult, I’m left with a hard-wired inability to meet my own expectations. This isn’t necessarily a bad place to be but it can lead to burnout, anxiety, and never feeling quite "enough." It’s also in my case closely tied to Imposter Syndrome. The good news is I have a great therapist and he’s going to retire comfortably based on the amount of work I need. ;)

The Feedback Loop

Everything moves in cycles and much of life is governed by feedback loops. We’re in a perpetual state of self-assessment, trying, testing, failing, thinking about it, and then iterating again. Introspection is a Super Power but it can turn toxic without some objectivity. This is where feedback from the outside world comes in; seeking out 3rd party feedback can give you some much-needed perspective.

Give yourself the grace to acknowledge the feedback, take a break, and start fresh. They say feedback is a gift, and it might be the one that saves you from being overly self-critical…or madness.

Mitigating the Negative Effects

So, how do we harness the power of self-criticism without letting it spiral into self-destructive behavior?

1. Celebrate Wins: High performers often gloss over their successes, rushing to the next challenge. Taking time to celebrate victories, no matter how small, can boost morale and provide a sense of accomplishment.

2. Understanding Limits: Recognize that there's a limit to what you can achieve at a given time. Accepting that perfection is unattainable and that mistakes are part of growth can reduce the pressure we put on ourselves.

3. Get some Perspective: Look to your mentors - how have others handled similar situations? How does your performance stack up against others? Maybe this can temper expectations down to a more reasonable level.

A Note about the Interview process:

I’ve spoken about how I run interviews in the past and this notion of Introspection and self-study/criticism is definitely something I look for in candidates. Do they move quickly past their successes and obsess over their failures? Maybe not the healthiest thing but it’s another data point and an indicator that a person is on a path of self-learning instead of being happy with the status quo. Those folks tend to do well when given the right support and direction.

Conclusion

How has being self-critical affected your career? or the career of those around you? Drop a comment, share your story, and let's navigate the paradox together.

Leave a comment

The Excellence Paradox is a testament to the complex nature of success. The very traits that propel high performers to the top can also be their greatest challenge. By understanding and managing this paradox, we can strive for excellence without sacrificing our well-being.

Let's rewrite the narrative around success, making room for self-compassion. Accept the 98% with grace and rise above the loss of the 2%.

We can navigate our careers with both ambition and humility, driving towards excellence while maintaining our mental and emotional well-being. After all, the journey is as important as the destination.

The time and place are not important but my team and I had an incredible amount of work to accomplish to meet a critical deadline. We’d worked long hours for many months to develop and launch a brand-new system. Early mornings, dinner at the office, working past when the building air conditioning would turn off, and then a car service home only to turn around and do it again the next day. Weekends too. For months. That’s just what you do early in your career.

This was a high visibility project and we’d been crunching for months to get it over the line. The launch moment came and yada yada yada it was a complete fail. We’d missed a weird corner case that resulted in a highly visible outage right at the critical moment. An absolute gut-punch. The team was devastated and what happened next caught us completely off guard.

That afternoon the boss called a few of us together. We figured it was to discuss corrective actions, ask how we’d missed what we’d missed and maybe to do a mini retrospective. We were ready for that but instead the boss wasn’t interested. He wanted to see how we were feeling. We were exhausted and morale was low. We knew we’d failed and we each individually felt terrible but the boss met us with open hands. He wanted to ensure we were psychologically and emotionally ok. He asked how he could help? He vocalized what we were secretly thinking, that we’d all be fired, and assured us our jobs were safe. This boss acknowledged our effort and made us feel seen. He provided support in our weakest moment and although physically exhausted from months of burning the midnight oil we walked out of there restored, rejuvenated, brimming with confidence and eager to get back to work and fix the issues that had tripped us up during launch.

In the movie “ANGELS WITH DIRTY FACES (1938)” Jimmy Cagney plays Rocky Sullivan, a hardened gangster, tough as nails with no regard for the law. Rocky is adored by the local street kids who look to him as a role model. To a kid with limited opportunities in a gritty New York neighborhood Rocky’s path represents a way out. Rocky is ultimately faced with a choice. Grappling with his natural instincts versus his influence on the next generation he makes a decision in how to behave and carry himself at a critical moment in his life. Go watch the movie, then come back and read the rest of this…

And now the truth; That story I told? That was a lie. Not the part about the deliverable and the months of crunch, that was all true but rather the part about how the boss handled it. That didn’t happen. Let me tell you what really happened. It’s burned in my memory for so many reasons.

After our epic fail the boss pulled the whole team together in our shared space. Not just the leads, but the full team. He closed the door in silence, and then proceeded to unleash the full force of his wrath on us for over an hour. He called people out by name. He threatened firing. He talked about our Visa status! He slammed the desk, the wall, and indulged all his frustrations in a visceral display of anger. He roared. He ranted. He raved. It was performative. We were all stunned and unable to really respond. And he wasn’t interested anyway. That went on for over an hour, to the point where I marveled at the stamina. That’s what actually happened. It was cruel and ultimately pretty sad.

As I watched that boss rant and rave, I went into a disassociation where I could feel myself watching the whole thing play out, outside myself.

To me this was not a display of strength but of weakness. This was a weak person, resorting to their most base emotions. Anger. Frustration. This wasn’t a leader. This wasn’t a professional. This was a privileged man-child flailing about in a position of authority which they had no objective qualification to hold. In that hour they lost the respect of the entire team. Things were never fully the same and I think most of us decided to leave the team and company in that moment.

I decided to rewrite this moment in my life and reverse it. Like George Costanza; what would that moment have been like if they’d behaved the EXACT opposite of their instincts? What would’ve happened in the days and weeks thereafter?

There is a Lesson in Everything and as much as we learn good habits through experiences we can also learn the opposite; What NOT to do. How NOT to behave.

I won’t say I’ve never lost my temper or been frustrated in life or work, I most certainly have. I’m a work in progress. To steal from my friend Taq; “frustration is natural but we ought to be frustrated at the problem not the people.”

Life is hard, projects are challenging and involve risk and sooner or later things go wrong. When they do I try to keep that boss in mind. Reject your base instincts. Find objectivity. We all want to succeed but it’s up to the leader to own the failures and protect the team because just like in the movies, people are always watching.

P.S. Go watch “ANGELS WITH DIRTY FACES (1938)” - James should’ve won the Oscar.

It’s simple. Find the right moment, pull that person aside, look them in the eye and….say ”thank you”. That’s it! That’s all you have to do. You can stop reading now. Done with sincerity the results will amaze you.

About 4 years ago, I made a commitment to lean in on gratitude, and it has been a long overdue breakthrough for me frankly. I have discovered that saying thank you, is a powerful tool and one too often goes underutilized in a my arsenal.

Why was this such a revelation?

I was raised to judge things. Show me something you did or achieved and I’m going to pick it apart almost immediately. This isn’t conscious on my part, I guess it’s just my default behaviour or something I picked up from those around me. (True story when I was a kid I got a 98% in Leaving Cert Honors Math and was asked “what happened to the other 2%?” - this literally scarred me for life).

I used to think my self-worth was somehow linked to how well I could cast judgement on things. I thought that by judging, or “providing feedback” as I learned to call it I would somehow:

1. Demonstrate my understanding - I will prove that I’m intelligent and knowledgeable and that I know what’s going.

2. Justify my leadership - Surely by providing some insight I can demonstrate that I have a lot of experience and am worthy of my leadership position.

3. Encourage the person - I can “encourage” someone to reach new heights by providing more ideas, thus simultaneously endorsing what’s been done and building upon it to go even further.

These are easy traps to fall into but I’ve come to realize when someone delivers on a milestone what that person really needs to hear, myself included, is “amazing job, and THANK YOU”. If you are hiring the right kinds of people, that’s generally all they’ll need.

As a leader my responsibility is to help teams avoid pitfalls that I’ve encountered previously so in those situations I try to make a point of separating the conversations - leading with gratitude and then following up with additional guidance.

Behold the Benefits of Gratitude!

Saying “thank you” is magic in many ways. When you express thanks either in a 1x1 or public forum, it validates that person’s efforts. It means “I see you and I appreciate your effort”. When you celebrate the person publicly it “Sponsors” them (that’s another super-power you have, more on this in a future post).

Gratitude works 1x1, remote, in public or in private. The recipient doesn’t even have to be present! I will shout-out someone if I think it’s warranted even when they’re not in the room as a means to have their contribution recognized. It also sends a message to the org - that good effort is recognized and appreciated. It’s harmless, costs nothing but it can be meaningful.

This past week in the USA was Thanksgiving. In 2022 we started a slack channel internally named “#thankful2022” and solicited everyone in the company to drop a message celebrating someone for whom they were thankful. The response was incredible and the good vibes flowed all year through. I’m happy to say this tradition continued into 2023, the channel is new, “#thankful2023” but the idea is the same. It’s a simple notion that maybe you can pioneer in your org?

Life is multi-dimensional and complex. It’s taken me far too long to figure that out. Everyone’s dealing with much more than what you realize and far more than what they bring to work. A simple act of gratitude, however trivial can change a person’s entire day. I hope you’ll try it and see what happens.

Thank you for reading!