Fostering Innovation within IT Teams
Introduction
Most writing about IT innovation assumes resources I have never had: dedicated labs, hackathon weeks, teams large enough that someone can disappear into research. I lead a 20-person team that keeps six locations running, supports production around the clock, and carries a roughly five million dollar budget with no line item labeled “innovation.” And yet some of the most consequential work we have done started as experiments nobody scheduled. So I think about innovation less as a program and more as a set of conditions a leader either creates or destroys, mostly through small daily decisions.
Creating the conditions
Protect slack, because innovation is what slack gets spent on. A team running at full utilization cannot innovate; every new idea competes with a ticket queue and loses. I deliberately keep some capacity unallocated, which requires defending it in budget conversations where it looks like inefficiency. The defense is the track record: nearly every internal tool and automation that later saved us real time began in hours that a stricter utilization target would have eliminated.
Reward the attempt, examine the failure, never punish the honesty. The fastest way to end experimentation is to make one failed experiment career-noise. When something we try does not work, the review question is “what did we learn and what did it cost,” not “whose idea was this.” People calibrate quickly. If honesty about a dead end is safe, you hear about dead ends early, which is exactly when you want to hear about them.
Put problems in front of the team, not solutions. The best ideas we have shipped came from framing a business problem and letting the team propose the approach. When client issue resolution was our sore spot, I did not hand down an architecture; I made the pain visible and asked what would fix it. The eventual mix of process and system changes took our client ticket resolution from eight business days to under two business hours. I could not have specified that outcome top-down, because the people closest to the work saw options I could not.
An example: getting to AI early
We started working with OpenAI’s models before ChatGPT made them a boardroom topic. There was no mandate and no budget line; it began as exploration, a few of us testing whether the models could do useful work against real problems in our environment. Much of what we tried in those early experiments went nowhere, which is the unglamorous truth of being early. But when the technology suddenly mattered to everyone, we already had firsthand judgment about what it could and could not do, while many peers were starting from vendor slideware. That head start was purchased entirely with protected slack and tolerance for unproductive-looking tinkering.
Challenges to be honest about
Operations always wins the scheduling fight. In a production business, the press run tonight beats the experiment every time, and it should. The mistake is letting that be the whole story. My workaround is rhythm rather than heroics: experimentation happens in small, regular allocations that survive busy seasons, instead of mythical future quarters that never arrive.
Mid-market talent math. I cannot outbid larger companies for specialists, so innovation capacity has to be grown. The trade I offer is scope: at our size, a curious engineer touches infrastructure, integrations, and new technology in the same year. The people who value that range stay, and they are exactly the people who innovate.
Novelty for its own sake. The failure mode nobody warns you about is the team chasing interesting technology with no business pull. My filter is simple: every experiment must name the business problem it would matter to. Curiosity is fuel, but the destination has to be real.
Conclusion
Innovation in a mid-market IT team is not a program you launch; it is slack you protect, safety you maintain, and problems you frame well. The compounding effect is real. A team that has been allowed to experiment approaches every new technology wave with confidence instead of anxiety, and over the years that posture, more than any individual breakthrough, is what has separated the teams I am proudest of from the ones that merely kept the lights on.