Quick Bridge: Your engineers adopted AI and got measurably faster. The velocity chart looks great, and a few of your best people seem strangely flat next to it. Nothing in the sprint data explains the gap. One of my strongest engineers asked if she could go back to writing a chunk of our test coverage by hand. Not all of it. Just the part she used to like. She had been running three or four AI agents at once for a couple of months, shipping more than she ever had, and she told me the days felt like air traffic control. It was all watching and deciding, with nothing at the end she could hold up and say she made. I did not have a good answer for her in the moment. The velocity chart said she was having her best quarter. She was asking to be slower on purpose. Why Agentic Work Feels Like a New Kind of Engineering Burnout Making something gives you a finish line you can see. A test that was red goes green. A design problem you have been circling for an hour finally gives way. You po...

Quick Bridge: Most technical leaders build their promotion case in the final weeks before asking. By that point, the decision is already forming somewhere else. This post explains how promotion decisions actually work, what the research shows about visibility and sponsorship gaps, and what to do in the twelve months before a formal ask to actually shape the outcome. Most promotion conversations go like this. The employee walks in prepared. They have gathered their wins. They know what they want and why they deserve it. They make their case clearly. Then they hear "not yet." What they almost never know is that the real decision about their promotion happened weeks or months earlier. In a calibration meeting. With managers comparing peers against each other and against limited budget. Among people who may not know their name. This is the part nobody tells you about. Why Promotion Decisions Don't Happen in Promotion Conversations Most people assume the promoti...

Quick Bridge: Your team is shipping more since the AI tools showed up, and somehow the mood got worse. People finish faster and then stall. The tiredness is real, but it does not line up with the hours anyone is actually working. One of my teams finished its sprint work by Wednesday. That had not happened before. The team had been using AI coding tools for about two months. Features that used to fill the full two weeks were landing in a few days. And then the team sat. Not because anyone was slacking. The spec for the next big piece was still in review, the security sign-off had not come back, and the group that approves architecture changes meets once a week. The building had gotten faster. Nothing around the building had. By Friday, two of the strongest engineers on that team looked worn down. Not from long hours in the usual sense. From a week of hard calls with nothing easy in between, and then a wall of waiting they could not do anything about. That is the pattern worth naming...

Quick Bridge: "Force multiplier" is no longer a compliment your manager pays you in passing. It is now an explicit line on senior and staff engineering leveling rubrics at major tech companies. This post breaks down what that criterion actually asks for, why the work behind it is invisible by design, and the specific narration habits that get it credited before someone else's launch takes the win. I once spent the better part of a year in meetings that had nothing to do with my own team's roadmap. My job that stretch was to learn how localization worked at my company from beginning to end, then negotiate a completely different process with every internal team and outside vendor that touched it. I did not write the software that ultimately automated most of the steps. My own team did that part. My job was defining the new process, negotiating it across departments that had never had to agree on anything before, and evaluating what the savings would actually be once it...