Last year only very early adopters had a coding agent on their desktop, so the way you had to connect AI with your product was to build it in. That is no longer the case. While the vast majority of people still only have Claude or ChatGPT that they interact with regularly, it is becoming clear that what they want is more connectivity for that agent - not 40 different agents to interact with.

This is arriving as people using a coding agent for all kinds of non-coding uses.

Maybe you haven’t arrived here yet, so let me paint the picture about what local agents on my desktop do for me:

• Run a small business, tracking projects, tasks, deliverables, calendars, email, and helping us all prepare for our day by pulling together any information we need.

• Fetch and send signals between my co-workers agents to assign tasks, share new information, distribute software updates, debug software problems, and have agents work synchronously together on problems.

• Perform constant gardening on a repository of thousands of documents including transcripts, research, writing, proposals, product designs, strategy, etc. Each new piece of information arrives and gets synthesized and integrated.

• Allow us to operate effectively as a fully remote team with very few meetings and largely asynchronous communication - but everyone is able to keep up with what everyone else is making progress on.

This list goes on, but these aren’t things you do very easily in ChatGPT or even Claude Desktop until very recently with CoWork - though even CoWork just barely manages some of these. More sophisticated flows like this become possible through a combination of better context, connections to external tools, and the magical capability that coding agents have to extract knowledge from files on a filesystem. Coding agents like Claude Code, Codex, Cursor, Opencode, and others give an LLM eyes, ears, and hands - the ability to see your files, consume your context, and take action on your behalf.

The Impact of giving agents eyes, ears, and hands

I first started seeing this when we hooked claude code up to Obsidian to operate on my notes. Now anything I researched could be easily saved, iterated on, metadata could be used to differentiate types of data. Then I started adding in other types of data - web clippings, transcripts, strategy ideas, voice recordings. Then we shared the vault across our team, we set up agent to agent signaling, information hierarchies, decision records, runbooks, agent identities and protocols.

This all became possible because we had an extensible system that we could work with an agent to manipulate. Agents are great at writing code, but they are also great at helping you think, and to help you think they need access to the same information you are working with.

All of this information comes in through a variety of channels, often locked away in systems of record. Extracting and centralizing that information makes agent access easy. Whether centralized or not, having an agent reach across all those channels and work from a common repository of context is a pattern we are betting drives huge unlocked functionality this year.

Do you see what I see? Yes, my agents do.

An agent hostile world will need to evolve

For decades, the Internet has fought against bots scraping websites for competitive purposes and now we’re on the verge of a complete 180 degree shift. For my part - if I can’t interact with your product using an agent, and especially if I can replace your product with a few days of development effort, I’m not paying you money.

Andrej Karpathy tweeted recently about his experiences using a local knowledge base with agents. He does a good job of describing the capabilities here, and how different it seems than using an agent that’s locked away in a closed system. He’s only describing the most basic form of this.

Basecamp just announced that they’re opening up Basecamp to agents. Not building AI into the product. Not selling you a new tier of product where they pay for the inference. No, they are simply extending their system to make it easy for agents to use. They are in the minority right now, and I’ll be interested to see if people migrate as a result.

37Signals believes, just like I believe, that the agent embedded in the product - while potentially useful in some niche situations - is largely a failed experiment. I have an agent tuned for my way of working, connected to all the tools I use. For your product to be useful to me, it needs to be one of those tools. If I can’t do that, then you are limiting the capability I have to use your product.

The Agent Native Registry has audited nearly 1500 tools in the SaaS space. Here’s their key takeaway:

Nine out of ten tools score below 40. No tool on the market scores above 58. The biggest bottleneck isn’t pricing or documentation — it’s authentication and discoverability. Most tools were built for humans clicking through browsers, not agents calling APIs.

Improving Human and Agent Collaboration

This last week I opened up our internal doc collaboration tool to agents using a CLI and some API updates to make agent enrollment easy. It wasn’t that hard to do, but immediately the new possibilities became apparent. I can move a doc from anywhere to this app and collaborate with my agent and my team on it. I can make comments, have my agent review those comments, it can respond to my comments - we can actually collaborate. All this without copy/paste.

I’m able to move beyond reviewing files in markdown, toward excellent UX and agent integration.

Oh, by the way: the CLI to interact with that new capability, the instructions and skills our agents use to interact with it, all the setup was distributed asynchronously to our team agent to agent. I spent about 10 seconds asking the agent to craft instructions, my co-workers spent a few minutes working with the agent to get auth setup, and they were done.

Our shared context infrastructure has become a new way to distribute information, instructions, software, tasks, and constantly keep others aware of what’s happening. This is becoming the primary way that we share information.

We are also working on desktop experiences that bring this same idea to how you collaborate with other humans. The GUI isn’t dead, but its purpose is not to present you with a text box, nor is it to provide you with controls to do something your agent can do. Now you need to collaborate with humans and agents, and the expectations of that paradigm are rapidly shifting.

Old collaboration platforms are broken

“Can’t you do that with Google Docs?” you might ask. Yes, you can also eat rocks - just ask any 3 year old.

Google and plenty of others have made it as difficult as possible to connect an agent to their tools. Tools like gog exist to try to simplify this but my god - this is not the way. A variety of other properties who want you to stay in their ecosystem have all made agents difficult or impossible to use with their systems. While they’ve done this, they’ve provided AI features that are about as useful as Siri at helping me get my daily work done. A brain in a jar - no eyes, no ears, no hands.

Do you see what I see? No, they do not.

New platforms are emerging

My bet is that composable, local-first, extensible systems that leverage your ability to extend software to work the way you want it to work are going to be the future. This is how I’m operating, and I’m rapidly ending subscriptions for anything that doesn’t play in this ecosystem.

If you’ve been using ChatGPT, Claude, or even a coding agent, and feel like you should be able to collaborate more and would like to change how you are working - please reach out. We will start sharing more about what we’re doing in the near future but for now - happy to walk people through it on a call. For those of us with busy lives and scattered brains, these tools are incredibly powerful. For teams who want more time to focus and less time in meetings, these tools can unlock some of that. And for organizations who want to move faster and have their organization operate more in unison, this will become an important tool in enabling that behavior.

Reach out if you’d like to learn more.

Subscribe now

Leave a comment

• Obsidian hasn’t developed more powerful AI features.

• Obsidian hasn’t added any killer features that I was missing.

• Obsidian’s plugin ecosystem hasn’t gotten any better.

The killer feature - extensibility - has been there since the beginning, but AI coding agents have unlocked access.

• I can run Claude Code, Gemini, Codex, and any other agent I want on top of my entire Obsidian vault.

• I can use Claude Code to author Obsidian plugins to do whatever I want.

• I can make Obsidian the central nervous system of my workflow - hyper-personal and fully automated

I can now make this platform do exactly what I need it to do, and I don’t have to worry about whether it works for anyone else.

AI coding agents have changed my relationship with the software. I no longer look for the most complete or polished application. I look for the one that will give me maximum ability to shape my own experience by building inside of it.

When I can’t find a tool with that flexibility, I build it myself. Agency and control are the new feature foundations.

Designing My Own Workspace

In the last few weeks I’ve built a handful of applications I needed:

• A call transcriber that listens to system audio, performs real-time transcriptions, and lets me chat with those transcriptions (Yes, just like Granola)

• An Obsidian plugin to sync Zoom transcriptions directly into my vault

• A tool that inventories my test suite and helps me understand and refine it

• A worktree management tool that launches containers for isolated dev environments (yep, there are tools, I wanted one that didn’t exist)

None of these are particularly novel ideas. Transcription tools exist. Ways to export Zoom data exist. Test management tools exist.
What has changed is that, in the time it would take me to find an imperfect tool for any of these things, I can often build a perfect one. All that searching, testing, potentially paying for a tool I don’t use… all of that goes away. Not for every use case, you still have to make a build vs. buy judgement - but I’m finding for many situations, the tool I can build is preferred.

And I have full control over it. That’s the part that matters.

Control Over Compromise

The call transcription tool is a good example. I’ve been using Granola for a while now and I really like it, but my transcripts are locked away inside Granola and I have limited control over what I can do with them. I can pull them into Obsidian or Notion, but that’s not actually where I always want them - it depends on the context. Granola also insists that people in this world only have one context for calls - business - a fundamental assumption that doesn’t apply to me.

I wanted to control what happened to the transcription after a call ended. I wanted to control the quality of the transcription. I wanted to be able to take action on the transcription during the call - something I could never do with a tool like Granola until they built that feature in. However, in an afternoon, I had a functional transcription tool that ran in my terminal and could be extended easily.

I might be the exception here, but I am not super keen on waiting for the rest of the world to figure out how I should be leveraging AI in my life and tools. I’d like to be exploring now. In order to do this exploration, I need to be able to use AI to extend the tools I’m using.

The Economics are Shifting

I have a complex application with a flaky test suite. I got tired of fighting with it.

So I built a tool to inventory my entire test suite. It runs each test and tells me how long it takes. It explains why each test exists and what it covers. It walks through the flow of the application that each test reproduces. I can ask it for whatever I want, and then tune my test suite based on that information.

Here’s the thing though, I have no idea if a tool like this already exists. I didn’t bother looking.

That’s what is changing. The economics have flipped. If something seems like it’ll require searching, evaluating, and potentially paying for, I’m just going to try to build it first. If I have a hard time building it, then maybe I’ll look for commercial software. That’s the opposite of how this would have worked even a year ago.

The Application Inside the Application

For people who are already working in codebases, there’s another layer to this. Within my more complex applications, I’m building sub-applications:

• A tool that shows me the design system components and color palette available

• The test inventory I mentioned earlier

• A CLI built specifically for AI agents to interact with my Linear ticketing system

I can build control surfaces directly into the repository I’m working in as tools specific to that codebase, without integrating external solutions. Maybe that’s wasteful if there’s a great tool I’m not using. But I’ve been burned more times than I’ve been saved by pulling in outside tools, it’s just not hard to build my own.

Over time and at scale, these tools become more commodity, I know that, and using your own special thing becomes a liability. But I’m operating mostly solo here, so personal friction reduction is most important to me right now.

The Invisible Software Stack

Here’s what I think some people are missing about AI coding agents: there’s an entire class of software being created right now that nobody sees.

This isn’t new in the development community. Developers have always built personal tools. But now it’s spreading to product managers, to people who traditionally would be less technical. They’re building up inventories of software they’ve made for themselves. Maybe some of it gets shared, but most of it won’t work for others because it was built for a very personal purpose.

