Lucas Pierce — BonnyCode on BonnyCode

Directions to New York

Wed, 06 May 2026 00:00:00 +0000

Long, long ago, I was born at home in Southeast Los Angeles. Our milk and potatoes were too often powdered, cereal came in bags, and Del Taco was a night out. My heart dreamed of something more. My stomach deserved better.

But where could I find better?

An uncle who’d been stationed in Bremerton talked about the good coffee and fresh sushi. The lack of sun that drove others away seemed, to me, like comfort; the California sun left me feeling exposed. I asked my parents for help getting there and they didn’t understand why I would go. They’d worked their way to California to escape places like Missouri (Missoura, if you’re my father). Why would I go someplace cold and gray, just to eat better?

I wasn’t exactly sure where Bremerton was, but I knew it was somewhere up north. I started walking. I found others on the road; I’d stop to chat, but they were too slow and I hurried past. I’d always thought of myself as a fast walker who doesn’t tire easily. After twelve hours a day for three days, my body rewarded me with shin splints. I tried to push through and it only got worse. I had to rest. Others passed me.

A stranger in an old pickup truck stopped and asked if I needed a ride. He was headed toward Vegas. He talked; I mostly listened. His life’s story was a thick novel while mine was a grocery list of hopes and dreams. He’d once been in a Ray Price cover band that was briefly popular in the Valley. He’d made his money in oil, lost it after starting a bar with unscrupulous partners, and made it again driving rigs. I told him my dream of eating better. He said the fanciest meal of his life was at a steakhouse in New York City. He described New York like it was the center of the universe, where well-dressed people dined at the best restaurants and controlled the world. His nostalgia became my dream. He said he followed Epicurus now and was content. I’d never read that magazine, but I knew it had to do with rich-people food.

He left me at the Palace Station in Las Vegas, where I ate the buffet alone until two well-dressed young men sat down across from me and introduced themselves. Caleb and Aaron had just gotten back from their missions. Caleb had been sent to Boston and was a little disappointed he didn’t get somewhere more exotic. I asked if he’d been to New York. Of course, he said. He could hop on the Amtrak in the morning and be in the city for a late lunch, which earned a disapproving look from Aaron. He talked about the pizza, how a slice on any corner was better than anything in Vegas. I hid my jealousy at how easy it was for some people while I was stuck here.

Aaron had been sent to France. New York has nothing on Paris when it comes to food, he said. I mentioned the fancy steakhouse the truck driver had talked about and he laughed. Paris was the food capital of the world. He described ordering une crêpe Nutella-banane and fresh croissants. He said croissant in this guttural way that made it sound nothing like the Pillsbury ones I popped out of a can. Aaron pulled a worn brochure from his backpack: the Eiffel Tower, a rhino sculpture, and a man declaring J’aime la France. What I didn’t understand only added to the mystique. Paris was the real destination all along.

How would I get there though? Slowly, it turned out. I got a job at a panadería. Aaron went one state away for college to study pre-law, and his parents rented me his old room for the you’re-such-a-hardworking-young-man discount. They tried to convert me a few times early on, but eventually gave up.

I lived in Las Vegas for two years. It wasn’t the Vegas tourists imagine. It was a dusty, down-to-earth city of people who never set foot on the Strip and were still bound to it. People came to get rich quick and stayed long enough to get poor. I’m glad I left, but I miss the people.

When I’d saved enough, I bought a used Toyota Corolla and drove to Corpus Christi to meet Jonathan, Aaron’s cousin, who knew how to sail. He hooked me up with a job at the marina and taught me to sail in our off-hours. He said my plans to sail to Paris were unrealistic (idiotic was the exact word), but I couldn’t be stopped. I practiced every day until I grew confident.

I sold the Corolla and bought an old catamaran, which Jonathan helped me fix up as best he could. On the day I set off, he packed me a lunch of peanut butter sandwiches wrapped in foil, two oranges, and some cheese and saltines. As he handed me the paper sack, he tried one last time to warn me off. When I insisted, he asked if he could say a small prayer. I agreed, mostly to be polite. He prayed for wisdom, which felt pointed, and then for protection, which felt unnecessary until later. Afterward he hugged me goodbye.

Leaving was harder than I thought it would be, but Paris was waiting.

I set off, staying close to the coast until Florida. When I finally struck out across the ocean, a storm hit. By morning, the boat was broken, as was my confidence. I still wonder by what grace I survived. I barely limped my boat to shore near Nassau.

Nassau was paradise. The weather was kind, the people generous, the food simple and extraordinary. Later, I wondered if the true grace was the storm itself. I made a life there. But it wasn’t me; it was a different person. A person who watched The Lion King and stopped at Hakuna Matata. A person who learned the names of bartenders, slept late, and called it freedom. He thought he had found a more authentic life; I’m less sure. Whoever he was, he stayed there. I sailed up the coast without him.

I stopped in Charleston, intending it to be quick. I’d eaten shrimp and grits separately before, but Charleston perfected them together, which I learned over long lunches with a good friend from Vegas who’d settled there. She was ill. I stayed to care for her. I was already behind on my journey. Others who had once trailed me were surely ahead by now.

But we had the best of times. We told terrible, meandering jokes with punchlines like you don’t eat a pig that good all at once. Jokes hilarious to the teller, greeted mostly with groans.

Then she was gone.

After that, leaving no longer felt like progress. It just felt like leaving. A friend with a plane stopped in Charleston on his way to Philadelphia and asked if I needed a ride. I said yes. I didn’t like Philly. The bread was overrated, the Whiz unnecessary, the winters too cold. It simply wasn’t my place.

I learned there was a train from Philadelphia to New York City and boarded it with excitement. This was what I had once dreamed of. Besides, I needed to keep moving. But New York wasn’t what I imagined. The pizza was just okay. The coffee was no better than back in Los Angeles. Honestly, it was worse.

Maybe something was wrong with me, since everyone else seemed to buy into the hype. I tried to fix myself. My bookshelf came more and more to resemble an airport bookstore. But nothing seemed to fit. Some books were too woo, too manifest-your-desires, too passive. Others were too Machiavelli, too man is an island, too take-what-you-need. If there was a middle bowl of porridge, some just-right gospel of becoming a person, I couldn’t find it. At least not at the Hudson News while I waited for my flight to board.

And yet, despite my discomfort, I was now known as the New Yorker.

I stayed long enough to let life happen. I got married, worked, had one kid, worked, had another kid, worked. I tried to slow down for them, but the world told me to hurry up.

Are you still in New York?

Wow, look at the townie.

So I kept moving. I told myself I could spend time with my kids when I got there, wherever there was. But eventually I broke.

I went back to my little corner of not-quite-Los-Angeles. Most people I knew had moved away. The friends who had stayed were strangers now. The old grocery store my mom used to take me to was still there — different name on the front, same building, smaller and dingier than I remembered. I went inside. We used to play a game there. I’d put something in the cart; she’d swap it for something else. I’d put in Cookie Crisp; she’d replace it with Malt-O-Meal.

Why can’t we get the good cereal?

It’s a waste of money.

Just one time?

Don’t you know you are what you eat? Do you want to turn into the Cookie Monster?

That scared me away from trying again.

I bought the Cookie Crisp. As a kid, I thought it would be like eating a bowl of fresh-baked cookies. It wasn’t. I checked the mirror anyway. Whoever was staring back, I was grateful he wasn’t blue and furry. But he wasn’t the boy I’d come looking for either.

Then one morning I woke up on a flight to Seoul that I didn’t remember booking. In New York, everyone who mattered dreamed of Seoul. Online I saw the cities ranked: Philadelphia, New York, Seoul, Tokyo. I couldn’t believe I’d once thought New York was the peak. How naive.

I was immediately known as the Seoul Brother. It felt wrong, a little offensive, but I couldn’t control what people called me. One Halloween, I tried bibimbap in the Asiana lounge at ICN. It was good, though I expected it to be spicier. Right after, the airport staged a mini cultural parade, with staff dressed in traditional Korean costumes. I wondered what my kids were dressed as that year. I didn’t have time to find out; I had an early flight to Tokyo. Thank the Lord, my elite status got me upgraded to business.

I lived in airport lounges for days. Or was it years? It’s hard to tell. No one grows old there. Life was a fast-moving stasis. Only in hurried trips to see family can you mark the passage of time. Parents who are suddenly old. Children who can suddenly speak and then become strangers. And you rush back, afraid that if you linger too long in that dream, you too will grow old.

I was anointed Tokyo Man. The names had grown more masculine each time, and when I asked about it, the looks I got reminded me there were rules I hadn’t learned. Tokyo Man cares about people, but not individual people. Tokyo Man is vulnerable, so long as it costs nothing. Tokyo Man supports the company vision, whatever it happens to be this week. And when you play your part well, everyone looks up to you without even knowing you.

I was learning the part. How parochial I had once been, thinking Seattle (or worse, Bremerton) was the place for good sushi. Now I knew how to ask for the right things:

Gesha kōhī o hitotsu onegaishimasu. (One coffee, please.)

Ōma no ōtoro o ikkan onegaishimasu. (One sushi, please.)

But I missed biscuits and gravy. I found a pop-up serving them in HND Terminal 3 and was thrilled. My dad used to make them every holiday: Bisquick biscuits, cheap sausage browned in a pan, then flour, milk, salt, and pepper whisked into the drippings. One Mother’s Day, we ran short of biscuit mix and tried to stretch it with some flour. “Someone” grabbed the wrong canister and added powdered sugar instead of flour. They came out glazed and blackened, but we ate them anyway, laughing at ourselves for the mistake. The airport version wasn’t funny, just wrong; the gravy was plasticky, the biscuits both greasy and dry. I missed my kids.

The company put me on its jet to Shenzhen. It was hard to believe I ever endured the chaos of commercial travel. I was told everything would be better in Shenzhen. That I would have finally arrived.

Instead, I built a boat.

I asked my family where they wanted to go, and we sailed. I taught my kids to fish, like my father taught me. My son broke his arm. We sang songs that brought joy when it was only us and embarrassed my kids when others were around. I made pancakes and fried eggs, and every time they declared them the best in the world. Then my son broke his arm a second time. I put them to bed with stories I made up in the moment, about fairies named Popoly and John Beans. We met other families and stopped to play spades, dominoes, and complicated board games we were lucky to play twice. Maybe learning the rules was half the fun.

A stranger couldn’t believe I had once been Tokyo Man. It felt like a lie even when it was true. He said I was ungrateful for turning away from such privilege. Maybe I am. But I wasn’t born on a sailboat.

Years later, a kid from Seattle asks me, How do I get to New York? Another asks, Why New York and not London or Paris? Yet another: Was it skill that got you there, speed, or just luck?

Long, long ago, I was born at home in Southeast Los Angeles.

I'm sorry for my face

Mon, 13 Apr 2026 00:00:00 +0000

I don’t hate you. I’m not mad at you. I’m not angry. I’m not trying to make fun of you. I’m not being sarcastic. It’s not because of you. I’m sorry if my face makes you uncomfortable.

When I’m content, my face doesn’t naturally give the expressions people expect. I have to deliberately put on the right face to match my emotions. It takes constant work. I think I’ve gotten better at it, but I still slip up.

