“High-control situations” is the term practitioners use for environments that restrict autonomy through a combination of ideology, social pressure, and punitive consequences for departure. It applies to high-control religious communities (the BITE model covers the full architecture of these groups, and once you read it you will recognize environments you thought were ordinary). It applies to abusive intimate partnerships, where the control is interpersonal rather than institutional but the mechanism is identical. And it applies, more than the tech industry likes to admit, to certain workplaces: the startup that runs on fear, the charismatic founder who has constructed a universe in which their judgment is the only valid data point, the company culture so totalized that employees apologize for having thoughts that diverge from the official narrative.

What these environments share is not their specific ideology. They share a method. Control of information, control of relationships, and systematic punishment of dissent, administered alongside enough warmth and belonging that leaving feels more dangerous than staying. When someone finally goes (or is expelled, which is its own category of wound), they carry the behavioral adaptations that kept them safe. Those adaptations do not dissolve when the environment does. They walk in through your door on their first day.

In computing, a permissions model governs who can read a file, write to it, execute it. Permissions are not suggestions. They are enforced at a level below the user’s control. A person who has spent years in a high-control environment has had their permissions managed externally: what they were allowed to think, who they were allowed to speak with, which of their internal states were valid and which were symptoms of disloyalty. High-control groups restrict information (no outside media, no contact with former members), relationships (shunning, accumulated social debt as leverage), and internal experience (confession structures, purity culture’s surveillance of thought). By the time someone leaves, the external permission structure has often been internalized so completely that they cannot reliably distinguish their own preferences from the ones that were installed.

This is what shows up at work. Not the theology, not the specific rules. The operating system.

The behaviors are consistent enough across contexts that once you know what you are looking at, you cannot un-see them. A constant, low-grade scan for what the person in charge actually wants, so the correct opinion can be produced on demand. Genuine distress at ambiguity, not mere discomfort, because high-control environments run on certainty and the absence of clear rules feels like danger. A disproportionate relationship to mistakes: in a high-control system errors carry moral weight, and a typo in a presentation can produce self-reproach that makes no sense unless you understand what it was trained on. Difficulty saying no. Difficulty believing that no will not produce punishment. And frequently, an extraordinary work ethic that is not entirely healthy: the loyalty-through-output dynamic, the belonging-through-sacrifice logic, the performance review that should feel like a win but does not land, because in the previous environment approval was always provisional, always the setup for the next demand.

The toxic workplace version is the one the tech industry is most responsible for and least willing to examine. I have been in rooms with founders who ran their companies on a controlled information loop: the story told publicly, the story permitted internally, and the actual state of affairs were three different things. Employees who noticed the gap were managed out or exhausted into compliance. The ones who stayed learned to see only what they were supposed to see. That is a high-control dynamic. It does not require a theology. It only requires power, consistency, and the threat of exclusion. Someone who spent two or three years inside that and then joins your organization has been trained to suppress their own pattern recognition, to distrust their own discomfort, to perform certainty about the official narrative even when it is visibly wrong. That training does not expire.

I have been autistic my entire career, even the years before I knew the word for it. In practice that meant I had already developed a habit of reading environments carefully and producing approximations of expected behavior, because the direct expression of how I actually processed the world was rarely what was wanted. I did not live through a high-control situation in the formal sense, and I want to be careful not to claim equivalence where there is only adjacency. But I have some understanding of what it is to spend a significant portion of your cognitive budget running a continuous scan: what is acceptable here, what will be punished, what do these people actually want versus what they say they want. That shared texture is what makes me notice the breath-hold. It is also, I suspect, what makes me take it seriously.

What does not help is moving fast.

The instinct in startup culture is to throw someone in the deep end. They will acclimate. For many people this is fine. For someone rebuilding their sense of what they are permitted to think and say, a fast environment is just another system to frantically reverse-engineer for rules, another authority structure to read, another test they cannot quite believe they are allowed to pass.

What does not help is asking for vulnerability before you have demonstrated that vulnerability is safe. “We have a culture of radical candor here” is potentially alarming to someone for whom radical candor was the thing that got people expelled. They will nod. They will perform it. They will not actually practice it, because they have no evidence yet that it is not a trap. They are in read-only mode: receiving, processing, not yet willing to write to the shared environment, because in the previous one, writes that fell outside the expected schema were deleted.

What does not help is treating their compliance as a signal. High-control survivors are often skilled at producing exactly what the room appears to want. The person nodding enthusiastically in the all-hands may genuinely agree, or may be performing agreement while running a threat assessment in parallel. The person who never escalates problems is not low-maintenance. They are someone who has not yet decided whether you can be trusted with the truth. Mistaking that performance for engagement is how you lose them quietly, and you usually only find out they were gone months before they resigned.

What actually helps is less exciting to describe but more useful to practice.

Consistency. The single most stabilizing thing a functional workplace can offer is the repeated experience of stated norms being enforced. If you say mistakes are learning opportunities, and then someone makes a mistake, and you treat it as a learning opportunity, that is one data point. The first of many needed before the capacity to trust stated intentions can begin to rebuild. One instance is nowhere near enough. Ten instances might begin to register. The timeline is genuinely slow, and the responsibility sits with the leader, not with the person doing the recalibrating.

Explicit permission. “I am asking because I actually want to know” is more useful than it sounds, said to someone for whom that sentence was historically untrue. “You are allowed to disagree with me” is more useful still, stated once, then demonstrated, then stated again, then demonstrated again. Explicit permission given freely and shown not to be a trap is how you begin to help someone replace an externally managed permission system with one they own.

Patience with the gap between output and affect. The person producing extraordinary results while visibly running on anxiety is not fine. They are doing what they were trained to do in a context that required constant performance of adequacy. “You don’t have to work this hard” is genuinely worth saying aloud. So is “I notice you seem worried about this, and I want you to know the stakes are lower than they might feel.” These sentences can seem obvious. They are almost never said.

The people I am writing about are not broken. The management literature, when it addresses trauma in the workplace at all, tends to do so with the clinical remove of someone describing a country they have never visited. But broken is the wrong frame entirely. These are people whose threat-detection system was calibrated in an environment very different from the one they are currently in, and the recalibration takes time and safety and the unremarkable experience of simply not being punished for having an opinion.

Some of the most precise thinkers I have worked with came out of high-control environments. The hypervigilance, when it has somewhere useful to go, becomes extraordinary attention to detail and atmosphere. The pattern recognition that once kept them safe, freed from the work of self-protection, can see what everyone else in the room is missing. The person who spent years learning to read a room can, when they finally trust a room, read it at a depth that is genuinely rare.

What wastes that is a leader who does not recognize what they are looking at, mistakes the silence for contentment, and later wonders why the quietest person on the team somehow always saw the problem coming before anyone else did.

The breath-hold before speaking: I still see it. What I know now is that the question is not why they are hesitating. The question is what it would take to build the kind of room where they did not have to.

That is the work. It does not fit in a sprint cycle and it does not map onto an OKR. But it is what separates a workplace from just another context where someone learned to be careful, and the people who have been through those contexts know the difference, even when they are not yet certain they are allowed to say so.

There is a related pattern worth examining separately, one that does not require a history of control to produce its effects. It operates not on people recovering from high-control situations but on capable people who never needed rescuing at all. It is about how workplaces grant access to the context that makes work possible, and who gets made to ask for it. Specifically: what happens when a highly capable woman is brought in for something important, and then systematically not given what she needs to do it.

That is Part 2, coming next week.

I’ve been in tech for almost two decades. I’ve worked infrastructure, product, support, strategy. I’ve been the person in the hoodie keeping the lights on at 2am, and I’ve been the person on stage talking about organizational culture. I’ve been laid off and I’ve laid people off. I’ve been through the whole buffet. And I’m telling you: LinkedIn is doing something to us that we haven’t fully reckoned with.

It’s not just vanity. It’s something more insidious.

The first thing LinkedIn does is compress time. Everyone’s accomplishments appear in the same undifferentiated feed, stripped of context and duration. The person who spent eight years grinding before their “overnight success” shows up right next to the 27-year-old who raised a Series A. There’s no metadata. There’s no “this took a decade of failed attempts.” There’s just the announcement, the confetti, and the three hundred congratulatory comments from people who work at competing firms and are networking in real time while they type.

What you’re actually looking at is a highlight reel curated specifically to maximize professional status signaling. But your brain processes it as: everyone is moving faster than you.

