Developer Experience Research Ebook
Experimenting in Developer Experience - Time for Innovation
Research-based guide on experimentation for engineering teams. Learn how providing time to explore and test new ideas drives innovation and improves developer experience.
Experimenting
Our team has sufficient time to explore and test new ideas.
What is experimenting in a development context?
Experimenting in a development context refers to the practice of providing engineering teams with dedicated time and resources to explore new technologies, test innovative solutions, and validate alternative approaches to solving problems. It involves creating a safe space for developers to step outside the bounds of regular project work to try out ideas that could lead to better products, improved processes, or enhanced developer experience.
Why is experimenting important for software teams?
Engineering leaders consistently cite experimentation as a critical factor for:
-
Innovation and Continuous Improvement: Teams that regularly experiment are more likely to discover novel solutions and efficiencies.
-
Learning and Skill Development: Experimentation accelerates individual and team growth by exposing developers to new technologies and approaches.
-
Engagement and Retention: Developers value creative freedom and the opportunity to explore ideas beyond their daily tasks.
-
Competitive Advantage: Organizations that encourage experimentation often identify market opportunities and technical advantages ahead of competitors.
"Every Friday, we spend 90 minutes as a team on industry skill acquisition. This is for learning that would never happen without dedicated time. We have a Friday block for knowledge gathering where we explore new technologies. We've found that when someone later has a question about that technology, we don't need to spend 45 minutes getting context because we've already done that."
Senior Manager at Software Development Company
How does experimentation improve developer experience and productivity?
Reduced Technical Debt and Future-Proofing
When teams have time to experiment, they're more likely to discover and implement better technical approaches before committing to solutions that could lead to technical debt. This creates a more sustainable codebase and reduces future rework.
Accelerated Problem-Solving
Teams with experimentation time build a broader toolkit of potential solutions. As the example above illustrates, time spent exploring new technologies translates to faster problem-solving when those technologies become relevant to production tasks.
Enhanced Team Collaboration and Creativity
Experimentation often happens collaboratively, strengthening team bonds and encouraging creative thinking that carries over into regular work.
More Engaged Developers
Developers who have the freedom to experiment report higher job satisfaction and engagement, as it satisfies their intrinsic drive to learn and create.
What are the common obstacles to effective experimentation?
Delivery Pressure and Tight Deadlines
When teams are constantly under pressure to deliver, experimentation is typically the first activity sacrificed:
"I think we're under too much pressure. We don't have time to actually invest in sharpening our skills. I'm trying to help, and I'm essentially going to push them to make that time."
Tech Lead, Software Development Company
Lack of Structured Approach
Without a formalized approach to experimentation, these activities often become ad-hoc or nonexistent.
Difficulty Measuring ROI
Many organizations struggle to quantify the benefits of experimentation, making it vulnerable to budget cuts.
Fear of Failure
Teams without psychological safety may avoid experimentation for fear of wasting resources or being criticized for failed attempts.
How can you measure if your team has sufficient time for experimenting?
DevEx Survey Metrics
The Network Perspective DevEx Survey specifically measures this through the question: "Our team has sufficient time to explore and test new ideas." Tracking responses to this question over time provides quantitative insight into whether your experimentation culture is improving or deteriorating.
Time Allocation Analysis
Track what percentage of developer time is actually spent on experimentation versus planned allocation. Tools like time-tracking software or sprint metrics can help quantify this.
Innovation Output Metrics
Monitor metrics like the number of new ideas that graduate from experiments to production features, internal tools created, or process improvements implemented.
Qualitative Feedback
Regular retrospectives and team discussions can uncover whether developers feel they have adequate opportunities to experiment.
What are effective models for implementing experimentation time?
Dedicated Time Blocks
Many successful teams allocate specific time for experimentation:
"I've noticed that one team implemented a system where they dedicated a percentage of each sprint to innovation. It effectively combines enjoyment with productivity."
Delivery Manager at Software Development Company
Common approaches include:
- Google-style 20% time: Developers spend one day per week on self-directed projects.
- Dedicated innovation sprints: Teams take a full sprint periodically to focus entirely on experimentation.
- Weekly exploration blocks: Teams set aside a few hours each week for collective learning and experimentation.
- Quarterly no-meetings weeks: Some organizations implement meeting-free weeks that allow for focused work and experimentation:
"We have an organizational practice where we dedicate one week per quarter as a no-meeting week, unless meetings are absolutely necessary. During this time, we focus on experimenting, clarifying our priorities or optimizing our technology stack."
CTO at Digital Game Marketplace
Hackathons and Innovation Events
Periodic intensive events can supplement ongoing experimentation time:
"I implemented an innovation program focused on turning ideas into action. In the software industry, these are typically called hackathons, but the concept applies outside of software too. We facilitated discussions specifically designed to transform ideas into actionable initiatives."
Chief People Officer at Software Development Company
Incremental Approaches
Starting small with experimentation can be effective for teams new to the concept:
"Begin with a small experiment, perhaps with just one or two teams."
Agile Manifesto Co-Author at Software Development Company
How do you balance experimentation with delivery requirements?
Start Small and Scale
Begin with a modest time allocation that won't significantly impact delivery schedules:
"When you successfully implement a 10% time allocation per sprint in a team, that's experimenting and excellence in action. Four hours a week is enough for a developer to sit down and accomplish something meaningful—start and finish a substantial improvement. Yes, it initially slows the team down over a single sprint, but the benefits accumulate over time. The experiments and improvements they make eventually stop taking up their time because they've already learned something or optimized some processes."
Delivery Manager at Software Development Company
Set Clear Boundaries and Expectations
Establish guidelines for what types of experiments are encouraged and how outcomes should be shared with the team.
Link Experimentation to Business Goals
Frame experimentation as a way to solve existing business problems or explore new opportunities rather than as a separate activity.
What makes an effective experimentation culture?
Clear Success Criteria
Define what makes an experiment successful - it's not always about immediate production adoption.
Rapid Iteration Philosophy
Encourage quick cycles of trial, evaluation, and refinement:
"We aim to experiment quickly, learn from failures rapidly, and deliver promptly so we can expand our customer base."
Director of Engineering at Software Development Company
Knowledge Sharing Mechanisms
Ensure learning from experiments is documented and shared across teams.
Recognition for Experimental Contributions
Reward teams and individuals who conduct valuable experiments, regardless of whether they lead to production changes.
How do you get started with improving experimentation in your team?
Diagnose Your Current State
Begin by measuring where you stand using the Network Perspective DevEx Survey's experimenting question to establish a baseline.
Identify Specific Barriers
Common barriers include time constraints, unclear expectations, or lack of leadership support. Address these specifically rather than making general changes.
Start with Small, Structured Opportunities
Create small spaces for experimentation before committing to larger programs.
Look for Champions
Identify developers who already experiment in their free time and empower them to lead initiatives:
"You'll also find people who willingly use 20% of their free time to learn a new programming language or experiment with something different. It's essential to have these passionate enthusiasts on your team."
Senior Staff Software Engineer at IT Services Company
Create Feedback Loops
Establish mechanisms for teams to share what they've learned from experiments and how it impacts their daily work.
Conclusion
Organizations that successfully implement experimentation time typically find that the investment pays for itself through:
-
Reduced Technical Debt: Proactive exploration of better approaches prevents accumulation of problematic code.
-
Improved Developer Retention: Engineers value the opportunity to learn and create, making them less likely to seek these opportunities elsewhere.
-
Accelerated Innovation: New product features and process improvements emerge more quickly from teams that experiment regularly.
-
Enhanced Problem-Solving: Teams build a broader toolkit of approaches and technologies they can apply to production challenges.