An illustrated long-form essay

The Organization
Beneath the Organization

The people and relationships that keep work moving, with older questions about leadership woven through the story.

13 chapters · 22 crayon illustrations · 4 historical lenses

An audio companion

Hear the story

Listen to the literary narration, with room to pause and think. The illustrated text below adds historical lenses and later edits, so the recording does not match it word for word.

THE LITERARY NARRATION

A slower telling

A more reflective reading with room to pause, about 46 minutes.

Download MP3

A map for returning

Find an idea

Each link opens the paragraph where an idea is developed. Every paragraph also has its own shareable link.

  1. 01 / The Organization Beneath the OrganizationAuthority and trust Three kinds of influence Why the map matters
  2. 02 / The Route an Idea TakesHow a warning travels Strong and weak ties When bridges become bottlenecks
  3. 03 / Networks Are Not NeutralWho gets access The hidden routes to sponsorship
  4. 04 / The People Who Can Ruin Your DayWho counts as a stakeholder Listen before messaging
  5. 05 / The Customer Is Trying to Make ProgressThe progress a customer seeks Stories and workarounds Who else bears the cost
  6. 06 / What Leaders Say When They Do Not Yet KnowWhat silence communicates Autonomy needs context
  7. 07 / Culture Is a Translation ProblemCulture is relative Ask what the words mean Translation in practice
  8. 08 / Engagement Beyond the Edge of the FirmExternal engagement as sensing Evidence behind purpose
  9. 09 / When Drafting Becomes CheapWhen drafts become cheap A demo is not an evaluation How juniors learn the craft
  10. 10 / Deferred Is Not CancelledA later deadline still needs preparation Traceability and accountability
  11. 11 / Product Management After the DeckThe product manager’s real work Institutional knowledge
  12. 12 / The Team That Learns to Work With MachinesHow work moves with AI Review is a team capacity Protecting apprenticeship
  13. 13 / The Work of AttentionEvery map is partial The work of attention Where the real work happens

Chapter 01

The Organization Beneath the Organization

Every company has an official story about how it works, drawn in neat boxes and branching lines on an organizational chart. The chart shows who reports to whom, who owns the budget, who signs off on a decision, and where a problem goes when talks break down. You need that chart; without it, accountability evaporates and people are left guessing whose job is whose. Still, nobody actually works inside the boxes. The chart shows how formal authority is supposed to travel, while saying almost nothing about where trust lives. It leaves out the person everyone calls ten minutes before a tense meeting, the colleague who can translate between engineering and sales without starting a war, the veteran who remembers why an innocent-looking policy exists, or the newcomer who somehow gets three siloed teams talking again. On an ordinary Tuesday, the organization that gets the work done is the one underneath the chart.

Office colleagues connected by colored threads beneath a formal organization chart.
The formal chart shows roles; the informal one shows who people rely on.

There is nothing shadowy or subversive about this second organization. It grows naturally out of advice, old favors, shared curiosity, and hard-won trust—all the unwritten glue that turns job descriptions into actual work. No manual can cover every edge case. When a customer complaint arrives with a strange detail, or a project stalls between two departments, or an executive asks a question no dashboard can answer, nobody pulls up the org chart. People message someone they trust. They look for a colleague who knows the terrain, who can make a warm introduction, or whose read of the room carries weight.

At Carta, CEO Henry Ward once mapped this hidden layer by asking employees three straightforward questions: who gives you energy, who do you go to for help and advice, and who do you pull in when a real decision has to be made? Those three questions tease apart very different kinds of influence. The colleague who lifts the mood in a rough week isn't always the one who untangles a technical knot, and the best troubleshooter isn't always the person whose backing makes a decision stick. No one person needs to play all three roles. Separating them keeps the exercise from turning into a popularity contest and shows where people actually turn when they aren't sure what to do next.

Three distinct conversations: a man energizes a colleague, a woman advises a teammate, and an older man helps a group decide.
Energy, advice, and decision influence can come from different people. No one has to do all three.