The second thing LinkedIn does is manufacture a very particular flavor of fake vulnerability.

You know the posts I’m talking about. “I was let go eighteen months ago and I was devastated. I want to be honest about that. [paragraph break] But it turned out to be the best thing that ever happened to me. I’m now the CEO of a company doing $4M ARR and I’ve never been more aligned with my values. Growth mindset wins.”

This is not vulnerability. This is a redemption arc with the ending pre-loaded. Real vulnerability doesn’t come with a punchline. Real vulnerability is “I was let go and I still don’t know if I’m okay.” The LinkedIn version is vulnerability as currency, traded for engagement points and the warm glow of being seen as both relatable and successful simultaneously. It’s a trick, and the trick works because most of us are desperate for the relatable part and mistake it for the real thing.

For people like me (and there are a lot of us, more than anyone talks about), the neurodivergent people who already spend enormous cognitive energy trying to decode what’s authentic versus what’s performed, this particular genre of content is exhausting in ways that are hard to articulate. It’s not just annoying. It creates a kind of sensory overload of performed sincerity that makes it genuinely difficult to trust what you’re reading.

The third thing LinkedIn does is gamify comparison in a way that has no natural endpoint.

Social comparison is something humans do constantly. It’s not inherently pathological. The problem is that most natural environments for comparison come with limiting factors: you can only really compare yourself to the people in your actual life, your actual city, your actual industry cohort. The comparison has texture. You know these people. You know their struggles, their advantages, their context.

LinkedIn removes all of that. It is comparison without context, at scale, optimized by an algorithm that has learned that you engage more when you feel inadequate than when you feel secure. The scroll continues because the discomfort continues, and the discomfort continues because the algorithm keeps showing you the people whose trajectories look, from the outside, like everything yours is not.

And here’s the part that nobody says out loud: you can’t win. If you close the app feeling superior, you’ve revealed something uncomfortable about yourself. If you close the app feeling inferior (the much more common outcome), you’ve just handed a billion-dollar company your emotional state in exchange for nothing. There is no good ending to the session.

I want to be careful here not to do the thing I just criticized, which is wrap this up with a tidy lesson and a call to action that makes me sound simultaneously wise and humble.

So I won’t do that.

What I will say is that the people I’ve known in tech who seem most genuinely grounded, most actually successful in ways that survive contact with reality, are almost uniformly bad at LinkedIn. They post rarely. They don’t have the cadence down. Their content doesn’t perform because it’s not optimized for performance. It’s just true, which means it doesn’t hit the same dopamine notes and gets fewer impressions and doesn’t build their “personal brand” in any measurable way.

I find that genuinely encouraging, even if it’s not actionable.

The depression you feel after five minutes on LinkedIn is information. It’s telling you that you’ve just spent five minutes in an environment designed to make you feel like you’re losing a race you didn’t sign up for, measured by metrics you didn’t choose, against a field of competitors who are mostly performing rather than actually competing.

Closing the app is a complete sentence.

We had no equivalent visibility into the people running those systems. The engineer who resigned had been running at critical load for six months. We found this out in the exit interview.

I have thought about that moment for years, and what I keep returning to is not the failure of management, exactly, though there was that. What I keep returning to is the infrastructure gap. We were a team that cared deeply about observability. We had Prometheus scraping metrics, Grafana rendering them into dashboards, PagerDuty routing alerts to the right people at the right time. We had runbooks for every failure mode we could imagine. We had blameless postmortems when things went wrong. We had, in other words, a rigorous and sophisticated framework for understanding the state of our technical systems, and we applied approximately none of that rigor to understanding the state of our team.

This is the central contradiction of the high-performing startup: the same engineering culture that demands observability, redundancy, and graceful degradation from its software routinely builds teams with none of those properties.

In distributed systems, service discovery is the mechanism by which services locate each other on a network. The naive approach is to hardcode an address: Service A always lives at this IP, this port. It works until it doesn’t, which is usually at the worst possible time. Services scale up and down, get replaced, move across infrastructure. The hardcoded address becomes a lie the moment anything changes. Proper service discovery replaces static assumptions with dynamic queries: before communicating, a service checks a registry to find out where the thing it needs actually is right now.

The way we relate to our colleagues is almost always hardcoded. We know where to find them in the sense that we know their Slack handle and their calendar. We have a model of who they are that was formed during onboarding or a handful of 1:1s and has been gently calcifying ever since. We treat that model as an address: stable, reliable, findable at the same location it has always been. We do not run service discovery against the actual person. We do not check the registry to find out where they actually are right now, what load they are running under, whether the endpoint that used to respond in milliseconds has started timing out.

The consequences of this in a post-growth startup are specific and severe. The post-growth environment, which is to say the environment most startups have been operating in since the funding climate tightened and the easy money stopped, is characterized by reduced headcount doing increased work under elevated uncertainty. The team that once had twelve engineers now has seven. The roadmap has not shrunk proportionally. Everyone is, by any reasonable measure, running at high utilization. High utilization, in infrastructure terms, is when you want your observability to be sharpest, because a system running at 90% capacity has almost no margin before it starts degrading, and degradation under load tends to be nonlinear. A small additional pressure produces a disproportionately large failure.

The technical term for designing against this is building for graceful degradation. When load exceeds capacity, the system sheds work in a controlled way rather than collapsing entirely. You implement circuit breakers, popularized in distributed systems by teams like Netflix, which detect when a downstream service is struggling and stop sending it requests before it fails completely. You shed the less critical work first. You protect the core.

The human equivalent of a circuit breaker is a manager who notices that someone is at capacity and removes work from their plate before the system fails. This sounds obvious stated plainly. It almost never happens in practice, because the observability layer does not exist. You cannot react to a signal you cannot see. And the signals human beings emit when they are approaching failure are often counterintuitive: the overloaded engineer who gets quieter in meetings, more efficient in communication, less likely to push back on scope. From the outside, this can look like performance. It is often the last stage before the resignation letter.

What would it mean to actually apply engineering discipline to team health? It would mean defining what “healthy” looks like before you need the definition. Not in the vague language of culture decks (”we are a team that supports each other”) but in the operational language of SLOs: we do not assign more than two concurrent project threads to a single engineer; a person who has flagged overload gets scope removed within five business days; managers conduct genuine load assessments in 1:1s on a defined cadence rather than asking “how are you doing?” as a social ritual that everyone understands to mean nothing.

It would mean building runbooks for human failure modes the same way you build them for infrastructure failure modes. When a team member is showing early signs of burnout, the runbook says: first, do this. Then this. This is who you escalate to if those steps don’t resolve the situation. The runbook exists not because leadership is indifferent but because without documentation, the response to a human incident is improvised by whoever is closest to it, which produces inconsistent outcomes and guarantees that whatever happened will happen again.

It would mean treating the exit interview as the postmortem it actually is. Not as a formality to be completed before offboarding paperwork but as a serious attempt to understand what the system failed to detect and when. And it would mean, as with any good postmortem, making the process blameless. Not “what did this manager do wrong” but “what did this team’s observability layer fail to surface.”

I am autistic, which means I have spent most of my career building explicit internal models of social systems that other people navigate intuitively. It also means I have a reasonably high tolerance for making the implicit explicit, for saying the thing that everyone in the room already knows but no one has put in writing. What I know from two decades of watching teams work and fail is that the most expensive operational mistake a startup can make is not a database migration gone wrong or an API design you have to reverse. It is treating your people as infrastructure that requires no monitoring until it goes down.

Your Kubernetes cluster does not wait until it is failing to tell you it needs attention. You designed it that way on purpose. You can design your team that way too, if you decide that the people running the cluster are worth the same engineering rigor as the cluster itself.

Most organizations have not yet decided that. The exit interviews will keep being surprises until they do.

I did not connect this to anxiety for a long time. I thought it was efficiency. I thought I was staying on top of things. What I was actually doing was performing productivity for an audience of one, which is a strange theater to find yourself in, but a very common one in the technology sector, where the question of whether you are doing enough is always quietly present and almost never answered.

The allure of appearing busy is not, I want to be clear, about laziness or deception. It is not primarily about fooling your manager or padding your calendar to avoid additional assignments, though those things happen. It is about something more basic and more sympathetic than that. Being visibly busy is one of the few reliable ways to temporarily silence the question of whether you are valuable enough, contributing enough, present enough. Activity is legible. It has a shape that other people can see. Deep thinking does not. Strategy does not. The four hours you spent in a state of near-total stillness while your brain worked through a hard architectural problem does not look, from the outside, like anything at all.

