Prompting the org

I was in planning recently when someone asked, "How many points can we commit to next sprint?" For years, that question was normal. Useful, even. It gave us a shared language for forecasting effort and balancing load. This time it landed differently. We had engineers delivering implementation work faster than ever with AI support, but our most important initiatives were still bottlenecked. Not by coding capacity. By unresolved decisions about scope, ownership boundaries, quality bars, and integration contracts. That is when it became clear to me: if execution is getting cheaper, story points are becoming less informative about delivery risk. I do not think points are useless. I do think they are no longer the primary signal leaders should optimize. The Bottleneck Has Moved In a traditional model, writing and refining code consumed most of the schedule. Estimating production effort gave leaders a reasonable proxy for planning confidence. AI changes that equation. Now teams can...

A few weeks ago, I had one of those leadership moments that felt productive on paper and pointless in reality. I had spent over an hour stitching together Jira updates, GitHub activity, and status comments from different docs so I could write a leadership report. I had "done the work." I had the update. But I had also burned the exact time I needed for coaching conversations, planning decisions, and follow-through with my team. That tension has been following me all year: am I here to produce updates, or to produce outcomes? Back in February, I wrote about using a Gemini Gem to prep for 1:1s and skip-levels in minutes instead of scrambling for context in real time. That was my starting point, and it was a meaningful one. ( The "Just-in-Time" Manager and the 1:1 Gemini Gem ) It helped me eliminate hollow conversations and recover mental bandwidth. But between the start of March and now, I hit a wall. The One-Shot Illusion My early assumption was simple: if I wrote a ...

As Engineering Managers, we’ve always known that impact beats throughput. The best leaders in our industry already look past the raw volume of PRs or the velocity of a sprint to find the engineer who solved a scaling bottleneck with ten lines of configuration. We’ve always valued the person who understood the business problem well enough to realize we shouldn't build the feature at all. But in the pre-AI era, throughput still served as a useful, if noisy, proxy for effort. If an engineer was shipping a lot, they were at least engaged . AI has officially broken that proxy . When the cost of generating software approaches zero, the volume of output is no longer a sign of engagement - it is a commodity. For an engineering leader this means that focusing on impact isn't just a best practice anymore. It is the only way to keep your organization from drowning in its own success. From “Productive" to "Steward" The fundamental unit of engineering value has shifted. We a...

  The 1:50 Ratio: Is the "Pod" Dead and the "Horde" Rising? For decades, the "Rule of 7" (plus or minus two) has been the gold standard for engineering management. The logic was simple: a manager’s cognitive load is consumed by the complexity of human synchronization. Beyond 8 or 10 reports, you aren't managing; you’re just treading water. But as AI begins to act as a "force multiplier" for both code and coordination, we are seeing the emergence of a radical theory: The 1:50 Ratio. For example Meta just announced their new applied AI Engineering org with plans for a single manager to manage up to 50 engineers.  Why the Span of Control is Stretching Why could a manager suddenly oversee 50 souls instead of 10? It’s not because managers are getting smarter; it’s because the overhead of management is being automated. Automated Context: AI agents can now summarize PR cycles, flag blockers in Jira, and synthesize Slack sentiment. The "status...