Looking at an organizational x-ray can be jarring because the skeleton rarely matches what management expects to see. A chief executive may sit at the top of the page yet barely register in the day-to-day network. A relatively junior engineer might turn out to be the main bridge between two divisions, while a ten-year veteran sits quietly on the perimeter. A small regional office might run as a tight, self-contained island, while a larger department splits into factions that only talk through one exhausted middleman. That doesn't mean the formal hierarchy is broken. Hierarchy and informal influence simply do different jobs: one assigns accountability, while the other makes day-to-day coordination work.

Once leaders see that informal map, the reflex is often to try to manage it from above. That almost always backfires, since you cannot mandate trust by memo. What leaders can do is notice where a single person is absorbing too many requests, where quiet maintenance work is going unrewarded, and where certain colleagues are consistently left out of the rooms where decisions take shape. Sharing the load and opening those doors matters far more than turning relationships into another scorecard.

A colleague stands between a design studio and an engineering workshop.
A colleague who understands two teams can be their most important bridge.

Chapter 02

The Route an Idea Takes

On the night before the American Revolution, both Paul Revere and William Dawes rode out from Boston to warn the countryside that British troops were marching. They rode through similar Massachusetts towns at roughly the same hour, yet Revere's ride sparked a far wider mobilization. As sociologists Brian Uzzi and Shannon Dunlap point out, the difference came down to the social worlds the two men inhabited. Dawes knew people inside a narrower circle; Revere had spent years building ties across groups—merchants, artisans, militia captains, tavern keepers, and civic clubs. When Revere knocked on a door, he knew exactly which local voice could move the rest of the town.

That story cuts against the way people usually talk about networking. Stacking up business cards or LinkedIn connections leaves you with a large address book that is socially empty. A network only comes alive when ideas, warnings, favors, and opportunities can actually travel through it between groups that would otherwise stay walled off. A tight circle of close friends gives you candor and safety, though left to itself it tends to recycle the same assumptions. Bridges to outside groups bring fresh information, even if those ties are too thin to lean on in a crisis. Good networks rely on both the bunker and the bridge.

A historical messenger passes a lantern as news spreads through a town.
Revere's warning spread through relationships he had already built.

Sociologists call these strong ties and weak ties. Strong ties are the relationships where you trust someone enough to show a half-baked draft, admit you are lost, take blunt criticism, or call when things go sideways. Weak ties are looser acquaintances—people you don't see often, but who move in different circles. An old coworker mentions a job opening your closest friends would never hear about; a vendor introduces a buyer to a local organizer; a conversation in a conference hallway gives a designer a clue from an unrelated industry. Distant ties never replace close friends, but they keep a close circle from becoming provincial.

Two groups meet through an introduction at an outdoor café.
Close ties offer support; more distant ties bring unfamiliar information.

Ronald Burt called the empty spaces between disconnected groups 'structural holes.' Whoever stands in that gap becomes a broker. Sitting at a crossroads is an obvious career advantage, because you hear news long before it filters into a closed group. Yet brokerage also tests a person's character. When everything between two worlds passes through your desk, you choose whether to translate fairly or spin the message, whether to introduce people directly or hoard access like a private tollbooth.

Inside a company, a generous connector who translates every request between two departments usually ends up indispensable—and then burned out. The fix is to build other roads between the groups: pair people up on joint work, put regular cross-team conversations on the calendar, and keep a written record of decisions where everyone can find it. No team should depend on a single exhausted translator to understand the rest of the company.

A heavily relied-on connector watches a second bridge take shape.
If every introduction depends on one person, the network is fragile.

Chapter 03

Networks Are Not Neutral

Most career advice treats networking like a cheerful meritocracy of coffee chats, alumni mixers, and open doors. In practice, informal networks are anything but level playing fields. Access to context, credibility, and sponsorship flows along the grooves of who gets invited for a quick drink after a meeting, who is immediately assumed to be competent, and who has to ask permission for information that others are handed automatically. Before asking how well someone networks, it helps to ask which rooms are open to them in the first place.

Brian Uzzi's research on how men and women build career networks is easy to misread as a story about innate social habits. Read more carefully, it is a story about organizational structure. When the most powerful networks in a firm have grown up around similarity and old loyalties, informal sponsorship tends to reproduce itself. In those environments, a trusted inner circle of women often becomes vital—offering candid intelligence, backing, and introductions that the wider company fails to provide reliably. Leaders who see that pattern should look hard at how opportunity moves through their building before telling individuals to go network harder.