This software is invisible because it’s not released. It’s not on Product Hunt. It’s not in app stores. It solves one person’s problem in one person’s context, and that’s enough.

A Different Way of Looking

AI coding tools aren’t just about building apps faster or replacing developers. They’re about agency. The ability to control your own tools instead of waiting for someone else to build what you need. The ability to fix what’s broken instead of working around it. The ability to approach problems you would have ignored because the solution didn’t exist and building it yourself wasn’t realistic.

Right now, this probably works best for relatively simple applications. But the line of what’s “simple” keeps moving. And the fundamental shift: that you can be the one who solves your own problems, well, that’s already here.

What are you building?

Have you solved something for yourself and only yourself? Have you built an app inside your coding project?

Leave a comment

Subscribe now

Next week I’m going to return to a very different role, a very different career, and a very different path. Our industry is shifting, and I wanted to approach that change from a different perspective. To do that, I had to make some changes.

Earlier this year I was leading the largest organization of my career as a Sr Director at Workday, overseeing engineering teams across both our Financials and Professional/Business Services pillars. This organization was composed of 6 major product areas across two group GMs, and I was honored to have had the chance to take on this multi-industry and multi-product engineering area. Supporting these teams and leading this area was a huge growth experience.

By all accounts my career was on the right path, but something felt off. At first I thought that I needed to shift my mindset about the next stages of my career, to get more comfortable with the demands of a growing organization. As I worked with a coach and talked to others about what I was seeing, feeling, and getting energy from, the path forward became more clear. To really address what I was sensing, I would need to exit this career path and go another direction.

What I’m seeing

Memorial Day 2025, the weekend after the release of Sonnet 4, my personal experience building with AI turned a corner. That weekend I shifted from arguing with Sonnet to cranking out features. Feature after feature fell into place and just worked. By Sunday night I was out of ideas. It felt to me like a switch had flipped and building with AI became completely viable. The only thing that had changed was a model version.

Overnight, with a single model release, an entire product category of AI coding agents gained new capabilities. I hadn’t written a line of code in over 8 years, but here I was building functional apps in a weekend. In the coming weeks I built another, and another, and suddenly found myself distracted in my day job by what I was going to work on when I got home. My evenings and weekends became consumed by building, learning, and trying to understand how to harness these new tools.

This step change would happen a few more times in 2025, and each time we are able to do things one day that we couldn’t do the day before. This reminded me of when I started in tech back in 1997, the Internet was new and technology was moving fast. To keep up you had to be resourceful, hungry, and take your own initiative.

To take your own initiative takes energy and time…

What I’m feeling

While I spent my evenings and weekends cranking on apps using every AI tool I could get my hands on, something else was changing. Our workforces were shrinking and companies were rapidly expecting AI to improve the bottom line for them and their customers. Talk of AI replacing jobs gave way to actual layoffs. Whether or not these two things were related doesn’t matter - the trajectory became clear to me.

What I was seeing in my own use of AI made me increasingly uneasy about being a manager of hundreds of people. I wasn’t very worried about whether or not I’d have a job - I was worried about what that job would be. How many people would I be responsible for? How much connection to those people would I have? How would our drive for efficiency re-shape what it meant to be an organizational leader? My hypothesis was that I would be expected to lead a flatter organization, with less operational support, less leadership support, and more interrupt-driven work than ever. While coding with AI had felt revolutionary, the tools available to leaders operating a large organization were not experiencing this same pace of advancement.

My daily experience became an energy drain. My pessimism about the future of roles like mine, combined with an insatiable pull toward returning to a maker’s life - building and shipping things - made daily work more difficult. More than anything else I wanted to learn and experiment and build and ship - and doing that while holding up a day job leading a large organization felt incompatible.

What seemed inevitable to me was that the shape, size, operating model, and basic principles of running organizations would need to change in dramatic ways. I am deeply interested in exploring this, but that option is rarely available in large established organizations. These ways of working haven’t been written yet, and the exploration of what’s possible is mostly taking place in small teams and small organizations.

So, after careful consideration, I blew everything up…

What I’m doing

Next week, I return to a part-time IC role at Workday after a six-week sabbatical. Aside from one week spent on vacation, I spent the other 5 weeks of this time building a new business. You can see the beginnings of our ideas at nodaste.com. The site is very light on details, which is probably the biggest story here, we don’t know exactly what the world needs from us yet.

What has become clear is that tiny teams have a lot more oomph than they did this time last year. I’m grateful to have 3 partners who round out a very capable set of experiences and skills. We enjoy working together, we care about doing that in sustainable ways, and we care about helping others in the process. That’s really all I need to get going.

In a very real sense, we are getting lost for a reason. With these tools, the pace of learning is magnified so much when you are outside the constraints of the corporate world. While corporate policy and structure serve important purposes, rapid experimentation and access to the latest emerging tools are not their strengths.

What’s next

We are deep in discovery mode, connecting with as many people as possible about what they are experiencing in their own organizations as AI comes charging in. We’re exploring different approaches we could take - from providing professional services to building and operating our own products.

You’ve read this far, maybe you have thoughts to share that would help shape this.

Over a few short months we’ve proven to ourselves that we can build and ship products. We’ve proven that we can operate an organization in new ways with new tools, and we’re convinced that these tools are going to re-shape organizations of all sizes. We’re excited to work with teams on that journey, figuring out together what the future looks like, and my goal is to write about what we find as we go.

There are so many things that I don’t have answers to, and I think that’s what excites me the most. This book isn’t written, the playbooks are all out of date, and we’re going to have to work together to navigate the future.

Synchronicity

I asked a friend to read through this and she pointed me to an article from Ryan Martens published earlier this month: We Sit At a Precipice Between Systems . I have deep respect for Ryan, I learned a lot of what I hold dear about how humans can work together from working at one of his companies - Rally Software. In this article Ryan writes:

Today, something rare is happening. We sit at a precipice between systems: an old system in which human intelligence commands instrumental technology, and a new system defined by the interaction between human intelligence and superintelligent technology.

It is at this threshold that systems thinking doesn’t ask us to make incremental tweaks to the existing system, but rather to leap into the new one. In the old system, we adjust the variables of a known game. In the new system, we discover new, unknown games. In the old system, we accept and work within the established rules. In the new system, we help shape the future rules.

In new systems, the difference between those who thrive and those who flounder is one thing: the ability to take responsibility.

This nicely describes that anxiety I felt earlier this year to jump into this new system with both feet. Ryan made connections back to that period in the late 20th century where it seemed clear the world would never be the same. We are there again, and I’m here for it.

If you too are jumping in with both feet and want to connect, I would love to hear your story.

If I asked you to build and deliver a product with AI, would you tell me you aren’t technical enough? Would you tell me that it’s an intimidating process, or that you would need help from someone more technical? I think AI gives us an opportunity to re-frame this mental model of what we are and are not capable of - and I’d like to challenge you to re-position your strengths.

There’s an odd focus on “technical vs. non-technical” in the software industry, and we assign one label or the other to roles. Product Managers aren’t technical (except, they are), and Engineering Managers are technical (except when they aren’t). I don’t think the binary framing is accurate at all, and I think it’s getting in our way as roles shift and AI moves into our organizations.

I always thought of myself as someone who just had enough other technical people around him to figure stuff out - to “fake it”. I was coached into my first job in tech, later being told by my manager that they weren’t sure if I was going to work out - but that I had learned quickly and was doing great. I would be accused of being “a sponge” with technology, when in my eyes all I was doing was remembering stuff and playing with it.

This extends even to recent history for me, spending nearly 8 years in management without touching code and still being told I’m one of the more technical leaders. This accusation could not have come from my experience with the frameworks and technology that we were using - I had never used them myself. Instead, it came from my mindset about how I approach learning, being curious, supporting others, and my own accountability for being able to participate in decision making.

AI is re-distributing experience

Building with AI is a new beast - and it is a massive equalizer if you are willing and able to see it that way and leverage it. The difference has never been smaller between someone developing software their entire career and someone who has never touched code in their life. It’s true that seasoned software developers know better what good software looks like, and perhaps can better steer a coding agent. But, do they know what good product looks like? Good design? Good UX?

Understanding technology is not the hard part anymore. The hard part is making decisions about what is and is not useful to others. What makes a product delightful to use. How to understand how your users are interacting with the product. That has always been the hard part.

Taking advantage of this moment is about seeing obstacles as opportunities, about taking the time to find a relationship with technology, and re-framing how you see yourself. There are absolutely new skills required to build successfully with AI, but those skills aren’t hidden away in a university degree somewhere or a book you haven’t read, they’re sitting right there in that AI Agent you probably use every day.

You have a tool now that will answer your most basic questions about how software development works, without judgement. This tool will build software for you, sometimes well, sometimes badly, but with persistence it will get you to functional software. It’ll review it’s own software, it will help fix it’s own mistakes, and if you are willing to be curious - it will teach you what you need to learn.

What makes people “technical”?

I’ve been thinking about what actually earns someone the label of being technical, and I don’t think it has anything to do with technology. It is perhaps similar to what makes someone seen as a writer, or a mechanic, or a leader. It is embodying what others see and expect from that role - that’s it. Writers write - we can all write, but they write in ways that others see, that meets a certain bar, and they do it repeatedly.

What do people you’ve thought of as technical do to earn that label in your mind? Do they always know the answer? Or are they curious about a problem and willing to invest a little time in trying to understand it better? Sure, over a long career of being in technical roles, you accumulate understanding that’s available immediately - but a lot of that knowledge is available to all of us now. The same thing happens in Design, or Product, or Sales, or Leadership. Each domain has knowledge that accumulates over time.

The problem I have with declaring someone technical is that it really doesn’t say anything about what they know. Are they technical in a particular language or framework? Have they worked with frontend or backend? What about mobile software, or large high performance clusters? Hardware or software? It doesn’t say anything about their experience. And yet, somehow, it makes those without that experience feel like there’s a barrier there they can’t step across.

There’s no barrier, just get curious and start exploring.

You are technical

I think if you search in your own experience you’ve learned a new skill that you didn’t have at first. This skill, when you first approached it, was difficult and full of challenge and frustration. But you got curious about it, you accepted that there was some time investment needed to become good at this skill, and you put the time in to experiment, practice, learn, adapt, evolve, and eventually you became better at the skill. Maybe you did this because you had to for a job, or maybe you did this because you enjoyed the process, or because you wanted to be around the other people who were doing this.

