There's a particular kind of work that never shows up on a project plan. It happens mid-meeting, mid-ticket, mid-conversation… it’s the moment someone asks a question and you realize the honest answer is, "We could figure that out... eventually."
Most teams treat those moments as interruptions, write it down, add it to the backlog, get back to the agenda, but there's another way to work: solve it right there, in the middle of everything else. We call it innovating in the flow and it's less a technique than a posture, it’s a way of showing up to the work already prepared to build.
Here's the pattern, a real question surfaces during real work, the kind that would traditionally mean hours of manual digging, a pile of spreadsheets, and a follow-up meeting next week. Instead of deferring it, you extend something you've already built, answer the question before the conversation even ends, and walk away with a capability that didn't exist an hour ago.
We did exactly this recently: a question came up on a call, and by the time the call wrapped, we'd added a new module to an existing internal tool, tested it, and produced a report that used to take the better part of a day to assemble by hand. The specifics don't matter much, what matters is that the question wasn't a detour, it was the road.
Innovating in the flow looks spontaneous, but it's the opposite, it's the payoff of preparation and a few principles make it possible:
Keep your tools within reach. Your environment should be ready before the question arrives, assistants running, editors open, systems logged in. If your first move is twenty minutes of setup, the moment is already gone.
Know your inventory. Almost nothing you build starts from zero. Past work is scaffolding: roughly 80% of most solutions already exists somewhere in your repos, your docs, your shared knowledge. The innovation is usually the last 20% — if you can find the 80%.
Contribute back to the inventory. Everything you build should make the next build easier. Document it, share it, put it somewhere your teammates (and your future self) can actually find it. Knowledge that only lives in your head is inventory that doesn't exist.
Don't fear breaking things. Version control means every experiment is reversible. The fear of "what if I mess something up?" is the single biggest killer of in-the-flow innovation, and it's almost entirely unfounded. Iterate boldly; you can always roll back.
Every customer, every environment, every problem is unique. Off-the-shelf answers rarely fit the actual shape of the situation, they're designed for an average that doesn't exist. Innovating in the flow is how you honor that uniqueness: you meet the problem in its real context, with its real constraints, and build the answer that actually belongs there.
Each iteration is an opportunity to make tomorrow better than today. Your past self hands knowledge to your future self. Teammates hand it to each other. The scaffolding keeps growing, the next question gets easier, and what used to be a four-hour scramble becomes a button.
None of it requires genius. It requires curiosity, a little courage, and the discipline of keeping your resources close and your knowledge shared.
The next time a question shows up uninvited in the middle of your work, don't write it down for later. Ask yourself: could I just solve this right now?
Stay curious. Stay courageous. Journey on.