This is partly an office design problem. The open-plan workspace, which the technology industry adopted with considerable enthusiasm in the 2000s and has only recently begun to question, is a panopticon organized around the premise that visible activity equals productive activity. If you are at your desk and your fingers are moving, you are working. If you are at your desk and you are staring at the middle distance with your hands in your lap, you are not working, or at least you risk appearing not to be, which in a performance-evaluation context amounts to the same thing. The architecture of the space trains you to perform busyness the way a stage trains an actor: you are always potentially in view, so you are always potentially on.

Slack formalized this performance in software. The green dot is a status indicator in the technical sense, but it is also a status indicator in the social sense. Being available, being responsive, being seen to be engaged: these are the signals the platform is built to generate and reward. The person who replies within four minutes to every message in six channels is legible as a contributor in a way that the person who went dark for three hours to produce the technical design document that will save the project is not, at least not in real time, which is the only time that the always-on communication layer knows how to measure.

I have watched startups hollow themselves out this way. The culture rewards velocity of response, so people optimize for velocity of response. The meetings multiply because meetings are visible, because being in a meeting is an unambiguous answer to the question of what you are doing right now. The Slack channels fill with status updates and reactions and threads about the threads. Everyone is busy. The roadmap does not move.

There is something particular that happens to neurodivergent workers in this environment, and it took me a long time to name it accurately. For those of us with ADHD, the performance of busyness and the experience of busyness are often radically disconnected. The ADHD-i brain is either hyperfocused or it is not focused, and neither state is especially legible as conventional productivity. Hyperfocus looks, from the outside, like someone who has been staring at the same screen for four hours without moving or responding to messages. Absence of focus looks like exactly what it is. Neither produces the steady, metronomic appearance of work-in-progress that open-plan office culture reads as engaged.

The autistic brain has a different problem, which is that the energy required to perform a social state (busy, available, visibly engaged) competes directly with the energy required to actually think. Masking, the process by which many autistic people learn to present neurotypical behavior in neurotypical environments, is metabolically expensive in a way that is genuinely difficult to explain to people who have never had to do it. If I am spending energy making sure I look appropriately occupied, I am not spending that energy on the problem I was hired to solve. The performance consumes the resource it is meant to signal.

What this means at a structural level is that the organizations most addicted to the theater of busyness are systematically undervaluing the people most capable of the kind of work that cannot be performed. The deep thinker who needs long stretches of uninterrupted stillness. The engineer who solves the problem in the shower after two days of apparent inactivity. The strategist who has learned that their best thinking happens in the early morning before anyone can see them, and who therefore arranges their calendar to protect that time, and who is often perceived as difficult or insufficiently collaborative as a result.

The allure is real, and I want to sit with that for a moment rather than dismiss it. The performance of busyness works, in the short term, for reasons that are psychologically legitimate. It reduces anxiety. It provides social cover. It generates the small neurological rewards of visible completion (the email responded to, the Slack message reacted to, the meeting attended and survived) in place of the large and often delayed rewards of actual output. If you are a person who lives with the chronic low-level fear that you are not enough, that you are about to be found out, that the thing you are supposedly expert in is about to exceed your grasp, then a day spent visibly busy is a day that provides continuous small proofs against that fear. A day spent in deep, invisible work is a day that requires you to sit with the fear for hours at a stretch, trusting that what you are doing is real even when it cannot be seen.

That is a hard thing to ask of anyone. It is a particularly hard thing to ask without providing the structural conditions that make it possible: protected time, async-first communication norms, evaluation systems that measure output rather than activity, and leadership that does not confuse presence with contribution.

The organizations that figure this out tend to do it the hard way, after watching their most productive people disappear. The deep thinkers almost never quit loudly. They just gradually reallocate their energy toward the parts of their lives where their actual output is visible and valued, and they do less and less of the work that was the whole reason they were hired in the first place.

Then they leave. And everyone is surprised.

I came to the Macintosh SE late, as a child who encountered one in a library in the early nineties, but I have spent probably more hours than is healthy thinking about what it represented. Not as nostalgia, though there is certainly nostalgia in it, but as a design argument that the industry has spent forty years walking away from and that I believe we need to walk back toward. Especially those of us whose brains were not built for the world we accidentally built.

The Macintosh SE of 1987 ran one application at a time. Not because it had to, exactly. The machine shipped with one megabyte of RAM, and MultiFinder, Apple’s first real attempt at cooperative multitasking, had just arrived that same year as an optional add-on. Most users left it turned off. The single-application model was a choice, and it was a choice rooted in a philosophy that Jef Raskin had sketched years earlier when he first imagined the Mac project. Raskin was long gone from Apple by the time the SE shipped, but his foundational conviction survived three years of product iterations and two leadership changes intact: the Mac was supposed to be honest about what it was doing. It was supposed to do one thing at a time, and to be transparent about what that thing was. The menu bar told you which application owned the screen. The screen filled completely with that application. There was no taskbar full of other things hovering at the edge of your peripheral vision, asking to be clicked.

For an ADHD-i brain, this was not a limitation. It was a boundary.

I did not understand my own neurology for most of my working life. What I understood was that I was better at work when I could not see other work. I was better in environments that had imposed a kind of structural honesty about what the task was, because the executive dysfunction that comes with ADHD-i is not primarily about the ability to work. It is about the ability to choose the work, to start the work, to resist the ambient pull of the seventeen other things that are also technically the work. When a machine could only show me one application, that choice was made for me. The disk was in the drive. The application was on the screen. That was what we were doing today.

There was also something deeply important happening in the physical ritual of it. You inserted a 3.5-inch floppy disk and you waited through the grinding, searching sound of the drive reading it. That sound was a threshold. The mechanical resistance of the disk sliding into the slot, the audible effort of the machine understanding what you had given it, the moment when the icon appeared on the desktop: these were transitions, and transitions matter enormously to brains that struggle to manufacture them internally. The ritual of loading was doing the work of executive function. It was the external scaffolding for a context switch that my brain needed but could not reliably provide on its own.

Modern computing has eliminated transitions almost entirely. The laptop opens mid-session, Chrome reloads its last forty-seven tabs, Slack resurfaces every conversation you were in when you last closed the lid. The machine has no sense of before and after. It does not acknowledge that you left and came back. It simply resumes, mid-sentence, mid-thought, as though no time has passed, as though you have no need for the cognitive equivalent of clearing your throat before you speak.

This is framed, always, as convenience. And it is convenient, in the way that a fire hose is a convenient source of water if you are already on fire and do not need to aim.

The tab culture that contemporary knowledge work has produced is a sensory environment that is explicitly hostile to the kind of sustained thinking that product strategy requires. Strategy is not fast. Strategy is not reactive. Strategy is the work of sitting with a problem long enough that you begin to see its shape, long enough that the easy wrong answers exhaust themselves and the harder right ones start to emerge. That kind of thinking cannot happen in a cognitive environment organized around the shortest possible interval between stimuli. It cannot happen when the pull of the unchecked notification is always present, always offering the small neurological reward of resolution in place of the large neurological cost of sustained uncertainty.

The ADHD brain is particularly susceptible to this, and the irony is that ADHD brains are disproportionately represented in the startup culture that has built and celebrated these tools. We built the infinite scroll. We built the notification system that will not stop. We built the always-on communication layer. And many of us built it while quietly struggling with exactly the kind of focus fragmentation it was going to create for everyone else.

What the Mac 128K knew, accidentally and structurally, was that a tool that forces you to choose is a tool that respects the cost of choosing. Every toggle you add to a system, every parallel process you run in the background, every tab you allow to persist is a claim on cognitive space. That machine made no such claims. It held one thing and held it completely. When you were done with it, you ejected the disk. The machine returned to its sparse, honest desktop. The slate was clean.

I am not arguing that we return to single-threaded computing. I am arguing that we could learn something from the philosophy underneath it when we design the environments in which we expect people to produce their best work. A meeting culture that allows twelve calendar items in a day is not multitasking. It is a context-switching tax so large that it consumes the entire workday in the overhead of switching. An organizational norm that treats the always-open laptop as a sign of engagement is not measuring work. It is measuring the performance of availability, which is not the same thing and never was.

