There's a moment in a lot of standups that nobody names out loud. The team is underwater, everyone knows it, and when planning poker comes around a story that's honestly a three gets called a five. Nobody argues. Not because anyone's lying. Because the number has quietly stopped being an estimate and turned into a shield.
I've watched that happen on teams I was supposed to be protecting. The velocity chart looked great the entire time. That's the part that should bother you.
Using AI is fine. Using it to replace your thinking isn't.
There's a version of AI adoption that looks like efficiency and is actually absence. You've stopped being the person doing the work. You've become the person approving outputs. The strange part is how good it feels while it's happening. The work gets faster, the results look competent, and nobody notices, including you, until the day you need the skill the tool was quietly doing on your behalf.
If your AI workflow still makes you repeat the same instructions in every single chat, that's a tax you don't need to pay. I built Ink and Agency to fix that friction point. It’s a practical skills pack designed to integrate right into Claude—and can be adapted for other agents, giving reusable prompts for writing, planning, triage, architecture design, and just general day-to-day work.
I did not grow up in Pittsburgh.
I came here as an adult, with college debt, a meager job offer, and more than a little uncertainty. By the time I was learning to code in earnest and building a career, I was watching former industrial spaces turn into trails, riverfront paths, labs, and small tech offices. People pushing strollers where shift whistles used to run the clock is not my childhood memory. It is what I learned to notice after I moved here.
The most productive three hours of my week look suspicious from the outside. No meetings, no Slack, headphones in, do not disturb. From the inside, it's the only time I'm actually working.
I don't mean "actually working" as a knock on everything else. I mean it's the only time my brain is in the state where hard problems get solved, where the architecture makes sense, where I stop fighting friction and start making progress. Getting there, for an ADHD brain, is not as simple as closing your email client.
I was in an architecture review a few years back. Fifteen people on the call, half of them senior engineers. Someone proposed a caching strategy that I knew would fall apart under concurrent writes. I'd hit that exact failure mode six months earlier on a different project. I had the scars and the postmortem to prove it.
I didn't say anything.
I sat there, muted, composing and deleting the same sentence in the chat three times. Someone else eventually raised the issue twenty minutes later, after the team had already committed to the direction. The rework cost us a sprint. And I spent that whole sprint thinking: Why didn't I just say something?
If you've been that person, sitting on the right answer, the useful question, the experience that could save your team time, this one's for you.
If you've watched Resident Alien, you know the core premise: Harry, an alien, crashes on Earth and spends the series pretending to be a human so he can complete his mission (and eventually repair his spaceship). He's brilliant at it. He studies human behavior obsessively. He nails the performance. He says and does all the right things.
And he's absolutely miserable.
The alien's constant act of "being human" — perfectly mimicking behavior while feeling fundamentally separate from it — is actually a masterclass in imposter syndrome. And what's wild is how closely it mirrors something I see constantly in development teams: brilliant people who excel at their jobs while feeling like complete frauds.
The difference? The alien's situation is literal. He's actually not human. But the developers I know? They are good at what they do. Yet they're convinced they're faking it, waiting to be exposed, performing competence while feeling like imposters.
Resident Alien shows us why this matters and what healthy teams do differently.
Spoilers ahead.
After writing about what Ted Lasso taught me about being a Scrum Master, someone asked if I had any other TV shows that shaped my thinking on teams. I hesitated before answering "Yellowjackets," because unlike Ted's relentlessly optimistic football club, Yellowjackets is about a high school soccer team that crashes in the Canadian wilderness and descends into Lord of the Flies-style chaos. But here's the thing: I've seen more development teams operating like the Yellowjackets survivors than I'd like to admit. And the show's unflinching look at what happens when teams break down under pressure offers lessons that Ted Lasso's feel-good narrative can't.
So yes, we're going from biscuits and believe signs to cannibalism and cult behavior. Welcome to the darker side of team dynamics.
Massive spoilers ahead for Yellowjackets seasons one and two.
It's no secret that I am not a sports person. I don't follow football, baseball, basketball, or any of the major leagues. My idea of athleticism is walking briskly to the coffee shop without getting winded. So when I first heard about Ted Lasso, I was skeptical. But, I gave it a shot. And when Ted Lasso first walked into that Richmond AFC locker room with his signature mustache and relentless optimism, I had no idea I was watching a masterclass in servant leadership. Sure, he knew nothing about football (nor did I), but he knew everything about people.
I've just finished rewatching the series for the third time, and each viewing reveals another parallel between coaching a struggling team and facilitating a development team. Turns out, "Believe" isn't just a cute sign above a doorway — it's a whole leadership philosophy.
Beware: spoilers ahead for Ted Lasso seasons one through three.
Scrum gets mislabeled as project management. Then we ask it to do budget tracking, dependency orchestration, and scope control. No wonder it feels clumsy. Scrum is not your project management framework. Scrum is your communication framework for complex work. It sets the cadence, topics, and decision rules so a team can learn fast and adapt even faster. If you treat it that way, delivery gets less brittle and leadership gets better signal with less theater.
You know that moment in sprint planning when everyone reveals their story point estimates simultaneously, and the numbers range from 2 to 13? That's not a planning failure—that's collaborative dice rolling at its finest. Just like a D&D party assessing whether they can take on a dragon, your development team is essentially asking "What are the odds we can pull this off?" The answer, as any seasoned dungeon crawler knows, depends on your party composition, available equipment, and whether anyone remembered to bring healing potions.
Ever walked into a retrospective and immediately spotted the person frantically scribbling diagrams in the corner while someone else dominates the conversation? Or noticed how one team member always finds the potential pitfalls while another sees nothing but opportunity? Welcome to the beautiful chaos of agile team dynamics. Understanding these personality types isn't just helpful—it's essential for any Scrum Master who wants to facilitate effectively and unlock their team's full potential.
Ever notice how a well-run Scrum team feels suspiciously like a D&D campaign? The Scrum Master guides the narrative, developers bring specialized skills to overcome challenges, and everyone rolls dice (story points) to see how badly they've underestimated the complexity of "simple" tasks. After years of facilitating sprints and rolling d20s, I've realized these frameworks aren't just similar—they're practically the same game with different terminology.
You know the signs: minimal participation in standup, delayed deliverables, and that thousand-yard stare during retrospectives. A disengaged team member can derail sprint momentum faster than a production bug on Friday afternoon. But before you escalate to management or start documenting performance issues, remember that disengagement is often a symptom, not the disease.
You're about to deploy to production and your PM asks for "just a clean copy of the code without all that Git history stuff." Or maybe you need to package a specific release for a client who shouldn't see your development branches. Enter git archive — the Git command that's criminally underused despite solving these exact problems elegantly.
There I was, facilitating a retrospective for a team of brilliant engineers, when someone asked a technical question that made my stomach drop. I nodded thoughtfully, buying time, while my inner voice screamed: "You have no idea what they're talking about, do you?" Welcome to the Scrum Master's paradox — leading teams through complex technical challenges while secretly wondering if you belong in the room at all.