"The Lighthouse Problem"
Design leaders are not captains. They are lighthouses—fixed on the shore of user reality, illuminating the rocks that everyone else cannot see.
It was a Tuesday in October, the kind of overcast morning that makes conference room fluorescents feel particularly unforgiving, when Sarah Chen realized she had lost the thread.
She had been VP of Design at Forge, a mid-size software company in Austin, for just over two years. In that time, she had tripled the team, instituted a design system that engineering actually used, and reduced the average time-to-ship for new features by nearly a third. Her performance reviews contained words like "transformational" and "force multiplier." She had, by every available metric, succeeded.
The meeting that morning was meant to be a victory lap. Sixteen weeks of work on a comprehensive product redesign, distilled into forty-five slides. Competitor analysis showing Forge had fallen behind on core interactions. Accessibility audit results that would satisfy the legal team. A design system overhaul that would pay dividends for years. Sarah had rehearsed the presentation twice. She had anticipated the CFO's questions about timeline. She had prepared answers for engineering's concerns about scope.
What she had not prepared for was the CEO.
David Reiner had co-founded Forge eleven years earlier, back when it was three people in a apartment near the university. He had written the first code, closed the first sales, hired the first designers. He had also, in recent years, stepped back from the details. He attended these reviews but rarely interrupted. He trusted his VPs.
Twelve minutes into Sarah's presentation—she was explaining the competitive gap in their onboarding flow—David leaned forward.
"This is all very thorough," he said. "I can see the work that went into it."
Sarah waited. She knew David well enough to recognize the pause before a pivot.
"But I have a simple question." He looked around the room, then back at her. "What's the hardest thing our users are trying to do right now? And are we helping or hurting?"
The question was not hostile. It was genuine. And it landed in the room like a stone in still water.
Sarah opened her mouth to answer. She had data—she had so much data. Usage metrics, funnel analyses, NPS scores broken out by segment. But David hadn't asked about data. He'd asked about users. Specific, struggling humans. What they were trying to do. Whether Forge was in their way.
She realized, in that moment, that she didn't know. Not really. Not anymore.
The last time Sarah had personally spoken with a user was—when? She tried to remember. There had been that research readout in August, but she'd only joined for the synthesis. Before that, the quarterly business review in June, where they'd shown a highlight reel of user interviews. But sitting across from someone, watching them use the product, hearing them articulate their frustrations in their own unpolished words? Months. Maybe longer.
She had been so busy managing design that she had stopped doing it.
"We're helping," she said finally. "But I want to give you a better answer than that. A more specific one."
David nodded. "I'd like that," he said. "I think we all would."
The meeting moved on. The redesign was approved with minor caveats. But Sarah couldn't shake the feeling that something had slipped—not in the presentation, but in herself. She had climbed to a vantage point that was supposed to offer perspective. Instead, she had found fog.
The Seduction of the Org Chart
The promotion had come eighteen months earlier, and Sarah had celebrated the way you're supposed to—dinner with her husband, a nice bottle of wine, a long call with her mother who still didn't quite understand what "VP of Design" meant but was proud nonetheless.
What no one tells you about moving up is that the elevation happens all at once, but the disconnection happens slowly. So slowly you don't notice it. So slowly it feels like growth.
In her first month as VP, Sarah still attended user research sessions. She'd block off Thursday afternoons, sit behind the one-way glass, take notes in the same Moleskine she'd used as a senior designer. But then came the executive offsites. Then the hiring surge—twelve designers in six months, each requiring interviews, onboarding, one-on-ones. Then the budget cycle, which at Forge was a three-month odyssey of spreadsheets and negotiations. Thursday afternoons became Thursday morning stand-ups with her direct reports. The research sessions continued without her. The readouts got shorter. The Moleskine gathered dust.
This is the seduction of the org chart. It presents seniority as expanded influence, and it's not wrong—Sarah could greenlight projects that would have taken months of persuasion in her previous role. But influence over what? She was shaping a design organization. She was no longer shaping the thing that design organization was supposed to serve.
The calendar is the tell. Pull up the calendar of any design leader who has lost the thread, and you'll see it immediately: a grid of internal meetings. Stakeholder syncs. Planning sessions. Skip-levels and cross-functionals and the weekly leadership team check-in. Somewhere in there, maybe, a quarterly "customer immersion day" that gets rescheduled twice and eventually becomes a thirty-minute video compilation.
The calendar doesn't lie. It's a perfect record of what an organization believes your time is worth. And once you reach a certain altitude, the organization believes your time is worth spending on itself.
There's a story about Lou Gerstner that deserves more attention than it gets.
In April 1993, Gerstner became CEO of IBM. The company was bleeding money—eight billion dollars in losses over the previous three years. The mainframe business was dying. Microsoft and Intel were eating the PC market from both ends. Analysts were openly discussing whether IBM should be broken up and sold for parts.
Gerstner was an outsider, a former McKinsey consultant and RJR Nabisco executive who had never run a technology company. The business press expected him to arrive with a strategy. A manifesto. A bold vision for IBM's reinvention.
Instead, he got on planes.
For the first several months of his tenure, Gerstner spent the majority of his time visiting customers. Not the ceremonial executive-to-executive meetings where everyone performs satisfaction—real visits. Uncomfortable ones. He sat in conference rooms in Cleveland and Munich and Tokyo while IT directors told him, sometimes angrily, how IBM had failed them. How the company had become arrogant, slow, impossible to work with. How their salespeople didn't listen. How their products didn't integrate. How they'd started looking at competitors they would never have considered five years earlier.
Gerstner called this "bear-hugging customers." The board thought he was avoiding the hard work of strategy. He was, in fact, doing the hardest work of all: closing the distance that his new title had created.
"The most important thing I learned at IBM," Gerstner later wrote, "was that the view from the executive suite is almost always wrong. Not because executives are stupid, but because they're seeing a version of reality that has been filtered, interpreted, and softened at every level of the organization."
He wasn't describing a problem unique to IBM. He was describing a physics. The higher you rise, the more mediated your information becomes. The more mediated your information becomes, the less it resembles what's actually happening. This is true of every organization, every industry, every leader.
The question is what you do about it.
Sarah had read about Gerstner in business school. She'd found the story inspiring in the way that business school case studies are inspiring—distantly, theoretically. Now, standing in her kitchen the evening after David's question, she thought about it differently.
Gerstner had recognized his altitude as a liability. He had compensated for it deliberately, almost aggressively. He had treated customer proximity not as a box to check but as an epistemological necessity. You cannot lead what you do not understand. You cannot understand what you do not see.
Sarah pulled up her calendar for the past quarter. Scrolled through week after week of stakeholder syncs and planning sessions and budget reviews. Somewhere in the sea of internal meetings, there was supposed to be a design leader. She was having trouble finding her.
The Cost of Fog
On the evening of January 27, 1986, a teleconference was convened between NASA's Marshall Space Flight Center in Huntsville, Alabama, and Morton Thiokol's engineering facility in Utah. The subject was weather. The space shuttle Challenger was scheduled to launch the following morning, and the forecast was troubling: temperatures at Cape Canaveral would drop to 36 degrees Fahrenheit overnight, colder than any previous shuttle launch.
The engineers at Morton Thiokol were worried about the O-rings.
These were rubber seals in the solid rocket boosters, designed to prevent hot gases from escaping during launch. The engineers had data showing that the O-rings became less flexible in cold temperatures. They had photographs from previous launches showing erosion and "blow-by"—evidence that the seals weren't sealing properly. They had done the math. At 36 degrees, they believed the O-rings would fail.
Roger Boisjoly, one of Thiokol's senior engineers, later described the teleconference as the most agonizing experience of his professional life. He and his colleagues presented chart after chart. They argued. They pleaded. They recommended, in the strongest possible terms, that the launch be delayed until temperatures rose above 53 degrees—the lowest at which the O-rings had been tested.
NASA pushed back. The data was inconclusive, they said. The correlation wasn't clear. There had been O-ring erosion on warmer launches too. And there was pressure—unspoken but unmistakable—to maintain the launch schedule. The shuttle program was behind. The State of the Union address was that week. The teacher, Christa McAuliffe, was waiting.
Thiokol's management asked for a five-minute recess. When they returned, they had reversed their engineers' recommendation. The launch could proceed.
Seventy-three seconds after liftoff, Challenger broke apart over the Atlantic Ocean. All seven crew members were killed.
The Rogers Commission, convened to investigate the disaster, produced a famous finding: the O-ring failure was a direct result of the cold temperatures. The engineers had been right. But the more enduring insight came from the commission's analysis of how the decision had been made.
The engineers closest to the problem had seen the danger clearly. They had tried to illuminate it. But their warnings had to travel through layers of management, each with its own pressures and priorities. At each layer, the message softened. Engineering terror became technical concern. Technical concern became acceptable risk. By the time the decision reached the launch director, the O-rings were one factor among many, weighed against schedule and politics and momentum.
Richard Feynman, the physicist who served on the commission, put it simply: "For a successful technology, reality must take precedence over public relations, for Nature cannot be fooled."
But organizations can be fooled. They fool themselves constantly. Not through malice, but through structure. The engineers at Thiokol were lighthouses, throwing everything they had at the rocks ahead. But the light had to pass through too much glass. By the time it reached the people steering the ship, it was too dim to matter.
Sarah thought about Challenger sometimes—not the explosion itself, but the teleconference the night before. The engineers who knew, who had done the work, who could see what was coming, and who could not make anyone else see.
Design leaders face a less dramatic version of this dynamic every week. The stakes are lower. No one dies when a product ships with a confusing interface. But the structure is the same.
A researcher conducts twenty user interviews. She hears the same frustration, expressed in different words, from different people in different cities. She writes a report. The report is long, because the truth is long, so she writes an executive summary. The executive summary goes to the design lead, who synthesizes it with three other research streams into a quarterly insights document. The insights document goes to the VP, who pulls out the top themes for the leadership team. The leadership team discusses it for fifteen minutes at the end of a two-hour meeting, then moves on to roadmap prioritization.
By the time user reality reaches the people making decisions, it has been translated so many times it no longer resembles what anyone actually said. The texture is gone. The specific is now general. The human is now data.
This is not a failure of any individual. It's a failure of distance. Every translation is a lossy compression. Every summary discards something. The organization is doing what organizations do: processing information efficiently. But efficiency and fidelity are different things. Sometimes they are opposite things.
The design leader's job, Sarah was beginning to understand, is to prevent this translation loss. Or, when prevention isn't possible, to bypass the chain entirely.
This is harder than it sounds. It requires the VP to sometimes act like an IC—to sit in the research session herself, to hear the user's exact words, to carry that specificity into rooms where specificity is usually sanded away. It requires resisting the organizational pressure to summarize, to abstract, to make things tidy for executive consumption.
It requires, in other words, refusing to let the glass accumulate between the lighthouse and the ship.
Boisjoly tried. He had charts and data and decades of expertise. What he didn't have was a way to make the people in charge feel what he felt. The distance was too great. The translations had done their work.
Sarah stared at her laptop in the quiet of her home office. She thought about the users she hadn't talked to, the research readouts she'd skimmed, the quarterly insights she'd approved without ever touching the raw material underneath.
She thought about the glass accumulating, layer by layer, between her and the thing she was supposed to see.
The Lighthouse Metaphor
There's a reason we build lighthouses on shores and not on ships.
A lighthouse on a ship would be useless. It would move with the vessel, see what the crew sees, blind itself to the very dangers it was built to reveal. The whole point of a lighthouse is its fixity—its stubborn refusal to join the journey. It stays where the rocks are. It stays where the truth is. And from that fixed position, it throws light into the darkness, night after night, whether anyone is watching or not.
Organizations are ships. They have momentum, direction, a crew with roles and hierarchies. They have captains—CEOs, founders, general managers—who set the course. They have navigators—product managers, strategists—who chart the route and adjust for conditions. They have engine rooms—engineering, operations—that convert decisions into motion.
What they often lack is someone standing on the shore.
This is the role that design leadership is supposed to fill. Not steering. Not navigating. Not powering the engine. Illuminating. Making visible the obstacles that the ship, in its forward motion, cannot see. The users who are struggling. The workflows that make no sense. The assumptions baked into the product that were never true, or were true once and aren't anymore.
A design leader who does this well becomes invaluable. Not because she has the best ideas—she might or might not—but because she sees what others can't. She has access to a different vantage point. She can say, with credibility, "There are rocks ahead," and be believed.
But here's the trap: the organization will constantly invite the lighthouse onto the ship.
It happens gradually, and it feels like recognition.
You're so valuable, the organization says. Your perspective is so important. We need you in the room where decisions are made. We need you at the leadership table. We need you closer to the center of things.
And so the lighthouse accepts the invitation. She boards the ship. She joins the crew. She attends the meetings, absorbs the context, learns the constraints. She begins to see what the captain sees. She begins to understand why certain courses were chosen. She becomes, in the language of organizations, "aligned."
The problem is that alignment, in this sense, is another word for shared blindness. The lighthouse now moves with the ship. She sees the horizon from the deck, not the rocks from the shore. She has gained influence and lost the very thing that made her influential.
This is not a failure of character. It's a structural inevitability. Organizations are centripetal; they pull everything toward the center. The center is where resources are allocated, where decisions are made, where careers advance. The shore, by contrast, is lonely. The shore is where you spend time with people who will never know your name, doing work that doesn't show up on dashboards, generating insights that resist summarization.
The shore is where the truth is. The ship is where the power is. And every design leader must choose, consciously and repeatedly, where to stand.
Sarah had chosen the ship. She hadn't meant to—no one means to—but the evidence was undeniable. Her calendar, her priorities, her attention: all of it had drifted toward the center. Toward alignment. Toward the view from the deck.
She remembered something a mentor had told her years ago, back when she was a senior designer preparing for her first management role. "The hardest part of leading design," he'd said, "isn't convincing other people. It's staying convinced yourself. Staying close enough to users that your conviction is earned, not borrowed."
She hadn't understood it then. She'd thought conviction was a personality trait, something you either had or didn't. Now she understood it differently. Conviction wasn't a trait. It was a practice. It was maintained through contact, through proximity, through the repeated act of seeing.
The lighthouse doesn't believe there are rocks because someone told it so. The lighthouse believes because it watches, every night, as the waves break against them.
David's question in the conference room had been, at its core, a question about location. Not "What does the data say?" but "What are users experiencing?" Not "What have you been told?" but "What have you seen?"
He was asking whether she was still on the shore.
She hadn't been. For months, maybe longer, she had been on the ship, drifting further from the coastline with every stakeholder sync and budget review. She had been managing a design organization. She had not been doing the one thing a design organization exists to do.
Illuminate.
The word sat with her that night and into the next morning. It wasn't about heroics or transformation or any of the words that showed up in leadership books. It was simpler than that. More humble. A lighthouse doesn't transform the ocean. It doesn't stop the storms. It just shines, in the direction of the truth, for anyone who cares to look.
The question was whether she still could.
Two Models of Design Leadership
In the winter of 1961, a city planner named Robert Moses stood before a crowd at a public hearing in Manhattan. He was sixty-two years old. He had been building New York for nearly four decades—parks, bridges, highways, housing projects, beaches. He had reshaped more of the city than any single person in its history. And now he was presenting his latest proposal: a ten-lane expressway that would slice through lower Manhattan, demolishing a fourteen-block swath of what he called "blight" but what others called home.
Moses was brilliant. This was beyond dispute. He understood power, finance, bureaucracy. He could read a balance sheet and a zoning map with equal fluency. He had built things that lesser planners only theorized about. Jones Beach. The Triborough Bridge. Lincoln Center. His ambition had transformed New York from a crowded nineteenth-century port into a modern metropolis.
But Moses had a weakness, and by 1961 it had become fatal to his vision. He didn't walk.
He designed from above. He saw the city as a map, a system, a problem to be optimized. The neighborhoods his highways destroyed were, to him, abstractions—"blighted areas" full of "substandard housing." He had data to prove it. Exposed wiring, inadequate plumbing, population density statistics. The numbers said these places should go. The numbers were, in a narrow sense, correct.
What the numbers didn't capture was the barbershop on the corner where men had been arguing about baseball for thirty years. The bakery whose owner knew every child on the block by name. The stoops where teenagers fell in love and old women watched the street. The web of relationships, invisible from altitude, that turned a collection of buildings into a community.
Moses didn't see these things because he didn't look. He didn't look because his position didn't require it. He was a master builder. He had people to do the looking for him. And those people produced reports, which became summaries, which became statistics, which became a ten-lane highway through the heart of Greenwich Village.
Sitting in the same hearing room was a woman named Jane Jacobs.
Jacobs was not a planner. She was not an architect. She had no professional credentials, no advanced degrees. She was a journalist and a mother who lived in a townhouse on Hudson Street and had spent years doing something that almost no one in the planning profession did: paying attention.
She walked. Every day, she walked the streets of her neighborhood and others like it. She watched children play on sidewalks. She noticed which corners felt safe and which didn't, and why. She observed the intricate choreography of shopkeepers and residents and visitors that she would later call "the sidewalk ballet." She talked to people—not as subjects of study, but as neighbors. She asked questions and, more importantly, she listened.
Two years earlier, Jacobs had published "The Death and Life of Great American Cities," a book that attacked nearly everything Moses stood for. It argued that the planners had gotten cities fundamentally wrong. That density wasn't the problem but the solution. That the messy, organic complexity of old neighborhoods wasn't blight but vitality. That highways didn't connect cities—they destroyed them.
The book was not based on models or theories. It was based on observation. "The way to get at what goes on in the seemingly mysterious and perverse behavior of cities," Jacobs wrote, "is, I think, to look closely, and with as little previous expectation as possible, at the most ordinary scenes and events, and attempt to see what they mean."
Look closely. With as little previous expectation as possible. See what things mean.
This was not Moses's method. This was not, in fact, the method of most people who rise to positions of power. Power, by its nature, tends toward abstraction. The higher you go, the more you deal in categories rather than cases, trends rather than individuals, dashboards rather than details.
Jacobs refused the abstraction. She stayed on the ground. And from the ground, she could see what Moses, in all his brilliance, could not: that the neighborhoods he wanted to demolish were working. Not perfectly, not without problems, but working—in ways that his highways and housing projects, for all their rational design, never would.
The expressway fight lasted years. Moses had power, connections, money. Jacobs had neighbors, attention, and an unshakable conviction rooted in direct experience. In 1962, she was arrested at a public hearing for disorderly conduct. The charges were eventually dropped. The expressway was eventually canceled.
Moses never understood what had happened. How had a housewife with no credentials defeated the master builder? He blamed politics, the media, a changing city that had lost its appetite for greatness.
What he couldn't see was that Jacobs had access to something he had surrendered long ago: proximity to the subject matter. She knew what she knew because she had seen it herself, repeatedly, over years. Her conviction wasn't theoretical. It was earned. And earned conviction, it turns out, is more durable than expertise.
Sarah had been thinking about Jacobs for days now. Not the famous Jacobs of the expressway fight, but the earlier Jacobs—the one who simply walked and watched and paid attention before any of that became useful.
There was something almost embarrassing about it. In an era of design systems and user journey maps and sophisticated research methodologies, the idea that a leader should just look felt naive. Unscalable. The kind of thing that worked in a simpler time but couldn't possibly work now, with thousands of users and terabytes of behavioral data and a research team whose whole job was to do the looking for you.
But that was Moses's logic too. He had people to do the looking. He had data. He had methods. What he didn't have was contact with the surface of things. And without that contact, all the data in the world couldn't tell him what mattered.
Jacobs didn't have a research team. She had a notebook and a pair of comfortable shoes and a willingness to be present in the world she was trying to understand. She had, in other words, exactly what any design leader has access to, if they choose to use it.
The question was whether Sarah still would.
What Belief Actually Looks Like
Let's be precise about something.
When people talk about design leaders who "believe in the product," they often mean something close to enthusiasm. Energy in meetings. Optimism in roadmap discussions. The ability to sell a vision with conviction and rally a team around it. This is not useless. Enthusiasm matters. But it is not what we're talking about here.
There is a particular kind of belief that transforms products, and it looks almost nothing like enthusiasm. It is quieter, more stubborn, less interested in performance. It shows up not in how a leader talks about the product but in what she's willing to fight for—and, more importantly, what she's willing to be wrong about.
This kind of belief cannot be manufactured. It can only be earned. And the only way to earn it is through contact with the people the product is supposed to serve.
Consider, as a counterexample, Elizabeth Holmes.
Holmes believed. There was never any doubt about that. Her belief in Theranos—in the vision of a device that could run hundreds of medical tests from a single drop of blood—was absolute, radiant, and completely untethered from reality.
She believed so thoroughly that she convinced Henry Kissinger to join her board. She believed so thoroughly that James Mattis, Rupert Murdoch, and the Walton family poured hundreds of millions of dollars into her company. She believed so thoroughly that she kept believing even as the technology failed, the results proved unreliable, and the patients whose blood was being tested received diagnoses that were simply wrong.
Holmes is often described as a fraud, and in the legal sense she was. But fraud implies conscious deception, and the more unsettling possibility is that Holmes deceived herself first. She believed the vision so completely that the gap between vision and reality became, for her, a temporary inconvenience. The technology would catch up. The problems would be solved. The future she described was so vivid, so necessary, so believed that the present—with its messy failures and alarming data—seemed like a distraction.
This is what conviction looks like when it's untethered from proximity. It becomes self-sustaining, feeding on its own intensity rather than on evidence. It seeks out confirming voices and dismisses dissenting ones. It mistakes the feeling of certainty for the fact of correctness.
Holmes didn't spend time with patients. She didn't sit in clinics watching people receive test results. She didn't follow up when those results were wrong. She stayed close to investors, to board members, to the press—to people who reflected her vision back to her. She stayed, in other words, on the ship. The shore, where the rocks were, was somewhere she never visited.
The belief that actually matters is different.
It comes from repetition, not revelation. From sitting across from users, again and again, and hearing the same frustrations in different words. From watching someone struggle with a task that should be simple and feeling, in your own body, the friction they're experiencing. From the accumulation of specific encounters that, over time, become a kind of knowledge that resists abstraction.
This kind of belief doesn't announce itself. It doesn't need to. When a design leader says "I believe in this direction," the statement carries weight only if it's backed by something other than taste or hope. The backing is proximity. The backing is having been there, having seen it, having earned the right to an opinion through the patient work of observation.
Sarah thought about the design reviews she'd led over the past year. How often had she advocated for a direction based on something she'd seen herself, versus something she'd been told? How often had her conviction been firsthand, versus borrowed from a research readout or a deck prepared by her team?
The honest answer was uncomfortable. She had been operating on borrowed conviction for months. Her beliefs about users were increasingly secondhand—synthesized, summarized, filtered through the very translation layers she was supposed to bypass. She still had opinions, still made decisions, still spoke with confidence in meetings. But the confidence was becoming untethered. She was becoming, in a small and less dramatic way, a version of the thing she most feared: a leader whose certainty was no longer grounded in contact with reality.
The difference between Holmes and Jacobs is not that one was a fraud and the other was honest. The difference is location.
Holmes stayed in boardrooms, on stages, in magazine profiles. She surrounded herself with people who wanted to believe. She never tested her conviction against the world it claimed to describe.
Jacobs stayed on sidewalks, in neighborhoods, among the people whose lives would be affected by the plans she opposed. She tested her beliefs constantly, not through formal methodology but through presence. When she said the neighborhood was alive, she could point to the specific interactions she'd witnessed that morning. When she said the expressway would destroy something irreplaceable, she could name the bakery, the barbershop, the stoop where the old women sat.
This is what belief looks like when it's earned. It's specific. It's detailed. It's willing to be corrected because it's based on observation rather than identity. Jacobs didn't believe in her vision of cities because it was hers. She believed because she had seen, over and over, that it was true.
A design leader who has lost contact with users can still function. She can still run meetings, approve designs, advocate for resources. She can still, from a distance, appear to believe in the product.
But the belief will be hollow. It will be a performance of conviction rather than the thing itself. And eventually—in a meeting, in a crisis, in a moment when real belief is required—the hollowness will show.
David had seen it. That was what his question had really been about. Not "Do you have data?" but "Do you have knowledge?" Not "What have you been told?" but "What have you seen?"
Sarah hadn't seen enough. Not recently. And she was beginning to understand that seeing wasn't optional—it wasn't a nice-to-have for leaders with extra time. It was the source of the only kind of conviction that mattered.
The Discipline of Staying Close
In the autumn of 1854, a thirty-four-year-old woman named Florence Nightingale arrived at the Barrack Hospital in Scutari, a crumbling Turkish military facility across the Bosphorus from Constantinople. She had come with thirty-eight nurses to tend to British soldiers wounded in the Crimean War. What she found was something closer to a morgue.
The hospital was built over a cesspool. Sewage leaked through the floors. Rats moved freely through the wards. There was no ventilation, almost no medical equipment, and a shortage of basic supplies like blankets and clean bandages. Soldiers lay in their own filth, sometimes for days. Men who had survived Russian artillery were dying of cholera, dysentery, and typhus.
The military leadership knew the mortality rates were high. What they didn't understand was why. The deaths were recorded as battlefield casualties, attributed to wounds, to the inherent dangers of war. The data said men were dying because war is deadly. The data, in this case, was lying.
Nightingale did something that seems obvious in retrospect but was, at the time, almost unheard of: she collected different data. She walked the wards herself, every day, often late into the night—hence the nickname "the Lady with the Lamp." She recorded not just deaths but causes, not just numbers but conditions. She noted which wards had ventilation and which didn't, which had clean water and which drew from contaminated sources, which were overcrowded and which had space.
Within months, she had assembled a picture of the hospital that contradicted everything the military believed about it. The soldiers weren't dying from wounds. They were dying from the hospital itself. From preventable infections, from contaminated water, from the basic absence of sanitation.
But Nightingale understood that data alone wouldn't move the generals. She had seen too many reports disappear into the bureaucracy, translated and softened and eventually ignored. So she did something else: she made the invisible visible.
Nightingale is remembered as a nurse. She should be remembered as a designer.
The visualizations she created—her famous "coxcomb" diagrams, polar area charts that displayed mortality data in a form even a politician could understand—were not decorative. They were strategic. They took the complexity of what she had observed and compressed it into an image that could not be ignored.
The diagrams showed, unmistakably, that deaths from preventable disease dwarfed deaths from battle wounds. They showed that mortality dropped dramatically after sanitation improvements were implemented. They showed, in a form that required no expertise to interpret, that the military's understanding of its own hospitals was catastrophically wrong.
Nightingale sent these diagrams to the War Office, to Parliament, to anyone who would look. She was tireless, relentless, and—crucially—credible. Her credibility came not from her position but from her proximity. She had been there. She had walked the wards. She had held the lamp over the dying and recorded what she saw. When she said the hospital was killing soldiers, she spoke not as a theorist but as a witness.
Within two years, mortality at Scutari had dropped from 42 percent to 2 percent.
Sarah had read about Nightingale in passing, the way most people had—a hazy impression of nurses and lamps and Victorian heroism. She had never thought of her as a design leader. But the parallels were hard to ignore.
Nightingale understood that leadership, by itself, was not enough. Position was not enough. She had access to generals, to ministers, to the Queen herself. But access without evidence is just proximity to power, not proximity to truth. The evidence had to come from somewhere. It had to come from the wards.
So she went to the wards. Not once, not as a ceremonial visit, but every day. She made the journey from leadership to front lines a daily practice, a discipline. And that discipline was the source of everything that followed—the data, the visualizations, the credibility, the change.
The discipline of staying close.
For a modern design leader, the wards are wherever users are struggling. Support tickets. Feedback forms. Research sessions. The comments section of the app store. The Slack channels where customer success managers share the complaints they hear every day.
None of this is hidden. It's all accessible, a few clicks away. The problem is not access. The problem is attention. The problem is that a VP's calendar doesn't have room for support tickets, and even if it did, reading support tickets doesn't feel like leadership. It feels like a step backward. It feels like doing the job you used to do, before you were promoted out of it.
But Nightingale didn't walk the wards because she lacked nurses to do it for her. She walked the wards because the walking was the point. The data she needed couldn't be delegated. The pattern she was looking for—the connection between conditions and outcomes—required her own eyes, her own attention, her own presence over time.
Delegation is how organizations scale. It is also how leaders lose contact with the thing they're supposed to be leading. Nightingale delegated the nursing. She did not delegate the seeing.
Sarah started small. The week after her conversation with David, she blocked two hours on Friday morning and labeled it "User Contact." She didn't tell anyone what it meant. She wasn't sure herself.
The first Friday, she sat in on three support calls. Just listened, didn't speak. Heard a woman in Ohio explain, with remarkable patience, that she'd been trying to complete the same task for twenty minutes. Heard a man in Toronto apologize for being frustrated, then describe a workflow so convoluted that Sarah felt herself getting frustrated on his behalf.
The second Friday, she joined a user research session. Not the debrief—the actual session. Watched a small business owner navigate the product in real time, saw him hesitate at exactly the places the team had debated in design reviews. Watched him miss a button that the team had thought was obvious. Watched him give up on a feature that the roadmap said was a priority.
The third Friday, she read fifty support tickets. Not summaries. The actual tickets, with the actual words users had written. Some were angry. Some were confused. Some were heartbreakingly polite, apologizing for taking up time while describing problems that should never have existed in the first place.
None of this was efficient. None of it would show up on a dashboard or a performance review. It was, in the language of organizational productivity, a waste of a VP's time.
But by the fourth Friday, Sarah noticed something had changed. In meetings, when someone made a claim about users, she had a reference point. When a design decision was debated, she could picture specific people—not personas, not segments, but individuals she had watched and listened to—who would be affected. When she advocated for a direction, her advocacy had weight. Not because her title demanded it, but because her knowledge earned it.
The light was starting to come back on.
The Same Room, Later
Six months later, a Tuesday in April. The same conference room, the same fluorescent lights, the same executives arranged around the same table. Sarah was presenting again—this time, the results of the redesign that had launched in February.
But she didn't start with results.
"Before we get into the numbers," she said, "I want to show you something."
She clicked to the first slide. It wasn't a chart or a framework or a competitive analysis. It was a photograph of a woman named Denise, fifty-three years old, who ran a landscaping business outside of Milwaukee. Sarah had spoken with her two weeks earlier.
"Denise has been using Forge for four years," Sarah said. "She has eleven employees. She does her invoicing on Sunday nights after her grandkids go home, because that's the only time she has. She told me that before the redesign, she used to dread it. The old workflow took her ninety minutes on a good week. She'd make mistakes, have to start over, sometimes give up and do it on paper."
Sarah clicked to the next slide. A short video clip—thirty seconds of Denise walking through the new invoicing flow, recorded with her permission during a follow-up call.
"Now it takes her twenty minutes," Sarah said. "She said—and this is a direct quote—'I actually don't hate Sunday nights anymore.'"
The room was quiet. Not the uncomfortable quiet of six months ago, when David had asked his question and Sarah hadn't known how to answer. A different kind of quiet. The quiet of people watching something they hadn't expected to see.
"The metrics are strong," Sarah continued. "Task completion up 34 percent, time-on-task down by nearly half, NPS improved across every segment. I'll walk you through all of it. But I wanted to start with Denise, because Denise is why the metrics moved. She's not an edge case. She's the case. There are forty thousand Denises in our user base, and for the first time, we're actually making their lives easier instead of harder."
David was nodding. Not the performative nod of an executive signaling engagement. The real kind. The kind that meant he'd seen something.
After the meeting, David caught Sarah in the hallway.
"That was different," he said.
"Different how?"
"You used to present like you were defending a position. Today you presented like you were showing us something we needed to see." He paused. "What changed?"
Sarah considered the question. The honest answer was complicated—the Fridays spent on support calls, the research sessions she'd started attending again, the slow accumulation of faces and voices that had replaced the abstractions she used to rely on. The way her conviction had shifted from something she performed to something she felt.
"I got closer," she said. "That's all. I just got closer."
David smiled. "Keep doing that."
She walked back to her office and sat for a moment before opening her laptop. Through the window, she could see the Austin skyline, the construction cranes that seemed to multiply every month, the city growing and changing in ways that planners were probably arguing about in rooms she'd never see.
She thought about Jane Jacobs, who had understood that the only way to know a city was to walk it. About Florence Nightingale, who had carried a lamp through wards of dying men because the truth was in the wards, not in the reports about them. About Lou Gerstner, who had spent his first months as CEO being yelled at by customers, because the yelling contained information he couldn't get any other way.
She thought about lighthouses. About the temptation to board the ship, to join the crew, to see what everyone else sees. About the discipline required to stay on the shore.
The discipline wasn't heroic. It wasn't even, most days, particularly hard. It was just a choice, made repeatedly—to spend two hours on a Friday morning listening to support calls instead of attending another planning meeting. To read the raw feedback instead of the summarized insights. To sit in research sessions and watch users struggle, even when watching was uncomfortable, even when it revealed problems she didn't have easy solutions for.
The choice to stay close. The choice to keep the light burning.
Her laptop chimed with a calendar reminder. The next meeting was in ten minutes—a hiring panel for a new design director. Sarah pulled up the candidate's portfolio and started reviewing.
But before she closed the other window, she added something to her calendar. A recurring block, every Friday morning, from 9 to 11. She labeled it the same way she had six months ago, when she'd started this whole experiment.
User Contact.
It wasn't much. Two hours a week, in a calendar crowded with stakeholder syncs and budget reviews and all the other obligations that came with her title. But it was hers. A small, stubborn commitment to the shore.
She closed the laptop and headed to the meeting. There was work to do.
The Argument, Restated
Design leadership is not design management.
This distinction matters more than it might seem. Management is the work of running a function—hiring, budgeting, coordinating, aligning. It is necessary work. Organizations cannot operate without it. But management, by its nature, pulls inward. It concerns itself with the health of the team, the efficiency of the process, the satisfaction of stakeholders. It asks: Is the design organization functioning well?
Leadership asks a different question: Is the design organization seeing clearly?
The two are not the same. A design function can be well-managed and still be blind. It can ship on time, stay within budget, maintain high morale, and produce work that completely misses what users actually need. The dashboards will look healthy. The org will be humming. And the product will drift, slowly and imperceptibly, away from the people it was built to serve.
This is the failure mode that no management practice can prevent. It can only be prevented by leadership—by someone, somewhere in the organization, who maintains a direct line to user reality and refuses to let that line be cut.
The obstacle is not awareness. Every design leader knows, in theory, that user proximity matters. The obstacle is structure.
Organizations are compression machines. They take complex reality and reduce it to formats that can be communicated, compared, and acted upon. This is not a flaw; it's a necessity. No executive can process every support ticket, every user interview, every piece of raw feedback. Summarization is how organizations function at scale.
But every summary discards something. Every synthesis loses texture. Every translation up the chain strips away the specific in favor of the general, the human in favor of the data point, the story in favor of the statistic. By the time user reality reaches the leadership table, it has been processed so many times that it no longer resembles what anyone actually experienced.
The design leader's job is to resist this compression. Not by rejecting data or dismissing synthesis, but by maintaining an independent channel to the source. By continuing to see for herself, even when her role no longer requires it. By protecting, through deliberate practice, her access to the specific.
This is what makes design leadership different from design management. The manager ensures the research gets done. The leader ensures the research gets through—that its texture survives the journey from observation to decision, that the people making choices can feel, not just analyze, what users are experiencing.
The lighthouse metaphor is imperfect, as all metaphors are. But its core insight holds.
A lighthouse does not steer the ship. It does not set the course or manage the crew. Its role is singular: to illuminate what others cannot see. To stand fixed on the shore of reality while the ship moves through darkness, and to throw light on the rocks that momentum and ambition would otherwise obscure.
The design leader who does this well becomes indispensable. Not because she has the best ideas or the most authority, but because she has something rarer: credibility rooted in direct observation. When she says there are rocks ahead, she is believed. When she advocates for a direction, her advocacy carries weight. When she challenges a decision, her challenge is taken seriously. Because everyone in the room knows that her conviction is earned, not borrowed. That she has seen what she claims to see.
This credibility cannot be faked. It cannot be performed. It can only be built, slowly and deliberately, through the accumulated practice of staying close.
The temptation to board the ship will never go away.
The organization will always invite the lighthouse aboard. The invitation will always feel like recognition, like advancement, like the natural reward for good work. And in many ways, it is. Design leaders should have seats at the leadership table. They should be involved in strategy, in budgeting, in the decisions that shape the company's direction.
But they should not confuse being at the table with doing the job. The table is where decisions are made. The shore is where the information that should inform those decisions lives. A design leader who spends all her time at the table will eventually find that she has nothing distinctive to contribute to it. She will see what everyone else sees. She will know what everyone else knows. She will become, in effect, just another executive with opinions.
The discipline is to do both. To sit at the table and walk the shore. To attend the strategy meeting and read the support tickets. To participate in the planning process and watch the user struggle with the thing that was planned. To hold both altitudes at once—the view from the deck and the view from the coast—and to make sure the second one keeps informing the first.
This is hard. It requires defending time that the organization will constantly try to claim. It requires accepting that some of the most important work a design leader does will never appear on a roadmap or a performance review. It requires a kind of faith—faith that the investment in proximity will pay off, even when the returns are difficult to measure.
But the alternative is worse. The alternative is the fog. The alternative is the leader who no longer knows what users are experiencing, who relies on borrowed conviction, who advocates for positions she can no longer defend from personal observation. The alternative is the lighthouse that has drifted so far from shore that its light no longer reaches the rocks.
Design leaders are fond of saying they give users a voice. This is true, but incomplete.
Users have voices. They use them constantly—in support tickets, in feedback forms, in the workarounds they invent when products fail them. The problem is not that users are silent. The problem is that organizations are structured to muffle them, to aggregate and summarize and abstract until the individual voice becomes a data point and the data point becomes a trend and the trend becomes a line on a chart that no one looks at too closely.
The design leader's job is not to give users a voice. It is to make their existing voices impossible to ignore. To carry their words, their frustrations, their specific and irreducible humanity into rooms where specificity is usually sanded away. To protect the texture. To resist the compression. To shine light on the shore until the ship has no choice but to change course.
This is the work. Not the only work—there are systems to build, teams to manage, stakeholders to align. But the essential work. The work that justifies the title.
A lighthouse, tended carefully, burning through the night.