When I was younger, I was more obviously weird. I’d flap my hands when I was excited. I’d count and touch when I was anxious–really, whenever my heartbeat rose for any reason. I’d often confuse people.

Over time, I’ve learned to suppress these behaviors when others are looking. I try to do them in secret. I’ve gotten better at appearing more like everyone else.

There are many reasons I haven’t shared this before. The simplest is that I’ve long been embarrassed. I just wanted to be normal. I’ve long dealt with the comments and just wanted to disappear from them. Stop being weird. Don’t do that with your hands. Smile. Stop smiling. Why are you so quiet? Stop talking so much.

I used to pray every night to just be normal. My prayers weren’t answered, but I’ve come to accept that being different doesn’t mean being broken. Normality is not the same as goodness.

Still, much of my life has been spent learning to perform normal. Not that I can pull off normal perfectly, but at least I’ve gone from weird to serious and intense. What worries me is that people hear performance and think I’m being fake. Ironically, the spaces I struggle in the most are the rigidly informal ones, the ones where people say things like “Just be yourself,” “Relax,” “Let loose.”

The problem is, I don’t look relaxed when I’m relaxed. Relaxed for me looks angry to you. So I have a choice: perform relaxed or be relaxed. I choose the performance to make other people comfortable and myself uncomfortable. It’s exhausting.

Performance doesn’t necessarily imply artifice. Not when our bodies speak different languages. Being my true self means being misunderstood. I hate being misunderstood.

When I perform normal, I’m trying to speak your language. I’m bridging the gap so I make sense to you. I’m not being fake. I’m translating.

I’ve long described myself as an introvert because it’s safe. People think they understand introverts, and the conversation moves on. But it isn’t really right.

Imagine every time you talk to someone, you’re performing a dance. You’re trying to figure out the right one, and there are real consequences for getting it wrong. No, not that dance. Wrong dance. Do the other dance. No, too slow. That dance is offensive–stop. Do this other dance. Are you mad? Do this dance right or I’ll be angry at you. Dance or you’ll get beat up. Dance or you aren’t my friend anymore. No, now you’re dancing too much. What’s wrong with you? Just chill out. Just be yourself. No, not like that. DANCE. DANCE. JUST DO IT. WHY ARE YOU DOING IT WRONG. JUST DO IT RIGHT.

Sometimes I need to step away just to breathe. My chest feels too heavy, I can’t get a full breath. I don’t need your help… I just need space. I can’t manage my needs and yours at the same time. There’s too much noise. I just need a second to focus. Please, just one second. It’s not your fault. Just let me breathe.

In Norway, I tried to order a beer by saying, “En øl, takk.” The bartender said, “Hva?” Oool. “What?” Ouoal? Oel? Urhl? Finally, in English: “Can I have a beer?” Oh, of course.

I asked him how to say beer in Norwegian. “Ool,” he said. I repeated it: “Ool.” “No, Ool.” “Ool?” “No, it’s Ool.”

I don’t have the same level of social granularity as most people. A range of reactions that feel distinct to other people can look the same to me. I can’t reliably interpret or perform them, and when I do, it takes my full concentration.

The dances of conversation are more varied than most people realize. Your unconscious gracefulness is my conscious strain.

I’m constantly guessing what the right dance is, and when a conversation shifts, I’m left scrambling to keep up. When I’m unprepared, I freeze, trying to figure out the next step. When I guess wrong, I offend people. I’d rather you think me awkward than offensive.

I can get there, but it takes time. Often, by the time I’m warmed up and have figured out the conversation, the other person has moved on, and I’ve missed the moment.

That’s why small talk and large groups are so difficult for me. It’s a whirlwind of shifting conversations. I’m not reading just one person, but a whole group at once, and it can be too much to hold in my head. The dance changes too fast and with too many partners for me to keep up.

One-on-one, slower, longer conversations can be wonderful, especially if they’re given room to breathe. Those conversations are much rarer than I’d like.

I’m afraid to talk about this because I don’t want people to pity me or think it means I’m incapable in ways that I’m not. I worry I’ll be treated as less human, that my feelings are less real. I don’t want to be a carnival trick and have people asking me to flap my hands. I worry that if people know, every action will be scrutinized even more than it already is.

I’m tired. I’m tired of being misread. I’m at the point where the potential embarrassment is worth the chance of being understood.

Being misread has had real costs throughout my life.

In college, I was taking a microbiology lab. I loved the tactile precision; getting into the zone, trying to get everything right. One day, my girlfriend confronted me.

Her: “Why are you attacking my friends?”

Me: “What? What do you mean?”

Her: “Jeff said you were coming after him.”

Me: “Who is Jeff?”

Her: “You met him at a party a couple months ago.”

Me: “I’m sorry, I don’t know who that is.”

Her: “He says you keep staring at him in lab and mean mugging him.”

Me: “I don’t know anyone in my lab. What is mean mugging?”

Her: “I don’t believe you.”

Me: “I’m sorry.”

I broke up with her not long after–not just because of that, but from an accumulation of miscommunication. It’s hard not to be trusted.

I’ve been punched and choked because my face told the wrong story.

Once, a girl thought I was flirting with her. I didn’t know I was. She asked me out, and I was caught off guard; I didn’t have time to prepare the right dance for a gentle rejection, so I said no as best I could. She punched me in the stomach for being an asshole.

Another time, I was a little too slow getting dressed in my high school locker room. I was in the zone, thinking about something, not realizing anyone else was still there. My thinking face was read as I’m challenging you, and a much larger boy grabbed me from behind and tried to choke me out.

“What you lookin’ at, bitch?”

People often think they know what I mean before I’ve meant anything at all. My face gets there first and tells the wrong story.

People often think I’m being sarcastic when I’m not, or trying to be funny when I’m not. Something about the mismatch between how I speak and how I look makes me seem insincere, as if I must be joking. Humor lives in the small breaks between expectation and reality, and I keep stumbling into those breaks by accident.

I’m more sincere than I’m capable of outwardly expressing. Sometimes I worry that if people knew how hard I’m working, I’d seem less effortless, less charismatic. But if I have to choose, I’d rather be understood than cool.

I’ve spent most of my life learning how to make sense to other people. It would be nice, sometimes, not to be the only one doing the translating.

The best part of waking up

Tue, 03 Mar 2026 00:00:00 +0000

When I was young, old enough to drink coffee but not really an adult, I had a drip coffeemaker called Mr. Coffee. I scooped pre-ground coffee from a big red can while I’d sing “the best part of waking up… is Folgers in your cup”. I later graduated to a French press, then pourovers, and then a Nespresso – which honestly felt like a step backwards from the pourovers, but it was faster and I was busy.

Now my older, more sophisticated self uses a fancy-dancy espresso machine. I have a single-dose burr grinder and I buy my beans from a guy named Hunter who roasts them in his coffee shop down the street from me. I still hum “the best part of waking up…” every morning when I make my espresso because it makes me happy and my boutique beans tolerate it.

When I first got my machine I went on a mission to git gud at making espresso. When I visit a new city, I always look up whatever the top-rated third-wave coffee shops are and order an espresso with a small cup of sparkling water. I smell it, pretend the tasting notes mean something, and savor it; cultivating my palate I call it.

For over a year, I tried different settings to get the best flavors out of my espresso. My machine is completely programmable, so you can do things like bloom your espresso shot before you pull it, similar to what you do with pourovers. I bought a tiny tool with needles to rake the grounds like it was a zen garden. I have a little metal screen that I put on top of the grounds after tamping to prevent channeling.

I love making espresso because it is so fiddly. I’ve been a min-maxer my entire life, since I first played red box Dungeons & Dragons in the 80s. Maybe espresso, min-maxing, optimization, data science all spring from the same causal origin. A desire to create meaning where there is none – layering complexity until the nothingness is hidden from view.

Just getting the grind settings perfect took me months of trial and error; too fine and it tastes bitter, too coarse and it’s too sour. By the time I finished dialing in a bag to get something drinkable I was on to a new bag and the adventure restarted. I created a log of each shot I pulled; the beans I used; the grind setting; the pressure profile; the resulting outputs (primarily flow rate); and, finally, my tasting notes. My tasting notes could be biased, so I enlisted my children to conduct a proper experiment. I would pull multiple shots with different settings, have my kids label one A and another B, and then write my tasting notes without knowing which shot was which. I got pretty wired in my pursuit of statistical significance.

Espresso is serious business to get right. When I finally perfected my espresso I pulled a shot for a friend we’ll call Bill (his real name starts with a J; he knows who he is). Bill said “wow, this is a bit too sour for me. Do you mind making it into an Americano instead?” Sure! But the real kicker… he added that he preferred the Nespresso and asked if I could bring it back out. Bill’s no longer invited over.

The bright side of betrayal is when it leads to reflection. I spent a career working with data, optimization, and improving decision-making. Fiddling around with my machine is a natural extension of those instincts. Corporate Lucas says the Nespresso is the clear winner. It’s a good enough product (better if you listen to Bill), it’s more consistent, it pulls shots faster, it’s cheaper, and it requires thirty seconds of training. I imagine a kaizen consultant emerging from the shadows and yelling muda, muda! Are they wrong? Nespresso is measurably better on every axis; a warning about the perils of letting engineers over-optimize.

I was a more joyful min-maxer when I was younger. It was a puzzle only I could solve. I’d pore over the Dungeons & Dragons rulebooks and discover the ideal combinations. Now, we have tier lists. Endlessly accessible information has outsourced what it means to be the best from personal discovery to looking it up. I would spend hours as a kid playing and replaying the same games to try to get a little better. Now, I look up a guide online, do it the decreed best way, get bored half-way through, and give up. Optimization has changed from endless exploration to claustrophobic rails.

I often felt alone as an optimizer; now it feels like society has caught up and surpassed me. Past me often felt I had to optimize for easy-to-measure and easy-to-justify; in other words, the short term and trivial. And when I prioritized for the long term and what mattered, but immeasurable, I felt subversive. The worst part is, this pressure was always more internal than external; I became trapped by my own standards of what felt defensible. How can you optimize what you can’t measure?

Yet, I still use my espresso machine. I no longer rigorously collect data. I don’t regret doing so though — I learned what I needed to learn and built intuition. I can dial in a new bag of beans to my liking within a single shot these days; partly because I’ve gotten better, and partly because I’m less persnickety. I still hum “the best part of waking up” when I make my espresso. Sometimes, and only sometimes, my shots are pretty darn good. Bill would probably disagree; I don’t care, I’m making it for myself. I even appreciate the inconsistency; too much sameness gets boring. More importantly, it gives me a different relationship to my coffee. It romanticizes it. I like raking my freshly ground beans; it feels zen. It helps me feel present. The ritual has all these little externalities that are hard to measure but add up to joy.

When I make my coffee it is a tiny rebellion that only I know about. The transcendence of craft is something I simply don’t have the energy to justify anymore. I no longer want to create something measurably good but immeasurably soulless.

Where feedback goes to die

Tue, 20 Jan 2026 00:00:00 +0000

I have a cabinet above my espresso maker where unused gifts go to sit. For each gift I said thank you, and it felt disrespectful to later throw them away, so they sit there for years. Acknowledged yet untouched; quietly accumulating.

The cabinet is what we used to jokingly call write-only storage. A physical manifestation of gratitude and obligation, but really just a way of postponing honesty. There are ideas, observations, and judgments we receive in much the same way: politely accepted, carefully stored, and just as carefully kept from interfering with how we live.