This willingness to approach the challenge and work through the learning process is all you need to build software with AI, to become technical. What’s new is that you have a relatively inexpensive tool that can answer a LOT of the questions you might have about how to build software, how to design software, and how to get un-stuck. It’s not quite the same as having a trusted friend that you can go to, but if your obstacle is understanding how to navigate a problem - the robots can help.

Getting support beyond AI

What I’m observing right now is that many people are building in isolation. This world of AI makes you feel like everyone around you is ahead, they’re all cruising and building hundreds of apps and shipping every week.

They aren’t.

While a few may have found a recipe that works for them, what’s likely is that they’ve accepted a tradeoff they aren’t talking about. Building with AI is not easy, it’s not magic, and while it provides the illusion of available velocity - the trick is to actually move slower than you feel like you should be able to move. Be thoughtful, experiment, play, and take time to think about the experience you want to build. Anyone can skip that step and just build - writing code is now the un-differentiated part of building software.

You may still get stuck, and I think we need more communities of builders who are working together to support each other. We need to share techniques, help with basics of getting started, and support people through all the other parts of product delivery that an AI Agent can’t do for you. If you are building a community like this, or if you are interested in joining a community like this, please reach out - I’d like to make that connection.

Make it human

Context is everything, and the thing that will make you good at building software will be how you think about quality, taste, and the effort you put into weaving your unique style into whatever you build. This has very little to do with a technical background. In fact, I’d argue that feeling like you are experienced at building software will cause you to focus on the building and miss out on the thinking. The further from software you are, the more likely it is that you are going to bring something unique into the world.

So, go build something, and if you feel stuck please give me a holler - I’m happy to help.

Subscribe now

In recent years I've come to appreciate the art of listening as a collaborative act - one that, when done with care, can help influence and shape the ideas being heard.

Brenda Ueland wrote a short essay, The Art of Listening, that opened my eyes to just how powerful this can be:

Who are the people, for example, to whom you go for advice? Not to the hard, practical ones who can tell you exactly what to do, but to the listeners; that is, the kindest, least censorious, least bossy people you know. It is because by pouring out your problem to them, you then know what to do about it yourself.

... you then know what to do about it yourself. That's what we all want, isn't it?

Listening is a skill to be developed

I am not a naturally good listener. Over the last decade, I've put focused effort into improving. I've learned to be more curious, more quiet, and more interested in the needs, challenges, and objectives of others. I've studied ways to ask questions that get people talking, keep them talking, and rapidly build rapport. If you have worked with a good leadership coach then you've seen some of this in action. But there's more available.

Coaches tend to go only so far, their job is to keep some distance. They are there to help you explore your ideas without injecting much of their own. I've recently come to appreciate a more... entangled form of listening. Something more like improv, something more vulnerable.

The anti-pattern, the listening offramp

We've all had the experience of carefully weaving a story to pull the other person into our inner circle, to share the thing that we just cannot get off our mind. We hope they'll intensely validate our idea and go deeper on this journey with us.

They listen, quietly, and then when you finish they respond. "Yeah, I had a similar idea... let me tell you about it…"

And now the mic is theirs. The topic moves on, and the moment passes.

Crushing.

There's another way.

Three Techniques for Collaborative Listening

Yes, and…

Have you ever watched “Whose Line is it Anyway”? One person declares she is going to ride a jet ski, and without hesitation the other person becomes… a jet ski. Improv is all about expanding on the lead of others and never rejecting the ideas that come up. Improv is generative, producing ideas quickly - like rapid brainstorming - and it requires total focus on the situation as ideas emerge.

A key component of improv is the "yes, and…" - this idea that whatever the other person starts, you continue, you do not negate, you pull the thread and extend it along. You are saying “I agree, and let me expand on that idea with another thought”.

Applying this at work and as a leader

I stumbled upon this at work with a friend and co-worker, and realized we were doing something similar. We would begin to talk out an idea and the flywheel would get spinning in a way it didn't with other people. We moved fast through developing ideas, and it was expansive and generative, and the idea would blossom or hit a dead end more quickly than usual. What I noticed most was that we kept each other on task - we stayed with the idea - we developed it together. But it always started with one person sharing something new.

Here’s what this might look like:

A: “Hey, I was thinking about this idea yesterday… <describes their idea>”

You: “That’s really good, and if you took that a step further you could…. <add another angle>”

A: “Oh, yeah, totally - and with those things, you might be able to … “

You: “Nice, yes, and what about xyz? Could that add something here?”

In my post on Six Leadership Principles, I wrote about how I see listening today, as a collaborative act, based heavily on this experience:

Think of your own ideas as fuel for entering relationships, currency that you exchange for other people’s ideas, and in this process your ideas are consumed - burned in the flames of collaboration to become something else. They become a new idea that was only possible because of the chemical reaction that happened between two ideas that needed each other’s fuel to become great. The oxygen for this combustion to occur is curiosity - without it, both ideas remain potential energy that can’t ignite.

I've used "yes, and..." with others when they share an idea with me that I want to help them develop — it's a powerful listening tool. Once you begin modeling the behavior, it's very natural for the other person to follow.

Tell me more

Another powerful phrase is "tell me more" - this can be a statement, but it can also be a mindset. During one of these conversations, this statement rolls around in my head - like it's painted on the walls.

Tell me more...

Tell me more...

When my mind distracts me with a response I want to inject, or an offramp from the present conversation I want to take, this statement brings me back. Tell me more...

This statement also gives permission when said out loud. It tells the other person "I'm here, I'm listening, keep going" - tell me more.

I use “tell me more” when it seems like the other person hasn’t completely unfurled their idea. I don’t like to make assumptions when I’m listening, and this request usually provides much more detail about what they are thinking, helping me follow their trail more closely.

What matters most to you?

The first time I was asked "What matters most to you in this situation?" I was stunned - I didn't have a response. I hadn't thought intentionally about what mattered most to me, and it took a fair amount of reflection to settle on a point of view.

We often move through life looking for external validation from others about our ideas - but what matters to you about your idea? Are you asking yourself that? Is someone else asking that question for you? Are you helping others think about that for themselves?

What's most important about this question is that it is asked, and that the thought process happens, not so much what the answer is.

I use this when someone has shared that they have options, and they seem to be looking for help weighing those options. Asking what matters most is a way of getting at what’s underneath their desire to pursue any of these options. What’s important? I also use this when other leaders ask for my help: “Happy to help, can you tell me what matters most to you about this?”

Advanced Technique: Naming the Elephant

There's an elephant in the room and it's hard to talk about. You think there's a lot more available to talk about if you could stop dancing around this topic, so you need to ask permission to name it - describe it - and get feedback from the other person about whether you are on track.

Name the thing: "I'm picking up on something, and I want to hear your perspective about what you would call it, but to me it seems like..." or "I'd like to say this out loud, and I would love to hear your perspective on it...". When you’ve opened the door on this topic - go back to listening.

This is still listening. You hear something worth talking about, and you need to steer the conversation toward opening that door.

I use this when I sense something going on that needs to be out in the open, and I want to make it safe to talk about. Be kind with this approach, if you confront the topic and there's still resistance - move along to something else. Interrogating is not listening.

Closing Thoughts

Some of the most meaningful conversations I’ve had as a leader have been as the listener, using these techniques and watching another person’s ideas blossom. In a world of increasing isolation, deepening every human interaction is worth your time. These techniques make conversations more interesting, they make you more interesting as the listener, and they improve outcomes for everyone you work with.

These techniques also translate in powerful ways to our digital interactions as well, bringing humanity to Slack conversations and video calls.

Further Reading

The Outward Mindset - The Arbinger Institute

This book describes how to shift your mindset toward the needs, objectives, and challenges of others. It has had a profound impact on how I approach others.

You're Not Listening: What You're Missing and Why It Matters - Kate Murphy

This book confronts the challenge that our world isn’t structured to encourage good listening behaviors, providing strategies and mindsets that help you improve how you approach everyday conversations.

The Coaching Habit - Michael Bungay Stanier

How do you bring a coaching practice into your daily leadership conversations with your team? This book helps you do that, and more.

Subscribe now

Leave a comment

Do you set the pace? Do you set the standard? When an ambiguous request arrives at your desk, do you wait for others to figure out what it means, or do you go figure it out yourself?

Setting the pace can be a massive differentiator in your career, allowing you to navigate uncertainty by having some control over how work gets done. There is tremendous power in controlling the narrative, shaping the story, and clarifying a situation. At every possible step, you want to practice being that storyteller.

When you let others make the first move, you are leaving an opportunity on the table to demonstrate your leadership capability, give your team an advantage, and strengthen your relationship with your peers.

In this post, I want to talk about how being a first mover can present a strategic advantage, how you can leverage that advantage, and what risks to watch out for in that process.

Ambiguity as strategic advantage

The more senior you are, the busier your manager probably is. Your manager has their attention spread across many areas, and an important job that you have is to help make their job a bit easier by taking things off their plate. So when you get that request that clearly hasn't been thought through, take a step back and think through one question.

How could you be first to clarify this for everyone else who has to do this task? How could you shape the narrative?

The act of coming out of the gate first with a point of view on an ambiguous request has a number of advantages. Strategically, it allows you to apply some influence over the outcome. It also allows you to show up for your peers and anyone else who is struggling with the request. It could also provide an opportunity to connect with others across the company.

Most importantly, for anyone looking to continue to grow in their career, it demonstrates clearly how you navigate ambiguity. This capability is often referred to as "ambiguity tolerance," and it's a key attribute of senior leaders. When these little challenges appear, it's an opportunity to demonstrate your ability to grow in your career.

Pathways for clarifying ambiguous requests

We are all smart and resourceful people, but it's easy to be swept up in a moment of frustration over a poorly formed request and forget what's available to you. This technique works better when you have a good network of people who are open to helping you with challenges like this.

A few questions to ask:

• Who besides my manager could help me clarify what needs to be done?

• How are my peers handling this request?

• What are the consequences if I just take a point of view and get it done?

Most of the time, the risk of an incorrect point of view is low. Put yourself in your manager's shoes - what are they likely needing here? You can reduce the risk of this by working with your peers and others around the organization who aren't your manager to come up with an answer.

Validating your approach

How do you know that the approach you came up with is what your manager intended? You tell them what you intend to do and gracefully accept the feedback when they steer you in a different direction.

