Jon Mort
Published on 10 November 2025
How HackDays deliver much more than code
Our HackDays have flattened hierarchies, built new products, and grown a collaborative culture for 10 years. See how we do it and get tips for running your own.
How important are innovation and collaboration to your organisation? At The Adaptavist Group, we've been using hackathons to address operational problems and inspire the creation of new products and services for ten years. The benefits are many—for individuals, teams, and the company as a whole—but I find they also help us in more subtle yet fundamental ways, too.
Jon Mort
Chief Technology Officer, The Adaptavist Group
The Adaptavist Group has been holding HackDays—hackathons where teams come together to rapidly build problem-solving solutions—for ten years now. This summer, approximately 15% of our thousand-strong global team got involved in a project. Our HackDays are collaborative and competitive. Anyone in our company can define a problem, submit a project proposal, and recruit a team to give it life. By the end of the competition, participants must deliver a prototype and pitch it to the rest of the business. Everyone in The Adaptavist Group casts a vote for the winner, and prizes are allocated by a panel of judges. The teams bring together people working in different roles, departments, business units, and locations. It’s not just for engineers—designers, consultants, marketers, product managers, project managers, and anyone across the organisation can get involved too.
This year was our largest event ever, with 23 projects submitted. Most teams worked entirely remotely, with a handful arranging in-person meetups to kick off on day one. We cap the team size at 10 to keep collaboration manageable, and group sizes ranged from 2 to 10 people. As we view AI as a tool rather than a teammate, each collective must consist of at least two people.
Why have HackDays?
We started running HackDays to give people time and permission to pursue ideas that don’t fit neatly into their day‑to‑day priorities. In a company of our size, it gives people the opportunity to work alongside colleagues they've never met before, forging new friendships and connections. They've become a highly anticipated cultural fixture that encourages experimentation and learning, surfacing bottom-up innovation that can mature into real products and services, and building community across disciplines and locations. HackDay projects have evolved into shipped products (ScriptRunner Cloud), as well as tools that changed how we work (for instance, we have a Quote Builder tool, which helps manage and scale licensing operations).
How have HackDays changed at TAG?
HackDay projects typically focus on internal efficiencies and processes or client‑facing apps and integrations. The toolset has evolved significantly; this year, nearly every team used AI-assisted build tools—including Lovable, Bolt, Claude Code, and Cursor— to accelerate ideation and development. AI also regularly appeared within the prototypes themselves with features that summarise, generate, or automate tasks. Of course, presentations used AI support with scripting and video editing. One observation was that AI voice‑overs only landed well when used deliberately, as a stylistic choice.
One of the main themes in internal efficiency projects was that some teams sought to address hard-to-automate processes, including drafting solution documents and responding to RFPs. There was significant progress in this direction, with many creating what I would call '80% solutions'. The final 20% tended to require deeper engineering, domain, or compliance knowledge and skills.
When it came to building prototype apps, however, what would have required specialist skills was often addressed by cross-functional teams using AI support. One team created a functioning monday.com app with no developer.
What else do we learn from HackDays?
HackDays aren't about creating finished, shippable products. However, it’s remarkable how far people can go in just a few days. With a hard deadline and the need to prepare and present to our peers, it differs somewhat from our usual business operations. I noted the following key differences:
- Speed and focus over polish. There isn't time for long scoping or extended research cycles. Teams need to define a narrow problem and a clear user, consider their options, pick an approach, and move quickly.
- Flattened hierarchy. The makeup of teams is often pragmatic, but they quickly find that contribution beats title, and people assume roles that differ from their usual job descriptions.
- Tight feedback loops. The teams that demonstrate the best productivity work through a build-review-tweak loop multiple times per day. Shipping something that works beats trying to build perfectly.
- Outcome over output. The prototype and how it delivers customer value are what matter, rather than the specification or the length of the feature list. Winning teams tend to make early technical bets and resist gold-plating the solution; good enough wins every time.
- Communicate continuously. Working together and exchanging ideas is crucial, though it doesn't mean that the team has to be in the same physical location. Many groups leave a Zoom chat open all day for ad‑hoc collaboration and quick unblocks.
Blurring boundaries and roles
When I reflect on ten years of HackDays, I think what's most valuable is how they can influence teamwork within the product development process. Time becomes the scarcest resource during a HackDay, and that affects teams and individuals in several ways. Teams assemble around ideas in the weeks leading up to the HackDays, and the boundaries between roles and disciplines become increasingly blurred.
We run light‑touch 'project speed‑dating' sessions to match ideas with skills. The person who proposes the idea typically leads, setting direction, maintaining momentum, and unblocking where necessary. However, there tends not to be enough time for micromanaging. Likewise, because the teams usually lack a few specialist roles, everyone contributes beyond their usual domain. Developers pitch, project managers create wireframes, and marketers test flows, for example.
Communication is the most significant overhead, so smaller teams generally perform better. Similarly, teams where people swarm to tasks that need doing, rather than having tasks owned by specialists, tend to make the best use of the limited time.
Leave your identity at the door
Working effectively in a hack‑day team tends to mean thinking of yourself as an all-rounded 'engineer/designer/marketer on the project'. You're one of the collaborators working to solve the problem central to the project. That identity shift unlocks creativity for many; they may try things they'd never consider doing in their day-to-day work. Some people discover new strengths, and some realise that something 'good enough' can be developed quickly enough.
A standout example from this year's projects involved two marketers using AI‑assisted tools to build a working monday.com app without any prior software engineering experience. They shipped a fully functional prototype that ran inside monday.com. The app proved the value of the idea and created a clear path to commercial launch (security, compliance, and marketplace readiness).
Every project successfully shipped something this year. That's unusual, and I think it's a sign that the tooling, mentoring, and format support we've built around help everyone make progress.
Focus on the problem and the people you're trying to serve
In my experience, the key benefit delivered by the constraints of a HackDay is the focus it brings. Teams quickly learn to focus on the functionality that absolutely must be delivered to solve the identified problem, abandoning interesting but non-essential features. They put the user first and ensure they have an ultra-sharp framing of the problem—one painful use case always works best.
The focus extends to the presentation as well. The demo presents the solution in development, showing the before-and-after and quantifying the benefits. When the team has a concise and coherent narrative, they can deliver a three-minute story that says as much as the demo. HackDay teams learn to explain their projects in an easily digestible way and shine a light on their thinking.
How did their research lead them to a solution? What challenges did they encounter and how did they overcome them? How did the members collaborate to deliver in such a compressed timeframe? These are all essential lessons that help us in our day-to-day work outside HackDays.
After ten years, HackDays still deliver much more than code. They expand our skills, flatten our hierarchy, and renew our belief that innovation is a team sport. The prototypes matter—but the mindset we build together matters even more.