Back then, “scale” was a problem you solved with a screwdriver and a prayer. Today, scale is a slider in a dashboard. We have reached the era of infinite scale (the ability to spin up ten thousand instances of a containerized application with a single command) but I find myself wondering what we left behind in the data center.

When resources were finite, we were forced to be intentional. You couldn’t just throw more RAM at a memory leak; you had to actually find the leak. There was a craftsmanship to it. Now, the prevailing culture in startups is to move fast and let the cloud infrastructure soak up the mess. We have traded elegance for velocity.

But it is not just the code that has become bloated. It is our empathy.

In the days of physical constraints, we understood that our systems were built and maintained by people. If I pushed a bad update at 2:00 AM, I knew exactly which person was going to have to drive to the colo to fix it. There was a human cost to every technical decision. Infinite scale has decoupled the engineer from the impact of their work. We no longer see the burnout; we just see the auto-scaling metrics.

For those of us with neurodivergent brains (my autism thrives on predictable systems while my ADHD craves the novelty of new tech) the shift to “infinite” has been particularly jarring. The world feels louder and more chaotic when there are no boundaries. A mainframe had a beginning and an end. The modern web is an endless, recursive loop that never sleeps and never stops demanding more of our attention.

We built these systems to be more efficient, but we ended up creating an environment where we are always “on” because the machines always are. We gave up the natural rhythm of work (the ebb and flow of capacity) for a relentless, flat line of constant availability.

We scaled the technology, but we forgot to scale the human soul to match it. We became so obsessed with removing the bottlenecks in our Kubernetes clusters that we created a massive bottleneck in our own mental health.

Infinite scale is a miracle of engineering, but it is also a trap. It convinced us that boundaries are a bug to be fixed rather than a feature of a healthy life. Sometimes I miss the screwdriver. I miss knowing that even the most powerful machine in the building had a plug that someone could eventually pull.

But the boardrooms and the “huddle spaces” of the startup world are not governed by TCP/IP. They are governed by subtext, eye contact, and the “vibe” of the room (variables that my Autistic brain often struggles to parse in real-time). Being the “Autistic in the room” in a leadership role feels like trying to run modern software on hardware that was built for a completely different architecture.

We talk a lot about “disruptive” ideas in tech, but we rarely talk about the person who is actually disruptive to the social fabric of the office.

My brand of disruption isn’t intentional. It is the result of a brain that values truth over hierarchy and clarity over comfort. When a Product Manager presents a roadmap that is logically inconsistent, I don’t see a “vision” to be massaged. I see a null pointer exception. I point it out, not to be difficult, but because I believe the most empathetic thing I can do for the team is to prevent them from building a bridge that will inevitably collapse.

In the startup world, this is often misread as “not being a team player” or “lacking soft skills.” But what we call soft skills are often just the ability to navigate neurotypical social rituals.

The irony is that the tech industry was built by people who thought like me. The early internet was forged by individuals who preferred the Usenet to a cocktail party. We built Linux and the World Wide Web because we wanted systems that were open, logical, and predictable. We created a world where we could communicate through text and code, bypassing the confusing “wiring” of face-to-face interaction.

Now that tech has become the dominant culture, we have brought back the very barriers we once escaped. We have filled our offices with open floor plans (which are essentially sensory torture chambers for an Autistic person) and we demand “radical candor” while simultaneously punishing anyone who is actually candid about the things that matter.

Empathy in the tech sector needs to move beyond the superficial. It isn’t just about being “nice.” It is about recognizing that the person who isn’t making eye contact in the meeting might be the only one who sees the catastrophic flaw in your API design. It is about understanding that my “bluntness” is actually a form of deep care for the mission.

We need to stop trying to “patch” Autistic people to make them compatible with neurotypical environments. Instead, we should look at the environment itself. If your company culture cannot handle someone who speaks the literal truth, your culture is the one with the bug.