An experienced engineer mentors junior colleagues at a workbench.
A skilled performer strengthens a team by teaching what he knows.

That distinction explains why a company can look diverse in its hiring numbers while remaining socially segregated day to day. You can recruit broadly and still keep the real decisions inside a familiar clique. You can offer formal mentorship programs—friendly advice over coffee—while withholding sponsorship, where a senior leader actually puts their own reputation on the line for someone when promotions or stretch roles are scarce. You can praise 'authenticity' on posters and still penalize anyone who doesn't talk like the dominant group. On paper the process looks fair; underneath, the informal network quietly decides who gets context and who just gets marching orders.

As Rose Jacobs has argued, closed networks warp more than individual careers; they warp how institutions see reality. Communities grow brittle when people only talk to peers who share their blind spots, and companies fall into the same trap. A vice president who never talks to frontline staff ends up managing an imaginary factory. A product team that only listens to power users mistakes early enthusiasm for mass demand. An executive surrounded by careful handlers hears only the version of bad news that survived three rounds of polishing.

A colleague is welcomed into an influential informal gathering.
Informal invitations affect who gains opportunity.

Broadening your network isn't about collecting different perspectives for show. It is a way of making sure inconvenient facts and unfamiliar ideas can actually reach you. And it only works when it is reciprocal—when you ask not just what a contact can do for you, but what context, credit, help, or introduction you can offer in return. People know immediately when they are being treated as information channels rather than human beings with their own pressures, histories, and limits.

Chapter 04

The People Who Can Ruin Your Day

As soon as a project leaves the conference room, it bumps into people who were not on the invite list. Some are obvious: customers, employees, investors, suppliers, regulators. Others stay invisible until they are suddenly urgent—neighbors down the street, local officials, advocacy groups, platform partners, trade associations, reporters, or families affected at one remove. A team can walk out of a review with a clean roadmap and a solid business case, only to be stopped cold by a question nobody rehearsed: What happens to our data? Who eats the risk if this fails? Why are we hearing about this last?

A project leader listens to the people affected by a decision.
Listen to the people who will live with the decision.

Witold Henisz at Wharton starts stakeholder mapping with a disarmingly blunt rule of thumb: include anyone who can ruin your day. That isn't cynicism; it's an antidote to tunnel vision. A stakeholder is anyone with skin in the outcome or the leverage to change it, now or six months from now. Sometimes that leverage is legal authority. Just as often, it is technical expertise, press access, ties to a community, or the moral weight of a fair grievance. A useful map tracks more than who holds power—it tracks what they care about, who they listen to, and what stories they are already telling one another.

Before trying to persuade anyone, a leader has to read the room accurately. Who actually trusts whom? Whose opinion carries weight with the undecided? Which objection is really about money, and which is about dignity, safety, or an old broken promise? Which critic has every reason to be skeptical, and which quiet supporter is losing faith because nobody followed up? Done honestly, mapping stakeholders is due diligence on the human fallout of your plans.

That means listening comes before messaging. Sitting down for open-ended interviews, paying attention to recurring complaints, and watching how groups talk to each other will tell you far more than a communications plan drafted in a quiet room. And because positions shift as a project unfolds, the map is living rather than static. A neutral neighborhood group can turn hostile after one clumsy mistake; a wary regulator can become an ally when you share test data early; an enthusiastic partner can become a liability by promising things you cannot deliver.

A company representative and community organizer map concerns together.
A stakeholder map should show interests and relationships, not just names.

Think of a stakeholder map as the shadow org chart turned inside out. Both trace where trust sits and how news actually travels. And both are worth drawing only if you are willing to change course when they show you something uncomfortable.

Chapter 05

The Customer Is Trying to Make Progress

Ask a team what customers want and you usually get the same four adjectives: faster, simpler, cheaper, more personal. True enough, most of the time, yet almost useless for designing anything specific. Those words leave out the Tuesday afternoon when a real person reaches for your product—trying to get a job off their desk before five, keep a promise to a client, avoid looking foolish in front of a boss, or calm a nagging worry. Features only make sense inside that moment.

