Kevin E. Schlabach

Category: Productivity

  • The One-Word Test

    One of my litmus tests for a company, and sometimes an interview question, is this: “You have to change a single word in legal copy on your production website and it’s critical. How quickly can you get that fix to production?”

    The gap between answers is always interesting: minutes for some, hours or even days for others.

    If it takes days to change a single word, the friction in that pipeline is the same friction slowing down every feature your team is trying to ship. Cycle time is one of the biggest enablers or drag points a team has.

    The delays usually live in one of two places. The first is the engineering toolchain: build times and deployment automation that make anyone nervous about pushing quickly. The second is business and process governance: review queues and release approval chains that were designed for monthly software cycles and never kept pace when the team moved to continuous delivery.

    A prior organization I worked for could accomplish that change in about 30 minutes on their newer platform. 2 hours on the older, much larger one. Those were numbers worth being proud of.

    The question is loosely rooted in what the DORA framework surfaces as lead time for changes, one of the clearest signals of a healthy delivery pipeline. The one-word litmus test just makes it concrete enough to get an honest answer in a room.

    If you can’t move a single word in minutes, both aspects of that pipeline are worth a deeper look.

  • The 10% Meeting Rule

    I regularly hear engineers complain about too many meetings. They’re right.

    The specific complaint is usually about flow state, and it’s worth taking seriously. Flow state is where you’re fully locked in on a problem, holding a lot of context in your head at once. It takes 15 to 20 minutes to get there. Chop the day into pieces and flow doesn’t happen.

    When you insert planning, refinement, retro, daily standups, a Scrum of Scrums, an engineering leads sync, and whatever cross-team dependency meetings have accumulated on the calendar, several hours of a sprint are already spoken for before a line of code gets written. In a short sprint, that’s a meaningful percentage of the available time.

    Here’s the rule to apply: all standing meetings that support the sprint should consume about 10% or less of it. For 2 weeks, that’s one business day. For a 1-week sprint, that’s about 4 hours total. The meeting budget should scale with the sprint length.

    Another common problem is that meetings accumulate and never get reassessed. Someone adds a sync to solve a problem. It works. The problem fades, but the recurring meeting stays. Attendees get added when coordination gets complicated. They rarely get removed when it simplifies. Over time the calendar fills up not because anyone designed it that way, but because the question never gets asked: does this meeting still earn its slot?

    The engineers aren’t wrong about the meetings. Give them room to actually work.

  • Capacity Is Not the Constraint

    Over my career, the ask from leadership has been pretty consistent: more development capacity. The list of requests never shrinks, so the conclusion is always the same: we need to go faster. AI is now delivering on that in ways hiring never quite could.

    The list will always outpace the team. That’s not a capacity problem, it’s the nature of the work.

    What I haven’t seen is a matching increase in clarity about which parts of the work actually matter.

    Capacity without direction is just faster drift. You ship more, but you’re not sure what’s landing. You don’t know which features people actually use, or which ones drove engagement.

    There’s an infinite supply of “can we build this?” The constraint that’s always been scarce is “should we build this at all?”

    That second question is worth more than it gets credit for. Every feature you don’t build is scope your team doesn’t carry: no implementation cost, no maintenance burden, no support tickets, no documentation. The savings compound in ways that never show up on a roadmap because there’s nothing to point at.

    The gains from AI make this more urgent. When capacity goes up, the temptation is to fill it. But the better return is a leaner organization pointed at fewer, more deliberate bets.

    More “can we measure whether this mattered?” would help too. But it starts with being willing to ask whether to build it at all.

  • The Muscle Memory AI Tax

    There’s a version of AI adoption that looks like pure win. You hand off the lower-level work, it gets done faster, and you reclaim hours. Nobody argues with that math.

    But there’s a quieter cost that shows up later.

    I order a lot of prepped meals now. I’m genuinely rusty at cooking. I have a house cleaner, and I’m slower and sloppier at cleaning the bathroom than I used to be. I made those tradeoffs on purpose. Those are skills I’m fine letting atrophy.

    The question worth asking at work is: which ones are you fine with becoming weaker and slower at?

    When you hand off lower-level tasks to AI completely, and eventually stop reviewing the output because the trust has built up, you don’t just save time. You lose the reps. The muscle memory quietly fades. And with it goes something harder to name: the ability to glance at something and just see that it’s wrong. The quick discernment that comes from having done the thing hundreds of times yourself.

    That pattern recognition isn’t a personality trait. It’s built. It comes from the unglamorous repetition of actually doing the work, making small errors and catching them. Pull the repetition and the calibration drifts. This is true regardless of seniority. Anyone can automate their way past their own skill development if they’re not paying attention.

    This isn’t an argument against using AI. Some things are your cooking. Some things are your judgment. Be intentional about what you hand off and what you keep doing.

  • Meetings Need a Definition of Done

    You’ve been in that meeting. Everyone’s looking at a slide deck on the shared screen, and half the room is quietly doing something else on their own monitor. Prepping for the next one, probably. Which will go exactly the same way.

    Agendas were supposed to fix this. They didn’t. A list of topics isn’t a destination. It’s just a longer way to drift.

    TDD (one of the core XP practices) says write the test before you write the code. Before you build anything, define what passing looks like. The test makes the goal concrete and tells you when you’re done.

    Do the same thing for meetings.

    Before you send the invite, write one sentence: “This meeting is a success when…”

    Something like: “…we’ve agreed on which candidates from this list we’re extending offers to,” or “…we have a shared understanding of what caused last week’s production fire and how to prevent the next one”

    It allows you to park anything that tangentially arises. It gives the meeting a real finish line instead of a time slot.

    Put the condition in the invite. People who care about that outcome show up. If they don’t, the decision gets made without them. That was already the deal.

    When you hit the condition early, end the meeting. Give people the remaining time back. Don’t fill the time just because it was booked.

    Do this consistently enough and something shifts. People show up expecting your meetings to have a finish line. They pay attention because the conversation has somewhere to go.

    Some of them might even look forward to it. That might sound unlikely. But it happens.

  • Output Isn’t the Point

    Knowledge work productivity is getting cheap. Fast.

    AI can write the code, draft the document, and generate the plan. The time it takes and the cleverness of the approach are becoming irrelevant. Speed and output volume, the things that used to signal skill, are getting commoditized.

    So what’s left?

    Discernment. Judgment. Knowing which question to ask next. Predicting the outlier that’s going to cause trouble down the road. Recognizing when the output is technically correct but pointed at the wrong problem. These things mattered before AI. They matter even more now.

    The catch is that you still have to put in your 2k, 5k, 10k hours to develop these skills. There’s no shortcut to the experience that lets you see what others can’t. You have to have built things, broken things, and lived through the failures before the pattern recognition kicks in.

    Which creates a real problem for the next generation coming into the field. A lot of the foundational work they would have done (the small bugs, the basic implementations, the unglamorous repetition that builds muscle memory) AI is doing now. The entry ramp just got steeper even as it looks easier. 

    That means mentoring matters more than it did. Not just passing down knowledge, but helping people find ways to build the experience base that the tools are quietly skipping over.

    The hard part is thinking through the work, not building it.