The Macintosh had a physical switch because the people who made it understood that a clear state boundary was a kindness. On and off. Present and away. Working and resting. Those of us whose brains require external structure to manage internal transitions have always known this. The machine knew it too, for one brief, underappreciated moment, before the industry decided that what people really wanted was everything, always, all at once.

They were wrong. But the power switch clicked so nicely that I still remember it.

I have been in the technology sector for nearly two decades. I have shipped infrastructure, led teams, sat in enough all-hands meetings to have strong opinions about the optimal length of an all-hands meeting (it is twenty minutes, and you are all wrong). I have watched the communication layer of our industry transform so completely that the old protocols feel like archaeology. And what I keep coming back to, in conversations about burnout and neurodiversity and why the most interesting thinkers at every company I have ever worked for tend to go quiet and then go away, is this: we broke the latency on purpose, and we called it productivity.

The baud rate, for those who came up after the modem era, is a measure of signal transmission speed. A 300 baud modem in 1982 could transmit roughly 300 bits per second. At that speed, text appeared on your screen character by character, like the machine was reading the message aloud to itself. Then came 1200, 2400, 9600 baud. The physics of copper wire and analog signal created an enforced ceiling on how fast humans could exchange information. That ceiling, it turns out, was doing a lot of social work that we did not appreciate until it was gone.

Usenet newsgroups operated on a propagation model. A message posted to a newsgroup did not arrive everywhere at once. It traveled from server to server across the network over hours, sometimes days. Threads developed slowly. A question asked on a Tuesday might gather its best responses by Thursday. This was not a bug. It meant that when you arrived at a thread, you were arriving at a conversation that had already had time to breathe, to attract the people who had something worth saying, to filter out the reflexive and reward the considered. The NNTP protocol was, accidentally and beautifully, a cognitive accessibility tool.

I did not know I was autistic for most of my career. What I knew was that I was slow in meetings, that I needed time to think before I spoke, that I gave answers to questions approximately forty minutes after the meeting ended when I sent the follow-up email that contained the actual substance of my thinking. What I knew was that I was fast in writing, in async threads, in the kind of communication where the expected response time was measured in hours rather than seconds. I was, as it turns out, operating at a baud rate that the open-plan office and the real-time chat window were not designed to accommodate.

Slack is an extraordinary product. I want to be clear about that because this is not an argument against the tool. It is an argument against the culture that has grown up around the tool like kudzu around a fence post. The green dot. The read receipt. The “typing...” indicator that appears and disappears, appears and disappears, like someone on the other end of a phone call breathing too loud. These features, individually unremarkable, collectively create an ambient pressure that says: you should be here, you should be fast, your silence is suspect.

The cost of that pressure falls unevenly. For the neurotypical extrovert who thinks in real time and performs their thinking in public, Slack is a native environment. For the autistic brain that needs to move through a processing cycle before it can produce language, the green dot is a constant reminder that the environment is watching you not respond fast enough. For the ADHD brain that has finally, after ninety minutes of deep work, managed to get the problem fully loaded into working memory, the ping from a channel is not a message. It is a core dump. Everything scattered. Start over.

What gets lost is not just the comfort of individual contributors. What gets lost is the thinking itself. The deep thinker, the person who produces their best work in extended, uninterrupted focus, is structurally disadvantaged in a culture organized around immediate response. They learn, quickly, that the way to survive is to perform availability rather than produce insight. They keep the app open, they react with emojis, they respond to the simple things fast so that the expectation of fastness does not attach itself to the hard things. They code-switch, as neurodivergent people have always code-switched, between who they are and what the environment will accept.

The concept I want to offer here is what I have started calling latency-tolerant leadership. It is the organizational equivalent of that old Usenet propagation model, and it is built on a simple premise: the response time of an idea is not a measure of its quality.

Latency-tolerant leadership looks like this in practice. It means your team norms explicitly say that a message sent does not require an immediate reply, and that norm is actually enforced by how leaders themselves behave. It means design reviews have a written comment period before any synchronous discussion, so that the person who needs seventy-two hours to form their real opinion is not steamrolled by the person who has a loud opinion at t-plus-fifteen-minutes. It means the performance review system stops treating “collaborative and communicative” as a proxy for “responds to Slack quickly” and starts asking what the person actually built, thought, and shipped. It means you hire for depth and then create the conditions where depth can do its work.

None of this is new. The engineering discipline has had decades-long arguments about the value of asynchronous communication, and the remote-first movement pushed many teams toward written, async-native workflows out of necessity. But there is a difference between tools that support asynchronous work and a culture that genuinely tolerates latency, that does not flinch when someone takes three hours to think before responding, that does not silently penalize the person whose Slack status goes dark for a four-hour stretch because they were, in fact, doing the best work of their quarter.

The baud rate of empathy is not measured in milliseconds. It is measured in the depth of what arrives. And right now, we are running enterprise culture at the speed of anxiety, optimizing for the signal that comes back fastest rather than the one that comes back true.

The deep thinkers have not gone quiet because they have nothing to say. They have gone quiet because the channel is too loud to transmit what they actually mean.

As a young person, my ambition wasn’t rooted in the typical markers of success like titles or corner offices. I wanted to understand how things fit together. I spent hours staring at the blinking cursor of a Commodore 64, typing out lines of BASIC just to see the screen change color. My inner child didn’t want to be a “Leader of Infrastructure” or a “Strategy Consultant.” I wanted to be a builder of worlds where the rules were consistent and the feedback was immediate.

The problem with the tech sector is that it takes that pure, obsessive childhood curiosity and tries to turn it into a quarterly roadmap. We enter the industry with a love for the Apple IIe and a fascination for how TCP/IP connects us across the void (only to find ourselves years later sitting in “strategic planning” meetings that feel like they are draining the very marrow from our bones).

Healing the inner child in this context isn’t about some nebulous, “woo-woo” concept of self-care. It is a technical debt exercise. For the ADHD-i mind, our ambition was often a sprawling, beautiful mess of interests that people called “distractions.” We were told to focus, to narrow our scope, and to pick a lane. We learned to mask our wandering thoughts to fit into a corporate culture that values a straight line over a fascinating detour.

To heal is to realize that the “what do you want to be” question was always a trap. It implies a finished state. It suggests that once you reach the destination (the “Director” level or the successful exit) the work is done. But for the autistic soul, the joy was always in the process. It was in the way a Lego brick clicked into place or the way a complex piece of Linux kernel code finally compiled without errors.

I am learning to look back at that younger version of myself (the one who sat in the back of the class drawing diagrams of space stations instead of doing long division) and tell them that their “lack of focus” was actually a superpower. We were never meant to be just one thing. We were meant to be the connective tissue between the machine and the human experience.

If we want to fix the burnout crisis in tech, we have to stop asking our employees to leave their childhood wonder at the door. We need to create space for the “special interests” that drive innovation. We need to remember that before we were “resources” or “headcount,” we were just kids who thought the World Wide Web was the closest thing to real magic we would ever see.

We in the tech sector, especially in the breathless, venture-fueled atmosphere of the startup world, have built a religion around the concept of iteration.

We obsess over the Minimum Viable Product (MVP). We launch a v1.0, gather metrics, learn from the data, and then refine. We practice Agile development, Scrum, and Kanban (we have a thousand sophisticated frameworks to simply say, “Try again, but faster”).

But here is the million-dollar question: Why do we treat empathy (the fundamental requirement for good product, good support, and good leadership) as a static personality trait that you either downloaded at birth or you didn’t?

Empathy is not a feature. It is a system. And like any system in a dynamic environment (like a relationship, a company, or a network protocol), it needs constant debugging and upgrades. It needs iteration.

The Neurodivergent Feedback Loop

For many of us who are hard-wired differently (myself included, navigating the world with the dual-stack architecture of Autism and diagnosed ADHD-i), empathy is explicitly not an automatic download. It doesn’t run on instinct. It is a meticulously engineered system.

We have to consciously seek data (facial cues, tone, body language), run it through a complex logical parser (the ‘social context engine’), and generate an appropriate, human-centered response. This is iteration in action. The reason it can feel exhausting is that we are constantly running a parallel process: Build, Measure, Learn (BML).

If we can apply the BML loop to our infrastructure (which we do religiously, measuring latency and throughput), we can certainly apply it to our leadership and communication.

The Minimum Viable Empathy (MVE)