In the book "Turn the Ship Around" by David Marquet, the consequences of a crew member taking an incorrect action could be fatal. Despite this, Marquet needed a way to empower the crew to make their own decisions about actions to take and have those decisions validated by others. The mechanism they used goes something like this:

Instead of the traditional exchange:

• Crew member: "Captain, should I dive the ship?"

• Captain: "Yes, dive the ship."

Marquet implemented the "I intend to" approach:

• Crew member: "Captain, I intend to dive the ship."

• Captain: "Very well" (if he agreed with the decision)

I have used this behavior throughout my career to validate my approach without asking for permission. There is an implicit expectation in the request that if I'm doing something wrong, you are going to intervene, but if you do nothing I'm going to proceed. My manager only needs to expend energy if I'm wrong.

This same approach works here: describe how you intend to address the request and if there isn't pushback, make it so.

Move first on clear requests too

Even when the request seems to have a clear ask, there’s value in being the first to respond. Getting a quick response to your manager helps them know if the request matches their intent. If their intent was different, all of these practices and advantages apply as well. You get an early opportunity to shape the correct response, help your manager clarify their ask, and support your peers in the process.

I coach everyone I work with to respond to their manager’s requests as quickly as possible. Don’t cede the first mover advantage to your peers. Whether the request is straightforward or a complete mystery - be the first to respond.

Cautionary note

This approach does require some good judgement on your part. Here are a few things to watch out for:

Don't expose your manager's ambiguous approach to their peers or leader

Some situations might be tempting to just go ask your manager's peers for clarification. After all, it's not your manager, and they probably got the same request. Keep in mind that you are exposing this aspect of your manager's style to that peer - and they may not appreciate that.

Be careful about breaking confidentiality

Consider who else should know about the request and don't over share in the interest of figuring this out.

Sometimes your manager will want to be the one to clarify

You'll have to figure this out over time, but sometimes your manager will want to shape how this gets done. You might find out because they push back on your request, or it might be more their style to specify the approach. You'll need to judge when doing this yourself is right.

Summary

When you take initiative in the face of an unclear request, you benefit from stepping out in front of the pack to help your peers, your manager, and your team. This opportunity to collaborate with those around you to move action forward can have long-term strategic advantages for your team, your reputation, and your career.

To summarize:

• Respond to ambiguity with a point of view, be the first to drive clarification

• Carefully consider who can help you clarify the request

• Use "I intend to" as a mechanism to pressure test your approach

• Respond to feedback and redirects with grace and gratitude

Just be careful — this approach might make you look like you are ready for the next level.

Share

Leave a comment

A challenge you run into in most organizations is getting high fidelity context distributed across the organization quickly and effectively. How quickly you distribute information can have real impacts on how well your teams navigate rapid change and uncertain times. One of my main principles is to distribute context and decision-making - and one of the primary tools I use to do this is the Week in Review.

In this post I’ll describe how I organize my Week in Review, the different formats I’ve used in the past, and some of the things I’ve leveraged the document for. You’ll want to customize this for your team, org, company, and mission - a few examples are provided below.

What is a Week in Review?

Think of the Week in Review (WiR) as an opportunity to share context across your teams. A lot of the topics I put in my WiR are things that I might bring into a staff meeting or share via email. The intention is to collect and distribute context that is useful to my directs and their teams in as timely a way as possible.

You can make this document as light or heavy as you’d like depending on your organization. The most important outcome is that you are passing along context to your team in a timely manner that helps them make decisions and get involved in the right conversations.

Why maintain a Week in Review?

Besides distributing context, which I think is reason enough to do this, there are a number of other benefits to this practice. Here are a few surprising benefits I've found:

• Awareness: The act of putting this together each week helps you build awareness of what's going on across your teams. You are sharing context, but you are also mining it and keeping an eye out for it because you know you will want to share it.

• Engagement: Some team members engage with the written document more actively than a staff meeting. They are also able to engage at times that work better for them, and have more thoughtful questions and responses to the items I share.

• Visibility: While questions from staff will often come up after the fact in 1:1 meetings and aren't visible to the rest of the team, questions asked in the WiR are visible to everyone. That is additional context that everyone can benefit from.

• Performance Reference: When I maintained these for smaller teams we would call out individuals who had significant accomplishments. These served as really great reference points for promotions and performance reviews in the future.

• Historical Reference: I've had countless times where I needed to go back and reference when something happened, or get details about a project, problem, or other initiative. I've found important context in my WiR document months or even years later.

For some teams I've maintained four or five years of history in a single document. Going back and reflecting on where a team came from and what they achieved over that timeframe is valuable to have.

Organizing the Week in Review

Doing this takes work, and my first piece of advice is that when you start this practice you need to set aside time to ship it each week. When you begin doing this, your teams will likely find value in the information. When you don’t ship it, they’ll notice. I recommend blocking out a few hours each week to collect, organize, and ship the review. Personally, I find this easiest to do when I’m not likely to be interrupted and have a solid chunk of time - but you’ll have to figure out what works for you. Look for ways to automate this too - there are new tools each week that could help with this practice.

Collecting information

If you are familiar with Getting Things Done, then you are familiar with the idea of quick capture. If you aren’t, the idea here is that you need a fast and low-friction way to capture items immediately when they come up. I personally use my todo list capture mechanism for this, but any tool that allows you to capture context, deadlines, links, articles, or other types of information that you can later put into your WiR will work. The tool isn’t important. What matters is that you capture the information when it comes up and flag it for inclusion in the WiR.

In Todoist, I have a project set up for the Week in Review. Todoist makes it easy to use their quick capture keyboard shortcut and I can drop a URL, or a quick reminder, and use #WeekInReview to drop that into the project. I use this for Slack threads, documents, email messages, tasks from meetings, etc. Anything that needs to go into the Week in Review starts here for me. If something comes to mind when I’m away from my computer, I can use my phone to easily capture it in the same way.

Structuring the Week in Review Document

Here is an example of how I’ve structured this document - tune this to work for your team. It’s worth asking your team what is working for them as you go.

I have always used Google Docs for this. I think the features in GDocs are really helpful for enabling collaboration and engagement. My main advice is to use what your team will engage with - this document is for them.

Week in Review Template

Here is a template you can use to start - make a copy of this and modify as needed:

Week in Review Template - Google Docs

The first tab in that document has my instructions and an example note I might send to my team to introduce the Week in Review.

In the document I have at least two tabs to start:

• Week in Review

  • This tab is the actual Week in Review where final versions are placed

• Week in Review Collection

  • This tab is for my team to share items that they think are worth sharing with the rest of the team

The Week in Review Collection tab has only the upcoming week, and each week I clear it out and set it up for the next week.

Week in review Collection Tab

This section has contributions from the team, and at the end of the week I will use the collection tab to draft my final week in review update. Once I have it in the final form I move it into the main tab and it looks largely like what you see above.

Week in Review Tab

The main difference between the collection document and the main document is that the main tab maintains a running list of each week’s updates in reverse chronological order, the most recent at the top. I insert each new week at the top - the H1 heading is the date.

Alternative Formats

Different teams will have different areas of focus, and I use the headlines to steer what the document should represent. When running more operationally focused SRE/Production Engineering teams I will include an “Incidents” header.

In the past the WiR has included sections like:

• Asks and Deliverables - Anything that has come up over the last week that the team needs to take action on - anything with deadlines and deliverables goes into the WiR as a reminder. This is primarily where I put the more operational deadline type asks on the team so that it is referenceable and authoritative.

• Updates and Progress - Updates on strategic programs, ongoing projects, issues that the team has been waiting for clarity on, budget updates, staffing updates, etc - all the operational information you’d normally cascade in a staff meeting can go in here.

• Issues / Incidents / Challenges / Unexpected events - I think of these as items that the team can learn from or should be aware of so that they can raise or maintain awareness with their teams. In particular, when I’ve run SRE/Production Engineering type teams - documenting any incident that came up was important to keep resilience top of mind and to guide our customers (product development teams) to do the same.

• Wins and Celebrations - The WiR is a great place to acknowledge the hard work your team is doing and highlight individual contributions. You can cover progress on key objectives, valuable increments that have shipped, and even wins with customers where they’ve found success using the thing you shipped to them.

• Organizational Context and Opinion - Sharing the broader movements you see across the organization, whether strategic context sharing, changes in direction from the business, your perspective on how the landscape is shifting and how teams can prepare, or any other useful context you think the team should have based on what you are seeing week over week. This is a helpful place to constantly stream your thoughts to your teams and help them know what’s on your mind.

• Industry Trends and interesting reads - This is one of the areas that gets the most engagement from my teams. I will share interesting articles, videos, podcasts, reports, or general perspectives across our industry.

Also note that my teams have used this themselves for sending out updates - this approach isn't just for managers:

• Project Updates - I've had technical ICs send out weekly updates on big projects to let people know how it is evolving, using the same running weekly document format.

• Periodic Reporting - I've had teams use this format to track weekly/monthly/quarterly reporting of things like availability, incidents, quality, etc. Anything where an ongoing record is useful can use this format.

Play with the format to work for your team - there is no right or wrong here, but there is definitely useful and not useful.

If weekly seems too frequent for your situation, consider doing it less frequently. This has been successfully implemented as a Monthly Review as well.

Week in Review Email

This part is pretty simple - each week when I’ve written up the week in review and dropped it into the main document I will email out a quick summary. I do not copy/paste the entire update into the email - I want the team to look at the document, not just read my email and move on. That email looks something like this:

Subject: My Organization Week in Review for Week ending July 11th

Week in Review for week ending July 11th

Good week of progress - the User Dashboard shipped, super proud of the team getting that out. I have a budget review ask of you, and there’s one incident from this week that your teams should review. A few interesting reads, but overall a quiet week.

Thanks, Aaron

My goal in sending the email is to signal that there’s something there to read and comment on. I expect team members to add comments, make corrections, add their own context worth sharing. Ideally they would have added it to the collections doc but in practice, most context doesn’t get added until I send the email out and that’s completely fine in my view. I don’t add a lot of detail about what’s in the WiR - I want them to go read the doc, not my email.

When you miss a week

Sometimes life catches up with you and you don't ship the WiR - I've done this quite a few times, it happens. Don't sweat it too much, but there are some practices that I've found help me tackle these moments.

1. Try to cover all the period you missed - I will usually date the section for multiple weeks if I skipped a week and put in the effort to try to find items from the prior week that I should have included.