In 'jobs-to-be-done' thinking, a job isn't a job title or a demographic box; it is the progress someone is trying to make in a specific situation. Nobody downloads a budgeting app out of a love for colorful dashboards—they want to stop feeling surprised by money at the end of the month. A manager buys a workflow tool not because they crave automation, but because they need to show an overwhelmed team that nothing is falling through the cracks. A patient logs into a hospital portal late at night just to feel less alone with a scary diagnosis. The software is a means to an end; the real product is the change in the user's situation.

A parent describes his practical needs while a designer listens.
The real customer need may be reassurance rather than a faster feature.

Asking people what features they want rarely uncovers that situation. Asking for stories does. What was happening the day they started looking for a fix? What cobbled-together spreadsheet or sticky-note system did they try first? What almost made them give up? Watching people work in real time is even better, because it exposes clumsy workarounds they stopped noticing years ago. Pair those observations with support tickets and usage logs—where people stall, backtrack, or drop off—and a real picture of what they were trying to accomplish starts to emerge.

A researcher observes someone working around a difficult interface.
Workarounds show needs customers may not think to describe.

Now that AI makes prototyping dirt cheap, teams are sorely tempted to skip that legwork and jump straight from a hunch to a slick demo. A working prototype feels seductive because it makes the future look finished. The trouble is that a persuasive demo can easily mask a bad premise, getting the team to the wrong answer at record speed. The antidote is to ask up front what evidence would prove your hunch wrong: if you think users want speed, what would you see if they actually want reassurance? If you think they want full automation, how would they act if they're afraid of losing control?

Here customer research runs straight into stakeholder mapping, because no user acts in a vacuum. A buyer's choice touches coworkers, family members, procurement officers, and support staff. A tool that delights one person can quietly dump extra work onto someone else: a customer-service chatbot answers common questions in seconds, but leaves human caseworkers with a tangled mess they lack the permissions to fix; a streamlined clinic app helps tech-savvy patients while locking out older ones who can't read the small print.

Chapter 06

What Leaders Say When They Do Not Yet Know

Most advice on executive communication boils down to: keep it short, stick to the facts, don't clutter people's inboxes. Good advice in calm weather—and terrible advice during a storm. When a company is going through upheaval, silence is never read as neutral. People immediately fill the vacuum with their own theories: leadership has no plan, leadership doesn't care, the real deal was cut behind closed doors, or the axe is about to fall. Even a brief check-in takes the edge off that anxiety if it states plainly what is known, what is still up in the air, what happens next, and what the team should focus on until then.

Research discussed at Stanford's Graduate School of Business backs this up: employees judge leaders who undercommunicate far more harshly than leaders who overcommunicate. Too many updates might be mildly irritating, yet people generally read them as a sign that their manager is trying to help. Radio silence looks like indifference. The volume and rhythm of communication carry a message of their own—showing whether a leader is willing to stay in the room when things get uncomfortable.

You see the cost of silence sharpest when managers confuse autonomy with abandonment. Telling someone 'Use your judgment' is a genuine vote of confidence when they already know the goal, the boundaries, and the consequences of a bad bet. Without that context, 'Use your judgment' isn't empowerment at all; it's a way for a manager to stay clean while pushing the risk and ambiguity downstairs.

A leader gives an honest update to a gathered team.
When leaders lack an answer, a timely update still helps.

Good updates don't need to be long; they just need to match the moment. A team waiting on a stalled budget decision needs a date and an honest reason for the hold-up. A group going through a reorg needs to hear what is changing, what is staying put, and where they can ask blunt questions without penalty. Good leaders don't wait until every detail is locked down before they speak—they say what they know today, admit what they can't answer yet, and show up again when they promised they would.

Clear updates also keep everyone who wasn't in the meeting connected to the reasoning behind a choice. When a shift goes unexplained, the rumor mill writes its own script, and people burn hours hedging against imaginary threats. You can't talk uncertainty away, of course, but you can keep people from feeling stranded in it.

Chapter 07

Culture Is a Translation Problem