When I sit in those rooms now, I no longer try to hide the wiring. I accept that I am the legacy system that still holds the most important data. I am there to remind the room that while feelings matter, the laws of logic and the reality of the code are not optional.

We talk a lot about the “human firewall” in security circles. It is a nice metaphor, but it is also a bit of a lie. We treat people like software components that just need a patch, rather than complex biological systems with their own anxieties, distractions, and sensory overloads.

I have spent two decades watching infrastructure evolve from beige towers (like my beloved Commodore 64) to abstract clouds. Yet, in all that time, the way we fund security awareness has remained stuck in a very archaic, “check-the-box” mentality. We spend millions on Next-Generation Firewalls and Endpoint Detection and Response tools. But when it comes to the team responsible for teaching employees how not to get tricked by a Social Engineering attack, we give them a shoestring budget and a library of boring, thirty-minute videos that everyone mutes while they check their email.

This is a failure of empathy.

As someone who is both autistic and ADHD, I experience the world through a lens of high pattern recognition and, occasionally, social friction. I see the “invisible” work. Awareness teams are essentially internal marketing and education departments tasked with the hardest job in tech: changing human behavior.

When we underfund these teams, we are effectively saying that we don’t value the cognitive load of our employees. We expect them to be security experts on top of their actual jobs, without giving them the engaging, accessible, and frequent guidance they need to succeed. We treat security as a technical hurdle rather than a cultural practice.

In the old days of the Bulletin Board Systems, security was about knowing the right people and the right commands. It was intimate. Today, it is massive and impersonal. To fix the funding gap, we have to stop looking at awareness as a “cost center” and start seeing it as an investment in emotional intelligence.

If we want people to care about protecting the company, the company has to show it cares about how people actually learn. That requires more than a compliance officer with a spreadsheet. It requires writers, designers, and educators who understand how to capture attention in a world designed to fragment it.

Until we fund the human side of the equation with the same urgency we fund the silicon side, we are just waiting for the next “human error” to happen. And that is a failure of leadership, not a failure of the users.

But the ADHD tax (that invisible, compounding interest on the cost of existing) is not a cable management issue. It is a fundamental architecture flaw in how the modern workplace is wired.

In the tech sector, we praise “agility.” We celebrate the person who can pivot mid-sentence and handle a dozen Slack notifications while writing a Python script. But for those of us with ADHD-i (the “inattentive” variety that feels less like a motor and more like a radio stuck between stations), this environment is a sensory minefield. We spend half our cognitive load just trying to filter out the noise so we can do the work we were hired for.

The tax manifests in small, brutal ways. It is the SaaS subscription you forgot to cancel for eighteen months because the “unsubscribe” button required a phone call. It is the late fee on a server renewal because the invoice got buried under a mountain of Jira tickets. It is the burnout that hits on a Tuesday morning because you spent Monday hyper-focusing on a single line of code, forgetting to eat or hydrate until the sun went down.

We often talk about “accommodations” in the workplace as if they are a gift (a special dispensation for the broken). We offer noise-canceling headphones or “focus time” on the calendar. But these are just dongles; they are temporary fixes for a system that was never designed for our hardware.

The real empathy in leadership comes from realizing that the ADHD tax is not a personal failure of discipline. It is a byproduct of a culture that values “always-on” connectivity over deep, meaningful work. When we build startups that require constant context-switching, we are essentially charging our neurodivergent employees a twenty percent tax on their productivity before they even log in.

I look back at the old IBM ThinkPads with their tactile buttons and lack of distractions. There was a physical boundary there. Today, my laptop is a portal to every distraction in human history. To survive, I have had to learn to build my own “wiring” (systems of automation and radical transparency) that protect me from my own brain.

We need to stop asking people to pay the tax and start questioning why the bill is so high in the first place. Emotional intelligence in tech means acknowledging that not every brain runs on the same operating system. Some of us are built for the long, slow hum of a mainframe, and forcing us to act like a high-frequency trading algorithm is only going to result in a system crash.