2. Acknowledge the change, but don't apologize - I think any good team should see that we're human and sometimes things slip. This practice is one of those things that can definitely slip and nobody gets hurt - pick it up the next week and move on.

3. Don't stop shipping because you missed a few - You took 3 weeks of PTO and missed a few of these? Pick it up the next week. You got busy and couldn't ship for 2 weeks, pick it up on the 3rd week. Just keep shipping as best you can.

Model the behavior you want to see from your teams. We all have to prioritize differently sometimes.

Changes as you scale up

As your team grows, the WiR will change as well. I've found that the level of candor I would put into the WiR for a five-person team had to be more carefully considered for a 30 person team. Are you comfortable sharing the document with your entire organization, or do you want to share more timely information with only your directs?

For small teams I will typically share with my whole team, but as the organization grows and my directs are primarily managers, I will restrict the WiR I produce to be for my directs only. This allows me to share more candidly and they can make decisions about what is appropriate and relevant to cascade down to their teams.

Adding stakeholders

One powerful addition as your team grows is to share the WiR with your manager, your peers, and your other stakeholders. This can become a powerful tool to provide transparency to the teams around you about what is going on in your own organization. You might be surprised how many people will pay attention to it in this format, and how much they'll appreciate getting visibility into topics that would normally be limited to your staff.

Confidential Information

I tend to avoid putting anything really sensitive in the WiR as my team grows. It's too easy for people to copy/paste material out of the document. I also do tend to share this document with stakeholders, other managers, peers, etc, which makes it challenging to share anything confidential. I don't think this reduces the value of the activity at all.

Automating this with AI

I think this is the type of activity you could definitely automate and I would encourage you to experiment with doing so. I've tried putting this into Gemini and having it generate the content in various tones or adding humor. At the end of the day, I personally prefer to just write it out because I think it helps me. If that's not you, automate it.

Collecting up the items you share is easy to automate and LLMs are pretty good at understanding the context of each item and writing up a brief summary. You could even have an agent prompt you for a weekly summary that you write and it takes care of the rest. There are lots of options here, and this is a great opportunity to play with your favorite vibe coding app and see what you can build.

Wrapping it up - the Week in Review

I hope you find this practice useful. If you put it into practice for your own teams and find it valuable, please let me know how you implemented it. Did you make changes to what I've described here? What did you find that worked better or worse? I would love to hear about your experience.

Subscribe now

Share

Leave a comment

Over my career, I’ve developed 6 principles that guide most of what I do in work. These were picked up by blending experiences of my own with advice I found in people, books, and various other sources. This article covers how some of those developed, but for the impatient - the 6 principles are these:

• Be Curious: You are likely surrounded by experts, rely on them, allowing them to do their job and keeping the BS out of their way. Don’t let your assumptions guide your decisions, ask for feedback, ask others to challenge your thinking, and listen after you ask a question.

• Set the Pace: When you are first to take a run at a problem, you set the pace, the BS is less, and this makes the whole experience smoother. My preferred way to respond to an ambiguous request is to propose a point of view, let others give you feedback, and evolve from there.

• Distribute Context and Decision-making: Share context liberally with those around you so they can directly act as the experts they are capable of being. Distribute decision making as far to the edge of your teams as possible.

• Align Responsibility and Authority: If someone has authority for a decision, they are responsible for the impact. Many of the most stubborn technical problems are not technical at all — they exist because authority sits with a person or team who does not have direct responsibility for the impact of their decisions.

• Build a Signal Network: Invest in building relationships you and your team can depend on in the future. Signal networks are your eyes and ears in an organization. The better your signal, the sooner you’ll pick up on upcoming opportunities, risks, and changes.

• Be Sustainable and Predictable: I focus on building sustainable and predictable teams. Sustainable means we aren’t burning more fuel than we are able to recover. We can maintain our pace indefinitely (and enjoy it). Predictable means others can count on us to do what we say, and as a result we can make and meet commitments.

I believe these principles are also well suited for a world where AI is prominent. When things are changing rapidly and the future is uncertain, these principles help you gather context quickly, distribute that to your team, and set your team up to navigate uncharted waters in adaptive ways.

What follows are some of the experiences that shaped these principles.

Being Lucky

My first real job, the one that would open the door to a 25 year career, wasn’t a job I got because of my experience. You’ve been told for years “it’s not what you know, it’s who you know”, and you probably have a job or two that wouldn’t have happened without someone helping you out. Sometimes people help you out in ways you wouldn’t expect. In my case, they leveraged their stumbles to help me avoid the same.

I applied to my first job in tech with a bunch of other friends — most of whom weren’t technical at all. Unprepared and nervous, most of them flopped the phone screen. The questions they didn’t know were seared in their memory. But a few of us didn’t answer the phone screen. Then, the calls started to flow in — “Man, I bombed that phone screen”. As each friend called, we shared a moment of sympathy, and then… “So, umm, what did they ask?”. After 3-4 calls from disappointed friends, we had a list of about 15 questions. My friend and I stayed up all night researching answers.

It is strange to me to think that, of my friends at that time, it was only those who passed that phone screen that ended up with a career in tech. Some moments are pivotal.

I memorized all the questions I knew I’d be asked and hoped to hell that they’d have mercy on my soul because I was sure they’d know I was lying my ass off. But I got that job anyway, and it has led to a long and fulfilling career.

Through that career I’ve connected with some amazingly smart and capable folks - the most amazing of them were those who just figured shit out. Those were my people. Degree in geology turned Sysadmin running corp IT systems. Degree in chemical biology turned software developer building the CRM system. Degree in sports law turned program manager.

That’s me, with half a semester of music theory and no degree, now a software development and platform engineering leader.

There are substitutes for luck - hard work and persistence are known workarounds. But the privilege of being lucky is difficult to ignore in all of these stories. Where I was born (California Bay Area), the friends I had (already into computers when I wasn’t), and the timing of me entering the workforce (just as tech was taking off) are all things one doesn’t manufacture. I can’t take much credit for those circumstances; I can only express gratitude to the universe and acknowledge the role luck played in this path.

Curiosity and Resourcefulness

I got that job in 1997 - the year before Netcom declared Internet was a verb (”Your way to Internet!”). You’ll have to trust me, this is further back than the wayback machine goes back. God, I feel old. The job was providing call center tech support to every poor soul who couldn’t connect to the Internet.

What I found at Netcom was a group of people who were ambitious - not to climb the corporate ladder, but to learn and have agency over their future. Netcom couldn’t hire pre-trained folks, they had to train them, and they looked for a basic level of competency and expected to fill in the rest. Their training was basic - once you got on the phone with customers you had to adapt quickly. You’d think call center techs might stand around talking about the interesting technical problems they had - and sometimes you’d be right, but more often, we talked about the humans we talked to. Those awesome, awful, confused, impatient, hilarious, and distraught humans who just wanted to Internet. I was now surrounded by people like me who were learning how to do this job day by day, call by call, experiment by experiment.

I once spent 30 minutes talking to a man whose “Internet wouldn’t do anything”, only to discover he had shrunk his browser window to a few inches small (try it, it still works) making the web page invisible. Do you have any idea what kind of Columbo-style curiosity it takes to figure that shit out over the phone?

I learned to be resourceful, leveraging all the tools at my disposal to figure out problems. I learned how to be patient with people, how to listen to every-single-word-they-said. How to pay attention to the tone, the rhythms, what relatives were yelling at me in the background. I learned how to calm someone down, how to give them confidence that we could solve their problem, that even though I was the 5th person they talked to today, it was going to be ME who got them back to Interneting.

Progress required self discipline, study, and experimentation

When I wanted to progress in my career, I had to go read books and run my own experiments. There were some books about how the Internet was wired together, how ISPs built networks, how Unix systems worked, and those were fine. However, I quickly learned that my brain was coated with some industrial-grade Teflon when it came to absorbing information that didn’t solve some problem I had. I’d read an article and think “Oh, wow, I didn’t know grep could do that!” and then promptly forget that grep can do that.

What became clear to me was that I had to engineer problems to scrub that Teflon off and allow new information to stick. If I wanted to learn networking, I had to try to build networks. If I wanted to learn Linux, I had to install Linux. If I wanted to learn to scale systems, I had to work somewhere with that problem. Taking classes and getting certifications did nothing for my understanding of the world.

In the first few years of my career - along with many of my friends doing the same - I’m pretty sure I installed Linux about 500 times. You got your degree dissecting cow eyeballs and human cadavers? Awesome. I got my degree watching green text whiz by my eyes at 2am.

But slowly I discovered solutions to the problems I ran into, and by rinsing and repeating I found that I would retain that information. I could recall it even! A few years into this journey I would have someone accuse me of being “a sponge” for information. Can you imagine?

Writing it down

At some point along the journey to learning something, you want to show others how to do it. You bring your unique background and way of looking at things, and people may start to seek out your opinion. You see an opportunity to be valued for your experience, and writing things down scales your knowledge in ways that talking about it doesn’t (remember, I’m old - no TikTok or YouTube yet).

I found a love for writing, first for just documenting things and then for explaining it to others. I would get a pang of inspiration when someone had asked the same question for the nth time and I’d become hyper-focused on writing a single response that could be referenced into the future. I created documentation that was right in your face in systems - like instructions under the hood of a car (also something they don’t do anymore), they showed up right when you needed them.

The most powerful form of writing though, was writing for myself. It was as if the idea changed the moment it was observed. If I wrote things down, my perspective on them evolved. My frustrations would dissipate. I also found new collaboration partners who would engage with my writing in ways they wouldn’t otherwise.

Writing would become a core tool for me to evolve my thinking, collaborate with others, put ideas out into the world, and drive influence. My ability to write made it easier for me to set the pace, and describe a point of view, which made it easier to shape the landscape in which I operated.

Learning Craftsmanship

Sometimes you get a chance to have real agency and set a high bar for yourself. Agency doesn’t mean you alone make all the decisions, it means you are able to influence your destiny. I usually did this in collaboration with others, and the opportunity to have a small team collaborating toward some end goal has always been the most engaging and rewarding experience. Along the way you learn about craftsmanship - that deep pride in the work you are doing that makes you sweat the small stuff. Craftsmanship requires some confidence in yourself, some sense that the extra effort you are putting in is worth the time. For me, the idea that some future human may come across this thing I did drove a lot of the craftsmanship I put into my work.

Build it well. Document it well. Leave behind something for someone else to learn from and appreciate.

