All articles
The Feedback They Almost Didn't Give You
There is a habit I picked up somewhere in the middle of my career, small enough that I almost don’t think of it as a habit. At the end of any feedback conversation, once my supervisor has said what they came to say, I ask if there’s anything else. The answer is almost never no. Most feedback conversations are built around correction, because correction is what feels urgent and actionable to prepare in advance. A manager sitting down to plan what to tell you runs through the list of things that need to change, sequences them, maybe softens the language a little, and walks in with that list ready. Whatever positive observations exist tend to travel separately, if they travel at all: mentioned in passing, tacked on at the start as a warm-up, or quietly dropped when the meeting runs long and the corrective items feel like the part that actually has to get said. You leave with a snapshot that’s technically accurate and still somehow lopsided, because the version of you that got written down is the version that had problems attached to it. There’s a second layer under that one, and it’s the part I find more interesting: good performance is often invisible by design. Nothing went wrong, so nothing registered as worth mentioning. A deviation from expectation is memorable precisely because it deviates. Meeting the expectation, even meeting it well, just looks like the absence of a problem, and the absence of a problem doesn’t generate a note in anyone’s head unless someone goes looking for it. Asking is the going-looking. When I ask if there’s anything else, I’m not fishing for compliments (though I won’t pretend it doesn’t feel nice when one shows up). I’m asking because I’ve learned, across enough of these conversations to trust the pattern, that there’s something positive sitting in there that didn’t make the first round, not because it wasn’t true, but because nobody had built it into the plan. I’ve written before that advice is autobiographical: a story about someone else’s context, offered to you as though it were built for yours. Feedback has a cousin version of that problem. It isn’t a complete account of your performance. It’s an account of whatever was salient enough in your supervisor’s head that week to write down, and salience is not the same thing as significance. The good work you did competently and without drama is real. It just doesn’t announce itself the way a missed deadline does. The part I actually want to talk about, though, is the ambush. Unprompted feedback, even well-intentioned feedback, has a way of landing on you rather than with you. You sit there absorbing whatever arrives, with no say in its pacing or its scope, bracing for whatever comes next because you don’t yet know how much more there is (a bracing that costs more than people realize if uncertainty is already expensive for your particular nervous system). The moment I ask if there’s anything else, the dynamic changes, even though nothing about the substance has changed. The request came from me. I opened the door. Whatever walks through it now is something I invited rather than something that happened to me, and that single shift in authorship is most of the difference between a review and an ambush. It costs about thirty seconds. It’s one sentence, asked at the end of a conversation that’s already happening anyway. And more often than not, it turns up something true and kind that was never going to make it into the room on its own.
Most Advice is a Memoir, Part II
Last time I wrote that advice is autobiographical: a story about someone else’s context, offered to you as if it were a set of instructions for yours. What I didn’t get into, because it deserved its own space, is what happens when the storyteller has a product to sell you at the end of the story. That changes the transaction completely, and it is happening right now, at scale, to a very specific and very vulnerable audience: people who just lost their jobs. Job search advice has the same context problem as any other advice. Someone got hired because of a referral they had, a market that was hiring, a specific gap in their resume that happened to match a specific gap on a hiring manager’s whiteboard that week. They tell the story afterward as a method (five things I did to land my dream job), because a method is more shareable than a shrug, and because most people, in good faith, misattribute their own outcomes to the parts of the process they controlled rather than the parts they didn’t. That’s the ordinary version of the problem, and it was the whole subject of the first post. The job search version has an extra layer, and the extra layer is money. Losing a job is one of the more acute forms of vulnerability a person can experience in professional life. Your income is gone or going. Your identity, if you’re anything like most people in tech, is tangled up with your title in ways you don’t notice until the title disappears. You are anxious, you are scrolling more than usual, and you are, for a window of time, unusually open to anyone who sounds certain about a way out. That is precisely the emotional state an entire content industry has learned to target, and it targets it with a specific, recursive product: financial freedom, sold to you in the form of a $47 PDF that teaches you how to sell $47 PDFs. I want to be precise about what that actually is, because the packaging is designed to obscure it. It is not a skill. It is not an asset. It is a replica of the sales funnel itself, handed to you as though it were the destination, when it is actually just another copy of the machine you already stepped into by watching the video. You buy the map, and the only landmark on the map is the gift shop where they sell the maps. It is a beautifully drawn map. It is laminated. It has testimonials. It was made by someone who has, in a meaningful number of cases, never actually been anywhere except the gift shop. This is not a new scheme. It is one of the oldest ones there is, wearing a hoodie and calling itself a personal brand. What’s new is the delivery mechanism: an algorithm that has learned, with some precision, exactly which faces to put in front of you the week your employment status changes on a professional network. It doesn’t need to know you lost your job. It only needs to know you started looking at job postings, and searching “how to negotiate severance,” and pausing a half-second longer than usual on a video with a rented car and the word “freedom” in the caption. The targeting is the product. The PDF is just the receipt. I said something like this in a comment a while ago, on someone else’s post about being laid off and not looking: if I have to choose between interviewing and grifting, interviewing seems a little better. I still believe that, and I want to be honest that I also went and built something in the space between those two options. I started a consulting business, not because I had cracked a formula, but because I had a specific set of skills and a specific set of people who needed them, and that combination happened to be enough to keep the bottom from totally dropping out. I am aware of how close that description sits to the thing I am criticizing. The difference, and it is the whole difference, is that nobody is buying a story from me about how I did it. They are buying the work. That is the test, and it is the same test from the first post, just aimed at a sharper target. Ask what the person is actually selling, not what they say they’re selling. If the answer is a service, or a skill, or a thing that exists independent of whether you go on to sell it to someone else, you are looking at ordinary commerce, and ordinary commerce is fine. If the answer is a copy of the pitch you just watched, dressed up as a shortcut to the freedom the pitch itself promised, you are not looking at advice, and you are not looking at a business. You are looking at a chain letter with a landing page. During a job search, this type of non-advice can cost you more than the forty-seven dollars.
More writing this week...
Saturday preview (took a tiny break this week, the good kind, not the ominous kind). Two posts landing soon. The first is part two of “Most Advice Is a Memoir” (this one’s about job searching, and the very specific grift of being sold financial freedom in exchange for a $47 PDF that teaches you how to sell $47 PDFs). The second is about feedback from supervisors (specifically, the one question I ask at the end of every review that turns an ambush into a conversation, and what usually shows up once I ask it). Back to a normal schedule next week (probably).
Most Advice Is a Memoir
The most useful thing I learned about advice I learned too late, and the way I learned it was expensive. So here it is for free. Advice is autobiographical. Every piece of it. The person giving it to you is telling you what happened to them, what they concluded from it, and what they would do again. They are not, and cannot be, telling you what will happen to you. That gap is not a flaw in the advice. It is the nature of advice. The problem is that it gets delivered in the second person, as if it were meant for you specifically, and received in the second person, as if the recipient’s job is to apply it directly. And almost nobody says out loud: this is a story about me, filtered through my conclusions, offered to you as a suggestion. Try it on. It might not fit. There is a difference between taking advice and listening to it. Taking advice means importing someone else’s conclusion without their context. Listening to advice means trying to understand what they learned and why they learned it, and then asking separately whether any of it applies to your situation. The first is a shortcut. The second is the actual skill. And the reason most people are better at the first than the second is that it’s much faster, and the person giving the advice usually seems pretty confident, and confidence is contagious in the specific way that other people’s certainty about your situation can temporarily feel like your own. I have been given a lot of advice in my career. Most of it was well-intentioned. Some of it was genuinely good. A meaningful amount of it was, in retrospect, correct for the person who gave it and actively wrong for me, and I spent years trying to figure out why I couldn’t make it work before I understood that the advice had been generated from a different dataset than the one I was running on. I am autistic. I have ADHD. I did not know either of those things for most of the time I was receiving the advice. The people giving it to me did not know either. So the advice was calibrated for a neurotypical person navigating a mostly neurotypical professional world, and I was applying it as if it had been calibrated for me, and then privately wondering what was wrong with me when it didn’t produce the expected results. “Be more visible in meetings” is solid advice if the reason you’re not visible is that you haven’t tried. It is not particularly useful advice if the reason you’re not visible is that you’re spending all of your available cognitive bandwidth processing the sensory environment and can’t simultaneously do that and perform spontaneous insight for an audience. Same advice. Completely different applicability. This is the sharpest version of the problem, but it is not an unusual one. You do not have to be neurodivergent to receive advice that was generated from a different context than yours. The person giving it might have had resources you don’t have, or constraints you don’t have, or a network that made a particular move available to them that isn’t available to you. They might have operated in a different market, a different era, a different size of company, a different set of relationships with power. The advice might have worked for them because of something they are that you are not, and they may have no idea that’s why it worked, because most of us are not great at identifying which variables actually drove our outcomes. Listening to advice, rather than taking it, means holding the conclusion loosely and asking about the conditions. Not in a dismissive way. Not in the way of someone who has already decided the advice doesn’t apply. More like: what was true for you when this worked? What would have to be true for me? Where does my situation match yours, and where does it diverge, and how much does that divergence matter? This is a richer conversation than the one most advice gives you access to, and it requires treating the advisor as someone whose experience is genuinely interesting rather than someone whose conclusions you are supposed to download. The social dimension of this is complicated in a way I want to name. Advice often comes with an implicit expectation that it will be followed, and visibly not following it can feel like rejection. In mentor-mentee dynamics especially, in startup culture especially, there is a kind of performance of learning where you receive the advice, express gratitude, and then produce a future version of yourself that validates the advice. The alternative, which is receiving the advice, genuinely considering it, and then deciding it doesn’t apply to your situation, can come across as arrogance or stubbornness or ingratitude, even when it is none of those things. It is just an honest assessment of fit. What I have tried to start doing, when advice is offered that I’m not sure applies, is saying something that is true: “That’s useful context. I want to think about how it translates to my situation.” This is not a polite brush-off. It is an accurate description of what I’m actually doing with it. I am listening. I am not automatically taking. And I have found that the advisors who are actually worth listening to tend to appreciate this, because they understand that their experience is one data point and not a prescription, and they were offering it as the former and hoping you wouldn’t mistake it for the latter. The people who are least worth listening to are the ones who need you to follow the advice in order for the advice to matter. That is not advice. That is something else. The right trusted advisor won’t ask you to become smaller.
Your Strengths Outlast the Mission Statement
I used to post like I was in a hostage video. Not literally. (The lighting was fine.) But if you went back through my LinkedIn content from my startup years, you would find a person who was enthusiastic in a way that had no texture, supportive in a way that had no specificity, and aligned in a way that, now that I am outside of it and can see it clearly, was not alignment at all. It was performance. And I was not alone in this. The whole feed was full of it. We were all doing it, in the particular key that startup culture requires, which is somewhere between “true believer” and “very excited about our Series A.” Here is the thing about that kind of content: nobody believes it, including the person writing it. Not fully. You cannot fully believe something you have been trained to say, any more than you can fully believe your own laugh track. The words come out right. The sentiment hits the expected marks. And yet there is something in it that even the most credulous reader clocks, at some level, as off. Not dishonest exactly. Just hollow. The kind of hollow that is the absence of something real, and that your nervous system recognizes even when your conscious mind gives it a pass. Startup culture produces this because it has to. You are asking people to bet on something that does not fully exist yet, to commit their time and identity and professional reputation to a vision that is, by definition, not proven. The social contract of that environment includes a certain amount of performed certainty. We are all convinced. We are all here. We are all going in the same direction with the same energy. Expressing doubt, or individuality, or even a perspective that exceeds the four corners of the mission statement, can feel like breaking the spell. And breaking the spell, when the spell is what’s holding the thing together, feels dangerous. I understand this. I genuinely do. I am not writing this to shame anyone who has posted that way, because I posted that way and I know exactly what it felt like and why. What I want to name is what it costs. Not to the audience, though it costs them something too (their attention, and a little of their faith in authenticity). What it costs the writer. Because what you give up when you perform alignment in place of expression is not just a more interesting LinkedIn presence. You give up the thing that actually builds a career. Your strengths do not live inside your company’s mission statement. They predate it. They will survive it. The things you are genuinely good at, the perspectives you have earned through actual experience, the problems you find interesting enough to think about at 11pm when you should be sleeping: those belong to you, not to the employer whose talking points you are currently reproducing. And the version of you that shows up in your content, either the performed-alignment version or the actual-human-who-knows-things version, is what people remember when you are not in the room. This is not an argument for airing grievances about your employer on LinkedIn (please do not do that, for reasons that should be obvious). It is an argument for writing from the place where your knowledge actually lives, which is usually one or two levels deeper than the mission, and which does not require you to pretend the mission is perfect in order to engage with it honestly. The people I find most worth following in any industry are not the ones who are most enthusiastic about their employer. They are the ones who are most clearly themselves: who have a perspective that you can actually disagree with, who notice things that most people in their position don’t notice, who occasionally say something that costs them something to say. Real alignment, the kind that actually means something, is not agreement. It is shared purpose pursued honestly. And you can write from that place while still being employed, still being a team player, still caring about whether the thing succeeds. The mission statement will change. Almost every startup I have watched long enough has changed its mission statement, sometimes more than once, sometimes in ways that required quiet retrospective edits to old posts. The things you actually know and care about do not change like that. They accumulate. They compound. They are, in the long run, the only professional asset that is fully portable. Write from there. The performed version is less interesting, less durable, and less true to whatever made you worth hiring in the first place.
The Block Button Is Not a Career Decision
I want to talk about the six weeks I didn’t block someone, because I think that interval is more instructive than the block itself. The situation was not complicated. Someone had been leaving comments on my posts that were designed, with some precision, to make me look like I was out of my depth. Not hostile comments (those are actually easier to deal with, because the hostility is visible and people can see what’s happening). These were the more sophisticated kind: agreeable on the surface, subtly correcting in the subtext. The kind where if you screenshot them and send them to a friend you sound paranoid, but if you read them in context you can see the architecture of what’s being built. They were positioning me, comment by comment, as someone who meant well but didn’t quite know what they were talking about. I knew what was happening. I’m autistic, and one of the things that comes with that, at least for me, is a very fine-grained sensitivity to patterns in social behavior. I might miss the obvious stuff that everyone else seems to catch instinctively, but I am genuinely good at noticing when a pattern of behavior has a structure to it. This had a structure. And still I didn’t block them. For six weeks. I wrote a few months ago about why LinkedIn makes you feel worse after you close it, and one of the things I didn’t get into in that post (because it deserved its own space) is what that platform does to your ability to protect yourself. The same mechanism that makes the scroll depressing also makes the block button feel dangerous. LinkedIn has convinced a meaningful portion of its professional user base that their reputation is a live, fragile thing that can be damaged by any visible conflict, and that the block button is a kind of conflict. So there I was, a grown adult with two decades of professional experience, doing the math on whether blocking someone who was quietly working to undermine my credibility would hurt me more than letting them continue. The math I was doing went something like this: this person has a reasonably large following. We have mutual connections. If I block them, they might notice. They might post about it (people do this). Mutual connections might see. I might come across as petty, or thin-skinned, or unable to handle professional disagreement. My “thought leadership” (a phrase I will never stop finding mildly embarrassing) might take a hit. My engagement numbers might dip if the algorithm interprets a block as a signal of some kind. I am describing this in the tone of something absurd because, in retrospect, it is absurd. But I want to be clear that in the moment it felt like genuine risk management. That is how completely LinkedIn has colonized the part of my brain that is supposed to handle self-preservation. Here is what is actually true about the block button: it is a door with a lock. That is all it is. The person on the other side is not entitled to access to you, your work, or your comment sections. There is no professional obligation, no social contract, no industry norm that requires you to leave your door unlocked for someone who is using their access to cause you harm. The idea that exercising that lock is a reputation risk is something LinkedIn’s engagement-optimization machinery has implanted in your head, and it benefits from you believing it in the same way a landlord benefits from tenants who don’t know their rights. The thing I kept worrying about, the social consequences of being visibly protective of myself, was not actually a risk in any meaningful sense. Nobody with a healthy relationship to professional self-respect looks at someone who has blocked a bad-faith actor and thinks less of them. The people who perform outrage at being blocked are overwhelmingly the people who were doing something that warranted the block. And the people watching, the mutual connections I was so anxious about, are mostly not watching at all. They have their own feeds, their own anxieties, their own six-week decisions they haven’t made yet. What I lost in those six weeks was not nothing. The comments continued. A few people who didn’t know the context probably absorbed some of the framing being constructed. I spent cognitive energy I didn’t have to spare on managing my own response in a space where I should have been able to show up without that overhead. And I modeled, for myself, a pattern of tolerating something harmful because I was afraid of how it would look to stop tolerating it. That last part is the one I keep coming back to. Because the fear of reputation damage, in this context, was not really about my professional reputation. It was about being seen as someone who couldn’t take it. Someone who needed protection. Someone who was, in some hard-to-articulate way, not tough enough for the game. Which is its own kind of LinkedIn logic, and its own kind of trap. The block button is not a career decision. It is a boundary. Those are not the same thing, and the fact that a professional networking platform has spent years blurring that distinction is one of the more successful pieces of psychological manipulation in recent tech history. I blocked them. Nothing happened. My follower count did not move. No mutual connection sent a concerned DM. The algorithm did not punish me. The person did not post about it, at least not anywhere I could see. What did happen is that I stopped spending six weeks doing math that shouldn’t have needed to be done. That is the whole lesson. I wish I had a more interesting one.
The Perfect Solution That Never Ships
The best argument against doing the imperfect thing in front of you is that it isn’t perfect. I have watched entire organizations lose years to this argument, and I want to talk about what that actually looks like from the inside, because from the inside it doesn’t feel like paralysis. It feels like rigor. There is a name for what I’m describing. The nirvana fallacy, sometimes called the perfect solution fallacy, is the habit of measuring a real option against an ideal one that doesn’t exist and concluding that because the real option fails the comparison, you’re better off doing nothing. The name comes from the Buddhist concept of nirvana, the unattainable perfect state, which is a little ironic given that the whole point of Buddhism is to be okay with impermanence. But the fallacy has taken the word and run with it, and it is running through your industry right now at a pace that would impress you if it weren’t costing you so much. Here is what it sounds like in practice. “We can’t implement this feedback process until we can guarantee anonymity.” “We can’t hire until we’ve built out the onboarding program completely.” “We can’t address the team dynamics issue until we understand the root cause.” “We can’t launch the empathy initiative until leadership is fully aligned.” What all of these sentences have in common is that they are using a real concern (incomplete anonymity, incomplete onboarding, incomplete understanding, incomplete alignment) as cover for something that is not a concern at all: the imaginary version of the thing, which would be perfect, and which will never arrive. I spent enough years in infrastructure to know what this looks like when the stakes are concrete. A monitoring system that catches seventy percent of incidents is not a good monitoring system in the ideal sense. But it is infinitely better than the perfect monitoring system you are still designing. A p95 SLO that you actually measure beats a p99.9 SLO that lives in a slide deck by any metric that matters. The engineers who understand this viscerally, who have been woken up at 3am enough times to have a healthy relationship with imperfect observability, are not confused about whether to ship the imperfect thing. They ship it. They improve it. They do this because they have learned, through direct experience, that the absence of imperfect coverage is not the same as perfect coverage. It is the same as no coverage at all. The fallacy gets harder to see when you move from infrastructure into people. And I think this is worth sitting with, because the domain shift is not incidental. With systems, you can measure the gap between what you have and what you want. With people, with culture, with the soft and unglamorous work of building an environment where people can actually do their best work, the gap is harder to quantify, which means the perfect imaginary solution is easier to construct and harder to argue against. You can always conjure a more complete version of the thing. You can always find a reason why this particular feedback mechanism isn’t quite right yet, why this particular conversation is better had after the next planning cycle, why the team health check feels premature while the roadmap is still unsettled. What you are actually doing, in those moments, is comparing the cost of the imperfect action against the cost of nothing. And you are miscounting. The cost of nothing is not zero. The cost of nothing is everything that accumulates while you wait: the engineer who decides you don’t actually care because nobody asked, the team dynamic that calcifies because there was never a structured moment to name it, the trust that doesn’t get built because the conditions for trust never got created. The nirvana fallacy hides these costs because they don’t appear on any ledger. The imperfect solution you didn’t implement doesn’t generate a line item. It just generates a culture where people have learned not to expect much. There is also a version of this problem where you are doing the imperfect thing, you have done the imperfect thing, and someone accuses you of not doing enough anyway. This happens more than people admit, and I want to address it directly because the nirvana fallacy does not only freeze leaders from the inside. It gets aimed at them from the outside too, and knowing how to hold your ground in that conversation is a different skill from knowing how to start the right project. The single most useful question I know in that situation is: compared to what? Not as a deflection. As a genuine request for the comparison being made. When someone says “this isn’t enough,” there is always an imaginary “enough” hiding inside that sentence, and it is worth pulling it into the light, because about half the time it turns out to be incoherent, and the other half it is a real thing you can actually respond to. “Compared to what?” does not mean “what I’m doing is fine.” It means “show me the standard so we can evaluate it together, instead of against a feeling.” The second thing that helps is making the imperfect action visible before the criticism arrives. This is partly about communication and partly about framing. If you implement an eighty-percent solution without naming it as such, the gap between it and one hundred percent looks like negligence. If you implement it while saying “here is what this does, here is what it doesn’t do yet, and here is when we revisit it,” the gap looks like a plan. The difference between those two things is not the action. It is whether the action has been given enough context to be evaluated honestly rather than just compared to an imaginary alternative. The third thing, and the hardest, is to stop accepting the premise that imperfect action equals insufficient effort. This is the frame the nirvana fallacy needs to survive, and you do not have to grant it. Doing the sixty-percent version of the right thing is not evidence that you don’t care. It is often evidence that you are the only person in the room who is actually paying attention to what’s achievable. The people demanding the perfect version are not wrong to want it. But they are not the ones who have to answer to the ones on the outside watching you build it, which is a relevant asymmetry that sometimes needs to be named out loud. I want to be clear that I am not arguing for thoughtless action. The answer to “this isn’t perfect” is not always “ship it anyway.” There are genuinely bad plans that should be improved before they go anywhere near a team. But there is a difference between a plan with real structural problems and a plan with the problem of being imperfect in a world where nothing is. Most of what I see stuck in organizational purgatory is the second kind. It is feedback mechanisms that would work at eighty percent. It is check-in cadences that aren’t perfectly designed but would be better than nothing. It is conversations that need to happen before someone is ready to have them flawlessly. The one thing I keep coming back to, the thing that took me embarrassingly long to stop arguing against, is this: you are not choosing between the imperfect thing and the perfect thing. You are choosing between the imperfect thing and what exists right now. That reframe does not make every imperfect solution worth implementing. But it does make the question honest. And honest questions are the only ones that lead anywhere useful. The perfect version of this post would have a cleaner ending. This is the ending it has.
Stepping-Aside-As-A-Service
A few weeks ago I was at a business networking event, doing the thing you do after the formal part ends, which is stand near the coffee and make small talk with strangers while deciding whether your social battery has one more conversation in it. Mine did, as it turned out, and the conversation was a good one. I struck up a chat with a woman who had built a successful virtual assistant business. She knew her market, she knew her numbers, and she talked about her clients the way good operators talk about their systems (with affection and a complete absence of illusion). I happened to know someone else in that exact space, a man in my network who was becoming a recognized leader in virtual assistant services. So I did the networking thing. I recommended they meet. Collaborate, maybe. Share ideas, at minimum. And then I heard myself say it: “There’s a lot he could show you.” I caught it the moment it left my mouth, the way you catch a bad config change the instant after you hit enter. What I meant was “I want to see you succeed.” What I said was “here is a man who can teach you about the business you already built.” She had the successful company. She had the track record. I had positioned her, reflexively and without a moment of conscious thought, as the student. I have spent more than twenty years in technology, most of it in leadership roles of one kind or another, and I want to be precise about what that sentence was. It was not malice. It was not even a belief I hold, in the sense of something I would defend if you asked me directly. It was a default. It was the factory setting talking, the firmware I was shipped with, doing what defaults do, which is execute silently whenever nothing overrides them. I have been working on overriding them for years. The sentence was a status report on that work: incomplete. This is the part of the conversation about privilege that I think the technology industry, my industry, is actually equipped to understand, because we already have the vocabulary. We know the difference between a one-time install and a service. Boxed software was something you bought once, ran until it broke, and felt no further obligation toward. The whole industry moved away from that model (to SaaS, to subscriptions, to continuous deployment) because we learned that anything worth running is worth maintaining, and that maintenance is not an event. It is a posture. It has uptime requirements. It gets patched on a schedule, not when the mood strikes. Most of what passes for allyship in leadership circles is boxed software. The one diversity panel. The single mentee. The statement issued the week everyone else issued one. You install it, you point to it, and you consider the matter handled, the way we used to consider a server handled because someone racked it in 2009. And like that server, it is quietly accumulating vulnerabilities the whole time you are not looking at it. What I have started calling Stepping-Aside-As-A-Service is my attempt to take the other model seriously. The premise is simple. If you are someone like me (white, male, a couple of decades into a career where the doors opened so smoothly I rarely registered that they were doors), then the most useful thing you can do with your position is not to occupy it harder. It is to treat the redistribution of access as a standing service you run, with the same expectations you would put on any production system. Always on. Actively maintained. Monitored for regressions. In practice it looks unglamorous, which is how you know it might be real. It is recommending the woman as the expert, not the recipient of expertise. It is hearing about a conference slot or a podcast invitation and asking, before you say yes, who would be better than you, and meaning the question. It is saying her idea was the load-bearing one in the meeting where the credit is being distributed, specifically in the meeting, where the record gets written, rather than privately afterward where it costs nothing. It is making the introduction and then getting out of its way, because an introduction you stay in the middle of is not a bridge. It is a tollbooth. And it is the monitoring, which is the part my networking story is really about. Because the failure mode of any long-running service is not usually the dramatic outage. It is the silent regression. The thing that used to work, that you believed still worked, drifting out of spec while the dashboard stayed green. I believed my deprogramming was further along than it was. I had read the things, examined the assumptions, done the deliberate work. And then the default fired anyway, in a half-second of small talk, in a sentence I did not plan, which is exactly where defaults live. You do not find out what your system actually does under load by reading its documentation. You find out in production. What I did next was the only part of the story I am at all proud of. I patched it live. I went back to the sentence and reframed the introduction the way I had actually meant it: two successful operators in the same space who might sharpen each other, with as much for him to learn from her as the reverse (and, given whose business was further along in the ways that counted, possibly more). A small correction. She may not have even registered the original sentence; the people on the receiving end of these defaults have usually heard them so many times that one more barely produces a signal. But I registered it. The patch was for the system that produced the bug, not just for the output. That, ultimately, is why the “as-a-service” framing matters to me, and why I am suspicious of any version of this work that comes with a completion date. A service does not graduate. There is no release where you declare the maintenance finished and walk away; the moment you do, the drift begins. The defaults I was shipped with were installed over decades, by a culture that was very thorough about it, and they do not uninstall because I have decided I am one of the good ones. Deciding I am one of the good ones is, in fact, the most reliable way to stop checking the logs. So I keep the service running. I step aside, on purpose, on a schedule, and I watch for the regressions, and when one fires in the middle of a perfectly pleasant conversation over networking event coffee, I treat it the way I would treat any incident: fix it now, figure out the root cause later, and do not waste time pretending the system is something other than what the logs say it is. There was a lot she could have shown me. That was the sentence. Next time, I intend to say it on the first try.
The Kindest Leader in the Room Can Still Build a Cult
I want to be careful here, because the person I’m describing does not exist as a villain in this story. That is exactly what makes this worth writing about. Picture a leader who is, by any reasonable measure, the real thing. Not the LinkedIn version of empathic (which is to say: someone who posts about vulnerability and gives TED-style talks about psychological safety while running a culture where people are afraid to have a bad quarter). I mean the actual version: someone who listens without performing listening, who can tell the difference between someone being difficult and someone being in pain, who builds teams where people feel safe enough to say true things. Someone who has done the internal work and whose care for the people around them is not a strategy. It is just who they are. This person is real. I have met them. I have worked for some version of them. And I am here to tell you that around this person, if you are not careful, something very strange can happen. The team starts routing everything through them. Not because the leader demands it (they don’t, and would be uncomfortable if you pointed it out). But because the leader is so reliably good at holding the complexity of a situation, so genuinely trustworthy in a way that most professional relationships are not, that people stop trusting their own read as much as they trust the leader’s. Disagreement starts to feel disloyal, not because anyone said it was, but because the culture has started treating alignment with this person as a proxy for good judgment. The team’s collective ability to reason about hard things begins to run through a single node. This is a cult of personality. It does not require a charismatic egomaniac at the center of it. It does not require anyone to have bad intentions. It can form entirely around someone who is trying to do the right thing, and who would be mortified to know what had been built in their name. I think about this a lot in the context of what I’m writing about in this book, because the thing I keep coming back to is that empathy is a capacity, not a personality trait. The goal of empathic leadership is not to be someone your team can always turn to. It is to build a team that does not need you in that way. Those are very different projects, and they require different things from you. The version that builds dependency is not always obvious from the inside, because it feels like trust. When your team looks to you for guidance on hard judgment calls, it can feel like evidence that you have created something safe. And you have. But safety that is contingent on a specific person’s presence is not the same as safety that is woven into how a team operates. One of those is a gift. The other is a dependency. They can look identical from the outside, and sometimes from the inside, for a long time. What tends to reveal the difference is a transition. The beloved empathic leader takes a new role, or leaves, or is on leave for a month, and the team either holds its shape or it doesn’t. The teams that hold their shape are the ones where the leader spent years doing something that felt, in the moment, a lot less rewarding than being turned to: they pushed decisions back. They said “what do you think?” when they had a perfectly good answer of their own. They deliberately made themselves less necessary, because they understood that the point was not to be a good leader forever but to grow people who could do things they couldn’t have done before. The teams that don’t hold their shape, the ones where everything quietly stalls or fractures or just gets visibly worse the moment the leader is not in the room, reveal something harder to sit with: the leader had become the team’s capacity, rather than building it. I want to pause here and acknowledge the obvious irony in what I’m about to say. There is a clip that circulates online of Steve Jobs answering a question about the most important thing he learned at Apple. Jobs is, by most accounts, the canonical example of a tech cult of personality. His name is on a religion. People still argue about whether he was a genius or a monster, as if those were mutually exclusive, and that argument is itself a kind of devotion. He is not the person you expect to quote on this subject. And yet what he says is this: when he sees something not being done correctly, his immediate instinct is to fix it himself. But over time, he learned to fight that instinct. Because his job, he realized, was not to fix the thing. His job was to build a team that could do great things over the next decade, not just the next year. Which meant that when someone struggled, his question had to shift from “how do I solve this?” to “how do I help this person learn from it?” He admits it is painful. He says he still fights the instinct every time. I find this genuinely interesting, and not because it makes Jobs a hero of humble leadership (it doesn’t, and there is substantial evidence to the contrary). I find it interesting because even someone who spent decades being the center of gravity in a room full of exceptionally capable people eventually understood, at least intellectually, that the center of gravity was the problem. That the instinct to fix, to step in, to be the one who makes the call, is exactly the instinct that prevents a team from becoming something that can survive you. There is also something worth naming about what happens to the leader in this dynamic, because I don’t think we talk about it honestly enough. Even someone who genuinely does not want to build a cult can start to find comfort in being depended on. The team’s trust feels good. Being the person everyone turns to feels good. Being the person without whom the hard things can’t get resolved is a particular kind of significance, and significance is not nothing. The risk is not that the good leader becomes corrupt exactly. It is that they stop noticing when their presence has become structural, when the thing they have built requires them specifically to function, and when quietly withdrawing from that center might be the most empathic thing they could do. I do not think this is a simple problem, and I am not going to hand you a simple solution. What I will say is that the question “does this team work without me?” is one of the most important questions an empathic leader can sit with, and that the answer you arrive at through wishful thinking is not the same as the answer you would get from a real test. The cult does not announce itself. It accumulates, quietly, in the gap between how much people trust you and how much they have learned to trust themselves. The kindest thing a good leader can do, sometimes, is be less available. Not absent. Not cold. Not performatively hands-off as a management philosophy. But genuinely willing to let the team carry more than is comfortable, to let them make calls you could have made faster, to let them sit with uncertainty you could have resolved, because the point was never to resolve the uncertainty. The point was to help them get better at living inside it. That is not a cult. That is a team.
Disruptive Empathy
For the past few years, I've been writing about the things that shaped how I think about work (and people, and technology, and the strange overlap between all three). Those posts are turning into a book. Disruptive Empathy is about what happens when you bring genuine emotional intelligence into spaces that have historically treated it as a liability (startups, ops floors, infrastructure teams, the places where "just ship it" is the default setting). It's part memoir, part manifesto, and entirely the book I wish someone had handed me twenty years ago. Out June 30.
What We Gave Up When We Got Infinite Scale
I remember the hum of the server room in the early 2000s. It was a physical, vibrating thing (a literal heartbeat for the company) that required us to care for it with a level of intimacy that seems absurd now. If we wanted to grow, we had to go buy a Dell PowerEdge and physically bolt it into a rack. We were limited by the length of the cables and the cooling capacity of the HVAC system. 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.
The Wiring Beneath: Autistic In The Room
I remember the first time I realized that my Cisco switches and I shared a common language. They required a specific sequence of commands, a precise syntax, and they didn’t care about my tone of voice. In the quiet of a server room, the world made sense. There was a protocol for everything. 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.
Why We Starve the Human Firewall
I was sitting at my desk recently, looking at a stack of compliance reports, and I felt that familiar, buzzing hum in my brain that comes when I’ve been staring at a problem for twenty years. It is a specific kind of frustration (one that my ADHD-i brain likes to fixate on) where the solution is obvious but the budget is nonexistent. 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.
The Wiring Beneath: The ADHD Tax
I used to think that my brain was just a series of poorly labeled patch panels. In the early days of my career (back when we were still crimping our own Cat5 cables), I assumed that if I just found the right cable management strategy, I could finally stop the signal interference. I thought that if I bought enough PalmPilots or organized my FileMaker Pro databases just a little better, I would stop losing time. 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.
Need-to-Know Basis: On Hiring Capable Women and Then Making Them Beg for Context
There is a particular kind of hire that happens regularly in tech companies, usually when something has gone sideways. A team is failing to execute. A product is stalling. A function needs to be stood up from scratch, or a relationship has been mishandled, or the company has grown faster than its systems and now things are quietly on fire. Leadership looks around, identifies the problem, and then does something that is, at least on its face, the right thing: they bring in someone exceptional to fix it. 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.
Context Not Included
If you’re of a certain vintage (the vintage that spent considerable time staring at CRT monitors, that is), you probably remember that specific, jarring sound of a computer connecting to the internet via a phone line. That digital screech was the gateway to another world: a world built almost entirely out of words. 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.
Read-Only Mode: On Working Alongside People Who Are Rebuilding Their Own Authority
There is a particular way some people hold their breath before they speak in meetings. Not the ordinary pause of someone collecting their thoughts. Something else. A scan. They are reading the room for permission, checking the faces of the people with authority before they commit to having an opinion. I noticed it for years, this pre-speech surveillance, and it took me longer than it should have to understand what I was looking at. I was looking at someone who had learned, in some previous context, that holding the wrong opinion at the wrong moment carried a cost they could not afford. “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.
Why You’re Depressed After 5 Minutes on LinkedIn
There’s a specific kind of low-grade misery that settles in around the third or fourth scroll. You weren’t even feeling bad before you opened the app. You were fine. Maybe a little bored. But then you did it anyway, and now you’re sitting there wondering why your career feels like a participation trophy while everyone else is apparently disrupting industries and “grateful for the journey.” 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.
Engineering Empathy in Post-Growth Startups
The first time I watched a senior engineer give their notice, I was sitting in an open-plan office surrounded by monitors. Half of them were displaying dashboards: service uptime, error rates, p99 latency, memory consumption across a dozen microservices. We knew, at any given moment, the precise health of every system we had built. We had alerts configured to wake someone up at 3 a.m. if a single service degraded past a defined threshold. 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.
Efficiency Vs. Busyness Theater
At some point in my mid-twenties I developed a very specific habit: whenever I felt uncertain about whether I was doing enough work, I would open my email client. Not to read anything in particular. Not to respond to anything that required a response. Just to open it, scroll through it, and let the act of checking feel like the act of working. The uncertainty would recede. I had somewhere to put my eyes, something to do with my hands. I was, by any external measure, working. 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.