She is, usually, exceptional. She has the resume. She has the judgment. She has done this specific thing, or something close to it, more than once, and she has the scar tissue to show for it. Leadership is, in that initial period, genuinely enthusiastic. They tell other people about her. They use words like “strategic” and “exactly what we need.” She gets the title and sometimes the budget and always the large, complicated problem.

And then they do not give her what she needs to do the job.

Not dramatically. Not through malice. It is quieter than that, and in some ways more corrosive because of the quietness. They share the information they think she needs, when they think she needs it. They loop her in after decisions are made rather than before. They hand her the brief but not the backstory. They introduce her to the stakeholders but not to the history of the relationship, or the failed attempt eighteen months ago that the stakeholder is still quietly angry about, or the internal political current she is now swimming against without knowing it. She finds the missing context the way you find missing steps in a staircase: at speed, in the dark, when it is too late to catch yourself.

When she asks, they answer. This is the part that makes it so hard to name. They are not withholding. They are responsive. They are even, they will tell you, transparent. But there is a profound difference between a system that shares information proactively and a system that shares information reactively, and that difference falls on her as a tax levied against her effectiveness in small, invisible increments.

In security architecture, there is a principle called need-to-know. The idea is that access to sensitive information should be granted only to those who require it for their function. It is a legitimate and important principle when applied to classified intelligence or medical records or financial data. It is a catastrophic principle when applied, consciously or not, to the professional context a person requires to do their job.

The tech workplace runs a degraded version of this. Not the formal, documented version. The informal one, the one that nobody wrote down and nobody decided, the one that accumulated over years of a company’s history like sediment. The old-timers know. The people who were in the room when the decision got made know. The person who was at the offsite where the strategy shifted knows. The information is not secret, exactly. It is just assumed. It exists in the oral tradition of the organization, passed around at the Thursday lunch or the post-meeting debrief in the hallway that the person who joined last month was not part of. Every organization has this. The question is who gets inducted into it, and on what timeline, and whether the induction is active or passive.

When the answer is passive, which is to say when the culture assumes that people will absorb organizational context by osmosis and will ask if they need something, the people who pay the highest price are the ones who joined with a clear mandate, a high-stakes problem, and no runway for looking uncertain. A new person who is positioned as junior is expected not to know things. A new person who is positioned as senior, as the person who was brought in specifically because of their expertise and judgment, is not supposed to need orientation. The expectation is that she arrived already knowing. The gap between that expectation and reality is hers to manage, invisibly, while also doing the actual job she was hired to do.

There is a cost to asking, and it is not evenly distributed.

When a man in a senior role asks for context, it reads, fairly consistently, as diligence. He is being thorough. He is making sure he has the full picture before he acts, which is the kind of strategic thinking you want in a senior hire. When a woman in a senior role asks for context, the same question can read differently. Not always. Not everywhere. But often enough to be a documented pattern rather than an anecdote: she is missing something she should already know. She is not as prepared as expected. She needed help.

This is not speculation. The research on gender and the perception of competence is extensive and grim and mostly ignored in practice. The same behavior reads differently depending on who performs it. A woman who advocates for resources is demanding. A man who advocates for resources is strategic. A woman who says she needs more information to make a good decision is underprepared. A man who says the same thing is deliberate. The double standard does not require anyone in the room to be consciously sexist. It operates in the gap between stated values and the reflexive judgments that happen faster than reflection.

So she asks less than she should. She fills the gaps herself, spending time and energy on reconnaissance that her male counterpart spent on the actual work. She builds the map of the organization from scratch, interview by interview, meeting by meeting, and she does it largely invisibly, because visibility in this domain looks like weakness. She absorbs the cost and she smiles in the status meeting because the status meeting is not the place to say that she has spent the last three weeks finding out what she should have been told in week one.

I want to be specific about what leaders are actually doing when they hire a capable woman for something important and then manage the information asymmetry poorly, because I do not think it is usually conscious, and I think the unconscious version is worth examining more carefully than the conscious version precisely because it is harder to see and easier to excuse.