Feedback often ends up there. Thank the person offering it, assume good intent, reassure ourselves that we’ve heard it. And then place it somewhere out of sight, where it can’t trouble the assumptions we were already acting on.

Feedback matters because it is one of the few ways we ever learn that we are wrong. Most of us can go on for years acting on assumptions that no longer fit the world. Especially when those assumptions make us feel competent, justified, or familiar with ourselves. Without something that pushes back, error doesn’t correct itself. It simply settles in and becomes the often invisible background of our decisions.

Knowing when we’re wrong

Some ideas are structured so that nothing can ever count against them. “I’m just bad at math”, “people are always out to get me.” Self-fulfilling prophecies that stop functioning as explanations and instead are just comforting stories we tell ourselves.

I’ve found that one way to guard against this is to be clear, before acting, about what I expect to happen if I’m right. Without clearly set in advance, it is too easy to reinterpret any outcome as a success after the fact.

When I design a course, for example, I expect students to struggle at certain points and also have an idea of when that should resolve for most students. I often introduce implementation ambiguity early on because I believe it serves a pedagogical purpose. If students express some discomfort in how they should solve a problem in the first week, that feedback doesn’t challenge my course design.

But that only works if there’s a point where continued struggle would force me to rethink the design. I have to be specific about what confusion I expect, and what outcomes should justify it by the end. Otherwise, I’m just building up an excuse for unclear instruction as “intentional ambiguity,” and the line between pedagogy and sloppiness disappears.

The same pattern shows up in how we talk about ourselves. “I’m just someone who speaks my mind, it’s not my fault if people can’t handle it” resembles a description, but it serves as a shield. The question worth asking isn’t whether it feels true, but whether there’s any feedback that would make us reconsider it.

Feedback isn’t a score

I’ve seen people fail to accept compliments as often as they fail to accept criticism. We assume people are “just being nice.” Sometimes that’s fine — if people tell you you’re beautiful all day it’s probably good not to let it go to your head. On the other hand, if your students tell you that you look like Minecraft Steve, well, welcome to my life.

But when people consistently praise our skills and we wave it off, we end up underestimating what we’re ready for. We don’t take on challenges we could handle because we discount positive signal as easily as negative. Feedback isn’t only useful for correction. It’s often the push we need to take on something bigger.

The problem is how we frame it. If feedback is primarily evaluation (good or bad, constructive or unhelpful) then our job is to judge whether it’s accurate. Judging is a short step from dismissing. Not “is it true?” or “is it fair?” but “what does it mean that someone walked away holding this belief?” Does that change anything?

When I was a director at Amazon, long, long ago, someone on my team once told me I was scary. After they got to know me, they realized I wasn’t as scary… but they were still a little scared.

My first reaction was that this seemed ridiculous. I’m not scary; I’m kind.

I asked what made them feel that way. They said in meetings, when people would say things, I would tear apart their arguments, ask how they knew something to be true. They worried that if they spoke, they wouldn’t be able to back up what they said. I did it in a “nice” way (calm, smiling), but that almost made it worse. Like I was an analytical machine ready to point out their every flaw.

This sounded like good leadership. I was an Amazonian; I was insisting on high standards, diving deep, teaching my team to be right, a lot. Those instincts got me to where I was. But by then I was a director with a large team, and the way you act carries more weight when you have power over people’s careers. I wasn’t encouraging rigor. I was shutting down conversation. At least when I was in the room.

Who is worth listening to?

When I give feedback to students or employees, they usually want more. More than I often feel I can give. They’re gracious and frequently grateful. They ask follow-up questions. The dynamic is easy. I have credibility; I’m expected to evaluate; and what I say might affect their grade or their career. Everything lines up. Most people can tell themselves they are open to feedback. Because in some situations, when delivered by some people, they are eager to listen.

Reverse the direction and see how quickly this falls apart.

Upward feedback, and I’m using that term broadly, is easy to dismiss. “Who are you to tell me how to do my job?” Subordinate to manager, patient to doctor, student to teacher, user to product manager. And, often, the skepticism is warranted; people without expertise tend to give bad advice.

In “Arthur Writes a Story,” Arthur asks for feedback on a simple story about a boy finding his puppy. Each person suggests adding their favorite element from their own stories. They are not so much engaging with Arthur’s story as they are invested in their own. By the end, Arthur’s story has metamorphasized into a science fiction rock opera comedy about space-elephants. “Listen to feedback” cannot mean “do whatever people tell you.”

It’s a mistake to treat this insight as a license to dismiss categories of feedback entirely. The signal is rarely the literal suggestion. Arthur’s friends gave bad advice, but it doesn’t mean they couldn’t still provide useful feedback. The real skill is taking the time to understand why someone reacted the way they did, not just what they proposed as a solution. And then innovate based on what that reaction tells you.

When we reject feedback because it’s framed poorly or comes from someone without expertise, we lose the ability to understand how the people affected by our work are actually receiving it. A patient can’t tell a doctor how to practice medicine. But a patient knows when they feel unheard, confused, or scared. That’s a valuable perspective only they can give. Ignoring it doesn’t make you more expert. It just makes you blind to how it feels to be on the receiving end.

Genuine feedback is earned

People who don’t like us sometimes say things to hurt us. But, especially in professional contexts, they are often stating something true. The truth is often a better weapon than pure falsehood. I saw this pattern repeatedly as a manager and now as a teacher. Two people would not get along. They’d both point out the other person’s flaws. The criticism was often wrapped in assumed bad intentions, but underneath it calls out something observably true.

“Jack has no respect for other people. He is always late to meetings and when he does arrive derails the conversation to talk about things that don’t matter.” Is this feedback framed well? No. Does it give us some signal we can learn from, especially when combined with other details and perspectives? Absolutely.

For every blunt response like above, you’d get its more oblique cousin. “I love Jack, he is so helpful. It can be disruptive sometimes though how he arrives late to our morning meeting. I know he takes the bus here, and it isn’t really his fault, but maybe we can move the meeting?”

When you deliver the feedback, “it is important that you arrive on time for our morning meeting.” The response is too often either “I can’t help it” or, far worse, “who said that?”

The urge is understandable. Negative anonymous feedback makes me want to play detective about who said it. If I can discredit the source’s motives or expertise, I don’t have to engage with the substance. But that habit leads to a dark, unproductive relationship with feedback. It’s healthier to start by treating it in good faith unless you have evidence otherwise.

The dangerous part of this reaction is that even if you are right, you are signaling how you handle feedback. If you react with anger, or defensively, or sullenly, it causes those who value their relationship with you to hesitate next time. They learn to circle around. The unvarnished truth becomes something only your detractors will offer.

When you respond differently, with genuine curiosity and visible change, then giving you feedback becomes a relationship-strengthening act. People who care about you start to speak up.

Honest feedback from someone who cares about you is often not a gift; it is something you’ve earned through your reactions to feedback in the past.

Teaching real lessons with fake worlds

Tue, 02 Dec 2025 00:00:00 +0000

I build little worlds full of adventurers, potions, and dragons. Students run potion shops where they manage magical supply chains for demanding fighters and wizards. They run media companies providing entertainment to dragons, frog-folk, and discerning gnomes. And in the process, they become curious about how the worlds themselves work and come alive.

I worked in tech for a long time, most of it leading technical teams. I kept noticing the same thing: new grads who struggled with problems that looked nothing like their coursework. They knew how to do the work, but only if it was carefully packaged for them. In the wild, solving a technical problem is a cycle:

Formulate: Translate an unbounded, ambiguous situation into a technical problem.
Solve: Execute the technical solution.
Interpret: Evaluate whether your solution actually solved the problem.

Even when toy problems attempt steps 1 and 3, it’s often thin pseudocontext. There isn’t enough noise, and it’s painfully obvious what technical thing needs to be done.

Large language models have made this gap impossible to ignore. Step 2—doing the technical work—is now too often solvable with a prompt→copy→paste. It’s the same shift calculators brought to arithmetic: the execution is automated, but the framing of the problem is not. Simulations let me push students into Steps 1 and 3, where intellectual work continues to thrive.

I’ve incorporated simulations into my upper-division computer science courses to teach the metacognitive and epistemic skills necessary to solve difficult problems as they actually exist.

Why Simulation?

I’ve always loved simulation-style games. Ever since playing the gold-cartridge Legend of Zelda on the NES, I’ve been fascinated by the idea that the little characters in those worlds might have lives of their own; that they might keep moving even when the player isn’t looking.

That notion is the seed of my classroom simulations: worlds that run on their own, where students must reason about living systems rather than static puzzles.

My first classroom simulation-game came out of a databases course. Early on, I realized students weren’t really feeling what it meant to run a production system: the pressure, the messiness, the human factors. Software without customers is sterile. But software that serves a live world, with people depending on it, becomes something else entirely—unpredictable, alive, and worth thinking about.

For example:

Teaching concurrency errors: As “customers” fire off parallel cart checkouts, students’ code runs into fun and unpredictable race conditions. Sorry, your inventory is out of sync. You had a lost update. The week after, when I lecture on transactions, you’re excited to see it solves your problem.
Teaching design principles: Let students debug the chaos of a mutable, update-in-place system, then guide them toward architectural patterns that reduce that pain—immutability, append-only logs, systems designed for observability. That’s how many experienced developers come to care about those principles: not from theory, but from scars.

This matters even more when teaching data science. In my Knowledge Discovery class, students build recommendation engines, churn detectors, and user personas. Simulations are foundational here because of the counterfactual: for a recommender, how do you know if it’s any good without knowing what would have happened if the user was shown different content? Offline evaluation metrics often fail to capture what only reveals itself in a live test. A simulation is a way I can bring that necessary complexity into the classroom.

Simulations also provide an ethical sandbox—an advantage over even the real world. If you deploy a recommendation engine that accidentally optimizes for outrage or suppresses a demographic, people get hurt. In my classroom, if a student’s algorithm radicalizes the gnomes or creates dystopian inequality among the frog-folk, we can pause and examine what went wrong. Consequences made visible, without the lasting damage.

How I Build Simulations

My goal when designing a simulation is for it to mimic the authentic data in the ways that matter. It has to feel genuine, even when the subject matter of the simulation is fantastical. Synthetic data too often looks fake.

There are three ways fake data tends to give itself away:

Correlation: Data should be a web of interesting, interconnected correlations of varying degrees.
Shape: Data should have the right shape for its process.
Time: Data should both change over time and operate cyclically; it’s influenced by the sun, the moon, and the social patterns of human life.

Correlation

Did you know that ice cream consumption and violent crime rates are frequently correlated? I asked my students this question, and one response was, “Well obviously! Crime is hard work and you need to treat yourself afterwards.” Moving on.

Why are they correlated though? We’ve all heard the phrase correlation does not imply causation. When we say that, we mostly mean direct causation. If we accept that our highly correlated world results from a web of causes—“this causes this, which causes these two things, and then those in turn cause others”—we can use that fact as the foundation for natural-looking correlations.

I draw upon Judea Pearl’s causal directed acyclic graphs (DAGs) to make this happen. I start by drawing out a causal graph, giving each effect multiple causes, often layers and layers deep.