Nobody walks into a workplace as a blank slate. We all carry ingrained habits about what counts as plain speaking, respectful pushback, fair criticism, or a binding decision. Erin Meyer's The Culture Map is helpful because it puts names and relative scales to those habits—how directly people critique each other, how they build trust, how they argue, how they treat hierarchy and time. You obviously cannot predict how a colleague thinks by glancing at their passport, and trying to do so just trades ignorance for stereotypes. What the map actually does is help a team spot the local habits it had mistaken for universal common sense.

The key word is relative. The same comment can sound refreshingly candid to a Dutch engineer and needlessly abrasive to a British one. A startup might talk like a flat egalitarian commune on Slack while running like a monarchy whenever the founder walks in. National habits, engineering habits, company habits, and local team quirks all layer on top of one another—and power tilts the table. Whoever holds the megaphone usually gets to call their own style 'clear,' 'professional,' or 'rigorous,' while everyone else is expected to adjust.

Cultural frameworks work best when they prompt better questions in the moment. When a counterpart says, 'We'll think about it,' is that a polite no, a real request for time, or an invitation to send more data? When a manager wraps a critique in three layers of praise, are they protecting your dignity or dodging a hard truth? When a decision is announced right after a meeting, was the meeting a debate, a rubber stamp, or a formal roll call after the real deal happened in the hallway?

Colleagues compare different interpretations in a cross-cultural conversation.
Different cultural expectations can hide behind familiar words.

A few explicit team habits can spare everyone weeks of talking past each other. Label documents clearly as a rough draft, a proposal, or a final call. Agree up front on which debates belong in the group channel and which belong one-on-one. Spell out who holds the decision rather than treating silence on a call as unanimous consent, and ask people what a response means on their side of the house before reading bad faith into it.

Cross-cultural teams rely heavily on colleagues who catch when two smart people are using the exact same word to mean opposite things. One person leaves a call thinking the plan is 'agreed' and ready to ship; the other hears 'agreed' as a decent starting point for next week's debate. A good translator stops the room for thirty seconds and asks what each of them thinks just happened.

Chapter 08

Engagement Beyond the Edge of the Firm

Most companies treat the outside world as a messaging problem. There is an 'inside,' where the real work happens, and an 'outside,' where public affairs, investor relations, or communications go out to explain what the inside already decided. McKinsey's research on external engagement argues for a much wider view: treating the boundary of the firm as a sensing network—spotting shifts in the environment early, building relationships before you need them, and moving people and money toward emerging problems before positions harden.

That starts with a story about the company's purpose that can survive contact with a skeptical question. A slogan on the lobby wall convinces nobody. People want to see the receipts: who benefits from your work, what trade-offs you are willing to own, and where your stated values actually cost you something. If an organization claims to care about safety, it should be able to point to product launches it delayed or redesigned for safety's sake. If it talks about inclusion, it should be able to show whose voices shaped its systems.

The second piece is sensing what is happening on the ground without confusing metrics for comprehension. Media trackers and sentiment dashboards can tell you that an issue is spiking on Tuesday morning; they cannot tell you why it has struck a nerve, which local leaders are carrying the argument, or what it would take to earn back trust. Numbers are great for telling you where to go have a human conversation, and terrible as a replacement for one.

The third piece is speed across silos. When an outside crisis hits, the people who understand the pieces of it are usually scattered across legal, operations, product, comms, and local field offices. If every response has to climb up and down a rigid chain of command, the company will always arrive two weeks late. Teams handle external pressure well when they share a common playbook and let the people closest to the problem move quickly.

A community leader listens to neighbors in a garden.
External trust grows when promises meet visible action.

Track the number of stakeholder meetings if you must, then ask the harder questions: Did we actually understand what critics were angry about? Did outside evidence change our roadmap? Even when people still disagree with our call, would they say we listened in good faith?

Chapter 09

When Drafting Becomes Cheap

The first thing AI changes inside an organization is the price of a first draft. A research synthesis that used to eat an entire afternoon now takes ten seconds; a working prototype appears while the meeting is still going; competitor scans, recaps, and project plans pile up on command. The first few times, this feels magical. By Friday, it feels like another inbox. When anyone can generate ten plausible options before lunch, producing options stops being the bottleneck. Judgment—knowing which nine to throw away and which one deserves real attention—becomes the scarce skill.