Stop trying to deploy a fully-featured, perfect solution the moment someone expresses pain or frustration. That is the Waterfall model of empathy (long, rigid, and prone to catastrophic failure).

Instead, seek the Minimum Viable Empathy (MVE). The MVE is the smallest possible empathetic action that validates the other person’s emotional state while requiring the least effort (and therefore lowest risk) from you.

The process of Iterating Empathy looks exactly like your product roadmap:

1. The Build Phase (Observation/Data Collection)

Stop preparing your response. This is the hardest part for technical minds (we are geared to solve, fix, and explain). Instead, enter listening mode. Collect qualitative data. What is the user (your teammate, your customer) actually saying? What is the feeling they are emitting (anger, fear, shame)?

2. The Measure Phase (Deploying the MVE)

Once they pause, deploy your MVE. This is your first tiny, reversible release. It is not a solution. It is pure validation.

• MVP response: “That sounds incredibly frustrating.”

• MVP response: “I hear the weight in your voice, and that must be exhausting.”

• MVP response: “So, if I understand correctly, the outcome was X, and the feeling that created was Y. Is that right?”

This measured response is your Minimum Viable Product (MVP). You are testing a core hypothesis: “Is validation the thing this user needs right now?”

3. The Learn Phase (The Feedback Loop)

Observe the immediate result. This is your critical feedback loop. Does the person’s body language soften? Do they visibly relax? Do they sigh and then open up with more detail? If so, your MVE was successful. The system has stabilized. You have gained validated learning.

If they tense up or correct you (”No, it’s not frustrating, I’m just furious!”), then your MVP failed. You need to quickly branch the code and deploy an emergency patch. “My mistake. I hear you’re furious. Tell me more about that.”

Later, during your personal ‘retrospective’ (perhaps during your walk home or your hyperfocus deep-dive), you analyze the failure: What non-verbal cue did I miss that indicated fury instead of frustration? Document the finding (mental Jira ticket, maybe).

The Continuous Delivery of Trust

The best infrastructure I ever built (and I’ve built a lot) wasn’t the globally distributed one running on redundant fiber. It was the network of trust with my team. It turns out that people perform better, debug faster, and solve more complex problems when running on a steady supply of trust and psychological safety, rather than just cold brew coffee.

Stop waiting for the perfect, comprehensive empathy patch to magically appear. Start treating empathy like the critical business tool it is—a system that requires constant tuning, small, frequent releases, and an unwavering commitment to the iterative feedback loop. Ship often, and ship human.

I’ve come to realize that this entire ecosystem is defined by three interdependent forces: hope, potential, and exposure.

Hope: The Fuel of the Fool’s Engine 💡

Hope is the engine of the startup. It’s the completely irrational belief that this specific piece of technology, or this unique combination of people, will succeed where thousands of others have failed.

We often try to dress this up as “data-driven” or “market analysis,” but deep down, every founder, every product manager, and every engineer pushing a truly disruptive idea knows they are operating on sheer, unadulterated optimism. Hope is what allows you to look at a terrifyingly complex technical challenge (like achieving global scale, or figuring out generalized AI) and say: “Yeah, we can handle that.”

Hope is an act of defiance against the inevitable failure that statistical models predict. It’s the energy that keeps you coding at 2 AM (when every rational thought is telling you to go to bed). And crucially, hope is contagious (it’s the only way to convince other talented people to abandon stable jobs and join your wild ride).

Potential: Betting on the Unformed 🚀

Hope focuses on the outcome; potential focuses on the inputs—the messy, unpolished, often overlooked starting elements.

Potential is why VCs fund a founder with a shaky pitch but clear intensity. It’s why you hire that junior developer who lacks framework experience but possesses a relentless curiosity. We are not just building products; we are in the business of identifying and unlocking untapped human and technological capabilities.

Think about the origins of personal computing. When the Altair 8800 first appeared (a simple box with blinking lights), it had almost zero practical function for the average person. Its potential was theoretical, messy, and totally dependent on brilliant people seeing beyond the solder joints and imagining an entire industry. That is what potential is: the raw, untamed capacity for greatness.

In a strong team culture, you don’t just manage current performance; you coach and nurture potential. This requires a tremendous amount of empathy, because tapping into potential means accepting failure, letting people struggle (and often, exposing their weaknesses) so they can grow.

Exposure: The Cost of Creation 🛡️

This brings us to exposure. Every time you launch a product, every time you take venture money, and every time you step up to lead a team through a crisis, you are exposing yourself.

Exposure is vulnerability. It is the inescapable cost of operating with hope and trying to maximize potential.

• When you launch a new feature, you expose your code to bugs and user criticism.

• When you share a vision, you expose your ideas to ridicule and competition.

• When you lead with transparency, you expose your personal fears and uncertainties to your team.

In the startup world, we often talk about market exposure or risk exposure, but the critical part (the part that ties back to emotional intelligence) is the human exposure. The stronger your hope and the bigger the potential you are chasing, the greater the emotional vulnerability (and the potential crash).

True empathetic leadership means acknowledging this cost of exposure. It means creating a culture where it is safe to fail publicly, and where the exposure doesn’t lead to personal shaming, but collective learning. Only when your team feels secure in their exposure can they truly unleash their full potential, fueled by their original hope.

How do you, as a leader, manage that terrifying exposure? Do you shelter your team from it, or do you teach them to treat vulnerability as a source of strength?

Look at the pace of development. Every VC deck today features some mention of generative models or the path to AGI. We are stacking transformer layers higher and wider than anyone could have dreamed of even five years ago, building systems that exhibit emergent reasoning. The compute budget of training something like GPT-4 alone is staggering (well over $100 million, apparently), and the results are rewriting not just code, but the very nature of human work (from marketing copy to low-level programming). The technical achievement is undeniable, a massive testament to engineering prowess.

But this is Disruptive Empathy, and my whole focus has always been the soft stuff, the wetware, the human side of the algorithm. We talk endlessly about “model alignment,” meaning, making sure the AI’s goals match ours (preventing Skynet scenarios, basically). But in all the white papers and startup retreats, I find myself circling back to the deeper, messier, truly disruptive questions of human alignment.

In the rush to create synthetic intelligence, we seem to be bypassing the necessary internal introspection required to manage the people building it. If we are seriously talking about creating entities that can debate philosophers or write their own documentation (which many of these models can do, albeit imperfectly), we must surely stop and ask what we are sacrificing, or ignoring, in ourselves.

Back when the Commodore VIC-20 first shipped (the $299 “Friendly Computer” that brought computing to the masses), the challenge was defining what a personal computer was. It was a box of circuits. Today, the challenge is defining what a person is, and what value our emotional and mental presence adds when a token-based prediction engine can outperform us on the Bar Exam.

This isn’t just about job displacement (a topic for another essay). This is about the psychological state of a team that is building something that fundamentally questions its own value proposition.

How do you, the engineering leader (or the product manager, or the founder staring down a Series A) ensure the well-being and sense of purpose of your highly-skilled teams when they are actively trying to automate away tasks that used to define their careers? How do you maintain an empathetic culture when your core technology is constantly blurring the line between tool and colleague?

If the future of work involves us simply correcting the hallucinations of sophisticated silicon, then the soft skill of discernment (the ability to know when a thing is wrong, not just how to make it right) becomes the most valuable commodity in the world. And that skill is built on consciousness, empathy, and intellectual self-awareness. These are things that cannot be trained out of a data set.

So, I’ll ask the question directly to those of you running sprints in Nashville, in Austin, or anywhere else where the next trillion-parameter model is being spun up:

How do your teams deal with consciousness? (Their own, I mean, not the machine’s.)

What psychological guardrails do you have in place for the engineers who know they are building their own replacement, or at least, fundamentally reshaping their future role? Are we treating the people building AGI with the same meticulous care we are applying to aligning the AGI itself?

I’d genuinely love to hear your experiences, because the code only runs as well as the culture supporting it.

(Special thanks to for inspiring this post. Don’t sleep on the good work he is doing in the US, Ghana, and elsewhere.)

Now, the modern startup team exists in a kaleidoscope of time zones and Slack channels. We’ve unlocked incredible freedom, hiring talent from Buenos Aires to Berlin, and that flexibility is a tremendous achievement for the future of work. But that physical distance (the very thing that gives us flexibility) introduces a critical challenge: the latency of listening.