Some of it is paternalism dressed as protection. She is new. She does not need to know about the failed initiative that the executive sponsor is still embarrassed about, not yet, it will color her perception before she has a chance to form her own. The intention is good. The effect is that she walks into a room missing the context that would explain why the executive sponsor goes quiet when a particular topic comes up, and she has to figure it out through a read of social cues that she could have spent on the actual work.

Some of it is the way information is attached to relationships, and relationships take time, and organizations that run on relationships are often not aware of how much invisible onboarding those relationships represent. The person who knows why the last vendor relationship failed is the same person who was there for the vendor relationship. Getting that person to transfer that knowledge requires them to understand that the knowledge is worth transferring, which requires them to understand what she needs, which requires them to think about her perspective rather than their own, which is precisely the cognitive work that busy, well-meaning people tend not to do systematically.

And some of it (this is the part that is hardest to say plainly) is that keeping her on a need-to-know basis keeps her dependent. Not as a deliberate strategy. Not, usually, with any awareness that it is happening. But a person who must ask for context to operate is, functionally, a person who must maintain a relationship with the person who holds the context. She comes back, regularly. The relationship is maintained. She remains, in a subtle and deniable way, managed.

The version of this that most damages organizations is when it intersects with credit. She does the work. She navigates the missing context, she figures out the political geography through trial and some painful errors, she builds the relationships from scratch and delivers the result. And then the person who gave her the context she needed (when she needed it, when she asked, in dribs and drabs over months) gets attributed as having been essential to her success. He was so helpful. He really brought her up to speed. She could not have done it without him.

She did it despite him. The distinction is important and almost never made.

The fix is not complicated. It is just work, and it requires the specific kind of intentionality that organizations tend to apply to things they have decided are important and almost nowhere else.

Proactive context transfer when someone senior joins. Not the org chart and the P&L and the slide deck that was presented at the last all-hands. The actual history: what was tried before this, what failed, who has a position on this that is not yet visible to someone new, where the real decisions get made and who has to be in the room for them to stick. This information exists in the heads of the people who were there. Someone has to go get it and give it to her, before she asks, before she needs it, before she walks into the room without it.

Explicit relationship introductions with actual context. Not just “this is the head of engineering, you should connect” but “this is the head of engineering, he had a proposal for this space that did not move forward eighteen months ago, he is not a blocker but that history is in the room with you.” That sentence takes fifteen seconds to say. It saves weeks.

A reckoning with the asymmetry of asking. If her asking for information is a tax on her perceived competence, then the organization has an obligation to make asking structurally unnecessary, not by telling her less, but by giving her more without requiring her to surface the need. The burden of proactive information sharing should sit with the people who have been there longest. They hold the context. Moving it is their job.

There is a version of this that gets framed as a communication style difference, or as organizational onboarding challenges that affect everyone, or as the natural friction of joining a complex system. Those framings are not wrong, exactly. The friction is real and it does affect everyone.

But “affects everyone” and “affects everyone equally” are not the same sentence, and collapsing them is how organizations avoid the specific work of looking at who bears the cost disproportionately, and why, and whether the structure that produces that outcome is acceptable once it has been named.

She was brought in because she was exceptional. The least the organization can do is let her be exceptional with full access to the information she needs to operate. Not on a need-to-know basis. Not when she asks. From the beginning, on the assumption that she is there to succeed, and that success requires context, and that providing context to the people who need it to do important work is not a favor.

It is the job.

Before the era of sleek smartphone interfaces, high-definition video calls, and a practically infinite library of perfectly curated reaction GIFs, there was the pure, unadulterated text based internet. BBS message boards, AOL chat rooms, ICQ (remember the “uh-oh!” sound?), and AIM (AOL Instant Messenger). All of them had one glaring commonality: they put everyone in the same communication environment.

Just words. No facial expressions. No vocal tone. No body language. No implied subtext handed to you for free.