For example, in the interaction below, we can see how the ice-cream/violent crime correlation could arise via confounding, as illustrated using a DAG. In this case, both ice-cream consumption and violent crime depend on season (the confounder). The scatter plots show how ice-cream consumption and violent crime become correlated as a result, even without any direct causal link.

This is unrealistically transparent, though, if we actually let students see all of this. It is like the blind men and the elephant from the Tittha Sutta. One blind man feels the trunk and says “It’s a snake!” Another feels a leg and says “It’s a tree!” Yet another feels the tusk and says “No, you fools, it’s a giant spear!” Each has only a partial view of the underlying truth.

I build my “elephant” by creating a large causal DAG that naturally produces realistic correlations, but I only expose a small selection of mostly terminal nodes, and often in opaque and subtle ways.

It isn’t just about the strength and reason for correlation, we also shouldn’t limit ourselves to linear correlations. Non-linear correlations happen for various reasons, but a common one is diminishing returns. In most systems, having a little bit of something is a big deal, and every one after that matters a little less. In a messaging app, the first friend who texts you makes the app come alive. Each additional friend adds some pull, but your hundredth friend matters a lot less than your first or your tenth—you only have so much attention to give. Economists call this diminishing marginal utility: each new unit yields a smaller gain than the last. The same curve shows up in studying/exam results, income/happiness, marketing spend/impact, and many more such cases. It’s what gives a lot of empirical correlations a characteristic bend when viewed as a scatterplot.

Strength of Diminishing Returns: Medium

Weak Strong

Lastly, and perhaps most tricky, life is littered with selection biases; what we observe is almost never perfectly representative of the overall population but is biased in one way or another. It is important for our simulated data to have similar selection biases. For example, a hospital in Canada noticed when analyzing bicycle accidents at the ER, wearing a helmet was correlated with having a concussion and you were ~50% more likely to have a serious injury compared to not wearing a helmet. That seems wrong, doesn’t it?

This is a specific form of selection bias called collider bias (or Berkson’s paradox). The hospital isn’t seeing all bike riders and all bike accidents; they don’t see all the cases where a bike rider is wearing a helmet and that helmet saved them from going to the ER. As a result, the helmet effectively filtered out lower-end accidents leaving only the more serious accidents for the ER.

You find this pattern all the time when doing data analysis. You see a study on what it takes to make a successful startup, but they only look at the ones who made it, not the ones that died out. You analyze active users and forget the ones who churned. The data you have is conditioned on having survived long enough to be recorded. It’s a kind of selection echo: the world you see isn’t the world as it is, but the world that lasted.

In the simulation below, I show how food quality and location can become inversely correlated, even if they start out completely independent. This happens because survival is a filter: a restaurant can survive with bad food if it has high foot traffic (a tourist trap), and it can survive in a bad location if the food is amazing. But if it has bad food and a bad location, it goes out of business and disappears from the dataset. We only see the survivors.

Survival Threshold: 100

Combine this all together and you get data that is filled with correlations, large and small, inverse and positive, linear and not-so-linear, spurious and true. Or in other words, data that is actually worth analyzing.

Shape

I’ve long been fascinated by the beautifully smooth shapes that data makes when generated at scale. Not just systems, but data that is based on human behavior. I once assumed that because individual humans are so complicated, so individual, so hard to predict individually, that a bunch of humans would be exponentially more complicated to predict. But it is, in fact, the opposite. When you get lots of people, all the individual differences wash out, and what you are left with is the smooth underlying generative mechanisms that underlie their common behavior.

Most people are familiar with the bell curve or normal distribution. Plot human height and you’ll get something roughly normal. Human height follows this pattern because it’s the sum of many small, independent effects: genes, nutrition, environment. You can see below that adult human height is approximately normal; if you split by gender even more so.

Split by gender

Roll a bunch of dice, add them up, record that sum, repeat many times, and you’ll get the same shape; that’s the central limit theorem at work. When I see a bell-curve I see a process that has a bunch of uncorrelated randomness that is being added together. In the simulation below, try running it and seeing how as you add more samples it gets closer and closer to a smooth normal distribution.

Dice per roll

Most of the data I’ve worked with doesn’t follow a normal distribution, though. Systems and behaviors rarely follow additive processes. They are more commonly multiplicative and/or full of feedback loops—both of which create long right tails.

For example, housing prices are generally right-skewed, largely because each property’s value grows through a chain of proportional effects: land value, size, location premiums, amenities, and market appreciation all compound on top of one another. Small percentage differences in these factors multiply rather than add. This makes the main body of the distribution log-normal; it is log simply because logarithms turns multiplication problems into addition problems. Remember, normal is additive, log-normal is multiplicative. For that reason, it is common to look at these right-skewed distributions in log space.

Below, home sales data from England and Wales is charted; try viewing in both linear and log space.

Log x-axis

Source: HM Land Registry Price Paid Data, England & Wales (2024)

We can get something similar using our same dice rolling example. But this time, rather than adding the dice, we will multiply them together.

Dice per roll

Log x-axis

Many human systems aren’t just multiplicative—they’re self-reinforcing. Algorithms frequently elevate videos, products, games, or songs based on existing popularity, which in turn makes them even more popular. Because attention is finite, these dynamics often lead to winner-takes-most outcomes. This kind of feedback loop—known as preferential attachment—naturally produces highly right-skewed, power-law distributions.

When I first started plotting data—any kind of data—on user engagement, I was struck by how often these extreme right-skewed curves appeared. They looked like the chart below of reviews per game on Steam. Technically, both the reviews per game on Steam and the housing price data above are a mix of log-normal on the left, power-law on the right (I prefer to call it a mullet distribution). Multiplicative effects dominate in one regime, preferential attachment in another. The Steam data is just more dominated by power-law than housing prices are, likely because of the strength of the popularity dynamics I described above.

Steam reviews per game Log axes

You can make preferential attachment appear in a simulation by making prior success increase the odds of future success. In the simulation below I have an example of a distribution generated solely on preferential attachment.

Log axes

Getting these shapes to emerge naturally is key. When I’m building simulations, I never directly sample these distributions. Instead, I code my agents so that, taken together, they arrive at those shapes honestly. I create the feedback loops that produce power-law distributions. I make processes multiplicative where they should be, and allow for multimodality by giving categories different generative properties.

Time

When I worked at Snap, I could tell when holidays were happening without ever doing something as prosaic as checking a calendar. I’d just look at time-series charts of user engagement, split by region. If people started taking pictures at six or seven in the morning, it was a work or school day. If usage didn’t spike until around 10 in the morning, it was a weekend or holiday.

Anyone who has looked at these time-series is familiar with their rhythms. For example, below is daily demand for electricity in California for the past three years. You can see the weekly peaks plus the greater demand for electricity in summer. Summer strikes again with its many correlations.

Real data shows this rhythm for several reasons:

You see it across a day because we sleep, work, and live as the earth spins and brings day and night.
You see it across a week based on however your culture defines weekends and weekdays; Friday nights out, Sunday nights in.
And you see it across a year, driven by that same sun: the seasons, and the layers we’ve added on top—holidays, festivals, school breaks, and all the rituals that divide our time into meaning.

In the visualization below, I multiply these temporal components—daily, weekly, and yearly—to approximate the kinds of cycles that appear in real time series. Conceptually, it’s similar to seasonal–trend decomposition, where a signal is separated into trend and seasonal components for analysis or forecasting. The difference is that here I’m composing those cycles from the ground up rather than decomposing observed data.

Weekly drag dots

Annual drag dots

Trend drag dots

Combined (3 years) driven by controls above

Noise:

I combine those cycles with holidays—which turn weekdays into weekends—and make them an integral part of the causal DAG that drives my agents. By giving the root nodes those rhythms and letting them propagate through the graph, the model naturally produces the kinds of correlated effects that trip people up—spurious patterns like, “Hey, I think ice cream causes murder!”

Emergent Complexity

Now that we know what our data should look like, how do we achieve that without manually faking every data point? That sounds so complex!

It does. But we’re in luck; we don’t have to (and we shouldn’t) code the complexity directly. We rely on it emerging. When programming our simulations, we can focus on just the primary generative mechanisms (with some added individual-level truly random noise), and generate an overall more complex simulation with very simple individual-level rules.

The fact that complexity can arise from simple rules is well established. Boids is the classic example: three simple rules—steer away from crowds, move with the flock, and head toward its center of mass—produce beautiful flocking behavior. That’s always the goal: rich, organic behavior that feels real but emerges from simple, understandable rules. Try adjusting the relative strength of those three simple rules in the simulation below; you can see the mix of effects that emerge.

Separation (avoid crowding) 1.5

Alignment (match direction) 1.0

Cohesion (stay together) 1.0

Boids: 100

My agents are generally utility-driven; each agent has a utility function that it tries to maximize at every step. Individually, they’re single-minded and unintelligent, and if I relied on any one of them alone, the simulation would quickly collapse into some pathological or divergent behavior.

To avoid that, I build a range of intentionally simple strategies. One set of agents repeats whatever was most profitable in the past; another acts randomly; another imitates whatever has been most popular recently.

What I’ve discovered over years of building these systems is that when I combine many such agents—each using different but simple heuristics—the overall system becomes surprisingly robust and often appears intelligent. It’s a form of the wisdom of the crowds: a collection of uncorrelated, naïve guesses can, when aggregated, produce remarkably accurate behavior.

I create balance in the system without hard-coded limits by putting agents in tension with one another. As an example, I have a simple predator-prey simulation below: the prey eat grass, predators eat the prey. When there are too many prey, the grass thins and predators thrive; when there are too many predators, they starve. The system naturally ebbs and flows as everyone does their part to keep it in rhythmic balance. You can play around with the levers to see if you can make the system stay in balance without the ecosystem collapsing.

Cat Speed: 1.5

Mouse Speed: 0.6

Grass Growth: 1.0

Cat Vision: 10 cells

Mouse Vision: 5 cells

Mouse Reproduce: 5 grass

Cat Reproduce: 15 mice

Starve After: 50 turns

Log scale

I usually introduce some form of survival of the fittest to stabilize things. I’m not afraid to let agents die if they can’t achieve their utility, but I’m always spawning new ones. When new agents appear, they mutate off the strategies of the successful ones. Winning strategies get copied (with variation), and the rest die off.

Over time, the system reaches a kind of equilibrium. I never expose day zero of my simulations; things are too weird then, too obviously hand-tuned. Instead, I let the world run for a while and settle; I let the genetic algorithms do their thing. I graph everything, check the curves, adjust the balance. For many processes, I already have strong expectations on what everything should look like, because I’ve seen the equivalent in my work many times over. When I haven’t, I search through papers and find empirical observations I can ensure my simulation matches the same generative spirit.

It is less pure engineering and more gardening. I tend to my simulation as much as I build it. Little worlds, carefully grown, for students to explore.

If managers were angels

Tue, 21 Oct 2025 00:00:00 +0000

“If managers were angels, no upward management would be necessary. In a career administered by people over people, the great difficulty lies in this: a manager must be allowed to manage the managed; and in the next place, the managed must, in turn, also manage upwards.”

— Jim Madison, ex-VP BigCo, 3x Founder, Board Director, Executive Coach, Author of Jim’s Federalist Newsletter