Empathy is fundamentally about presence. It’s about picking up the subtle, non-verbal cues that tell you a teammate isn’t just busy, but actively struggling. When the only data points you receive are words on a screen (a terse email, a late-night commit message, a sudden silence in the project channel), it is tragically easy for empathy to degrade into mere procedural politeness.

The problem isn’t just miscommunication (that’s an engineering fix). The problem is misinterpretation of intent (that’s a human fix).

We’ve been dealing with this textual bandwidth problem for decades. Even back in the early days of the internet (when text-based protocols like IRC were king), we struggled with tone. A period at the end of a sentence could carry the weight of passive aggression, or it could simply mean the sender was rushing. Without shared context, the default human response is often to fill the emotional vacuum with the most negative available interpretation. This is how burnout starts, often in isolation.

The Empathy Protocol for Remote Teams

If proximity is no longer guaranteed, empathy cannot be accidental. It has to become a protocol, an intentional part of your culture’s operating system.

Here are a few things I’ve seen work beautifully in distributed organizations that prioritize humanity:

• Mandatory Presence Check-Ins (Video On): Teams should set aside brief, scheduled time (daily or bi-weekly) where the only goal is to see faces and share personal context. This isn’t a stand-up for tasks; it’s a moment to see if someone looks tired, or excited, or overwhelmed. It builds the visual library necessary for accurate interpretation later (when you are reading their asynchronous messages). If necessary, set a time limit. Seeing your co-workers’ faces is a great way to initiate or maintain connection.

• The Intent Slack Channel: Encourage team members to explicitly prefix potentially fraught messages with a positive intent statement. For example: “Urgency/Action Needed” or “Friendly/Just FYI” (this avoids that 3 PM jump-scare feeling of a stern-sounding email).

• Time Zone Tax: Leadership must acknowledge and actively compensate for the “always on” culture. If a task requires someone to be online past 8 PM local time (to connect with another zone), that emotional and physical tax should be recognized and offset, not just expected. This could materialize in goal-first objectives or simply the availability of comp time.

The promise of the distributed team is access to global potential. The risk is that we build globally distributed teams that feel entirely disconnected, alone in their struggles (a modern update to the feeling of being the only person in a late-night server room). The fix for the latency of listening is not better code; it’s better human discipline. We have to work harder to be present when we are not physically together.

How have you successfully closed the empathy gap in your remote-first organization? What tools or rituals do you use to ensure nobody is silently struggling in their home office?

I’m talking about the progression from raw Executive Function (EF) to fully realized Executive Presence (EP). They sound like two sides of the same corporate coin, but I assure you, the journey between them is where all the messy, emotional work (the real work) happens.

The Tyranny of the Checklist

In my early days (especially when I was knee-deep in managing servers running Windows NT or trying to figure out how to debug mail flow on a legacy system), my entire identity was built on EF. Executive Function, at its core, is the administrative suite of the brain (it is the operating system for how we plan, prioritize, initiate tasks, and inhibit distracting thoughts).

For a lot of us who are wired a little differently (a big hello to my fellow Autistic and ADHD-i folks), EF is often a battleground. We develop complex scaffolding (tools, rituals, body doubles) just to get the minimum viable product (the MVP of the workday) out the door. When you’re an individual contributor or a tactical expert, this raw ability to execute, to organize the chaos into a checklist, is golden. It is the hard skill that gets you hired, promoted to Senior Engineer, and maybe even a Team Lead role.

But then you hit the wall.

You ascend to a role where your job is no longer primarily about doing the task, but about defining the task, prioritizing the team’s capacity, and influencing stakeholders. Suddenly, your perfect Trello board and your ability to remember obscure command-line flags for the BlackBerry Enterprise Server are functionally useless. The most perfectly planned project roadmap fails because the team is stressed, the client is panicking, and the CEO needs assurance, not a Gantt chart.

The Empathy Bridge (The Missing Link)

The reason so many brilliant, technically capable people stall out at the mid-management level is simple: they mistake Executive Function for Executive Presence. They believe the solution to chaos is more order, more planning, more doing.

But EP isn’t about doing tasks; it’s about inspiring confidence and commanding trust in volatile environments (which is essentially the definition of a startup, right?).

This transition requires one fundamental, often overlooked, layer: Emotional Intelligence.

EP is the public output of internal emotional maturity. If EF is the operating system, then Emotional Intelligence is the network security layer and the user experience team combined. It’s what allows you to perceive that your CEO isn’t worried about the Q3 numbers (which are solid), but is actually worried about their personal standing after a recent board meeting (which is messy). It is the ability to read the quiet tension in a meeting and address the subtext, not just the agenda.

In the language of the leadership track, Executive Presence is often boiled down to “Gravitas, Communication, and Appearance.” But what is Gravitas, really? It isn’t a power stance or a tailored suit. Gravitas is the calm that comes from knowing yourself (self-awareness) and knowing your audience (social awareness, or empathy). It is the unshakeable self-regulation that allows you to say, “The system is down, but we have a process, and we are following it.” That composure is what instills confidence in others.

It’s the shift from obsessing over the details of your own work (EF) to mastering the emotional details of the people around you (EI), thereby allowing you to project credible authority (EP).

For me (and for many neurodivergent leaders), this required actively building what others might take for granted. We have to learn to translate our deep systemic understanding of the world (our EF superpower) into a human context, using empathy as the translator. It’s not about masking; it’s about broadcasting the confidence we already possess in our capability, but packaging it in a way that aligns, engages, and inspires others to action.

The future of work, especially in tech, doesn’t need more perfect project managers. It needs fewer brilliant jerks and more empathetic executives who understand that the most complex system they will ever manage is the human heart.

I’m talking about the 3 AM, P1, “whoopsie it’s not working,” outage call. The launch that went sideways (the one you couldn’t fix with an apology blog post). The grueling six-month sprint that ended in a pivot, with all that hard-won code thrown onto the digital scrap heap.

In these moments, something fascinating and vital happens to the human organization. The hierarchy dissolves. The titles (CTO, VP of Product, Senior Engineer) become meaningless noise. You are reduced to a collection of tired, caffeinated human beings staring at the same console, struggling against a shared, immediate adversary (usually a configuration error, or a memory leak).

This is when the real team emerges.

The shared struggle, the exhaustion, the pressure? It all strips away the carefully constructed professional armor. The founder who usually talks about disruption is suddenly just a worried person trying to manage external communication. The quiet infrastructure specialist who rarely speaks up is suddenly the central nervous system, calmly diagnosing the problem. You are all equally vulnerable to failure, and equally dependent on each other for success.

This concept of shared adversity as a humanizing force is not new. We’ve seen it throughout the history of technology. Think about the early days of the commercial internet (long before we had Mosaic to make things pretty). The challenges of connectivity, the limitations of bandwidth (dial-up was a true test of patience, wasn’t it?), and the sheer novelty of decentralized communication meant that everything felt like a monumental effort.

But it was that shared struggle against limitation that forged the early bonds of the online community. They weren’t just building networks; they were building culture out of necessity and common frustration.

In the startup world today, we often mistake success for smooth operation. We celebrate the frictionless user experience, the perfectly executed deployment, the clean exit. But true empathy, the kind that underpins resilient organizations, isn’t built in the sunshine. It’s forged in the fire.

Adversity, whether it’s a critical production bug or a major market downturn, is the universal human connector. It reminds us that everyone on the team (from the engineer dealing with the database deadlock to the person making coffee, bless them) is capable of vulnerability, mistakes, and, most importantly, extraordinary effort.

When you see a brilliant colleague break down at 4 AM because they feel responsible for the entire database cluster going offline (even though it was a vendor bug), that’s a moment of profound, painful humanity. When you step in to cover them, not because of a corporate policy, but because you know exactly what that dread feels like, you’ve established a connection stronger than any OKR.

We spend so much time optimizing our tools and minimizing our failures. Maybe we should instead learn to leverage the adversity. Recognize the fire drill not as a disaster to be forgotten, but as a crucible that reveals the essential, imperfect humanity we all share. Because acknowledging our common struggle is the first step toward genuine, disruptive empathy.

How has shared adversity (a massive, messy failure) actually improved your team’s cohesion? I’m interested in hearing about those 3 AM moments that ended up defining your success.

(Another acknowledgement here - big thanks for inspiration go to and !)

