All articles

The power switch on the back of the Macintosh SE was a small plastic rocker, about the size of a thumbnail, positioned on the left side of the rear panel. It clicked with a satisfying finality. On. Off. The machine did not sleep. It did not hibernate. It did not dim its screen and hover in some ambiguous low-power limbo waiting to be noticed. When you switched it off, it was off. When you switched it on, the startup chime played (a single, clean chord that sounded like a small friendly announcement), and a few seconds later you were looking at a nine-inch screen filled with everything the computer intended to be. 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.

Apr 14, 2026

There is a particular kind of quiet I miss. It lived inside IRC channels in the early 2000s, in the long pauses between messages where the cursor just blinked, waiting. You typed your reply, sent it into the void, and then you waited. Sometimes for minutes. Sometimes for half an hour. The other person was thinking. Or they had wandered off to make coffee. Or they were autistic like me, and they were composing something careful and considered in a text editor before pasting it into the channel. You had no way of knowing which, and that was fine. That was actually the whole point. 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.

Apr 7, 2026

When you are a child (especially one whose brain is wired to find patterns in the chaos of a sensory-rich world) the question “What do you want to be when you grow up?” feels less like an inquiry and more like a high-stakes architectural requirement. For those of us on the spectrum, we often interpret that question with a literalism that the neurotypical world doesn’t quite intend. We don’t just want a job; we want to inhabit a system. 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.

Feb 10, 2026

Most startup failures aren’t technical. They aren’t caused by the language stack, the database choice, or even a bad scaling model. They are, almost universally, human. 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.

Dec 11, 2025

When you talk about building a tech startup (or really, anything truly new), you’re not talking about predictable spreadsheets and established markets. You are talking about a fundamental emotional gamble. You are betting your time, your money, and your sanity on things that do not yet exist, and might never work. 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?

Dec 9, 2025

We are living through a strange, exhilarating moment. I have spent the better part of twenty years watching infrastructure evolve (from mainframes and terminal emulators to serverless functions and global edge networks), and I have never seen a technological shift ripple through the human organization quite like this one. We used to worry about uptime and latency (the hard, measurable metrics). Now, we are all worrying about meaning. 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.)

Dec 4, 2025

I spent years in data centers (loud, cold, but physically present places), where you could gauge the severity of a production issue just by the body language of the person walking down the aisle. You couldn’t hide stress, or excitement, or frustration. It was all right there (in the slumped shoulders, or the relieved high-five). 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?

Dec 2, 2025

I spent the better part of two decades in the trenches of the technology sector (infrastructure, product, strategy, support, writing about it all) and one of the most consistent (and honestly, baffling) paradoxes I’ve seen is the relationship between getting things done and getting people to trust you. 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.

Nov 27, 2025

There is a moment in the lifecycle of every high-growth, high-pressure tech startup (and frankly, every career) that defines everything that comes after. It’s not the moment the term sheet is signed, or the product launches successfully. It’s the moment the whole system fails. 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 !)

Nov 25, 2025