An AI assistant produces many drafts while a product manager chooses carefully.
AI can supply options; people must decide what matters.

OpenAI product chief Kevin Weil has pointed to how quickly this shifts what teams need from their people. Static expertise in yesterday's toolset matters less than high agency, curiosity, comfort with ambiguity, and the habit of testing assumptions in short loops. You cannot write a twelve-month roadmap as if the underlying models will sit still. Teams have to keep asking practical questions: What can the model reliably handle today? What failure rate can this workflow tolerate? Which decisions must stay in human hands, and what evidence would make us change our minds?

Where that judgment gets concrete is in evaluation. A slick demo is not an evaluation. A model can dazzle a room in a cherry-picked walkthrough and fail quietly the moment it meets messy real-world traffic. Building a real evaluation set forces a team to spell out representative cases, nasty edge cases, unacceptable failures, and clear criteria for review. It replaces 'this looks pretty good' with 'good for whom, under what conditions, and compared to what?'

A team tests an AI prototype together rather than admiring its demo.
A prototype becomes useful when it survives a serious test.

There is a quiet trap here for people early in their careers. If a model writes every first draft, summarizes every legal brief, and maps every unfamiliar codebase, how does a junior hire ever build the muscle underneath? You don't learn to spot a subtle bug or a specious argument by skimming polished summaries all day. Teams don't need to ban AI to fix this, but they do need to carve out space for deliberate practice—times when people wrestle with the raw material themselves, form their own view before prompting the machine, and practice catching plausible-sounding errors.

Cheap drafts also make it dangerously easy to wave things through. No matter how many options a model generates, the human who picks one still owns the consequences: whom the decision helps, whom it might burn, and what nobody bothered to verify.

Chapter 10

Deferred Is Not Cancelled

People in tech often talk about regulation as if it were a speed bump dropped in the path of builders. A better way to read laws like the EU AI Act is as a baseline for what it takes to earn public trust at scale. When the 2026 Digital Omnibus pushed back the enforcement timeline for certain high-risk obligations, it adjusted the calendar—it didn't change the underlying reality. Any company putting AI into consequential workflows still has to know what it deployed, why it deployed it, who gets hurt when it misfires, and how errors get caught.

Remembering that these rules are deferred, not cancelled matters because a pushed deadline breeds false comfort. Teams hear that a compliance date moved and shelve governance for next year. Yet governance isn't a certificate you buy the week before launch; it is basic operational hygiene. You need a live inventory of which systems are running, who owns them, what data feeds them, which human checks are real rather than rubber stamps, and who has the authority to pull the plug when outputs go off the rails.

Under the 2026 amendment, standalone high-risk systems in Annex III carry a later application date, while other rules run on earlier clocks or are already in force. Lawyers will track the exact dates in the official text, but engineering and product leaders need a simpler standard: build for traceability, not for a single calendar date. If a customer or job applicant asks why a system flagged them, can you give a straight answer? If a regulator asks who tested the model, can you pull up the evaluation logs? If a frontline worker spots a harmful output, do they know whom to tell—and will that person actually listen?

A safety lead examines an AI system inventory and its risks.
A later deadline gives teams more time to prepare, not less reason to care.

Seen that way, AI governance is really an internal network problem. Accountability falls apart when teams don't talk to one another: engineering knows the model's blind spots, while sales pitches it as infallible; legal writes a strict policy, while operations quietly routes around it to hit a quarterly target; customer support sees the first wave of weird failures, while the people who can fix the model never see the tickets. Good governance wires those rooms together—with a shared inventory, named owners, records that survive staff turnover, and a culture where flagging a risk is treated as protecting the product rather than blocking a launch.

If a shifted deadline buys your team extra months, spend them stress-testing systems in the wild, training the people who rely on them, writing down why key trade-offs were made, and agreeing on a kill switch before an emergency forces you to improvise one. Compliance may have a deadline. Responsibility does not.

Chapter 11

Product Management After the Deck

You don't have to work at Meta's scale to learn something from how AI is reshaping product management there. As Nikhyl Singhal has described it, when AI strips away the mechanical busywork of coordination, the classic multi-page product requirements document shrinks into something much tighter: a concise problem statement paired with a working prototype and, for AI features, a solid evaluation set. Coding and research agents can summarize codebases, triage bug queues, surface open questions, and draft status briefs—all the glue work that used to go into building a weekly slide deck.