But what happens when the line between your job title and your sense of self dissolves? When the help you provide to the company starts costing you your core identity?

I have spent the better part of two decades witnessing this cost, from the trenches of infrastructure to the strategic boardroom. The phrase, “help that doesn’t cost your identity,” isn’t just a management mantra (it’s a necessary survival guide for longevity in a perpetually demanding field).

The Burden of the Hero Complex

In the early days of any venture (or even in mature, high-growth companies), there is immense pressure to be indispensable. This often falls hardest on those in Support and Infrastructure roles (the people who keep the lights on and the protocols running). You become the single point of failure, and your heroic effort to constantly solve problems becomes the only acceptable solution.

The cost is steep. It starts with small sacrifices (a forgotten hobby, a missed dinner) and escalates into a complete erosion of personal well-being. Your identity shifts from “I am a thoughtful person who builds resilient systems” to “I am the person who fixes the P1 fire.” When the company needs help, it takes a piece of you. It takes things like your sleep, your time with family, and your moral compass in a moment of ethical compromise. This tax is levied repeatedly until your entire sense of value is predicated on your current job performance.

This is unsustainable empathy. It is the antithesis of healthy leadership and robust strategy (it is merely a systemic failure cloaked in virtue signaling).

The unfortunate thing about this? It also prevents you from being proactive. It prevents you from thoughtfully preventing the fires you’re constantly extinguishing.

Scaling Empathy Through Systems

In the infrastructure world, we learned long ago that a reliance on a single person for uptime is a ticking time bomb. The solution to a complex scaling problem is never to hire a genius who works 24/7 (that person will burn out or quit). The solution is to distribute the load through intelligent systems. This powers the flywheel that refines unsustainable empathy into Disruptive Empathy.

This principle must be applied to emotional intelligence as well. True organizational empathy means structuring the environment so that individuals do not need to perpetually sacrifice themselves. True help, the kind that endures, is baked into the architecture, not balanced on the back of an exhausted person.

Think about modern distributed systems. Tools like Kubernetes (an open-source system for automating container deployment, scaling, and management) exist because we learned that manually managing containers across multiple nodes is inhumane and error-prone. Kubernetes helps by removing the crushing burden of manual oversight, allowing the infrastructure itself to self-heal and scale. It is automated help (help that doesn’t cost an operator their weekend or their sanity).

The goal, whether you are building vintage computers or modern cloud platforms, should be to abstract away the repetitive, draining labor and automate the non-judgmental response.

The Right Kind of Giving

For the individual (especially the empathetic leader or builder), finding help that doesn’t cost your identity requires a fierce commitment to boundaries.

1. Define your core: Know who you are outside of your product or role. What are the non-negotiable aspects of your life (family, health, values)? These are the identity items that must not be traded for quarterly targets.

2. Delegate the heroics: Stop catching every falling plate yourself. Build the process (the runbook, the documentation, the cross-training) that empowers others to solve the problem in a resilient, distributed way.

3. Choose your battles: When you offer help that involves personal sacrifice, ensure it is a choice made consciously for a meaningful, rare event (not a habit built from daily panic).

The future of work depends on this shift. We must move past the cult of the indispensable martyr and embrace the power of sustainable, systemic, and humane effort. Only then can we truly innovate, because only then are we operating from a place of wholeness (not depletion).

For more about the hero complex, see this post from September.

The phrase haunts me because it is a perfect diagnostic tool for a broken culture: “When my time is no longer available, you respond with silence.”

It exposes the lie beneath the perpetual, humming anxiety of the startup world. We are told we are a team (a family, even), but the moment you stop being the immediate, available resource (the person who can put out the fire, or jump on the three-hour late-night debugging session, or craft the perfect last-minute marketing copy) the contact drops to zero.

The silence isn’t just an absence of sound (it’s the absence of recognition for your non-transactional worth).

The Problem of Reactive Design

In my years spanning infrastructure, product, and leadership, I’ve seen organizations design for maximum throughput but minimal humanity. We create systems, both technical and operational, that only activate on demand.

In the old days of the Internet (back when we were fighting packet loss on leased lines instead of scaling global microservices), the network was designed around its most expensive resource: bandwidth. Everything was throttled, buffered, and carefully managed. Today, in the modern distributed environment, the most expensive resource is no longer network bandwidth or compute cycles (it’s focused human attention). Yet, we still design our communication platforms (like Slack or email) to treat that attention as a cheap, infinite resource (constantly pingable, constantly interruptible).

When the signal light is on (when you are visibly solving a problem), the feedback loop is instantaneous: appreciation, questions, praise, more requests. But when you switch to strategic, heads-down work (the kind of deep focus that actually builds long-term value, the kind of work that requires you to be unavailable), the organization suddenly goes quiet.

The silence tells you that the relationship was not built on shared purpose (or mutual respect for your expertise) but on your immediate, reactive utility. You were a server, and when you went into maintenance mode, the client requests ceased.

The Future of Work and the Agentic Shift

This phenomenon is becoming even more pronounced as we move into the era of advanced automation. If we, as human workers, allow our value to be defined purely by instantaneous response and repetitive problem-solving, we are racing toward redundancy. These are precisely the tasks that future Agentic AI systems are designed to handle: monitoring the situation, evaluating options, and taking appropriate action (autonomous decision-making without constant human hand-holding).

As Kate O’Neill writes in her piece, Agentic AI: Beyond the Hype – What It Really Means for Businesses and Workers (a piece that rightly focuses on the human element of these changes), the core challenge around agentic AI isn’t about algorithms (it’s about power and human agency). If machines can handle the transactional noise, then the only sustainable value for humans lies in the strategic, empathetic, and boundary-setting work (the work that is inherently unavailable for constant interruptions).

We must stop seeking validation in the volume of the noise (the number of pings) and find strength in the quiet that comes from focused, high-leverage contribution. We need to train our organizations to value the preventative fix over the heroic firefighting (and to respect the necessary silence that allows deep work to happen). If the only time people talk to you is when they need something, then the silence is not a consequence of your unavailability (it’s a warning sign about your environment).

Big thanks to Domonique Townsend and Tiffany Hardin for inspiration behind this post.

Read more

This is the central paradox of working in a field built entirely on creating abundance: our culture is defined by a scarcity mindset. We see another founder’s successful exit, a colleague’s faster promotion, or a competitor’s massive funding round, and the brain, that magnificent but antiquated piece of biological hardware, immediately registers a physical threat.

Jealousy is a primal emotional spike, and like any spike, it doesn’t care about reality. It is a failure of emotional intelligence (EQ) because it misclassifies a stimulus. When your co-founder wins an industry award, your amygdala isn’t processing a celebratory event. It’s screaming that your share of limited resources (prestige, equity, future career trajectory) has just been reduced to zero. Jealousy means inventing a threat to your safety.

The Ghost of Proprietary Hardware

To understand this deep-seated fear of scarcity, we can look back at the history of computing. The early days were remarkably open and collaborative, defined by a spirit of tinkering. When the original Apple II hit the market, its success was driven largely by its open architecture. The manuals told you how to build peripherals (a concept now known as developer relations), and the entire community benefited. The communication protocols of the nascent Internet (like IRC (Internet Relay Chat)) were built by people sharing freely, focused purely on function and community.

Then came the shift toward proprietary systems. The belief that the code inside the plastic box must be hidden, copyrighted, and fiercely defended. Safety was defined by locking everyone else out. This ideological model (that value exists only when controlled by a select few) is the conceptual ancestor of startup jealousy today.

Many founders are still operating on the proprietary assumption: If they have success, there is less success left for me. This is a false choice, yet it drives insidious behaviors in the office: quiet sabotage, withholding information, and a pathological inability to celebrate another team’s win. These actions aren’t defensive; they are irrational, preemptive strikes against an invented threat.

The Antidote: Disruptive Empathy as a Protocol

As we look toward the future of work (which is increasingly distributed, cross-functional, and dependent on complex, global supply chains) this proprietary mindset will become fatal to innovation.

The path out of this invented danger is Disruptive Empathy (the core thesis of this work). It requires a conscious cognitive shift from Comparison Mode to Collaboration Mode.

How do we recode the jealousy protocol?

1. Acknowledge the Amygdala’s Bug: Imagine you’ve just received an email announcing someone else’s great success (or maybe you just logged on to LinkedIn for the first time in the morning.) When that tightness hits your chest? Label the feeling. Say: “This is a fear of scarcity, but the market is infinite.”

