Working Notes

Category: Leadership

  • The bridge was never written down

    AI is a building block. That was the argument in my last post. AI already helps my team in the ways you would expect. It helps us write code, draft plans, move work forward. Where it keeps coming up short is narrower and harder to name. It does not do the thing an experienced teammate does almost without thinking: surface the decision that matters and connect the dots, so someone lands on the right call instead of a defensible wrong one. That is the workflow I do not have an AI-native version of yet, and I am still working out what it looks like for my team.

    I spent last week at a conference, a full week away from my team. While I was gone, the kind of gap I have been trying to close opened up. A question came up whose answer meant connecting a few things that lived in separate places and had only ever been connected in one person’s head, which this time happened to be mine. The team is more than capable, and they worked through it. It just took longer, and some of it stayed open, because the reasoning that would have connected those things quickly was not written down anywhere. What stayed with me afterward was structural. The reasoning had no home other than a person, so the moment that person was out of reach, so was the reasoning. It could just as easily have been anyone else on the team. And I spent that same week in room after room where vendors and sponsors were each trying to build some version of the thing that would have kept that from happening. The word they all reached for was context.

    It came up so many times, from so many angles, that I started to suspect we were all using it to point at something none of us had defined.

    So this is not a finished thought. It is the closest I have gotten after a week of listening and a longer stretch of chewing on it, and I am still not sure it is right. But it is the most any of this has clicked for me so far, so I want to try writing it down.

    The person was the bridge

    For a while I assumed the problem was that AI lacked context, and that the job was to go get it more. That holds right up until you ask when the context went missing, and there is no good answer, because it never did.

    The individual systems, while not simple, exist already. The hard part was the reconciliation between them. Someone experienced holds the state of the code and the thread from three weeks ago and the decision nobody wrote down, all at once, and produces a judgment. That reconciliation was always the expensive part, always done partially, and it almost never got written down, because a person could get away with holding it. There was no cost to leaving it implicit. The person was the bridge.

    None of this is new. It is a tale as old as teamwork. Teams have always tried to get this reasoning out of people’s heads and into something the rest of us can use, through documentation and curation and pruning and the constant updating that keeps any of it true. That work is slow and expensive, and most teams undervalue it right up until it is missing. Mine is no different. We pay that tax by hand, imperfectly, because functioning without it is worse.

    What has changed is the urgency, because teamwork now includes agents. AI did not remove the person who did the reconciling. It ended our ability to leave that work implicit. An agent cannot do the intuitive, partial reconciliation someone does in a hallway conversation, and it will not quietly cover the gap the way a person did. So a gap that was always there, always a liability, suddenly has a cost attached to it, and you feel it at the scale of a team.

    This is the bus-factor problem, at the scale of a whole team. Every one of us is holding reasoning that someone else would need. When anyone is out for a week, there is knowledge in their head, about the design system, or an infrastructure choice, or how the analytics are wired, that the rest of us would have to piece back together. The reasoning that connects our systems of record has been living in people, and it has always been one departure away from gone. That was easy to look past while someone was there to reconstruct it live, on demand, for free. It gets harder to look past as teams push more decisions onto more people and more agents, because for any of that to work the connective reasoning has to leave the heads it lives in.

    What I want is a pit of success, so the right call is the easy one to fall into no matter who is or is not in the room that day.

    Everyone was building a different house

    Not every talk was about this. But context kept surfacing, and a striking number of the vendors and sponsors were each, in their own way, trying to fix some version of the same problem. Watching them not quite agree is what made me start pulling on the thread.

    One team argued the answer is a single company-wide wiki, grown rather than built, where every entry carries a human’s name and an agent proposes changes a person accepts. Another argued you should not curate a store at all, because stores go stale, and you should generate context on the fly from a graph over your live sources. Another argued that flat files fall apart under many hands, and that you need a temporal graph that keeps the provenance of every derived fact through every merge and revision. Another argued the whole reason coding agents work and knowledge-work agents flail is that code has a repo, a history, tests, and an undo button, and knowledge work has none of them.

    They sound like competitors. What I started to see instead was people building different houses for the same missing thing, each trying to find a place to keep the reasoning that used to live in a head. They looked like they were competing over context. Underneath, they were competing over where the bridge should live.

    The bridge is a record

    Here is the piece that made the rest click, at least for now. What we are missing is a record of the bridges: the reasoning that says why the code looks the way it does, why this account gets handled differently, why we stopped doing the thing we used to do. A bridge connects two systems of record, and the reasoning for why it connects them the way it does is content in its own right.

    Which means the bridge is a system of record too.

    I keep sitting on that, because it reorganizes how I see the whole problem. It is tempting to treat a bridge as plumbing between the real records. I think the bridge is a record. It gets built, which means someone had a reason. It can be inspected, which means the reason can be read. And it can fall down, which means that when one of the things it connects changes, the bridge might no longer hold, and someone has to know it was there in order to go check.

    Any one of us, looked at this way, is a walking set of bridges. Take any engineer on the team. Somewhere in our components a value is hard-coded instead of pulled from the token, and the code gives no hint why. The reason is a call they made months ago, tied to an accessibility decision that lives in a doc almost nobody opens. The same thing shows up everywhere once you start looking. A cache holds for thirty seconds because of a commitment that lives in a contract and never made it into the code. A service runs in one region and not another because of a data residency rule no one wants to relearn. An analytics event carries a specific meaning, and the definition that makes the dashboards trustworthy lives in one person’s memory and nowhere else. In each case the bridge is the sentence connecting the two sides: this is done this way because of that, and if that changes this should be revisited. It exists in neither system. It exists in a person. When they are out, the bridge is out with them, unless somewhere along the way it became a record.

    Who builds the bridges

    If bridges are records, the next question is who writes them? And here the sharper instincts from the conference help. Nobody is going to hand-author the reasoning connecting their systems of record for the benefit of a future stranger. That has never happened and it will not start now. I am not going to either.

    But an agent can propose a bridge.

    It can look across the code and the thread and the ticket, derive a reasonable guess at why they connect, and put that guess in front of a person. The person ratifies it, corrects it, or throws it out. The correction gets captured, with a link back to where it came from, and it becomes a record the next developer and the next agent start from instead of rebuilding.

    I want to be careful here. The agent is not the verifier. It does not know whether the reasoning is right or the decision was sound. That judgment stays human. What an agent can do is derive, propose, and expose, so the reasoning stops dying in someone’s head or a closed session. The machine drafts the bridge. The person says whether it holds.

    It concentrates the hard problems, it does not solve them

    Here is the thing though. Making the bridge a record concentrates the hard problems rather than solving them, and it puts them somewhere I can point at. The bridge goes stale when either side changes. It needs provenance, or it turns into a confident claim with no way back to its justification. Someone has to verify that a proposed bridge holds, and that someone is a human, at a cadence I do not yet know how to scale. I am not going to pretend I have solved that here.

    Even so, locating the problem feels like progress. For as long as I called all of this context, the hard parts were smeared across a word that could mean almost anything, and I could not say where they lived. Naming the bridge as a record brings them into focus. Staleness bites on the bridge. Provenance is required on the bridge. Verification, the real kind, will have to happen on the bridge.

    Framing it this way also lets me stop treating retrieval and recency as separate problems. While the reasoning lives in a head, you cannot find it, you cannot tell whether it is current, and you cannot tell whether it is right. Those are symptoms of the same missing home. A record with an address and a version answers the first two almost by construction. What is left is keeping it honest, which is the expensive part, for the same reason verification is: someone has to judge.

    There is an obvious next question hiding in that ratify-and-correct loop, which is whether the system itself gets better at proposing bridges over time, instead of only accumulating better ones. That turns entirely on whether the correction signal can be trusted, which is harder than anything here, so I am leaving it alone for now. I raise it only so it is clear I can see it. The same goes for whether AI should be doing this reconciliation at all, and for how we ever confirm that ratified reasoning was sound. Those are their own questions.

    What I have, and what I don’t

    So this is where I am, for now. I think context was never the thing missing. It has been sitting in the records we already keep. The thing that lived only in people was the reasoning that bridges those records, and it was fine to leave it there right up until we asked something that was not a person to do the connecting.

    I think those bridges have to become records of their own, built by agents proposing and humans ratifying, so that when any one of us is out of reach, the reasoning is still there for the people and the agents who need it.

    I do have a hunch about where those records should live, and it points back to one of the houses I heard argued for. Of all of them, the wiki is the one I keep returning to, something richer than a pile of markdown files and still recognizably a wiki. I am not ready to make that case yet, so it is a piece for another day.

    What I do not have is what that workflow actually looks like. I have watched, up close and recently, what happens without it, and I know I do not want the fix to be a person quietly put back into the wrong part of the loop to do the reconciling by hand.. I know the outcome I want. I am still looking for the mechanism.

  • AI is not a tool

    Lately I have been paying attention to how people talk about working with AI. There is a phrase that keeps coming up, in conversations and on stages and in the updates companies send around. We are becoming an AI first team. We are going AI first. And whenever I hear it, I find myself wanting to ask the same follow up question. What does that actually look like on a Tuesday?

    The answer is usually some version of the same thing. Everyone has Claude in their editor now. We ship a little faster. Code review moves quicker. The boilerplate writes itself.

    All of that is real. Having AI in your editor genuinely makes you faster, and I am not interested in pretending otherwise. But the longer I sit with it, the more I think we are using one phrase to describe two very different things, and that the blur between them is holding us back.

    The line I keep looking for

    So I have been trying to find the line. What separates a team that has truly reorganized itself around AI from a team that has simply added AI to the way it already worked?

    Here is the question I keep coming back to, and it is almost embarrassingly simple.

    If you take the AI out of the workflow, does the workflow still make sense?

    When the answer is yes, you have an AI assisted workflow. The shape of the work is the same as it has always been. You are writing code the way you have always written code, and the AI is sitting next to you making each step smoother. Take it away and you are slower, maybe noticeably so, but nothing fundamental breaks. The recipe is unchanged. You just lost a fast pair of hands.

    When the answer is no, something more interesting is happening. The workflow does not have a slower version. Without the AI there is simply nothing there, because the AI was never sitting beside the work. It was holding part of it up.

    Where “tool” stops fitting

    That distinction took me a minute to see clearly, and once I did, I started to understand why so much of what gets called AI first is really AI assisted in nicer clothes. The cause, I think, lives in a word we use without examining it.

    We keep calling AI a tool.

    I understand the instinct. It arrives as software, you open it in a window, you type things into it. It feels like a tool. And the more I work with it, the less that word feels like the right mental model.

    I want to be careful here, because I do not mean this literally. A programming language is technically a tool too, if you want to be precise about it. But a language does not sit at the same layer as an IDE or a linter. You do not bring it to your work the way you bring an editor to your work. You build the work out of it. And that is the layer AI has started to occupy for me. Closer to a programming language than to an editor. A building block rather than a tool. It is one of the materials the work is made of, not one of the instruments I carry to work I have already designed. Tools get added to old workflows. Building blocks get built from.

    This is also why the subtraction question works the way it does. An AI assisted workflow degrades when you remove the AI, because the AI was an addition. An AI first workflow does something else. It reverts. It falls back to needing a person, because the thing the AI was doing was never a faster version of a human task. The capability had always existed before, but only through a person, only as a dependency on someone who already understood the system.

    A capability with no slower version

    This is easy to nod along with and hard to picture, so let’s talk through an example.

    Imagine someone on your team who cannot read the codebase. Maybe they work in marketing, or design, or operations. Maybe they do not even have access to the repository. They hit a question in the middle of their own work, the kind of question that has only ever had one answer: go find an engineer who knows, and wait. Now imagine they can ask that question directly, in plain language, and get an answer good enough to unblock them and keep moving.

    Sit with what happens to that workflow if you remove the AI. It does not get slower. It vanishes, and the old dependency slides back into its place. Go find an engineer. Wait. There was never a manual version of someone who cannot read code reading the code. The capability was made entirely of the model. That is what built from AI actually means.

    When intelligence stops being scarce

    When I first built something like that, I thought of it as a convenience. A way to spare engineers a few interruptions. But I have come to think the real change is sitting underneath the convenience, in something closer to economics.

    For as long as I have worked in software, one fact has shaped every workflow I have ever designed, usually without my noticing it was doing the shaping. Human attention is scarce and expensive. The person who understands the system is a bottleneck, so you build careful structures around protecting their time. You route questions to them. You queue work for them. You write documentation so people will interrupt them less. A surprising amount of what I once thought of as good process is, when I look at it honestly, a strategy for rationing a scarce supply of understanding.1

    What changes with AI is subtler than speed. A usable version of that understanding suddenly becomes abundant. Human attention is still scarce, still expensive, still the thing I would protect first. But synthetic attention, the kind that will answer a reasonable question about the codebase at two in the morning for the hundredth time without tiring or resenting it, is now cheap and plentiful. And once something that used to be scarce becomes abundant, every workflow you built to ration it is up for question.

    Holding the outcome, letting go of the path

    The part of this I am still learning to do well is what it asks of me as the person directing the work. When AI is a tool, I stay in charge of how. I decide the steps, and the tool carries them out. When AI is a building block, my job moves. I become responsible for holding the outcome and for being almost uncomfortably clear about what a good result actually is, and I hand off a great deal of the how.

    It is a little like the relationship between a tech lead and a developer on their team. You decide the goal, and you decide what done looks like. They work out the path to get there, and often they find a path you would not have chosen, and sometimes it is better. Your clarity about the destination ends up doing more work than your opinion about the route.

    I have been learning a version of this same lesson somewhere completely outside of AI. When you stop leading the work directly and start leading the people who lead the work, you run straight into it. You have to hold the outcome and let go of the path. Some days that letting go is the hardest thing in the world, and some days it is a quiet relief, and I have not fully made peace with which one it will be on any given morning. It turns out an AI first workflow asks for the same muscle. Define the outcome with real care. Release the route.

    I made a fairly large bet on all of this recently. I built something with my team that only makes sense if you believe AI is a building block, something that would be incoherent if I tried to explain it as a faster version of what we already did. I am going to write about that next, properly, as a case study, because it deserves more room than I can give it here.

    What the work was actually for

    For a while the question I asked was what this tool could do for me. Lately the question has gotten bigger, and a little less about me.

    I have stopped thinking of this as a question about technology. The question an AI first team is really answering turns out to be an organizational one. Which parts of how we work only ever existed because intelligence used to be scarce? Which approvals, which handoffs, which queues, which roles are load bearing, and which are scaffolding we put up to protect a resource that is no longer rare?

    The teams that get the most out of this will not be the ones who push AI into every corner of what they already do. They will be the ones willing to look at a process they have run for years and ask what it would become if the thing it was built to protect were suddenly cheap. That is a harder question than it sounds, because it means letting go of structures that have felt like good engineering for a long time. But I am fairly sure it is the actual work. The tool framing keeps us busy making the old thing faster. The building block framing lets us ask what the old thing was for in the first place.

    1. I’m not against process, I’m just examining the source of a lot of our current procsses ↩︎

  • How to Be Yourself Despite Yourself

    I watched the karaoke from the sidelines.

    That felt honest to me. I’m not a karaoke person. When it comes to karaoke, I’m an observer, an introvert in that moment, someone who needs to work up to things. So I stood there, drink in hand, watching everyone else be loud and unselfconscious, perfectly content to keep my comfortable distance.

    And then a conga line materialized out of nowhere and swept me up anyway.

    And here’s the thing: I loved it. Fully, genuinely, without reservation. I wasn’t performing enjoyment to be polite. I was just… having a great time. Being exactly the kind of person I’d just told myself I wasn’t.

    I could have said no. I could have smiled and stepped aside and let the line pass. Nobody would have thought less of me. But I didn’t. I let myself be swept up, and I think that’s the more honest version of what happened. Not that the conga line pulled me in, but that I chose not to resist. I gave myself permission, just through the side door of someone else’s momentum.

    The edge of something good

    Which makes me wonder how often I’m standing at the edge of something good, waiting for an external force to make the decision for me. Waiting to be invited, waiting for a reason, waiting for it to feel justified…when I could just decide. The permission was always mine to give.

    And the strange thing is, in most areas of my life, I know this. I don’t wait for my life to happen to me, I make things happen. Particularly in my career. I’ve never sat back and hoped someone would notice, or waited for the right moment to land in my lap. I move. I decide. I act. But put me in a room with music and strangers and something in me goes quiet, and suddenly I’m waiting for a conga line to solve the problem I could have solved myself.

    This keeps happening to me. That same day, I stood at the edge of a group of people I didn’t know, running the familiar calculus in my head: do I have a reason to approach them? What do I have to offer here? Will I seem like I’m inserting myself? And then I walked over anyway. And the conversation was great.

    Every time I push past my own hesitation, it goes well. Sometimes I push past it alone and other times I do it with friends around me. Every time I do the thing I thought I couldn’t do, I find out I can. And yet somehow none of this has updated my story about who I am.

    Maybe because I never stopped to count it as data.

    A juxtaposition to myself

    So which version is real? The person standing at the edge of the room, or the person in the conga line?

    The honest answer is that I am a juxtaposition to myself.

    I am an introvert. I am also someone who can walk into a room, craft a vision, and bring everyone along. I genuinely struggle with small talk. I can’t just chat with anyone about anything, the weather, the weekend, the vague pleasantries that seem to come so easily to other people. And I am also, in the right context, incredibly talkative. Someone who can lose track of time in a conversation.

    As a kid I had no fear. I raised my hand. I sat in the front row. Then as a teenager I worked at a bookstore, and I had absolutely no problem walking up to strangers and chatting with them about what they were looking for. That wasn’t social ease exactly; it was something more specific. I loved books. I knew I could help them. The context gave me a reason to be there, a thing to offer, and that was enough. That’s still true of me.

    I think what I’m actually describing isn’t introversion exactly. It’s that I lead with what I have to contribute. When I know what I’m bringing to the table, I show up fully: talkative, engaged, present. In my career I’ve never struggled with this. I walk in with a vision, with a point of view, with something real to offer, and I move. The freeze only happens when the context strips all of that away and asks me to exist in the room with no role, no agenda, no clear reason to be there.

    Maybe the harder thing is learning that my presence doesn’t always need a purpose to be warranted. That I don’t need a role to deserve the room.

    Data I never collected

    So why doesn’t the story update? I think it’s because I never stopped to collect the data. The discomfort before feels vivid and fresh every time. But the good conversation, the conga line, the moment I surprised myself, those get filed away as anecdotes, not evidence. They don’t accumulate into anything I’m willing to call a pattern. And if I don’t measure it, I get to keep choosing which version of the story to believe. Not collecting the data is safe. Definitive data would force an update. And updates are uncomfortable.

    I don’t think I’m alone in this. Most of us are carrying stories about ourselves that haven’t caught up to who we actually are now. And I suspect the same is true of our organizations, our teams, even our customers, all running on narratives formed in an earlier version of reality, protected by a decision to not look too closely.

    The story that says I don’t do karaoke. I don’t insert myself into groups. I’m not a person who just walks up to people. I need a reason to be in the room.

    That story is not protecting me. It’s just old. And it’s probably wrong.

    So. Do the thing. File it as data. Let it accumulate, even when what it shows you is something you don’t like. Sometimes clarity is uncomfortable. But you can’t do anything about what you don’t understand, and an honest picture is always more useful than a comfortable fiction.

    The latest version of yourself might be someone who doesn’t always need a role to deserve the room. Someone who brings enough just by showing up.

    That’s not a performance. That’s just the data finally catching up to the truth.

  • The Shock Absorber

    There’s a moment in most cross-functional projects that looks, from the outside, like progress.

    The design is mostly there. The copy is mostly there. The direction feels right. A few open questions remain, but nothing feels blocking. Everyone in the room can sense that the thing is almost ready to become real.

    And then someone asks the question.

    “How do we move faster?”

    It’s a reasonable question. It’s asked in good faith, usually by someone senior, usually by someone who genuinely cares about the work. And yet it is, almost always, the moment the project starts to go wrong.

    Not because speed is bad. Speed is often exactly what’s needed. The problem is what the question does to the room. It shifts the conversation from what are we building to how much of it can we skip, and it does so at precisely the moment when the cost of that shift becomes invisible to everyone except the people who will have to absorb it.

    This essay is about that moment, and about what it reveals about how cross-functional teams think about craft.

    To see why, you have to look at what actually happens when a design that looks 95% done arrives at an engineering team.

    Inside the 95%

    When a designer looks at a nearly-finished design, they see something recognizable. The hierarchy is resolved. The tone is landing. The narrative flows from block to block. The work of making the thing feel right is mostly done, and what remains is polish, the kind of refinement that a skilled designer can do quickly once the bones are in place.

    When an engineer looks at the same design, they see a different object.

    They see a dependency graph. They see the six decisions that haven’t been made yet, hiding inside things the design treats as settled. They see the four places where this component will need to behave differently on mobile, and the question of whether the mobile behavior is a variant of the desktop behavior or a fundamentally different pattern. They see the block that looks like a simple card but will need to render three different content types with three different interaction models, and they’re trying to figure out whether those should be one component with variants or three components that share a visual language. They see the animation that isn’t specified but will need to be specified, and the loading state that no one has thought about, and the error state that no one has thought about, and the empty state that no one has thought about.

    They see the question of whether this block becomes a pattern the team will reuse across twenty other pages, in which case the API needs to be designed carefully, because mistakes will propagate, or whether it’s a one-off, in which case the pattern can be simpler but they need to be sure it actually won’t get reused, because one-offs that get reused are the single most reliable source of technical debt in the world.

    They see all of this, and then someone tells them the design is 95% done.

    What the engineer hears is that 95% of the design work is done. Which tells them almost nothing about how much of the engineering work is done, because the engineering work is a different thing, and it hasn’t started yet.

    This is a description of what engineering craft actually is. It is the work of taking something that feels resolved at one level of abstraction and making it resolved at every level of abstraction, including levels that the person who created the original artifact was not required to think about, and often could not have been expected to think about. It is a deep and specific form of thinking, and it requires time that looks, from the outside, like delay.

    Every craft has this property: the people inside it see things the people outside cannot. What I am describing is not engineering seeing more than other disciplines. It is what happens when disciplines work alongside each other without ever fully entering each other’s depth, when each craft becomes invisible to the others, and the cost of that invisibility lands somewhere it shouldn’t.

    Why the invisibility is structural

    The invisibility is a structural feature of how cross-functional work is organized.

    Design work is legible. You can see it. A finished design is a thing you can look at and evaluate. The craft is visible in the artifact. When a designer has spent three weeks refining hierarchy and tone and flow, the output of that work is a document anyone can open and feel.

    Engineering work is largely invisible. The artifact is a running system, and the craft is in the decisions that shaped the system, decisions that are invisible by definition because the whole point of good engineering is to make the right decisions feel inevitable in retrospect1. When a team ships a component that works beautifully, the work that went into making it work beautifully is erased by the fact of its working. You can’t see the architectural choices. You can’t see the edge cases that were handled. You can’t see the thirty decisions that were made quickly and correctly because someone had built up enough context to know which option was right.

    The asymmetry matters because it shapes who gets to have their work respected as craft by default and who has to argue for it. Designers don’t usually have to explain to engineers why their work takes the time it takes, the artifact does the explaining. Engineers routinely have to explain to designers, product managers, and executives why their work takes the time it takes, and the explanation is hard because the thing they’re describing is invisible.

    If a team doesn’t actively correct for this asymmetry, the team that produces invisible work will systematically be treated as the team whose work can be compressed.

    The shock absorber

    Here is the pattern that produces the worst outcomes in cross-functional work.

    A decision space opens up. There are trade-offs to be made. Some of them are hard, which features to cut, which ideas to let go of, which ambitions to defer. These decisions are uncomfortable because they require someone to say no to something they care about.

    The team has a choice. They can make those decisions together, in the room, while the cost of each option is still visible to everyone. Or they can defer the decisions, keep the scope, keep the ambition, keep everything that feels important, and let the decisions get made implicitly later, by whoever is the last line of defense before the thing ships.

    The last line of defense is almost always engineering.

    This is how you get a team where design finalizes, then engineering “figures it out.” Where the trade-offs that weren’t made explicitly in the planning conversation become trade-offs that engineering makes implicitly under deadline pressure, between features and polish, between correctness and speed, between doing the work well and doing the work on time. Where the scope stays ambitious because no one had to say no to anything in the room, and then the engineering team absorbs the impossibility quietly, through longer hours and deferred hygiene and quality corners that get cut invisibly.

    This is the shock absorber pattern. One discipline absorbs the uncertainty that the whole team should have shared.

    When it works, it looks like heroism. The team ships on time (ish), the ambitious scope is preserved, and the engineers who absorbed the cost are praised for their hustle. The praise is real and they feel seen, and the pattern is reinforced.

    But even when the shipping is working, the damage is happening. The engineers who absorbed the first round of uncertainty are not recovering between rounds, they’re being asked to absorb the next round too. The platform hygiene that got deferred during the heroic quarter is still deferred, and the cost of deferring it is compounding. The trade-offs that got made implicitly under deadline pressure were not the same trade-offs that would have been made explicitly in the planning conversation, and the system now contains those implicit decisions as invisible debt. The engineers themselves are a little more tired, a little more cynical, a little more likely to leave.

    And the next time the team produces a heroic quarter, the bar gets reset. The heroic output becomes the new baseline. The next ask is measured against the last delivery, and the last delivery was unsustainable, so the next ask is also unsustainable, and no one notices, because no one is tracking the gap between what the team is delivering and what the team could deliver at a pace that didn’t consume reserves.

    This is how good teams break.

    What craft-respect actually requires

    Respect across disciplines is not a matter of tone. It is not about being nice to each other in meetings, or using the right language in Slack, or remembering to thank each other for good work. Those things matter but they are the surface of the thing, not the substance.

    The substance is this: respecting craft across disciplines means making decisions in the rooms where they can still be made, with the people who will bear the consequences, before those decisions become invisible.

    In practice, this looks like a few specific things.

    It looks like engineering being in the room when scope is being set, not receiving the scope as a completed artifact. Not because engineers need to approve the scope, they don’t, but because the cost of each element of the scope is information that should shape the scope, and that information is only available if engineering is present for the conversation.

    It looks like the “how do we move faster” question being followed immediately by “what are we choosing not to build.” Speed without de-scoping is not speed, it is compression, which is the same output for a higher cost, and the higher cost gets paid by whoever is closest to the deadline.

    It looks like treating engineering estimates as the output of a function, not as an opinion to be negotiated. When an engineer says a thing takes six weeks, the useful response is not “can it be four”, the useful response is “which inputs to your estimate are the most flexible, and what does the work look like at each input level.” The first response treats the estimate as emotional. The second treats it as a model.

    It looks like recognizing that when a team runs hot to hit a date, the running-hot was not free, and planning the next period accordingly. A team that sprinted last quarter cannot sprint again this quarter without paying a compounding cost, and the cost compounds regardless of whether anyone is paying attention to it. The only way to avoid the cost is to plan deliberate recovery into the next period.

    None of this is about slowing down. It is about producing the best work a team is capable of over years instead of quarters, which requires understanding that craft has a pace, and the pace is not infinitely negotiable.

    What this is really about

    The argument I am making is not a soft one. The shock absorber pattern – the compounding cost, the heroic baseline that quietly destroys the teams that produced it – is the difference between organizations that build great work sustainably and organizations that build great work once and then wonder why they can’t do it again.

    The best teams I have been part of were the ones where no discipline had to absorb what the others chose not to decide. Where designers, engineers, marketers, and strategists sat in the same rooms when the trade-offs were live, and made them together, with full visibility into what each choice would cost and who would pay the cost.

    They were not always the fastest teams – although when you take the long view, they almost always are. They were the ones whose work got better over time.

    That, to me, is what respecting craft across disciplines actually means. Not tone. Not politeness. Not saying the right things in Slack. It means building the kind of cross-functional practice where no one’s craft is ever treated as the shock absorber, because every discipline’s work is understood to have depth, and every discipline’s depth is understood to have a cost, and the costs are shared in the open instead of absorbed in silence.

    1. The same by the way, can be said of good design, good strategy, good marketing. Any craft. But it’s easiest to see this about the craft you understand best. There is a name of for this bias: egocentric bias ↩︎

  • Clarity Has Gravity

    There’s a point in an organization’s growth where the problems stop being local.

    What used to feel like a workflow tweak reveals a deeper data inconsistency. A platform improvement surfaces unclear ownership. A tooling decision exposes assumptions that were never fully examined. The issues don’t live neatly inside a single backlog anymore; they stretch across teams, incentives, and timelines.

    At some point, you stop seeing tasks. You start seeing the system.

    And once you see the system, everything begins to feel connected.

    That’s when it gets interesting. And where, for me, growth began.

    As a senior engineer, my instinct was straightforward

    If something could be improved, improve it.

    If I noticed a fragility, I hardened it. If I saw a misalignment, I named it and helped correct it. If I could trace a downstream consequence, I surfaced it early so we could avoid unnecessary pain later.

    That instinct served me well. It’s how you build trust. It’s how you raise the bar. It’s how you grow into senior.

    But the shift into staff dev and higher requires a different muscle.

    Because at that level, the problems you can see are rarely confined to your lane. They span domains. They reveal capability gaps rather than implementation gaps. And they multiply the more context you gain.

    The question changes from “Can I fix this?” to “Should I own this?”

    That’s a learned lesson, by the way; not just theory.

    When clarity creates gravity

    One of the less discussed aspects of staff+ work is that clarity has gravity.

    When you can connect dots across domains, people naturally pull you into conversations. You have the context. You understand the tradeoffs or can figure them out very quickly. You can anticipate second- and third-order effects that aren’t yet obvious.

    Over time, you become an informal integration point.

    And that can feel like growth. And at first it is. Influence expands. The room relies on your perspective, you’re trusted with ambiguity.

    But there’s a subtle edge to it.

    If you equate understanding with obligation, you begin to absorb responsibility for everything you can see. The more interconnected the system becomes, the more you feel compelled to stabilize it personally.

    Over time, that pattern reduces leverage instead of increasing it.

    There’s also a social layer to this that I didn’t fully appreciate at first. Many women, and others who’ve been socialized to be the reliable one in the room, are conditioned to equate usefulness with value, to step in, smooth things over, and keep everything moving.

    But reliability and strategic growth are not the same thing. Being the stabilizer can make you indispensable at your current level. It doesn’t automatically position you to reshape the system itself. And without realizing it, you can start optimizing for being needed rather than being leveraged.

    Not everyone cares about that. I do.

    Interconnected doesn’t mean centralized

    At scale, everything touches everything. Architecture influences process; process shapes ownership; ownership affects incentives. The system is inherently interconnected.

    It’s tempting to respond to that by centralizing coherence through one person or one team. If you can see how the pieces fit, maybe you should coordinate them all.

    But interconnected doesn’t mean centralized ownership.

    In fact, centralizing too much through one person or team can unintentionally slow down the very maturity you’re trying to cultivate. You become the glue that compensates for structural gaps instead of designing structures that remove the need for glue.

    There’s a career dimension to this that took me time to understand. Organizations tend to elevate people who redesign systems, not just the ones who keep them running. If you’re constantly compensating for structural gaps yourself, those gaps remain invisible, and so does the need to expand the mandate around the work.

    There’s a difference between being helpful and being high-leverage.

    The former stabilizes. The latter transforms1.

    Foresight and restraint

    There’s also something uncomfortable about foresight. When you can see where something is likely to fracture months from now, it’s hard to watch it move forward imperfectly. Sometimes it makes me literally wince. It feels negligent to stay quiet when you can anticipate the cost.

    Earlier in my career, I interpreted that discomfort as a cue to step in.

    Now I’m realizing that instinct doesn’t scale.

    I think that part of operating at staff+ isn’t expanding the number of things you personally own, but refining the ones you choose to transform. It’s naming risks without absorbing delivery. It’s designing clean interfaces rather than patching every adjacent seam. It’s making the implications visible and then allowing the organization to decide how much it wants to invest in closing the gap.

    That feels less immediately satisfying. But it’s also a lot more scalable and more directly in service of cultivating and maturing a system.

    The goal isn’t to do less. It’s to do the work that makes the other work resolvable.

    Choosing the hill

    When multiple capability gaps are visible at once, the discipline isn’t in addressing all of them. It’s in choosing the one that, if transformed deeply, will change how the others are approached.

    The right transformation raises the baseline. It shifts mental models. It clarifies ownership. It makes future decisions less fragile. It might look like designing the interface three teams were previously working around, or naming the ownership gap that was quietly slowing every initiative. It’s not less work. It’s more precise work, the kind that compounds.

    The goal isn’t to reduce scope. It’s to increase leverage. To focus on the change that makes other changes easier, faster, and more durable.

    When that work is done well, adjacent systems don’t get ignored. They become easier to evolve because the foundation is clearer, the interfaces are cleaner, and the ownership model is stronger.

    Seeing the whole system still matters. But the real impact comes from reshaping it, not personally carrying it.

    1. This is a nod to Zone to Win by Geoffrey Moore, who articulated 4 zones an org can operate in: performance zone, productivity zone, incubation zone, and transformation zone. Here’s a brief-ish summary of the book. ↩︎

  • Slow Is Smooth, Smooth Is Fast

    People often admire decisive meetings.

    The kind where someone frames the problem clearly, tension surfaces, perspectives clash a little, and a strong direction emerges by the end. It feels productive. Strategic. Powerful.

    I admire those meetings too. I like clarity. I like direction. I am not short on opinions, and I’m comfortable steering a conversation when it needs steering. I care about outcomes. I care about momentum. I care about not wasting time.

    But I’ve started to notice something.

    By the time a hard conversation goes well, the real work has usually already happened.

    The work that happens before the meeting

    Before the meeting, there have often been one-on-one conversations. Sometimes directly about the issue at hand. Sometimes indirectly, reinforcing something more foundational: that a person’s perspective matters, that disagreement is welcome, that raising a concern won’t quietly cost them later.

    That groundwork rarely shows up in the calendar invite.

    And yet it shapes everything.

    In the meeting itself, I usually arrive with a point of view. I’ve done the thinking. I have a thesis. I can articulate a direction. That part comes naturally to me.

    What doesn’t come as naturally, and what I’ve had to learn (and still learning), is holding that thesis lightly enough that it can change.

    If I walk into the room with an answer that’s already locked in, then I don’t actually want collaboration. I want endorsement.

    The best answers I’ve seen don’t come from endorsement. They come from integration. They absorb perspectives I couldn’t have generated alone. They are refined through friction. They are stronger because they’ve been shaped in public.

    But that only works if the room feels safe.

    In The Five Dysfunctions of a Team, the foundational dysfunction isn’t conflict. It’s absence of trust. Without trust, teams avoid real disagreement. Without real disagreement, they commit artificially. And when commitment is artificial, accountability and results suffer.

    You can’t shortcut that first layer.

    Psychological safety isn’t something you declare. It’s something you build.

    The discipline of not rushing

    And building it requires discipline.

    I resist speed, even though moving fast can look decisive.

    I resist over-controlling the narrative, even though I’m capable of doing so.

    I resist the urge to appear fully formed and perfectly prepared.

    There’s a saying often attributed to the U.S. Navy SEALs: slow is smooth, smooth is fast. It is one of my favourite sayings.

    It’s not a slogan about taking your time. It’s about precision under pressure. Move deliberately enough to avoid chaos. Be smooth enough that execution accelerates naturally.

    I’ve seen the same principle play out in teams. When we slow down enough to surface real dissent, to let silence breathe, to allow an idea to be challenged before it calcifies, the decision becomes smoother. And when the decision is smoother, execution moves faster.

    I try to let silence stretch longer than is comfortable. I try not to rush in to rescue the room. Often, that pause is where courage gathers. It’s where someone decides to disagree or to say the risky thing. Or to suggest something more ambitious than they would have otherwise.

    This kind of work is sometimes described as glue work. The relational labor. The context-setting. The trust-building. The one-on-ones. The steady reinforcement that each voice matters. Historically, women have often carried more of that work in organizations.

    But I don’t see it as auxiliary. I see it as structural.

    Bold direction without trust is brittle.

    Speed without safety narrows the range of ideas in the room.

    Control without space produces compliance, not commitment.

    What success actually looks like

    For me, success isn’t walking out of the room having been right. It isn’t hearing my original thesis echoed back to me.

    Success is when the decision no longer feels like mine.

    It’s when there is real buy-in because the idea was shaped together. When people can see their fingerprints on the outcome. When constructive dissent made the answer better. When commitment is strong because ownership is shared.

    That kind of buy-in doesn’t happen accidentally. It’s the result of work that most people never see.

    When speed is necessary

    That said, not every moment allows for that kind of integration.

    Sometimes we do need to move fast. Sometimes the call has to be made. Sometimes the room doesn’t have time for full debate. In those moments, I am decisive.

    But when a team operates in a psychologically safe environment, those moments land differently. There is trust and context. There is an understanding that if space wasn’t held this time, there is a reason.

    Speed is accepted because it isn’t the norm. Authority works because it isn’t overused.

    The foundation holds.

    Building something that lasts

    There is power in setting direction. I do that often.

    But there is also power in building the conditions where a team can challenge, refine, and ultimately co-own that direction.

    When that happens, the decision holds.

    Why? Because it was built not dictated.