A version of this blog post appeared in The New Stack.
Enterprises have gotten pretty good at adopting DevOps practices. Scaling these initial successes can sometimes be difficult. To be sure disciplines like platform engineering and compliance architects are sprouting up as valid manifestations of DevOps. But, sustaining and expanding your productive, devops operating model requires constant validation and growth. That’s why we see more companies turning to the humble hackathon as a way to sustain their engineering culture!
Internal hackathons are a hidden gem for fostering an active learning culture that yields valuable innovation and ultimately, better business outcomes. But they require resources – that’s time, money, and infrastructure to make sure it’s valuable to your developers and your business. To justifying that kind of investment start by laying out the value of running an internal hackathon, such as:
Crowdsourcing innovation: The saying goes “two heads are better than one” and though that is not always the case, practices like pair programming – an element of Extreme Programming – resulting in better code, faster development and information sharing, as outlined in this blog post about the U.S. Department of Defense’s use of Extreme Programming. An internal hackathon could provide a perfect setting to have teams work together on a problem, improve existing software, or deliver new revenue-generating experiences. Hackathons foment innovation!
Discovering system weaknesses: Internal hackathons provide a controlled environment to discover security vulnerabilities, performance issues, or policy drift before your software hits prod.
Addressing technical debt: According to the The Stack Overflow 2024 Developer Survey more than half of developers listed technical debt as a problem. A hackathon gives them and you an opportunity to examine your current systems and identify technical debt that is no longer serving you, not to mention ideas for more efficient ways to do things.
Learning through experience in a safe environment: Hackathons provide a safe and secure environment for experiential learning. Developers and platform teams can learn new skills or sharpen existing ones with minimal risk. Engineers and developers like to learn new things. Keeping them happy is important. This American Airlines Tech Blog sums it up like this:
Hackathons are positive for morale and for team building, which inherently makes them amazing for keeping people excited about what they do, making them passionate about new tech, and distracting them from other job offers.
Hackathons cannot be a one person show
To pull off a successful hackathon that your developers want to attend year after year, you will need help with execution and resources. Ideally you’ve secured executive sponsorship for the event – someone who isn’t afraid to try new things, understands the importance of culture, has broad and deep influence, and is willing to be your voice at the executive level. Don’t discount the tech-minded line of business leaders who need to deliver better services and experiences and value software as an asset.
Partnering with your company’s internal learning organizations is another way to fund your hackathons. Many enlightened enterprises have internal teams dedicated to the adoption and use of open source software, like Comcast, Netflix, American Airlines, The Home Depot, and CapitalOne to name a few. By highlighting the learning aspects of the hackathon they could contribute resources and support for it.
Though it seems dubious, you might consider asking for outside help to make your hackathon dreams come true. Don’t be afraid to embrace the eager vendor. Many vendors, including yours truly, are willing to sponsor and help run a hackathon or hands-on labs. Broadcom Tanzu division’s advocates and architects run hackathons, workshops, and labs with dev and platform teams. Not to mention, they’ll be happy to bring stickers, tee-shirts and even free trials for new toys tools your team wants to try.
Set and Setting: The team that hacks together wins together
I asked my colleague DaShaun Carter, who runs and participates in hackathons regularly, if he would share some practical considerations of running a hackathon. DaShaun shared one of the most successful events he facilitated whereby the teams were upgrading from different versions of Spring 2.x to 3. Upgrading to Spring Boot 3 requires running Java 17 or later (read why we love Java 21 here) while some teams were still on Java 8! Participants were encouraged to share milestones on a shared channel in real-time. With several teams and hundreds of developers the milestones turned into mini celebrations that ultimately inspired and encouraged the participants. In addition to quantitative metrics (e.g. number of apps upgrade, versions) participants were measured on how many other teams they engaged. These little details were critical to fostering an active and celebratory learning environment.
While having a theme and incorporating a little friendly competition and encouragement from leadership is certainly a good way to get people excited about the event, it’s not just about making it fun and productive, there are many practical considerations to throwing a great hackathon. Here are some of DaShaun’s tips for IT leaders and app dev managers who want to set up a successful internal hackathon:
Involve your platform teams
Have the people who will ultimately deliver the platforms, paths to production and golden paths that your developers use attend. This will help them better understand the tools the dev teams use and want, and builds empathy between teams. It’s a great way to identify and mitigate technical debt and potential security weak spots.
Make sure the sandbox has enough sand in it
Nothing kills momentum more than not being able to deploy or waiting for your environment. Have a good sense of what resources they’ll need, like database instances,entitlements, credits, etc. and make sure participants have self-serve access to environments. Make sure the sandbox has all they need to build, bind, deploy and scale.
Have rules but leave room for creativity
Provide a menu of must-use and nice-to use criteria which helps if your teams are trying something new. For example they have to include a specific library or API that gets targeted for inclusion. Consider setting up time boundaries (e.g. use of buildpacks, how many instances wee updated in a set time) or offering extra credit for building a specific type of app or securing a vulnerability etc.
Don’t break your fixed engineering culture
If your organization has an established and successful DevOps practice it probably didn’t happen by accident and it probably didn’t happen easily. If your engineering culture is productive and (mostly) frictionless, you probably want to sustain it. Running regular hackathons builds on that culture and ultimately helps improve your application dev and delivery pipelines, improves your fundamentals (security, stability, availability, scalability) and encourages creativity.