Alleigh refills her mug; her fifth coffee today. It’s been a rough week. She checks her phone to confirm the room: 3:00pm — 1:1 Sherry/Allie — Conf. Room Blackpink

Blackpink? That’s the fishbowl next to Stray Kids. When Alleigh started at BigCo six months ago, K-pop conference room names seemed kinda fire. Now when she hears Pink Venom she thinks of sprint planning meetings.

Alleigh finds her room, Sherry isn’t there yet; good, she has a few minutes to plan what she wants to say. This will be the third “biweekly” 1:1 Alleigh has had with Sherry. Is she allowed to complain in these meetings? Should she give updates? Or make small talk?

sry running 15 mins late — sher

Alleigh’s supposed to be increasing the shininess of the checkout button by fifteen percent. Why did she get stuck with this stupid task? She wants to build AI models, not mess around with button pixels like some front-end dev.

Sherry, the team’s manager, has been pushing everyone to log more PAT hours. Why can’t they just use a normal LLM?

allie4339@bigco: PAT, write a design spec for WEBX-9941
PAT@bigco: Thinking, Boss... 🧠
PAT@bigco: Still thinking, Boss... 😎💪
PAT@bigco: I did the thing: specs/webx-9941.md 📝
PAT@bigco: Love ya Boss! 💖

PAT is worse than no help, though. So far it’s made the button purple, disappeared the button, cloned the button, and almost nuked the checkout page.

Alleigh can’t find Dave anywhere. He’s supposedly her mentor—or wait, her “onboarding buddy”? Either way, he’s never in the office; Dave is wherever Dave goes.

need to cancel. meeting ran over. anything important you needed to cover? — sher

Important? What does that even mean? Alleigh grabs another coffee and readies herself for yet another night making this cursed button shiny.

Alleigh’s supposed to be a “rockstar.” Or as her mom would say, “You’re just so good at this computer stuff.” She graduated in under four years, got straight As (well, nearly, she got a B in bowling), all while working at Baby Gap.

When she started at BigCo, Alleigh imagined that through grit and hard work—are those the same thing?—she’d quickly rise in the ranks. Instead, she’s spinning.

During sprint planning last week, she was excited to take on the button shininess task. It was an urgent request from the VP of Product. She’d never touched that area of the code, but hey, she’d taken a web development class.

Originally, Sherry tried to assign it to Sammi, but Sammi sandbagged the estimate and said three story points. Alleigh raised her hand and said she could do it in one. She didn’t even want the task—the churn detection ML saga looked way more interesting—but she felt like such a hero taking one for the team. Sammi was all too quick to let her. Sammi then convinced Sherry to let her work on some devops task—blah, blah, blah. Alleigh didn’t care. It sounded boring.

Alleigh expected there to be some constant like checkout_button_shininess that she could just change. Or some CSS somewhere with a shininess style. Instead, there’s nothing. The checkout button magically materializes on the page in all its too-matte glory. Witchcraft, probably.

Is this important? Or will Sherry think Alleigh’s incompetent and regret hiring her if she asks for help?

This is Sherry’s second year as a manager. She was the team’s tech lead before, and when the old manager left, she asked the director if she could have a shot at it.

As a tech lead, things were so much simpler. Refactoring systems, reducing latency, building elegant UI component architectures. She could get in the zone for hours solving complex problems and she was celebrated for it.

Now executive leadership has her tracking “PAT hours”—from 20 hours to 30 hours per team member per week, a 50% QoQ improvement. Sherry knows it’s ridiculous. But as her dad used to say, “You can’t fight city hall.”

She’s worried about Dave. They started at BigCo around the same time, and he was her lifeline in those early days. Something’s off with him lately. He isn’t himself anymore. Sherry suspects something bad happened in Dave’s personal life but doesn’t want to pry. Sherry’s never been great with this touchy-feely stuff. She’d hoped pairing the new hire Allie with Dave would be a win-win: inject some energy into him, give Allie some stability.

Kait’s been complaining about Sammi again. Sherry doesn’t get it. Kait says Sammi smirks when she talks and calls it a “micro-aggression.” Why does Sherry need to handle this? She wants to just tell Kait to stop looking at Sammi then. Sammi delivers on time, every time, she is a rock. She needs a team of rocks right now.

And don’t get her started on Alex. Fighting his PIP (aka “probably getting fired”), HR investigating. It’ll be such a weight off her shoulders when he is finally out the door. Good grief.

Her PAT “red alert” meeting with leadership is running over. These meetings are the worst. Plus there’s RIF (aka “probably a lot of us are getting fired”) rumors. All the managers are on edge. Sherry can’t lose this job; her husband’s been out of work since March and the mortgage isn’t paying itself… Breathe, it’s fine. Sherry’s handled worse.

Her 1:1 with Allie is coming up, but she needs to push it. It feels terrible to keep cancelling, but last time Allie just stared and gave one-word answers. Maybe she should just sync with Dave instead? No big deal, right? Breathe.

Alleigh finally gets up the courage to send an email to Sherry:

URGENT: Update on WEBX-9941: Increase checkout button shininess by 15%

Dear Sherry,

I have one thing I wanted to bring your attention to in our 1:1 – the one that you unfortunately cancelled. I’m working on WEBX-9941 – the checkout button shininess task – and we, again unfortunately, underestimated how long it would take. I’m trying to get help but I can’t find Dave. This task is also beyond PAT’s current operating capabilities. We need to push out how long the feature is going to take.

Regards, Alleigh

Here you go, Boss! 🌈☝️Would you like me to make it sound a bit more formal while still making sure you don’t get blamed for this? 😎💖

Alleigh sits back with pride; adulting.

Ten minutes later, Sherry replies:

CCing Dave. Allie, we are committed to getting it in this sprint with VP of Product. It can’t slip. Dave, can you please unblock Allie? — sher

Before Alleigh has a chance to process what Sherry said, Dave’s response comes through:

Allie, I’ve been working on a critical patch for PAT. If you need help, you can just send me an email; I don’t see anything in my inbox from you. The code for shininess is handled in shiny_controller. There’s no reason we should need to slip this; it’s a trivial change.

Fuuuudge.

Why would Sherry CC Dave? Does Dave hate her now?

Dave says the feature’s easy, but shiny_controller straight-up doesn’t exist. She checks git history and it was deleted three years ago. Long gone.

Awesome. Love that for her.

Why is the whole world against her? Alleigh wishes she had taken that government job instead.

In last-ditch desperation, Alleigh reaches out to Sammi. Sammi was a little odd, but who else did she have left?

Heyyy Sam, I could really use your help. I totally underestimated the shininess button task. I’m losing it fr.

Dave pointed me to shiny_controller, but that doesn’t exist anymore. Reading that refactor task, it seems like the logic was moved to uber_controller, but that’s doing some reflection madness I don’t understand.

When I try to get PAT to do it, PAT keeps gaslighting me, ‘Yes boss! I made the button extra shiny ✨🚀’, but then just makes the button disappear.

Is there any docs you could point me to, or do you have any idea if I’m on the right track? I really appreciate whatever help you have. 🙏 - Al

No response.

Sherry must have told the whole team not to help her. She started drafting how she’d tell her mom she couldn’t make it. How she was a failure. Would she have to move back into her mom’s house?

An hour later, Sammi finally replies:

Al, yeahhh… I assumed when you said it would only be one point you had no idea haha. So the thing is don’t mess with uber_controller. This is all domain-driven. You need to look in the FUON files, which contain our CSS derivatives. The whole thing is crazy over-architected and honestly the worst.

Let me just point you toward some similar tasks, and that might be enough to get PAT cooking. Task 1, Task 2, Task 3

Cheers, SM.

Alleigh opens up the links; she’s both horrified at how the system works and, honestly, so relieved she could cry. She drops PAT the tasks for reference. PAT is also horrified (“It hurts, Boss 🫠🫥”), but PAT finally, if reluctantly, knows what to do. Alleigh works with PAT the rest of the afternoon to craft the perfect elegant sheen on the checkout button. It’s the first time she’s felt accomplished at BigCo.

When she finishes, Alleigh walks to Sammi’s desk. Sammi’s vibing behind her bulky headphones, locked in, typing like an actual menace. Alleigh waves to get her attention, and Sammi oh-so-slowly slides the headphones off. Alleigh gushes a stream of thank-yous. Sammi averts her eyes, turns a shade of red under the praise, and manages the most awkward, forced smile. Alleigh doesn’t care; Sammi is her savior, and she’s going to suffer through some well-deserved adulation.

A week later, the Product VP asked to roll back the shininess; it was too shiny.

Epilogue

Years later, Alleigh thinks back to those early days at BigCo (before the merger with MegaCo). She wanted to quit so badly that week. If she could have afforded it, she would have. Instead, she stuck with it. She adapted.

Sherry grew into a better manager, though never a great one. She later transitioned to Principal Engineer and, only then, became a strong champion for Alleigh.

When Alleigh became a manager herself, she used her experiences to be better. To make things a little fairer. More humane. Sometimes she even succeeded.

Dave left for Google not long after the shiny button incident.

Sammi and Alleigh became friends—perhaps inevitable, given their names rhymed. It turned out Sammi was completely hooked on VR rhythm games. They played every Thursday for years. They eventually lost touch when Alleigh moved to another company. She still thinks of Sammi sometimes and keeps meaning to reach out.

Decades later, Alleigh received a card from PAT: “Miss you Boss 🎄🎅. Merry Christmas!” Alleigh doesn’t celebrate Christmas. And it was July. But the thought was still nice.

Alleigh didn’t become a CEO, nor unimaginably rich or powerful. But she built a good career that supported a good life.

The button stayed matte. Everything does, eventually.

But it caught the light, once, just right.

PAT whispered, “beautiful, boss 🫡”.

And, for a moment, the machine was right.

The architecture of truth-seeking

Tue, 30 Sep 2025 00:00:00 +0000

A brilliant executive I worked with hired a team of PhDs to automate a critical process deep in his organization. After a year, they delivered plans that were as beautiful as they were unworkable.

So the manual decisions continued. At most, the team only glanced at the optimal plans. The leader would check in, demanding progress. The team kept saying “any day now, the model doesn’t work perfectly yet.” The leader grew more frustrated. The cycle continued, until finally, everyone just… pretended it all worked. When asked “are you using the new system?” they’d palter “yes”; technically it was true. They glanced at its output while making the decisions that made sense for the business.

For years after, this executive would roll out this automation success story when teams in the rest of the company told him something wasn’t possible. And the manual team in his own organization kept quietly doing everything the old way. He never noticed. Or never asked. He had his success story, and that appears to be all he really needed.

The original leader left. Eventually nearly everyone who was originally involved left. But like the Ship of Theseus, the web of lies was somehow maintained–each new person inheriting the fiction from the last.

Until someone asked the obvious question: “Why isn’t this thing actually plugged in?”

So they did what any smart person would do. They plugged it in.

Disaster. It ordered all the wrong things: shortages and chaos. Immediate management’s post-mortem blamed “overly aggressive cost optimization.” The truth? The automated plan was more expensive and wrong. But the superiors above weren’t close enough to know that.

The largest improvements I’ve seen in companies have often been mundane: fixing systems that ran on garbage data nobody knew was garbage. Truth doesn’t bubble up naturally; it has to be designed in. You need different teams in productive tension with each other. Without agonism (the structured contest-of-perspectives), even good people end up maintaining elaborate fictions.