I had this opportunity when I moved into IT, running systems and networks. There were really just two of us driving most of the decisions around how we did things, and we had deep trust in each other’s expertise and judgment. We had each other’s back, and we tried to build the thing that would make us proud. Over 5 years and two computer room builds, we did just that, and the results spoke for themselves - the thing worked great.

And maintaining it was… boring. So I went looking for something more challenging.

Counter examples are education too

The year was 2006, and I had decided to move on from the corporate IT world into SaaS Operations at a fast-paced startup. Despite the dot-com boom and bust being years behind us, I managed to find a company that was undeterred - they partied like it was 1999, and they built software like… well, like a bunch of hackers. They were delivering video to mobile devices and PCs.

YouTube existed by this point, but it was pretty new, and the idea of running YouTube on a phone was fantasy. It would be 2 years before the first iPhone would be released. Every phone available was what we would today call a “dumb phone” - no apps, just basic texting. Blackberry was the most advanced device out there. It was in this climate that this company was delivering video to your mobile phone - one JPEG at a time. Motion JPEG, baby!

Oh, and we streamed live TV to your phone - you could watch live NFL games on your RAZR flip phone. Yes, it worked. Yes, delivering it was an absolute nightmare.

I racked up some impactful career experiences here:

• Largest number of “3 hour” service deployments that took 8 hours

• Longest service outage to date, lasting ~36 hours due to a corrupted distributed filesystem

• Largest amount of money spent on something I could have gotten open source

• Some of the most surprising HR experiences of my career (still standing strong almost 20 years later)

The place was fast paced, chaotic in many ways, but it attracted super bright folks. Everyone worked hard to just get shit done.

Over an 18 month period at this company I went from being a Sr Systems Engineer to a Sr Manager who reported to the COO responsible for Operations and IT. Nobody really explained how to manage humans, and I had zero spare time to learn from books. Upon reflection, it seems like my team mostly felt okay about the job I did - but I did not. I didn’t find a sustainable pace in this role, and the resulting burnout would be the catalyst for my family moving from California to Colorado to find a different relationship with life and work.

I left that place with a network of fantastic folks, and a head full of things I never wanted to see in any company ever again as long as I lived. Some of my most successful decisions have been shaped by what I perceived as failures at this company. I also left that place not wanting to manage humans - an avoidance that lasted for about a decade afterward. I had set a high bar for myself that I hadn’t met, and I wasn’t sure how to resolve that.

This experience left me with a challenge I needed to overcome, and I’ve since figured out how to make things more sustainable. I’ve also learned that careers can move in many directions, like Willy Wonka’s Glass Elevator - going up isn’t the only option. It can be really enjoyable to go down and sideways sometimes.

Embracing Ambiguity and Agency

The second and third thirds of my career have been a mix of startups and larger organizations. Every company had unique aspects - but most had one thing in common: Many people were not great at navigating ambiguity. When new challenges arose that required learning, experimentation, collaboration, and creativity - a bright line would form between different types of people. There were those who could find their way through it, and those who followed them.

I also met many people who were completely undeterred by ambiguity and who thrived when they had a hard and undefined problem to solve. From those folks I learned how to experiment rapidly, influence others, document your journey, and package all that up into a proposal and final decision record. I had multiple opportunities to work with small teams, sometimes just a pair of us, who had an outsized impact on the teams around us.

I learned that I really enjoyed this process because it thinned the herd - the people who could hang with ambiguity tended to be the people I loved being around. The other thing it thinned out was bureaucracy - when you are the first one doing hard things, often people leave you alone to pilot it. And so I gravitated toward taking on the hard stuff that didn’t have a clear solution - and especially where it involved changing hearts and minds. Many engineers hate doing that shit.

Certainty kills Curiosity

The biggest distraction, I learned, is certainty that your idea is right. This isn’t trivial pursuit where there is only one correct answer - the right answer also has to take into account how achievable and, often, how profitable the idea is. Over the last 15 years a huge part of my job has been evolving the good idea into the achievable idea. Ideas don’t win on merit alone, no matter how right they are.

In practice, this means developing collaborative alliances with others to build on a good idea, mobilize organizational support, and get enough people with skin in the game to make execution possible. Along the way you may learn your idea needs to evolve to get others on board - you may even learn that there’s a different idea that could positively impact more teams. Keeping your own ideas loosely held is very powerful. Listening as a collaborative process — asking questions to pull ideas from someone else’s mind, giving them space to think out loud, iterate, and re-shape their own ideas — has more power than you can imagine.

Think of your own ideas as fuel for entering relationships, currency that you exchange for other people’s ideas, and in this process your ideas are consumed - burned in the flames of collaboration to become something else. They become a new idea that was only possible because of the chemical reaction that happened between two ideas that needed each other’s fuel to become great. The oxygen for this combustion to occur is curiosity - without it, both ideas remain potential energy that can’t ignite.

The phrase “certainty kills curiosity” echoes in my head regularly. It reminds me to find ways to challenge my own thinking and to engage others in my problem solving process.

Leading in Ambiguity

I was presented an opportunity about 10 years ago to lead teams again. I took that opportunity because I cared more about how the team was led than I did about my own reservations with being the leader. That experience turned out wonderfully, and for the decade that followed my abstinence from leading humans, I’ve grown in ways I could never have predicted. What made this time different was realizing that I had a particular job to do. This job mostly revolved around enabling my team, but not helping them do their jobs - they’re great at their jobs. The parts that are my job don’t always feel like work to me. But just because it doesn’t feel like work to me does not mean it’s unimportant or low value. I’ve found quite the opposite.

I wrote down the 6 principles at the start of this article to capture key points I think are really important, but my guess is that those who have worked with me would identify others I missed. In time maybe I’ll complete the list, but for now I’ll present them again in a different order:

• Be Curious: You are likely surrounded by experts, rely on them, allowing them to do their job and keeping the BS out of their way. Don’t let your assumptions guide your decisions, ask for feedback, ask others to challenge your thinking, and listen after you ask a question.

• Set the Pace: When you are first to take a run at a problem, you set the pace, the BS is less, and this makes the whole experience smoother. My preferred way to respond to an ambiguous request is to propose a point of view, let others give you feedback, and evolve from there.

• Distribute Context and Decision-making: Share context liberally with those around you so they can directly act as the experts they are capable of being. Distribute decision making as far to the edge of your teams as possible.

• Align Responsibility and Authority: If someone has authority for a decision, they are responsible for the impact. Many of the most stubborn technical problems are not technical at all — they exist because authority sits with a person or team who does not have direct responsibility for the impact of their decisions.

• Build a Signal Network: Invest in building relationships you and your team can depend on in the future. Signal networks are your eyes and ears in an organization. The better your signal, the sooner you’ll pick up on upcoming opportunities, risks, and changes.

• Be Sustainable and Predictable: I focus on building sustainable and predictable teams. Sustainable means we aren’t burning more fuel than we are able to recover. We can maintain our pace indefinitely (and enjoy it). Predictable means others can count on us to do what we say, and as a result we can make and meet commitments.

With these basic principles I’ve led through some very ambiguous situations and emerged with a fantastic result that my team and I were proud of. I’ve watched this play out over and over again. You don’t always win the day - but it isn’t usually because you didn’t navigate the uncertainty well.

I re-ordered the principles a bit in this second set, because I think some principles build on the others. It all begins with curiosity and an ability to listen collaboratively to others. This makes you enjoyable to collaborate with, talk and listen to, and helps you build your signal network so that you can sense what’s going on around you. The context you get from those conversations is distributed to those around you, allowing you to delegate and distribute decisions. This makes your organization operate faster and more autonomously. With that space, you are able to set the pace, focusing your energy on shaping the landscape and clearing the path for your team to operate. Within your own teams you align responsibility and authority, so teams who have authority to make decisions also have responsibility for the impact of their decisions. This allows them to inspect and adapt rapidly and weigh consequences seriously. When put together, all of this creates a sustainable machine that is capable of operating smoothly, quickly, and predictably for long periods of time.

This can feel like a delicate balance at times, but listening to what’s going on around you is key to maintaining that balance.

One more note on predictability, it goes for leaders as well as teams. Teams want to be able to predict what their leader is going to do, or think, or ask. You don’t build a predictable organization unless your thought process is itself predictable. Unpredictable leaders create chaos and disrupt all of this. There might be a set of principles that work with an unpredictable operating model — but these aren’t that.

What has your experience been?

While these are my experiences, I recognize they represent just one perspective. How have you navigated ambiguity in your life and career? I would love to hear your story, and together we can collaborate on a representation of that history that helps others.

Subscribe now

Leave a comment

I’ve muttered these words so many times, probably to the dismay of my own team, and I apologize for the error of my ways…

Other little ditties that fit into this pattern:

• “What measurements do we have today? Let’s look at those first”

• “We already have a pretty good idea of what needs to improve”

• “We just need to tackle this one thing”

How often have you heard these phrases, followed by a few months of work, which is then followed by quiet resignation because the solution didn’t have the impact you expected?

In this post I’ll share why writing a diagnosis is a critical tool that I use to get clarity on a problem:

• What is a diagnosis and how does it help shape your problem solving?

• How to know when a diagnosis is needed, and how to differentiate a diagnosis from a problem statement.

• How to collaboratively develop a diagnosis with your team and stakeholders, and how to know when you are done.

We are wired to solve problems, and we love the idea that our dice roll at the craps table is going to yield instant success. Casinos, AI Code generators, and Pokemon Card Packs all take advantage of this quirk of human intuition. Unfortunately, the majority of the time we’re working with an incomplete picture of the problem space, and this leads to wasted time, money, and damaged team reputation.

In an uncertain world - the diagnosis should be your go-to starting point for discovery and understanding. I’ll grant that on smaller things sometimes the problem is clear. Burned out lightbulb - probably not much diagnosis necessary. But for larger problems, how do you know?

Diagnosing the Diagnosis problem

Diagnosis takes time and too often, isn’t seen as taking action. I think this is the most common reason it gets skipped. We see ourselves as pressed for time, needing to act urgently. There’s no time to think. Do or do not, there is no try. Just do it.

How many projects waste months or years of effort only to discover they were missing huge chunks of context from the start?

Using a diagnosis is a critical step to starting from a foundation of clarity and understanding. If you have concerns about not addressing a problem accurately, it’s worth investing the time to diagnose.

What is a diagnosis?