On the surface, that can sound like the product manager's job is evaporating. In practice, it just strips away the administrative camouflage and leaves the hardest parts of the job exposed. Somebody still has to decide which problem is worth solving, tell whether a flashy prototype actually solves it, and defend a painful trade-off in front of a room of skeptics. Making the deck was never the real work; it was just the suitcase that carried the decisions into the meeting.

A product manager and engineer evaluate a prototype together.
Product managers still have to choose the problem worth solving.

Singhal's account also highlights how much institutional memory matters when a company retools. You can bring in outside champions to evangelize new AI workflows, but the best guides are usually veterans who know where the bodies are buried. Insiders know which clunky sign-off ritual was actually preventing a recurring disaster, which handoffs were just historical accidents, and where a new tool is likely to break something downstream. Without that context, teams just layer shiny software on top of broken habits.

Automation cuts both ways here. Freed-up hours can go into deeper conversations with users, or they can get swallowed by twice as many auto-generated docs that nobody reads. Automated bug triage can sharpen a team's focus, or lull everyone into assuming nobody needs to look closely at customer pain anymore. What separates the two is a tight learning loop: real evidence comes in, humans weigh it, a call gets made, the team watches what happens in production, and the system gets adjusted. Without that loop, AI just helps a team drift off course faster.

And the part you can never hand off to an agent is human persuasion. An agent can summarize three competing priorities on a page; it cannot make a defensive peer care about the trade-off. A model can draft a delicate message in seconds; it cannot own the relationship after you hit send. Product work has always been social work disguised as process. AI does not change that. It makes the disguise less convincing.

Chapter 12

The Team That Learns to Work With Machines

Buying everyone an enterprise AI license does not make a team 'AI-native.' What makes a team AI-native is changing how questions, evidence, review, and final decisions move across the group. OpenAI's guide to AI-native engineering maps out how agents can take on work across the software lifecycle—from exploring legacy code to drafting tests and documentation. Alpesh Nakrani's Building an AI-Native Team looks at the organizational side of the coin: hiring for judgment, rethinking role boundaries, adjusting team cadences, and making sure humans don't get trapped rubber-stamping machine output they no longer understand.

Traditional product work moved like a relay race: one person wrote the spec, the next designed the screens, another wrote the code, another tested it, and a manager chased everyone for status updates. Every handoff clarified ownership at the cost of lost context and lost days. In an AI-assisted loop, two colleagues can frame a question together, have an agent spin up a draft or a spike, test the result on the spot, tweak the inputs, and log what worked. Specializations still matter, and someone still has to own the final call—but the distance between asking a question and looking at real evidence shrinks dramatically.

Once generating code, experiments, and analyses becomes fast, review quickly becomes the real bottleneck. A team can ship artifacts at twice its old pace and still learn nothing if nobody has the time or context to inspect what is flying past. Good review doesn't happen by accident; it has to be designed into the week. Teams need clear standards, concrete examples of what 'good' and 'unacceptable' look like, unhurried time to check the parts that carry risk, and full permission to send a polished-looking output back to the drawing board.

That also changes what it means to be senior or junior on a team. Seniority becomes less about who can crank out code or slides the fastest, and more about who can frame the right problem, smell a hidden risk, judge quality in murky situations, and coach others through the reasoning. Meanwhile, junior teammates cannot be reduced to prompt operators. Apprenticeship has to be deliberately rebuilt so newcomers still get their hands dirty enough to build real mental models—and to notice when a confident machine is confidently wrong.

A multigenerational team works with AI while a senior craftsperson mentors others.
Teams need both AI assistance and the judgment to review its work.

Before celebrating a jump in velocity, a team does well to ask what the new workflow is doing to its collective comprehension. Moving twice as fast is a bad trade if, six months later, nobody on the team can explain how the system works or challenge a bad result.

Chapter 13

The Work of Attention

