AI Generated Infographic illustrating the core elements of the hackathon
Jay Ashcroft shares how a ‘Hackathon’ approach can foster creativity and produce working digital solutions in days.
At the end of the summer, we collaborated on a ‘Hackathon’ event which brought together policy, analytical, digital and industry providers into a multidisciplinary working team for a two day event. Our aim was to provide a creative environment to explore automation in environmental reporting.
How we approached it
The intensive event used a structured approach to rapid solution development that combined user research, technical prototyping, and strategic planning within compressed timeframes.
We divided attendees into 2 mixed teams who focused on workstreams targeting specific problem areas:
- Team A focused on looking at the data intake bottleneck. They explored the manual emails, data gaps, and messy storage issues that slow everything down. Using Power Automate workflows, the team built clean, structured data ingestion.
- Team B targeted the “90% problem”, investigating the complex data transformation work that consumes analysts’ time before any meaningful analysis can begin. An Azure-based solution automated some of the heavy lifting.
Running parallel to both teams, a user research group conducted focused interviews with reporting analysts and policy teams. The message was clear: any solution had to serve real user needs, not just showcase clever technology.
This framework enabled the teams to transition from problem identification to a working proof of concept demonstration in just 48 hours, demonstrating that we can tackle complex government challenges with the right collaborative structures.
What we learnt
User needs first: Technical solutions only succeed when grounded in real analyst workflows and policy requirements.
Build on existing foundations: The most effective automation works with current systems rather than requiring wholesale replacement workflows.
Show don’t tell: Working demonstrations beat PowerPoint presentations every time when it comes to building confidence in new approaches.
Preparation is key: Prior to the event we undertook a series of interviews with both policy and operational colleagues and secured dummy data that supported the hackathon and allowed the prototyping to take place at pace.
What went well
Different perspectives: Having people outside the project ask questions and pick things apart was valuable as we gathered new perspectives on the problems. It also gave policy colleagues the opportunity to take a step back, assess a broader view and take the opportunity to hear new insights.
Engagement between policy and analytical teams: having policy and analytical colleagues in the same room for more than quick calls gave them the opportunity and time to have broader discussions around data. Some colleagues even thought this was one of the most valuable parts of the event. One colleague said:
“It was really valuable to hear different perspectives. Listening to their thoughts and questions helped me take a step back, especially since I’m used to discussing this project with the same group. It was refreshing to hear new insights and queries, and it gave me a broader view.”
They could explore areas beyond the immediate tactical needs of the problem space and gave them time to think more strategically.
Collaboration: Bringing together diverse expertise from policy specialists to data engineers and multiple industry specialists produced solutions no single team could achieve, and in a compressed timescale too.
What we would do differently
After knowledge and information was shared with technical colleagues, there were periods of ‘downtime’ for operational and policy colleagues. Once the technical teams began prototyping and building, the operational and policy colleagues felt slightly surplus.
How we addressed this: We pivoted quickly and led focused activities which ran parallel to prototyping. In future hackathons we would plan those activities in advance as they proved valuable in delivering insight and opportunities to discuss the business side of the problems we were exploring.
Those activities included; agreeing a North Star; working through and creating an initial draft of our minimum viable product (MVP) that could be revisited and refined during alpha; identification of wider opportunities; and a session working through the business or operational problems that needed addressing.
Other areas of opportunity:
- Our big focus was on automation but on reflection it would have been valuable to add more time in to discuss existing systems and software we could pursue.
- We probably had 30 people in the hackathon, far too many to introduce everyone, but on reflection a method to show who’s who in the room would have been beneficial.
- For those less familiar with the ‘Hackathon’ approach, more time explaining how the sessions would feel and run may have been beneficial, so they understood what to expect and what would be expected of them.
Would we use this approach again?
In short, yes! This hackathon proved that with the right structure, collaboration, and focus on user needs, we can rapidly prototype solutions to complex challenges. We’re excited to build on this momentum and will apply the approach to future transformation efforts as it provided genuine value. It demonstrated what’s possible when government teams and industry partners collaborate to solve real-world problems.
More information
Jay Ashcroft is a Strategy Lead in Digital, Data, Technology and Security at Defra.
Like what you’ve read? Why not leave Jay a comment and share your thoughts on hackathons?
Check out our LinkedIn page for all the latest news, stories and job openings. While you're there, why not give us a follow?
Leave a comment