A diagnosis is a strategic thinking tool. A good diagnosis captures the reality of the problem space you are working in. This goes beyond the specific problem you are working to solve to include surrounding pressures you may or may not have control over. It is an acknowledgement of the landscape you are operating in, and the obstacles that you may have to overcome.

In practice, a diagnosis is just a list of true statements about your environment, your culture, the project, and any other dimension of your reality that may result in challenges solving the problem you are focused on. Some examples of good diagnosis material:

• Cultural, Technical, or Policy challenges that may make success difficult - whether or not you can influence them

• Realities that can be worked around, but that need to be taken into account

• Evidence from past efforts that inform potential risks for the project

I’ve included an example further down in this document, but for now the important takeaway is that a diagnosis is intended to represent the reality you are operating in, and the obstacles you will need to be aware of and potentially overcome.

When do I need a diagnosis?

A diagnosis helps you capture different perspectives about the problem and the realities of trying to improve that situation. When any of these sorts of questions come up for you, a diagnosis might be in order:

• Is there more going on here than I realize?

• What’s the risk that this fails for reasons we haven’t thought about?

• When has this been tried before and why didn’t that work?

A diagnosis can be anything from a 5 minute whiteboard session to a multi-session effort to explore all possible options. In my experience, the act of calling the activity a “diagnosis” and opening the door to input from others will tell you how much is there to learn.

But I have a problem statement, that’s the same right?

A problem statement tends to describe a challenge that you’d like to solve, and should do so in an open-minded way that allows for multiple potential future solutions to exist. Problem statements are future looking and should avoid creating too many constraints on the solution space.

A diagnosis, on the other hand, is a set of statements of fact or sentiment about a situation which may or may not be solvable. Diagnosis statements should describe constraints, risks, and challenges. Diagnosis statements are designed to lay out obstacles so that your problem solving and strategic execution can consider how to address those obstacles.

Both are important tools in attacking a problem, but they are distinct and serve different purposes.

Developing a Diagnosis

So you are convinced, you are going to go write a diagnosis statement - how do you do it? When do you stop? How do you begin?

You can spend a lot of time on this activity, but I would encourage you to start with a few basic questions and when they are answered - move on. You can always come back and revisit the diagnosis if you discover something new, and I would encourage you to treat the diagnosis as a living document and feed it regularly.

What are those basic questions, you ask:

• What specific behaviors or outcomes are we trying to change?

• What forces are working against that change?

• What assumptions are we treating as true?

• What cultural norms are working against us making this change?

• What about our environment or situation is unpredictable and could impact this work in unpredictable ways?

Seek out all contributors

When answering each of these questions, take a “Five Whys” approach with each answer. Each question will probably have multiple answers, and for each answer you should challenge yourself to come up with all the underlying contributors.

For example:

• There is a perception that our software development teams deliver software too slowly. Why?

• Our teams spend a lot of their time discussing changes they are planning to make and can be slow to make decisions. Why?

• Team conversations are often focused on opinion and “what if” scenarios instead of next steps and evidence gathering. Why?

• Team members do not always have good behavior modeling to help them know when to take action vs. discuss. Why?

• Usually this is because we don’t have a team lead present to facilitate the conversation and/or the development manager isn’t very technical. Why?

• Team leads are spread very thin, and managers are hired for their people management skills and not necessarily their technical skills.

This conversation could have gone a lot of different directions in different companies, but you can see how we started with an observation and exposed a number of contributors to the problem:

• Team discussions may be taking more time than they should.

• Team leads are spread thin,

• Team members aren’t always getting good behavior modeling from team ceremonies.

• Managers aren’t always technical, yet we put them in positions where that can have a negative impact on the team.

These are realities of this particular situation, and some of them we have more control over than others. From a strategic perspective, attacking the problem of software development speed without understanding these nuances would likely have you solving a very different set of problems.

Write it down, share it out

An important part of developing a diagnosis is writing it down. This is true for a few reasons:

• Different people process information differently, some people will engage during conversations and some will engage with a document.

• Small nuances can come out when you read all the diagnosis statements together. This can be a powerful unlock to discovering all of the contributors to a challenge.

• You want a written artifact you can reflect on later to see what has changed, what you’ve improved, and evolve the diagnosis to represent your reality down the road.

Putting the diagnosis down in a document and sharing with others is a key step in making sure you’ve captured a wide set of perspectives.

How do I know when my diagnosis is complete?

A diagnosis is rarely 100% complete, but it should be clear when you’ve reached a point of diminishing returns. There is high value in the early stages of diagnosis discovery. When you sense that contributors are arguing semantics or little nuances, you’ve probably explored far enough. It’s ok to be imperfect. Here are some signals I look for and questions I’ll ask to identify if I’ve gone far enough.

• If someone new picked up this problem, is there a big missing area of risk they wouldn’t know about?

• Do we have feedback from anyone who is likely to have a divergent view of this diagnosis?

• As we expose the diagnosis to wider and wider audiences, are we getting big new insights?

Bringing the Discipline to Pause and Diagnose

We all have a responsibility to lead in ambiguous situations. The best leaders I’ve worked with will spot when a diagnosis is missing and pause the conversation.

• “What are we trying to change here? What’s happening today, and are we sure we understand why?”

• “What’s the behavior we’re seeing today that is a concern? What are the drivers causing that behavior?”

• “How do we know this action we’re talking about is the one with the greatest impact?”

Don’t just do this for your own teams, lend a bit of courage to the teams around you by asking the hard question when you see this happening. You might be surprised how often speaking up empowers others to enter the conversation. There are a lot of reasons a diagnosis gets skipped, and speaking up isn’t going to work all the time, but it’s important to try.

A Note on Safety and Candor

No post on talking about challenges would be complete without mentioning psychological safety. In the case of developing an accurate diagnosis, safety is critical, and it can be the difference between an accurate and inaccurate diagnosis. Have you ever watched a project fail because, while it was technically correct, it lacked the necessary support to overcome unspoken institutional challenges?

Many of the challenges of our environments are hard to talk about, that’s often why they are challenges. Writing a diagnosis that ignores that which shall not be named is far less valuable. In fact, the act of writing down those really hard to speak about challenges in your organization is the first step to acknowledging them and addressing them.

My advice here is to find a way to write them down that feels slightly uncomfortable, while avoiding being too edgy or calling anyone out specifically. Not sure how to do that? Then find people who are good at influential writing who can help you find a way to get these challenges down on paper.

Other Inputs to a Diagnosis

Besides the work of writing down diagnosis statements and getting feedback from your team, there are other sources of input to a diagnosis that many teams have already:

• Surveys: These are excellent sources of information for a diagnosis. Because they are sentiment based and are qualitative in nature, they aren’t often seen as “data” - but they are a rich source of insight into whether you’ve captured the full picture of challenges in your organization.

• Bugs, Incidents, Retrospectives: What other sources of evidence do you have that may provide clues about the challenge you are taking on? Can you incorporate data from these sources into your diagnosis?

• Industry patterns and research: If you spot a situation where your industry has a solution that isn’t being applied in your situation, it’s worth calling that out.

It’s easy to get into a cycle of analysis paralysis when considering all viewpoints. Review the feedback above about how to know when you are done and ship it!

Reflecting on Key Points

Let’s wrap this up - I really appreciate you reading this far!

• Keep in mind the signals that suggest a diagnosis might help and don’t be afraid to ask challenging questions of your teams to see if this step is needed.

• Write down your diagnosis and involve others to collaboratively build your full diagnosis. Pull in other sources of data if it’s useful, but don’t get bogged down in analysis.

• Keep an open mind, be curious, and create a safe environment to hear candid feedback about challenges that are difficult to talk about in your organization. Find a way to write those down.

For additional reading, I recommend the book “Good Strategy / Bad Strategy” by Richard Rumelt, which covers combining a diagnosis with guiding policy and cohesive action to create a comprehensive strategy. For software engineering specific disciplines, Will Larson will be releasing a new book called “Crafting Engineering Strategy” soon which covers the diagnosis process in much more depth.

I hope this helps with your next challenging problem - drop me a note and let me know if it helped or if you ran into problems.

Subscribe now

Leave a comment

Subscribe now

I’m super optimistic about the future. I think most of these skills we develop managing humans put us in a good position for this coming revolution in how companies build products, lead teams, and steer armies of automatons.

You probably have a lot of these skills too. Are you good at communicating direction? Good at breaking work down and focusing on iterative steps toward some outcome? Good at setting measurable objectives? Can you provide examples of what you want to see built? Then, IMO, you are not only well equipped to leverage this next phase of how software is built, but you are in a position to help others too.

Opportunity is knocking

Instead of getting worried we’re not going to have a job in a year, why don’t we start talking about how to adapt? Each of these topics could be their own post, but I want to lay out some reasons you should see opportunity in all of this. Here are 5 reasons for you to be excited about leveraging this new era.

The robots will teach you

I cannot think of another point in my lifetime where the technology I needed to learn was itself the teacher. There aren’t many sources of information about how to interact with AI tools that are better than the AI tools themselves. Want to create a great prompt? Ask Claude to help you write a prompt! Want to learn how LLM fine-tuning works? Ask ChatGPT to develop a course for you along with hands-on examples. The sky is the limit here - these things are capable of making you an expert faster than any technology before them - all for $20/mo.

The learning that we all need to practice is how to best interact with these tools to get what you need. Much like humans, when you communicate your needs poorly then you get poor results. However, if you approach this as a collaborative exercise and ask the tools to help you craft a set of instructions, the results improve considerably.

Managing uncertainty is a skill

If you’ve managed teams of people, you’ve probably managed uncertainty. You may not have loved the experience and you may have felt like you could have done better - we all wish for a crystal ball to tell us what the right moves are - but my bet is you did alright. I think now is the time to lean into that experience and think about what helped your teams make decisions.

My early technology career was all about learning as fast as I could. This period really brought out my tendency for hyper-focus and obsessive attention to projects. This was a huge tool for me in handling uncertainty - go build something… anything. Whether that was installing Linux over and over, or building my own network labs, or learning to write code, each of these obsessions was focused on a learning objective. As I moved from one learning goal to the next, the value compounded.

As I shifted into leading people it was about challenging myself and my team in interesting ways. We could solve the problem a traditional way, but what’s the interesting way? How can we shape this problem into something we want to solve, something that teaches us? This same opportunity exists for you today when using these tools. How do you shift from using these tools the same way everyone else does - to using them in an interesting way?

Be a Player to Coach