Put side by side, the pieces in this reader look like they come from completely different worlds—midnight riders in 1775 Massachusetts, shadow org charts at tech startups, cross-cultural misunderstandings, EU regulatory calendars, and AI engineering loops. Yet every one of them circles the same practical question: how do we pay attention to what is actually happening when the truth is scattered across dozens of people, contexts, and machines?

Every map we have looked at captures a different slice of reality: formal authority, informal trust, outside stakeholders, customer struggles, cultural habits, and operational risk. None of them gives you the whole territory on its own. Holding several of them up at once is useful precisely because a decision that looks clean on an org chart or a sprint board can look reckless on a stakeholder map.

Information is no longer what leaders lack; most of us are drowning in it. Time is tight, too, though even time isn't the deepest bottleneck. What runs out first is disciplined attention: the judgment to decide which signals deserve a closer look, whose lived experience should force a change of plan, how much evidence a high-stakes call requires, and when a decision has to stay in human hands because you cannot outsource a relationship or a moral risk.

A leader listens to a skeptical colleague on a park bench.
Trust is built by listening to the person in front of you.

Healthy organizations don't try to sand away all friction. Some friction is just the sound of two real priorities rubbing against each other. The trick is telling the difference between pointless friction—radio silence from leadership, clumsy handoffs, blindsided neighbors, boilerplate drafting a machine can safely handle—and the productive friction of dissent, careful review, reflection, and personal accountability. The smoothest process in the building is rarely the most trustworthy one.

Strip away the slide decks and the software licenses, and the organization beneath the organization is built out of what people choose to notice. It lives in the colleague who catches the detail everyone else skimmed past, the bridge-builder who carries honest context between two wary teams, the awkward question that punctures a convenient consensus, and the care that turns a flood of machine-generated options into a decision people can stand behind. Long after the reorg is announced and the new tools are rolled out, that is still where the real work happens.

People look over a town as threads of connection run between them.
An organization works through many different kinds of contribution.

Reading notes

Sources

Articles, books, regulations, and historical texts referenced across the thirteen chapters.

  1. Carta. The Shadow Organizational Chart, Henry Ward, 2017 Source ↗
  2. Harvard Business Review. How to Build Your Network, Brian Uzzi and Shannon Dunlap, 2005 Source ↗
  3. Harvard Business Review. Research: Men and Women Need Different Kinds of Networks to Succeed, Brian Uzzi, 2019 Source ↗
  4. Chicago Booth Review. Why Networking Matters More Than Ever, Rose Jacobs, 2021 Source ↗
  5. Wharton Executive Education. Stakeholder Mapping: Due Diligence, Part One, Witold Henisz Source ↗
  6. HBS Online. Types of Customer Needs and How to Identify Them Source ↗
  7. Stanford GSB. When It Comes to Communication from the Top, Less Isn't More, Claire Zulkey, 2022 Source ↗
  8. McKinsey. The Pivotal Factors for Effective External Engagement, 2020 Source ↗
  9. Erin Meyer. The Culture Map, introduction and author materials Source ↗
  10. Lenny's Podcast. OpenAI's CPO on how AI changes must-have skills, moats, coding, startup playbooks, more, Kevin Weil, 2025 Source ↗
  11. EUR-Lex. Regulation (EU) 2026/1744, Digital Omnibus on AI, official text Source ↗
  12. The Skip. How Meta Is Reinventing Product Management, Nikhyl Singhal, 2026 Source ↗
  13. OpenAI. Building an AI-native engineering team Source ↗
  14. Alpesh Nakrani. Building an AI-Native Team Source ↗
  15. Exodus 18:13–26. Narrative of Jethro's advice to Moses (NRSVUE translation). Source ↗
  16. Mark 10:42–45. Teaching on authority and service (NRSVUE translation). Source ↗
  17. Qur'an 3:159. Passage on gentleness, consultation, and decision. Source ↗
  18. Analects 2.3. Original text with English translation and commentary. Source ↗
  19. Ronald Heifetz. Technical and adaptive challenges, in his Harvard Kennedy School discussion. Source ↗

After the essay

Review what stayed with you

Fifty single-choice questions, ten at a time. Each answer comes with a short explanation and a link back to the relevant passage. Your choices are saved only in this browser.

Questions 1–10 of 500 answered
No timer. Take it at your own pace.