For most neurotypical people, this was a massive adjustment. It stripped away all the nonverbal cues they implicitly relied on to convey and interpret tone and intent. But for an AuDHD (Autistic and ADHD) brain like mine, it was simultaneously the closest thing to a native environment the internet had ever offered… and also, somehow, still confusing in entirely new ways.

Here’s why that history (and the “Context Not Included” nature of those early tools) actually matters for how we design and use communication tools today.

The AuDHD Native Habitat: An Even Playing Field

For many neurodivergent individuals, the problem with face-to-face communication isn’t understanding what’s being said, but navigating the constant, unspoken social signaling. There’s a perpetual, high-processing effort to decode eye contact (Too little? Too much?), read microseconds of facial tension, or interpret a slightly too-long pause that apparently means “I’m upset” instead of “I’m thinking.”

Early text chat accidentally leveled that playing field. Suddenly, everyone had to state their business directly. They had to choose their words carefully because they didn’t have a pleasant smile or a relaxed posture to do the heavy lifting of showing they were friendly, or joking, or stressed.

The communication was forced to be literal. For an AuDHD brain, this was clarifying. The uncertainty of social cues was largely eliminated. We were all temporarily standardizing our communication protocol: ASCII text only. It was like suddenly everyone agreed to turn off the confusing social “feature” and just use the base OS.

The Accidental Precision of T-9 and Forced Compression

Remember trying to “text” (a brand new verb back then!) on a numeric phone keypad? T-9 predictive text wasn’t just a technological marvel; it was an accidental lesson in precision and compression. Every word you wanted to type took effort and forethought. You learned to condense your ideas not just because of character limits, but because typing was work.

This forced brevity was often a bonus for AuDHD communication styles (where directness is prized), but it also revealed something profound about context. It showed how often we assume context rather than stating it. In a limited environment like a SMS message or an AIM away message, you didn’t have room for hedging or nuanced qualifiers. You had to say exactly what you meant.

The result? The resulting text was often sparse, literal, and... easily misinterpreted by anyone looking for that assumed context.

New Confusions and the “Away Message” Subtext

But don’t get me wrong: as clarifying as it could be, this new environment still managed to be baffling. Because, of course, the people using the tools were still people (specifically, neurotypical people) accustomed to complex social signaling. They just adapted.

The result was things like the “lol” problem. Did “lol” actually mean “laughing out loud”? Or was it just a filler word to show you weren’t angry? Was “LOL” different from “lol”? We had to develop new protocols on the fly to replace the old nonverbal ones.

And then there were the away messages. Oh, the away messages! A feature originally meant to just let people know you weren’t at your computer became a high-art form of emotional subtext. You were apparently supposed to decode the exact emotional state of your friend based on a cryptic lyric, an inside joke, or the precise combination of parentheses and underscores in their message. It was a whole new layer of implied context to worry about, just when we thought we had simplified things.

Why this History Still Matters: The Context Layer in the Human OS

Revisiting the era of AIM and ICQ isn’t just a fun dose of nostalgia. It’s a vital reminder of how context actually works in human communication. Our old, text-based tools revealed a fundamental truth that’s as relevant today as it was in 1999: We tend to ignore how much meaning we load onto the words, instead of packing it into the words.

Nonverbal communication does a massive amount of hidden processing for us. When that layer is removed, as it often is in modern work (Slack, emails, even this blog!) we face the same problems we did with AIM, only now on a much larger, global scale.

Today, we try to solve the “context not included” problem with emojis, GIFs, and video calls. But perhaps the real lesson from those archaic tools is that we should focus less on finding a digital replacement for tone, and more on improving the base communication protocol itself.

We need to become better, more conscious context-providers. If we want disruptive empathy (the kind that truly understands user needs or builds resilient teams), we have to start by accepting that context isn’t a given. It’s not optional. It must be built, explicitly and deliberately, into every interaction. After all, the human operating system, just like any other system, is only as good as the context you give it to work with.

“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 !)