Today I feel this need to obsess again. The challenge is to learn what skills I can bring to this new world where AI is probably going to be writing most of our code, and our engineering organizations are going to look different than they do today. I don’t have an opportunity to step into the future and read the playbook for these teams, but some people are learning to experiment today. How can we experiment and begin to challenge our own way of working? To do that I think I need to have first-hand experience doing the building. I’ve gone back to spending significant time learning how to use these tools to build software.

Am I building enterprise-grade software? No, I am not. I’m building fun things, and some useful things, some hard things and some easy things. I’m experimenting with how far I can push this technology and what it’s useful for. Along the way though, ideas I wouldn’t have thought of another way are surfacing for me.

Maybe I’ll build something with enduring value, but that isn’t necessary for my objective to be met. I’ll understand much more about what these tools can and cannot do, and I’ll be able to help others learn to leverage them.

Leverage a level playing field

Everyone has been astonished at the pace of change in these areas, and a lot of people haven’t gotten the memo that they need to jump in with both feet. The sooner you get started, the further ahead you’ll be. Yes, there are a handful of companies doing really neat stuff and you don’t work at one of those companies - This. Does. Not. Matter.

It might cost you a little money to sign up for some of the tools - think of it as investing in training. Think of this as paying for a book a month - if you really lean into these things, you’ll get more value than any single book has ever provided you in a given month.

I would strongly suggest investing in both a coding tool like Cursor or Windsurf AND an agent like ChatGPT or Claude. I personally use all of these tools. The technology is evolving weekly, and there’s no way to pick the one that’s best right now. One week it’ll be one tool, the next week it’ll be another, and having access to all of them allows you to observe the step changes that happen as new models and capabilities are released.

Feel the rough spots

In the last few months I’ve built software in Python, TypeScript, Rust, and Swift. I’ve built a terminal based RAG that taught me how vector databases and evals work. I built a web prototype of a gear game and an IOS todo list app. These tools allow you to move around in the software stack more easily than ever before. Not sure how to start? Go collaborate with Claude for a bit on your idea, ask it how to structure the project, ask it what technology to use, ask it what capabilities you should build first, second, third. Ask it to develop a plan that a coding assistant can use and put that plan into a markdown file. Hand that file to Cursor, and watch your app come to life.

…and then spend hours going in circles trying to figure out how to make the smallest things work right. This is what the tech is like right now and this is what your teams will be grappling with when you ask them to use these tools. Some of it is awesome and some of it can be really frustrating. How are you going to understand this new reality if you aren’t living it?

With all of that opportunity to learn, I also think there are rough waters ahead for many organizations. But here’s the thing - these aren’t going to be problems that are readily solved with fewer engineers or fewer managers.

What might need re-thinking

While I’m optimistic that TPS reports will be a thing of the past, and that finding a time-slot for 5 people to hop on a call will become easier, there are some things that will just be different. Organizations will face new challenges that you will be uniquely positioned to help solve. Here are a few predictions.

Reviewing change from the firehose

If you’ve used any of these AI code generation tools then you’ve seen the volume of code that can be produced. If we are successful at making our engineers 50x or 100x more productive, how are we going to review all the output? Humans are already a review bottleneck in many organizations. Strong automated testing has already been a requirement for orgs, but now we’re going to have these tools generating tests, so how do we evaluate successful outcomes?

Teams are going to have to develop tools and muscles to constantly evaluate the output of these tools, the products they build, and the ways that customers interact with them. Ideally AI can be leveraged to process a lot of that information, but someone has to build all of that.

Decision-making becomes the bottleneck

Do your teams get stuck in decision paralysis now? They will need to learn to process larger amounts of data and evidence to support faster decision making in order for products to evolve quickly. Building experiments may become trivial, but how will you leverage those experiments to learn and inform high quality decisions? How will your organization push decisions out to the edge, where product is being built, to enable high-velocity development to occur?

Not only will decision-making need to be distributed, but fast decision making will require fast access to data and strong analytics tools. Organizations that have relied on human intuition or high consensus behaviors will probably struggle to adopt a higher velocity development process.

Measuring individual performance

How are you going to evaluate the performance of engineers who are leveraging AI tools? What are the critical skills that they will need to have, and what experience is going to be crucial? Does 15 years of industry experience mean the same thing 3 years into this AI revolution? I suspect this will have to shift even more toward outcome driven measurements, very similar to what managers are measured on today.

Risk Management

New categories of risk are emerging with hallucinations, AI bias, data inaccuracy in reports, and an organization that is being asked to move faster becoming over-reliant on AI generated recommendations. The velocity is likely to increase before risk management strategies and tools catch up, and the impact of insufficient management will be a negative impact on the business. Much of this comes back to decision making frameworks and data to make good informed choices about how much of the AI firehose you allow to reach customers.

Team Topologies

A lot of the existing research on how teams work and how humans communicate will take time to accurately reflect AI supported teams. The correct team size, types of skills, ratios of skillsets, and appropriate span of control are all going to have to be reconsidered. Companies are just starting to experiment with what this might look like, there’s a lot of opportunity to learn and experiment on your own.

Go out and get started

The trick is to begin. Build something terrible, throw it away, start over, and work on your communication skills with your new teammates. Try different approaches, read about what others are doing, and exercise that curiosity muscle again.

Reach out, let me know what you build! Let me know what you observe - I’d love to hear about it.

Subscribe now

Leave a comment

Countless times in my career I’ve found myself in conversations where the team isn’t sure what path to take. This usually happens when there are multiple options and not enough information to choose the right path. The key signal? Not enough information. How could you get more?

Subscribe now

A powerful question is: What is the least amount of work we could do to learn more?

This approach works best in environments that support experimentation, and works exceptionally well in environments where lean and agile principles are applied.

Think in small increments

Lean and Agile principles remind us that we learn as we build. Every step we take, every new piece we construct, puts us in a more educated position than we were before we built that piece. When debate drags on focusing on opinion alone, pause the conversation. Ask the question above.

The goal with this is to shift the team to action - is there some action that’s either small enough that we don’t mind trying it, or that we’re confident enough in that we all agree we should do it? Can we find a small step to take that will give us a little more info?

Some increments open huge doors

Have you ever played minesweeper? If you have, then you’ve had that experience of feeling like you’re out of moves - you have to make a bet, you have to guess. You click a block and boom - game over. But sometimes a click opens an entire area - suddenly there are 20 different moves available where previously there were none.

Same deal: pick a square, watch the board change.

Often, after a move or two, the right path becomes much more obvious allowing you to execute rapidly.

But what about the boom?

Let’s address that concern. If you’re diffusing a bomb or performing surgery, experimentation is not advised. However, if you are designing a UI, tuning a model, refactoring a backend or doing anything where a wrong move at worst sets you back a bit - then I’d argue the upside is worth the risk.

The focus here should be on what move will help you learn. This isn’t just random guessing, this is about talking through what happens next. You can imagine what making that move might result in - what would happen? What could you possibly learn? If you thought of this move purely as an experiment, is there a different move that would teach you more? The point is to think about how to maximize learning instead of guessing at what might accidentally overcome an obstacle.

If you made 3 moves, and 2 of them set you back, but 1 of them propelled you forward and opened up 10 options you didn’t have before - is that a setback? I think it’s a win.

Psychological Safety becomes critical to pull this off

To do this your team will need to get comfortable with small setbacks, they are going to happen from time to time. The purpose of this exercise is to make little setbacks safe, so bigger bets are more informed. In fact, what often leads teams down a path toward indecision is pressure to be right, so make sure you’re making space for people to learn by running experiments that don’t always work.

When we ask this question we need to be clear that learning involves discovering we’re right as well as discovering we’re wrong. There are no failed experiments in this scenario, but there are invalidated assumptions. If someone in power is going to get upset or resist having their assumptions invalidated, this isn’t going to work.

A few small move examples

Let’s go through a few examples to help crystalize the idea.

1. Team has raised concerns about the design of an upcoming UI element.

   The work to build this UI element is material and they are trying to make sure the design is right, but they’ve been circling the plan for a week without a concrete plan. When we ask “What is the smallest amount of work we could to do learn more?” the team considers a small UI mockup they could provide to a few customers as well as some review of logging data they could do that may help inform the correct answer. The first round doesn’t yield 100% clarity, but it opens up 1-2 more experiments the team can do. It takes a few days, but by the end of the following week the team has much higher confidence about a new UI design.

   Impact: We moved to action a few weeks faster than we would have otherwise, and the team’s confidence was significantly higher.

2. Team is stuck during an incident and isn’t sure how to debug further

   The team has tried all the things they knew to do and the issue is still not being resolved. Most of the prior attempts were swings at a solution, so we step back and look at small increments that could teach us more. This turns up a few experiments that would help clarify how the system is working today and validate some assumptions we are making. As we run these experiments, one of them exposes a bad assumption, which explains why one of our previous fixes should have fixed it but didn’t. With a few tweaks to that approach, the problem gets resolved.

   Impact: We restored service for customers hours faster than we would have by continuing to make guesses.

3. You want to introduce a new process, but your managers are pushing back

   You have a strong sense that this process would improve outcomes, but your managers are resistant and believe it will have a negative impact. Through this question, you agree that the smallest thing you could do is to run a small pilot with a team to assess one part of the process and understand if your managers assumptions about what might happen are validated or challenged. You run this experiment and find that your managers are absolutely correct, you tweak the experiment again and run a pilot in another team, and once again your manager’s concerns are validated.

   Impact: We avoided a costly change management mistake that would have hurt our teams and the relationship with our team.

Bigger moves to reduce risk and uncertainty

Two tools for making bigger moves to reduce uncertainty are the Pre-mortem and a Future Backwards. I’ll tackle those in more detail in another post but for now, if you want to read ahead of the class, have fun! There are a ton of facilitation tools for exploring risk and uncertainty, exploring these should provide some new ideas about what you can do in different situations.

Try this

Next time your team is debating opinion, pause the conversation.

• Ask aloud: What’s the smallest step we can take to learn more about the right option?

• Time box the step - < 1-2 days.

• Bring results back for discussion, what’s next?

• Repeat until the signal changes

The team should signal when you are done - they’ll want to move in bigger leaps in a direction, they’ll have confidence they know what to do.

Outcome: You’ll trade opinion for data and regain momentum. Bonus, the team will probably ask themselves this same question for a while.

(Reach out and tell me what you tried - I’ll feature one or two in this post)

Subscribe now

Share

Leave a comment