2. Inspect the “Source Code”: Ask what that person achieved. Is it sales growth? A stellar product launch? Instead of viewing their success as a wound to your ego, treat it like an open-source contribution. How can you learn from their methodology (their “code”) and integrate it into your own project?

3. Choose Openness: This is the most powerful choice. The entire Open Source Initiative was founded on the pragmatic, business-case argument that open development is simply superior to closed development. It leads to stability, ingenuity, and a built-in community.

Applying this to your career means treating every person in your field (even your closest competitor) as part of the same vast, complex ecosystem. Their win does not diminish your potential; it validates the market you are both building, thereby increasing your potential.

Your true safety in the tech sector isn’t in locking down your ideas; it’s in the robust, collaborative network you build around yourself. Stop inventing predators where collaborators should stand. When you choose to see abundance, the threat to your safety disappears entirely. Your job, then, becomes building something truly great, not simply defending the small thing you already have.

Founders, especially those going it alone, often become so consumed by product-market fit, fundraising rounds, and burn rates that they neglect a critical piece of their foundation: empathy. And just like you’d seek expert advice on legal structures or financial modeling, you absolutely must seek guidance on building an empathetic culture from the ground up. This isn’t a “nice-to-have”; it’s a “must-have” for survival.

The Myth of the Solo Founder

Let’s debunk a pervasive myth: the solo founder. While stories of single-handed triumphs make for compelling narratives, the data tells a different story. Startups with a single founder are significantly less likely to succeed. Harvard Business School research has consistently shown that teams, particularly those with complementary skills and a shared vision, fare better. It’s not just about having someone to split the workload; it’s about having someone to bounce ideas off of, challenge assumptions, and provide a much-needed reality check.

And this “bouncing ideas” shouldn’t be limited to business strategy or technical architecture. It needs to extend to the very human elements of your nascent organization. How do you resolve conflict? How do you ensure everyone feels heard? How do you create a safe space for failure and learning? These are not soft skills; they are the bedrock of a resilient company culture. A co-founder can be your first, most important sounding board for these questions, helping you shape not just a product, but a workplace where people genuinely want to be.

Empathy as a Strategic Imperative

When you’re sketching out your initial business plan, you’re likely thinking about market size, competitive advantages, and your unique value proposition. But have you thought about your empathy proposition? How will your company interact with its customers, its employees, and even its competitors? These interactions, guided by empathy (or a lack thereof), will define your brand as much as your product features.

Founders should actively seek mentors and advisors who have a strong track record not just in scaling businesses, but in building thriving cultures. These are the people who can offer invaluable insights into managing team dynamics, fostering psychological safety, and creating feedback loops that actually work. Think of them as your “cultural architects,” helping you design the human infrastructure of your company.

It’s easy to dismiss empathy as something that will naturally emerge once the business is stable. This is a catastrophic mistake. Cultural norms are set early, often implicitly, by the founders’ behavior and priorities. If you launch your business without actively considering how empathy will manifest in your operations (from hiring to product development to customer support), you’re setting yourself up for long-term dysfunction.

Building Your Empathy Network

So, how do you seek this advice?

1. Look beyond the usual suspects: Don’t just connect with venture capitalists and serial entrepreneurs (though they have their place). Seek out HR leaders, organizational psychologists, and even community organizers. They understand human systems in a way many product-focused founders don’t.

2. Ask direct questions: Instead of “How do I raise money?”, try “How do I build a team that thrives under pressure without burning out?” or “What are the common pitfalls founders make when trying to create an inclusive culture?”

3. Read widely: Seek out books and articles on emotional intelligence, organizational behavior, and even philosophy. Expanding your perspective beyond the tech bubble is crucial.

Remember, your company isn’t just lines of code or clever algorithms; it’s a living, breathing organism made of people. And like any organism, it needs a healthy environment to flourish. Making empathy a core part of your launch strategy (and seeking expert guidance to do so) isn’t just good for your team’s well-being; it’s essential for your business’s enduring success.

For more on the benefits of co-founding, check out this article from Endeavor. It covers a good portion of the advantages, from shared stress to diverse skill sets.

We chase it in our metrics, we staff for it, and we write deployment pipelines (often using concepts like CI/CD) to make sure that nothing (absolutely nothing) impedes the flow of code from a developer’s branch to a user’s screen. We have automated away almost all friction in the machine, yet paradoxically, our teams are burning out faster than ever.

The infrastructure itself runs smoother, but the human infrastructure is failing.

It wasn’t always this way. When I started out, a deployment was an event. Not a routine pipeline commit, but a planned, high-stakes moment. We had time (and, frankly, systems that forced us to have time) to talk through changes. We understood failure deeply because the feedback loop wasn’t instant—it was often a late-night call after an unexpected server crash.

Think about the systems that once reigned supreme, like the massive VAX minicomputers. Though I never developed on these machines, I was a user during my early college career. Like every other user, I was affected by planned maintenance. For the team managing the systems I used, this bred a slowness that required planning, communication, and, most importantly, consideration for the users (and other engineers.) It required emotional intelligence.

The very definition of continuous integration (CI) is a technical optimization designed to reduce technical risk, but we mistook this technical velocity for human efficacy. We adopted DevOps practices (which are fantastic for systems) but forgot to apply the same rigor and thought to our people operations. We built systems for rapid failure and recovery (which is good), but we didn’t build a culture that allows humans to fail and recover without punishment (which is disastrous).

When a modern system using CI/CD auto-merges a feature, the technical debt is flagged in seconds. But when a team member feels rushed, overlooked, or unheard (a product of the pressure to maintain “velocity”), that human debt often sits silent for months, eroding trust and psychological safety until the entire project implodes.

The irony is that sustainable velocity (the kind that scales for two decades, not just two quarters) is a function of high emotional intelligence, not low friction.

Empathy is the most critical piece of infrastructure we need to be building right now. It is the real-time monitoring system for your team’s collective morale. It is the automated rollback function for bad communication. It is the 32-bit (or more) virtual address space we need to understand the memory limits (cognitive load) of the people we rely on.

We must slow down long enough to see our colleagues not as cogs in a DevOps pipeline, but as complex, analog systems (prone to bugs, yes, but also capable of genius) that require care, non-judgmental failure states, and ample processing time. The future of work isn’t about more automation, it’s about more deliberate human interaction.

The history of computing is fascinating, particularly the machines and systems that defined the early days of corporate IT:

The core tension is this: You can open doors of opportunity for people in need and still maintain healthy boundaries.

You want to help (and you should want to help). This isn’t just about being a good person (though that’s a nice side effect). It’s about building a durable, resilient organization. Opening a door for someone in need (a struggling junior engineer, a founder making a hard career shift, a student fascinated by the history of the Internet) is not a cost center, it’s a strategic investment.

It’s the human equivalent of finding Product-Market Fit (the degree to which a product satisfies a strong market demand) (https://stripe.com/resources/more/what-is-product-market-fit-what-startups-need-to-know) for talent. You see high potential and you connect it to a high-demand opportunity. This is leadership at its best.

But a healthy system (and I mean your system) requires guardrails. In the tech world, we use a Service Level Agreement (SLA) (an agreement between a service provider and a customer that defines the service to be provided and the performance to be expected) (https://www.atlassian.com/itsm/service-request-management/slas) to clearly define what we deliver, how fast, and what happens when we fail. Why don’t we apply this same rigor to our personal emotional capacity?

Your emotional boundary is your personal SLA. It’s the contract you have with yourself (and the people you’re helping) that ensures the service you provide is sustainable. The key to successful, non-destructive empathy is defining the terms before the request arrives.

That means setting a clear response time (I will answer your email within 48 hours, but I cannot drop everything for an unscheduled call) or defining the scope of support (I will mentor you on career strategy, but I cannot review your personal project’s code commits).

When you define your bandwidth, you avoid emotional debt. Unmanaged empathy, the kind that says “yes” to every urgent ping, leads to resentment and system failure. Resentment leads to the inevitable closure of the door, and that’s a tragedy for everyone.

The tech sector needs more open doors, not fewer. It needs more empathy, but it must be an empathy that is conscious, measured, and resilient. It needs an empathy that has a clear, well-written SLA, ensuring that the critical service (your capacity to care) has a 99.99% uptime. Anything less is a disservice to both the person you’re helping and the future of your own career.