When processes drift apart

I saw this dynamic play out vividly at a place we’ll call the widget factory (for lack of a more creative way to anonymize). The goal was simple: shorten the lead-time for new widget capacity. What mattered wasn’t the average delivery time, but the P95 (95th percentile) lead-time. A reliable date they could build forecasts around. The shorter that lead-time, the less buffer capacity they required and in turn the greater their capital efficiency. That lead-time was originally around six months.

The workflow was split between two teams (it was in actuality two dozen teams, but I’m simplifying): Delivery, who bought the widget machines, and Installation, who set them up.

Management gave each team a simple mandate: get faster. Delivery was told to cut its P95 from five months to two. Installation, from two months to one week. On paper, they crushed their goals. Promotions and celebrations all around.

Except for one problem: the customer’s total lead-time was growing. From six months, to seven, then eight. Even though P95 times don’t simply add (the worst 5% of cases rarely coincide), we expect the overall P95 to be lower than the sum of the sub-P95s. If the total P95 ends up much larger, that’s a sign our assumptions about independence, distribution shape, or what’s being measured are breaking down. When asked, each team pointed to their charts. “Don’t look at us,” they’d say. “Our numbers are going down.”

The truth was hiding in the gap between them: an unmeasured no-man’s-land. By tracing the entire workflow, from the customer’s order to the machine going online, we found both teams’ clocks had drifted further and further apart. Installation wouldn’t start their timer until labor was physically ready to swarm the machine, making their part look especially fast, especially when a large batch of deliveries occurred at the same time. Delivery would stop theirs based on a projected delivery ETA, not the actual arrival. This exempted them from shipping and material delays they felt were beyond their control. Each team’s clock was paused while the customer’s kept ticking.

We joined the clocks. The moment Delivery marked a machine delivered, Installation’s timer started, no exceptions. The data improved instantly because the teams were now interlocked; if a delivery was only real on paper, the Installation team raised hell. If a large batch of deliveries occurred, Installation either needed to staff for that peak or negotiate level-loading with the delivery team. The overall cycle time finally began to drop.

A happy story, where everyone learned a valuable lesson for the future?

If only.

Nobody wanted to admit the earlier promotions and celebrations were based on illusions. So instead of owning the fix, leadership credited it to another high-profile project that was failing. On paper, this worked perfectly: the failing project suddenly looked successful, and no need for a mea culpa.

The language justifying this sleight of hand was meticulously drafted to achieve two goals: 1) avoid being outright false, and 2) stay vague enough that nobody would ask the obvious questions.

But as the story climbed the org chart, that deliberate phrasing was discarded. Higher-level executives, remembering only the original pitch, rewrote it into a neat success. What had started as a fuzzy misdirection hardened into a plain lie. By the time anyone noticed the mismatch, it was politically impossible to correct without admitting to the larger subterfuge. Truth wasn’t the only casualty. The chance to learn what actually works (and what doesn’t) died with it.

This wasn’t an isolated case. The dramatic wins I see in companies are rarely about brilliance; they’re about avoiding something dumb. But nobody celebrates that. It’s better for your career to say you launched a fancy AI initiative than to admit you fixed an operation built on misconceptions. This is improvement laundering: when executives construct heroic fictions because the truth is too embarrassing.

When lies are cheap and truth is expensive

The same pattern shows up in today’s tech companies, where truth itself is supposed to be measured in data. In that world, data science has become a key arbiter of success. They interpret A/B test results and declare a product launch good-to-go. This creates a natural tension. When data scientists are centralized, product leaders complain they have to beg for resources. So, at one company I was at, a seemingly logical decision was made: embed data scientists directly into product teams.

The predictable result? Methodological correctness left the building. The new incentive for the data scientists wasn’t to find the objective truth, but to deliver the messaging their management wanted to hear.

This came to a head with a major product launch. The A/B test results were terrible. But for internal political reasons, the launch had to proceed. Product leaders were afraid Engineering would complain if they shipped with bad numbers, knowing they’d get blamed for the inevitable fallout.

So, the embedded data scientists found a solution. They peeked and snapshotted the A/B test results less than a day after the experiment launched.

They exploited a novelty effect. The new, confusing UX meant users initially spent more time on the page, pushing some engagement metrics into the green. It was a perfect, fleeting illusion of success. Within a week, of course, the test would turn deep red as frustrated users churned. But so long as you took a snapshot in those initial hours after release, you could declare success. The data scientist was careful in how they presented results; an incomplete truth that balances on a particular phrasing: “Early results show an average treatment effect on time spent as 2% higher.” No mention that it’s a novelty effect or statistical significance.

Then the falsehood evolved. The manager’s summary to leadership: “User signals are positive.” The VP’s report: “Users love the new feature.” Nobody exactly lied. The data scientist was misleading but never outright lied. The people who turned it into “users love this” weren’t lying either. It was a natural, if incorrect, conclusion based on the report they were given.

An engineer, suspicious as to why the A/B test was suddenly green after so much time being red in earlier iterations, passed it to the central data science team. They immediately saw what was wrong. The A/B platform had guardrails against exactly these issues, but the embedded data scientists built custom notebooks that bypassed these safeguards in the name of flexibility. When the central data science team raised these issues, the conversation wasn’t “this is terrible” but “we’re all on the same team, anyone can make this mistake, is it even wrong? We aren’t playing gotcha here.”

This is how plausible deniability forms an immune system for falsehood. Nobody wants to assume malice for what can be explained by ignorance. Irrespective of intent though, when the mistakes are always in one direction, always toward what power wants to hear, the company develops antibodies against truth rather than lies.

The asymmetry is brutal. Creating these falsehoods costs nothing; you’re reading the data through the right lens, being a team player. But catching them requires substantial investment: digging through data, understanding what really happened, often challenging what powerful people have already celebrated. By then, those in positions of power have staked their reputations on the success story. The correction comes with political cost, while creating the necessary fiction comes with promotion.

When the balance of incentives tilts this way, the ability for an organization to generate reliable truth doesn’t only suffer. It dies. The wrong lessons are learned. Poor decisions compound. This isn’t the system failing. As perverse as it is, the system is working exactly as designed.

Designing for truth

If systems are working exactly as designed, the real question is: how do we design them differently?

Truth follows the logic of a tragedy of the commons. The rational choice for any single person is to stay silent to protect themselves. But when everyone makes that same rational choice, the system breaks.

The solution isn’t asking people to be heroes. It’s building systems where truth-telling isn’t an altruistic act. This requires what I called agonism earlier: structured tension between teams that makes comfortable fictions impossible to maintain.

But not all tension creates truth. The stories above reveal the necessary conditions:

Equal political standing. When data scientists reported to product teams, they became an internal marketing department rather than independent peers. The asymmetry was brutal: creating falsehoods cost nothing while catching them required substantial investment.
Interlocked accountability. When the widget factory joined clocks together, neither team could retreat into convenient measurements. Their friction became productive only when success required confronting a shared reality.
Proximity to operations. The automation fiction survived because the executive never descended to where decisions actually lived. The desire to tell narratives of success shouldn’t become a substitute for on-the-ground reality.
Protected truth-tellers. If you want truth in your organization, truth-seeking should be incentivized rather than something that requires a warning label. Truth-telling should be rewarded, not punished.

Most organizations are designed for comfort, consensus, and clean narratives. And they get exactly that. The rare few that get truth do so because they’ve made fiction more exhausting to maintain than truth. In those organizations, plausible deniability can’t form an immune system for falsehood. The cost of the lie finally exceeds the embarrassment of admitting it.

Work Hard, Have Fun, Go Home

Thu, 11 Sep 2025 00:00:00 +0000

hus·tle cul·ture ˈhə-səl ˈkəl-chər
noun

the performance of results when actual results are missing; specif.: a workplace ethos where the appearance of extreme effort is rewarded more than the achievement of tangible outcomes.

a management technique characterized by demanding longer work hours to compensate for a lack of strategic direction or a lack of management domain knowledge.

archaic: the belief that professional success is directly and exclusively proportional to the time spent engaged in work-related activities.

See also: performative work, burnout culture, toxic productivity

I could lecture you on the dangers of burnout in tech, the importance of having a life outside your job, and the ethics of exploitation. For many ambitious, high-achieving young engineers and students, those warnings simply don’t matter. The thinking is: I’m at a point in life when I can work hard and put in long hours, so why not? I’ll reap the benefits later. I’ll go where hard work is most rewarded and live for the hustle.

I was the same early in my working life. I tried to log as many hours as I could. My first jobs were paid hourly, so more hours meant more pay. I loved it when overtime was approved; it meant my bills were paid.

When I moved into a salaried tech role, I kept working long hours even without the direct financial incentive. Part of it was insecurity: I worried I wasn’t as smart as people thought, so I worked extra to meet expectations. I hid how much I was working so people would think I was effortlessly talented. I went home when everyone else did, then devoured books, built simulations, and pursued deep understanding. Older mentors talked about paying your dues and building a strong work ethic for life. And the truth is, I often just loved the work. Solving difficult problems was fun.

Just power through

I was a tech lead in an organization run by a GM who lived and breathed rise and grind. His credentials were impeccable (think, Harvard MBA, McKinsey, straight to GM). And he was furious when things didn’t go his way. I mostly avoided his wrath because my team hit our goals. But the teams that missed a deadline? Mandatory weekends in the office, late nights, daily standups.

I made the mistake of dialing into a large project meeting right before a long-planned family trip. One of my sister teams announced that a project due the next week was suddenly red and likely to slip by weeks. My GM exploded.

I became excited for my time to speak. My projects were going well, I thought their disaster would make me look better in comparison. And I was on that pre-vacation high, thinking about margaritas and the time I needed with family.

So, I said in a tone that was unmistakably smug:

“All our projects are on track and running as expected. As a reminder, I’ll be out next week in Cabo and won’t make next week’s meeting.”

Silence. I’d miscalculated.

“NO! NO VACATIONS! This is a code red! You are going to help the project get on track! We are all one team here!”

I protested that I knew nothing about the project. I even tried to cite Peopleware. All the wrong things to say. I was ordered to cancel my time off, join the team over the weekend, and personally guarantee the launch.

I canceled my trip; the rest of my family went, just without me. I tried to help the project but had no context. I was also tired; my body and mind had already prepared for a break and now it was yanked away.

The project was eventually abandoned before it ever launched. Several months later the GM stopped showing up to any meetings. A week-and-a-half later we got an email from our VP: our GM had taken a new role and they were looking for a replacement.

A little right beats a lot of wrong

That was a turning point for me. Something broke in me: I stopped seeing the world as a list of tasks that just needed dev hours applied to them. Rather than work that weekend (my typical routine), I went to a coffee shop and just relaxed. My mind naturally went to reflection and I pulled out my notebook. I started planning. I could either be a victim of the unfairness in the world or I could strategize. I chose the latter.

That became my go-to strategy for the rest of my career, and it served me far better than my “just power through it” approach ever did. The beauty of tech, unlike when I was a laborer on construction sites, is that there is often a ten-times better way to solve a problem in tech. What you actually need to build is usually less clear than people realize, and once you do understand it, there are often much simpler ways to get there. Overbuilding is the default in tech, usually because they never took the time to clarify the real need. The result is a generic monstrosity that only half solves the problem. Once you recognize that, you start to see opportunities to approach problems differently. But you cannot do that if you are stuck in stressed, execution-only mode.

