Innovation does not happen by accident - it requires intentional investment of time, resources, and management attention. Engineering teams that dedicate time to experimentation discover new approaches, build engagement, and occasionally create breakthrough features. This guide covers how to structure innovation time, evaluate experiments, and turn promising ideas into real products.
Structuring Innovation Time
Innovation time can take many forms: dedicated percentage time (like Google's famous 20% time), regular hackathons, innovation sprints, or designated experimentation days. Each model has trade-offs. Percentage time provides ongoing flexibility but can be absorbed by regular work demands. Hackathons create focused energy but are infrequent. Choose the model that fits your team's work patterns and organisational culture.
Set clear boundaries and expectations. Innovation time is not free time - it should be directed toward experiments that align with the team's or organisation's strategic interests, even if loosely. Define what constitutes a valid innovation project, how engineers should document their work, and what happens with the results.
Protect innovation time actively. If innovation time is the first thing cancelled when sprint deadlines are tight, engineers will stop taking it seriously. Treat innovation time as a scheduled commitment, and guard it with the same vigour you would guard any other important meeting or planning session.
- Choose an innovation model that fits your team: percentage time, hackathons, or innovation sprints
- Set clear expectations about project scope, documentation, and outcome sharing
- Protect innovation time from being consumed by regular work demands
- Align innovation efforts loosely with strategic interests without constraining creativity
Running Effective Hackathons
Hackathons condense innovation energy into focused events that produce visible results. Effective hackathons have clear themes, reasonable time constraints (24-48 hours), and a structured presentation format where teams share their results. The constraint of limited time forces pragmatic decision-making and rapid prototyping.
Provide the infrastructure that makes hackathon projects viable: access to APIs, sandboxed environments, sample data, and technical support. Remove obstacles that would slow teams down - pre-provision accounts, provide documentation for internal services, and ensure that the development environment is ready to go.
Follow up on hackathon outcomes. The biggest waste of hackathon energy is letting promising projects die after the event. Establish a process for evaluating hackathon outputs and fast-tracking the most promising ones into the product roadmap. Even projects that do not become products often generate ideas, prototypes, or learnings that inform future work.
Evaluating and Measuring Innovation Outcomes
Not every experiment will succeed, and that is expected. Define success criteria before experiments begin so that evaluation is objective rather than retrospective justification. Success criteria might include technical feasibility demonstration, user interest validation, or performance benchmark achievement.
Track innovation metrics at the programme level, not just the project level. What percentage of innovation projects produce actionable learnings? How many have progressed to the product roadmap? How has innovation time affected engineer engagement and retention? These programme-level metrics justify continued investment even when individual projects fail.
Share experiment results broadly, including failures. Engineers who learn that a colleague tried an approach that did not work avoid duplicating the effort. A culture where sharing negative results is valued - where 'we tried X and it did not work because Y' is useful information - accelerates learning across the organisation.
Turning Innovation Into Product
The transition from innovation prototype to production product is where many promising ideas stall. The gap between a working demo and a production-ready feature is significant - reliability, scalability, security, documentation, and support all need to be addressed. Plan for this transition explicitly rather than assuming it will happen naturally.
Create a lightweight evaluation framework for innovation projects seeking product investment. What problem does this solve? How large is the opportunity? What is the investment required to productionise? What are the risks? This framework helps leadership make informed decisions about which experiments to invest in further.
Assign product ownership when an innovation project transitions to the roadmap. The engineer who built the prototype may or may not be the right person to lead productionisation - the skills required are different. Ensure that the original innovator is involved and credited, but bring in the product management, design, and engineering rigour needed for a production-quality release.
Key Takeaways
- Choose an innovation model that fits your culture and protect the allocated time actively
- Run hackathons with clear themes, supporting infrastructure, and follow-up on promising outcomes
- Define success criteria before experiments begin and track programme-level innovation metrics
- Share all results - including failures - to accelerate organisational learning
- Plan the transition from prototype to product explicitly with clear evaluation and ownership
Frequently Asked Questions
- How do I convince leadership to invest in innovation time?
- Present innovation time as a strategic investment with measurable outcomes. Track the ideas, prototypes, and learnings that emerge from innovation time. Highlight successful innovation projects that became product features. Frame innovation time as a retention tool - engineers who have creative outlets are more engaged and less likely to leave. Start with a small, time-boxed experiment (a single hackathon or a one-month innovation sprint) to demonstrate value before requesting ongoing investment.
- How much time should be allocated to innovation?
- 10-20% of engineering time is a common range, though the right amount depends on your organisation's goals and stage. Early-stage companies may invest more in innovation to find product-market fit. Mature organisations may invest less but more strategically. Start with a modest allocation and adjust based on the outcomes. Even 5% - one afternoon per fortnight - can produce meaningful results if it is protected and well-structured.
- How do I handle innovation projects that engineers want to pursue but do not align with business goals?
- Allow some completely open-ended experimentation alongside more directed innovation. Engineers who explore their own interests bring passion and creativity that directed innovation cannot replicate. However, set expectations that most innovation time should be loosely aligned with the team's or organisation's strategic interests. If an engineer's innovation interests consistently diverge from business needs, it may indicate a misalignment worth discussing openly.
Download Innovation Programme Templates
Access our innovation management tools including hackathon planning guides, experiment evaluation frameworks, and innovation metrics dashboards for engineering managers.
Learn More