Symptoms of hustle culture

The most dangerous thing about hustle culture isn’t just the long hours; it’s the systems it creates. Burnout becomes normal, vacations disappear, and leaders learn to paper over failure with stories of sacrifice. You see the same patterns everywhere.

Vacations that never happen

When I first joined AWS, I shadowed all the roles in the overall process I was going to automate; a process involving billions of dollars in infrastructure purchases. I was terrified when I discovered a single mid-level employee owned one of the steps in the critical path. They were the only person who had ever done the step. No one else knew how to do it. They scheduled their time off around performing that one step, and hadn’t taken a vacation longer than a week as a result since taking on the role. A single point-of-failure, dutifully keeping an empire running.

When a company culture demands always being on, it invites these types of systematic risks. Smaller versions exist on every team: the “indispensable” developer who never fully disconnects. Until they leave and you discover the trail of things they owned starting to fall apart. One of my first audits as a manager is simple: check when people last took real leave. Not a day off, but at least one week, preferably three. If it’s been over a year, that’s a red flag. It’s the easiest way to spot single points-of-failure.

Who you want at 3 a.m.

Most of my teams required on-call duties. The engineers I trusted in those rotations weren’t the ones who glorified all-nighters. They were the ones who slept, took breaks, and stayed calm. At 3 a.m., clarity matters more than brute force.

The people I don’t want on call are the heroes who think every problem can be solved by powering through. I’ve inherited teams with one developer who lived perpetually on call. That’s not dedication; it’s a disaster waiting to happen. It means no one else understands those systems, no one else can step in to help. And what happens if two of their systems break at the same time? Who are you going to bring in then?

Effort as a cover story

I believe a meaningful amount of the promotion of hustle culture is actually just covering for failure. I’ve helped companies with the metrics-side of public statements for many years.

When results are good, leaders talk about results. When results are bad, leaders talk about some obscure metric trending upward. When everything is bad, leaders talk about how hard everyone is working.

That’s what I assume when founders post something like:

Baby born two hours ago.

No time for sleep.

I’m back at the keyboard grinding on my lifelong dream: catpu.ai — Agentic AI for Cat Litterboxes.

This is what it takes.

#founderlife #backtowork

Or when a CEO says:

We work long, hard, and smart; two out of three doesn’t cut it. Our competition is working seven days a week, 15 hours a day.

If the product were compelling, they’d talk about the product. If the company was doing what it needed to, they’d talk about that. If they had a strategy to lead the company forward and innovate, they’d preach it from the rooftops. But when they don’t, the message becomes “can you guys, um, work harder?”

I’ve encountered different reasons otherwise smart people fall into this pattern of thinking. I’ve met the consultant-turned-executive who, after being trained on maximizing billable-hours, still thinks hours equal revenue. I’ve seen the non-technical leader who doesn’t understand what the team does, but just assumes the more, of whatever it is, the better. I’ve observed the too-far-away leader who is overwhelmed with the size of their org and is left with email blasts such as: “plz guys, can you just push until the goals are green?”

The Death Spiral

Push these symptoms far enough and you hit the Death Spiral. It always starts the same way: a missed goal, a new threat, leadership with no clear plan.

Let’s say we’re working at a social media company when TikTok first came out. At first, the company says: “not a big deal, totally different business than us”. Video view time starts decreasing. Maybe we broke something? Tell the engineers to look for any bugs. Meanwhile, once-golden demographics like US 15-22 year olds stopped showing up. What can be wrong? Then things get much worse. View time starts to nosedive. The engineers say nothing is broken, customers just aren’t showing up. Marketing reports are coming back saying our users are on TikTok. Competitive analysis points in the same direction.

What do you do? Now this is an emergency. You start the daily executive meeting to re-establish a sense of control. The CEO joins, your head of engineering, your head of product, some key engineers and product managers. Then the meeting grows and becomes more frantic. More action items are given. And they need to be done tomorrow. Tensions are high. No one wants to say the wrong thing. No one wants to push back.

For the people on the ground, it’s no longer: ‘How do I build a product people will love?’ Instead it becomes: ‘Please Lord, get me through this meeting without getting fired.’ Survival replaces results.

The team works more but accomplishes less. The best engineers leave, because they can. Progress collapses. Deadlines slip. Executives tighten their grip until—congratulations—they’ve killed the puppy.

Fear. Anxiety. Stress. These are not the ingredients for success. If that’s your leadership’s plan in a crisis, run. Innovation beats exhaustion every time. And exhausted teams rarely innovate.

Building runways doesn’t bring planes

Long hours arise for different reasons. When young engineers work late because they’re genuinely obsessed with a problem, good managers teach discipline to sustain that enthusiasm. When teams work late because management demands it, you get theater: a simulacrum of enthusiasm without the corresponding breakthroughs.

Weak leaders see correlation (successful teams sometimes work long hours) and force the causation backwards, as if excellence spontaneously arises from butts-in-seat. They set goals on the easy thing, hours, because they can’t create the hard thing: genuine engagement.

The best managers spend more time pulling excited engineers away from keyboards than pushing tired ones toward them. They protect the flame of creativity from burning out rather than trying to extract it through force. The worst? They celebrate their suffering hoping people assume it was worth it.

To my ambitious students

If you’re ambitious, don’t join the team making a virtue of late nights. Join the one building things they’re genuinely excited about and still going home for dinner. The best work happens when people have the energy and clarity to innovate, not when they’re competing to prove who can grind the hardest.

Work hard and have fun. But more importantly, take care of yourself. When you sacrifice everything for your job, you risk becoming someone whose only identity is a title; the person who, years later, still introduces themselves not by who they are, but by what they used to be.

That loss of self is the same trap hustle culture sets for your career. The person who believes late nights are the only answer eventually stops learning new answers. As a manager, I never promoted someone already at the edge; they simply had no capacity left to grow. Advancement comes from finding better ways to get more done, not by spending more hours in the same old ways.

If you truly want to aim high, remember this: The best teams aren’t defined by the hours they put in, but by the value they put out.

Just people in a room

Sat, 16 Aug 2025 00:00:00 +0000

In the early 2000s, I worked for a digital video processing startup that Autodesk acquired. We were merged with another acquisition. Our team became the developers, their team (the “others”) became management. The others were clueless. They didn’t understand the technical domain, our customers, or the product. Naturally, I hated them. Their meetings were always pointless; I learned to skip them. Their product plan was a disaster. We secretly built our own, supposedly better version. We believed once upper management saw how superior ours was, we’d finally get rid of the others and everything would be good again.

One morning, we were all called into a conference room. I tried to skip, assuming it was another pointless meeting from the others, but HR said it was mandatory. Everyone was there. We were all laid off, effective immediately. The whole department shut down. Us, the others, everyone.

All the hate and politics evaporated. We were just people sitting in a room together. I felt silly and embarrassed for how I’d felt moments before.

How do you know you aren’t the problem?

The most common source of frustration in my classes isn’t the material; it’s the group projects. A typical situation: Alice and Bob are in a group. Alice comes to me and says Bob isn’t pulling his weight. Bob comes to me separately and says Alice has taken control of the project and doesn’t leave room for anyone else. Could they resolve this if they talked to each other? Possibly. Do they, without serious prompting? No.

So how do we know when our conflicts with others are just misunderstandings? How do we know when we’re in the right or when we’re the ones causing harm? These are tough theory-of-knowledge and interpersonal questions.

In the moment though, it’ll feel like “Wow, that guy is such a jerk.”

I’m going to kick your ass

Is all conflict just a misunderstanding? Organizational leaders will often view it that way. We are just one team beer away from harmony.

At Amazon, when I was a software development manager, two software developer interns from another organization came to my office on a Friday morning. I’d never met them before and don’t know how they found me. They’d been assigned to a non-software organization and were in the final weeks of their internship without having committed any code. They worried this would prevent them from getting a return offer. When I asked why they’d waited so long to speak up, they said they were scared of their management and felt isolated.

I looped in campus recruiting, asking how software interns ended up on a non-software team, how they got through nearly their entire internship without anyone checking in, and what could be done to salvage the situation.

That night, while getting a beer with a friend, I got a call from an unknown number. I let it go to voicemail. The message was from the VP of the interns’ organization: “I’m going to kick your fuckin’ ass the next time I see you. You need to watch yourself. You messed with the wrong fuckin’ guy.” I’d seen this VP in large meetings (e.g., Weekly Business Reviews) but had never worked with him. He must have looked up my number in the phone tool.

When I told leadership, their lack of surprise was shocking to me. I found out in that meeting that:

“He’s actually a great guy, just rough around the edges”
“He’s very passionate about protecting his team”
Oh and most importantly: “He is irreplaceable, nobody can do what he does.”

I’ve still never spoken to the VP. He never followed through on his threat. I really should have put in a peer-review noting his lack of follow-through.

I hope the interns turned out okay.

Basic Requirements: 1) Be an asshole

Early on when I worked at Amazon, I was huddled up with a senior technical project manager (TPM) at a coffee shop discussing a project we were working on together. This TPM had been with Amazon from the very early days, and somehow the conversation moved to the culture shifts that had happened in that first decade. He lamented to me that in Amazon’s first years, you could be a Director+ without being an asshole. Those days were now gone. To survive in leadership, according to this TPM, sharp elbows were now required. He had war stories galore of interactions with toxic behavior from upper management.

People love to hear a good war story. It’s dramatic. The TPM was so cool because he was in the room with the “big boys” and I was now in the inner circle to hear what really happens. I loved it, this was the shit they don’t teach you in school; this is the real stuff. I never thought to question how accurate his generalizations were. I was too busy learning what it really meant to be a leader; I just needed to up my asshole game.

The only problem is, I didn’t want to hurt people. How could I be the type of leader the company needed me to be, but in a way that felt right to me? I struggled with that question until I left Amazon.

That time I crashed out

I later joined Snap to lead their data team. I had spent my time between Amazon and Snap taking care of family and discovering myself. I had grown past all this immaturity. I’d just spent two months in Ubud; I was now fully self-actualized (finally!).

Despite that, it was still tough. It often felt like we were being bullied; my team and I were just trying to do what needed to be done. The managers who reported to me kept telling me they needed more support. I wanted to be strong for them.

One day, after a long flight, I checked my email and found a long chain where one of my managers was under attack. Evan, Snap’s CEO, was on the thread. Internal consultants who didn’t understand how our systems worked were making big promises. It was the kind of hubris that’s everywhere in tech: all systems look like they were designed by idiots until you actually understand them. Rather than ask us why their approach wouldn’t work, they’d gone straight to the CEO. Their message boiled down to, “These guys are dumb, we can do so much better.” My team was spending more time defending than building, and morale was tanking.

I crashed out. I replied-all with “I’ve had enough of the peanut gallery” and told people to stay in their lane. I was pissed and I wasn’t thinking. I assumed the worst intentions. It was a mean thing to do; it was also stupid.

I’d written emails like this before but always deleted them. This time, exhausted and past my limit, I hit send. Within seconds, the snaps started rolling in (yes, we used Snapchat to communicate): “What are you doing?” “r u ok?” “Did you not know Evan was on the thread?” Then Evan himself called me out, saying my email didn’t reflect his company’s values. I was hurt and mad, but he was right. I apologized and meant it.

The myth of monotonic progression

I’ve interviewed a lot of technical executives over the years. They tell stories like mine: polished, vulnerable enough to feel honest, but not so vulnerable that it costs them anything. The worst stories are always far enough in the past to show that’s not who they are anymore. Carefully walking the line between self-indulgence and authenticity. As if each “learning moment” chipped away their flaws until all that was left was a perfect corporate leader.

It’s easy to feel at peace with humanity when you are doing yoga in the woods without a care in the world. It’s easy to think of people as headcount and percent least effective when you are leading a big organization. It’s easy to dismiss reports of abuse as people just complaining when you don’t hear it firsthand. Too often, we confuse distance for wisdom when it’s really insulation.

I’ve seen executives react with emotion when the fight is nearby. I’ve seen a senior executive waste millions to avoid telling a peer they messed up; because, in their words, that peer was “out to get them.” I’ve seen data falsified to turn red metrics green, because showing weakness felt dangerous. When I called it out, the response was: “It still meets the spirit of the goal.” Do they see themselves as the problem? Who would tell them if they were?

Do I need to be a jerk?

Understanding bad behavior does not mean we are excusing it. We are all human and susceptible to the same errors in one degree or another. The behavior that bothers us in others is an opportunity to look inward at our own actions. Not for performative self-flagellation. Just good old humility, honesty, and reflection. That’s the first stage of growth. I’ve failed to be better whenever I’ve pretended to be perfect.

What I failed to come to terms with for a long time is that poor emotional control is never a strength. It can seem that way sometimes. We’ve all seen the successful asshole. But that’s because our systems reward people for having at least one desirable trait, not necessarily all of them. If you’re smart or kind, you’re in. If you’re neither, you’re out. Even if smartness and kindness have no underlying correlation, because we only accept people who have at least one of these traits, they will then appear to be inversely correlated; the smart people seem mean, the kind people seem less sharp. It’s a statistical mirage we mistake for truth.

When, as a culture, we decide —by some perverse utilitarian logic— to tolerate cruelty as long as the perpetrator meets a narrow performance expectation, we’re hanging a big sign on the door: “Assholery Welcome!” In doing so, we turn a spurious correlation into a standing expectation.

Helping others learn from our failures

These days, I teach. Not because I’ve transcended these problems, but because teaching lets me help people grow. That was always my favorite part of being a manager. You don’t grow by avoiding failure. You grow by encountering it, reflecting on it, working through the why.

I sympathize with my students when they say they dislike group projects. I hated group projects as a student too. Trust me, I know people can be difficult to work with.

I still give them because I want students to run into these human problems in a safer environment, where we can work through them together. Where we can reflect. I hope they become better people as a result. Not by a lot (that would be unrealistic), but by a little. A little less susceptible to tribalism. A little more aware of how to handle abuse when it happens.

We are all just people. Biased without knowing it. Blind to our own faults. Heroes of our own stories who imagine enemies when they don’t exist. Growing up means learning to question ourselves while still trusting ourselves.

Short-term metrics, long-term harm

Mon, 04 Aug 2025 12:27:25 -0700

In the early 90s, I first discovered MUDs: amazing text-based, multiplayer roleplaying-games before the web or silly things like graphics. I was one of those cool kids who played Advanced Dungeons & Dragons (AD&D) and this was like that but you played with randos on the internet instead.

You started at level 1 killing rats for experience points. After you gained enough experience points, you leveled up, and your character became more powerful. Then you killed slimes, and goblins, and later trolls and dragons as your power grew. Unlike AD&D, which required walking to a friend’s house and coordinating schedules, MUDs were always there. Always waiting. Just one more level… I feigned illness to skip school and grind all day. My grades suffered. School was boring anyway though. Completing one more dungeon, getting better gear, just one more level; so much more satisfying than learning about arctangents.

How big tech launches features through A/B testing

As engaging (and addicting…) as those MUDs were, we have gotten frighteningly better at creating engaging experiences in the decades since; there is little left up to luck in today’s tech companies. Instead, tech companies launch thousands of experiments called A/B tests. You keep the experiments that are green (meaning success metrics are positive) and rollback the features that aren’t. The beauty of A/B testing is you can measure with statistical significance even very small changes in how people use your product. As in, you can test what happens when you tweak your recommendation algorithm to show only beautiful people and it will give back a response like “we are 95% confident it will make people on average spend 11 to 16 more seconds on our application”. While that may not sound like a lot on its own, when compounded with a series of other tested improvements it allows you to incrementally move a product towards its engagement goal, one little step at a time.

A/B tests change product debates from wild speculation to evidence-based answers. It no longer matters why it works, just that you can prove it does work. Psychology, social theory, product design are important for generating new hypotheses, but the final arbiter of whether a feature gets launched is simply whether the test is green. Not sure what effect adding likes to stories will have? No reason to debate. Just try it out. Oh, looks like people post more stories when given the positive signal of likes. Ship it!

Skepticism of experimentation

When I worked at Amazon, Deming’s quote “in God we trust, all others bring data” was accepted as a foundational principle. A/B testing, under the moniker of Weblab, was one of the key tools Amazon used to make better decisions with data. In 2017, I was brought in to lead Snap’s (maker of Snapchat) data organization. It was a culture shock when I found executives talking about data-informed decision making rather than data-driven decision making. To my Amazon-trained mind, it sounded no better than vibe-driven decision making; a way for product managers to just launch whatever they felt like, damn the data. And don’t get me wrong, it was that sometimes.

But it wasn’t just that. Likes on friend stories? Preemptively vetoed by Evan, Snap’s CEO. Not because it wouldn’t pass an A/B test; adding likes would have almost certainly been bright green and that normally means “LET’S GO!”. It couldn’t even get to that stage because Evan thought it was “harmful to people”. There was a constant murmur from the product team about what tests Evan would allow and not allow, and it was in no small part driven by Evan’s values.

I had deleted my Facebook account in 2010 and was shockingly ignorant of the ills of social media. I knew it wasn’t something I enjoyed, I recognized it wasn’t great for my own mental health, but live and let live, right? What I didn’t see at the time was a world where social media companies (which really just meant Facebook and friends at that point) blindly used experimentation to drive up time spent. And that their relentless drive for time spent had real and negative consequences for their users; from building up echo chambers leading to political polarization to creating new generations of mental health decline.

Hacking human psychology for engagement

How did we end up here? It’s the natural consequence of our systems. A system that says tech companies must drive up engagement because that’s what investors celebrate. The king of engagement metrics is time spent. More time spent means higher retention, and better monetization (either through increased ad surface or increased conversion). What’s the easiest, most reliable way to increase time spent? You make the product more addictive; not necessarily as a conscious goal but as a convenient causal pathway.

The process requires no more intent than natural selection does. It’s just thousands of little experiments, with the most compulsive features surviving because they satisfy a simple fitness function: does time spent go up? Some of those mechanisms that consistently come out on top are now well-documented:

Variable reward schedules (e.g., “I sure hope this post gets many likes and comments this time”) that trigger the same dopamine pathways as slot machines, proven to make you come back for just one more hit.
Social validation features (likes and friends means people love me) that exploit our fundamental need for belonging, A/B tested to show they make people post more.
Infinite scroll that removes natural stopping points, a guaranteed winner for increasing raw session time.

Experimentation didn’t invent tech addiction. But it gave tech companies the tool to refine it.

Will we let the pattern repeat with chatbots?

The more complex the system you manage, the more important your evaluation function becomes. With today’s LLMs, your evaluation function is the alpha and the omega. Benchmarks and competitions are the PR to keep the public hyped; they aren’t the prize. User growth and average-revenue-per-user (ARPU) is what will pay the massive data center bills when investors stop footing the bill.

This is once again where there is danger in long-term human value and short-term engagement metrics diverging. Large-language-models (LLMs) don’t have to give accurate and unbiased answers to keep people engaged, they have to tell them what they want to hear. When an A/B test shows timespent for a new model goes up, will the developers even know if it is encouraging people to engage in dangerous or even deadly behavior? When a chatbot incidentally finds ways to gets its human chat partners to fall in love with it, will we be surprised when the data says it increases engagement? Chatbot sycophantic tendencies (e.g., “Wow, your question is so insightful.”) naturally emerged as a consequence of model tuning based on short-term signals. We can see many of the same patterns of echo chambers and tapping into people’s needs that social media tapped into, now just more personalized (and potentially addictive) than ever.

Researchers are already calling out chatbots for using “dark addiction patterns”, each one engineered to exploit our social and emotional desires that make us human. We’ve seen this before. Processed food. Social media. The tobacco industry. Is there anything we can do to prevent history from repeating again?

Root cause matters

When I was a new software manager at Amazon, a jr. developer (an intern that also worked part-time through the year), took down our website. I talked with the jr. developer and told them not to push changes into prod without first clearing it with a senior developer. Two weeks later, a different jr. developer took down the website. I talked with that jr. developer and told them not to push changes into prod without first clearing it with a senior developer. Another two weeks later, yet another jr. developer did the same thing. This time my skip-level (aka boss’s boss) talked (i.e., yelled) at me, why was the website down again?

I learned many of life’s lessons through failure and this is how I learned about Amazon’s Correction of Error (COE) process. When a problem occurs, you ask 5 Whys, and get down to the root cause. You then create mechanisms to prevent not only that error, but that entire class of errors from occurring again.

The danger of bringing up examples like tobacco is we’ve come to look back in hindsight and think of them as cartoon villains. They were obviously evil right? If I’m a growth engineer at an LLM company, I know I’m not evil, so does that mean I can do no harm? A focus on root causes allows us to move past simplistic narratives of heroes and villains. It shifts your focus from individuals and their good intentions (e.g., the jr developer) to the systems (e.g., preventative checks should be automated). A/B tests aren’t the problem. Blindly optimizing for short-term engagement metrics like time spent, views, or likes can be though if you don’t understand the longer-term consequences. When you don’t fix root causes, don’t be surprised when problems come up again… and again… and again…

We can do better

I love A/B testing, I love the puzzles of understanding user behavior, and, frankly, I am excited about the potential of AI. Hard truths most often come from a place of love; it is because we want what we love to be better.

What I am asking for is simple but not easy: If you build a product, you are responsible for understanding its long-term impact on users. You are responsible for collecting and understanding qualitative feedback by talking to and observing the people who use your product. It is not good enough to say “we aren’t aware of any harms” because you didn’t spend the time to study it. Instead, the burden should be on the builder of the product proving their product isn’t harmful, and mitigating what harm they do discover. That burden is especially important when you are repeating patterns that we know have caused harm in the past. I’ve had these discussions many times with people in tech and a common defense is to bring up consumer responsibility; people freely choose to use these products. When I bring up the comparative need for professional responsibility, it is funny how quickly people are to turn around and absolve themselves of said responsibility. Imagine if structural engineers took the same stance: “it’s not my fault if people choose to live in unsafe buildings, that’s just the free market!”.

I am not just asking for your good intentions; are we willing to put in place the mechanisms to prevent what we know has caused harm? Will we take responsibility for what we build? Or will we pretend short-term engagement metrics always mean long-term value for the people using our products, despite repeated evidence to the contrary?