How to organize a hackathon for your internal developer portal
May 27, 2024
Ready to start?
You’ve chosen an internal developer portal. Now what?
You just chose an internal developer portal. You want to move ahead with your internal developer portal but you want to:
- engage your stakeholders so that you can drive adoption.
- showcase how the portal will benefit your users.
- involve your users in the process of building it.
- choose the right user stories for the portal MVP and define your future roadmap.
What we’ve seen as a solution is running a portal hackathon right at the beginning of the journey. It’s the perfect initiative for this; hackathons have the ability to bring the stakeholders together like nothing else. And we’re seeing first-hand how many organizations are taking the initiative and setting up their own portal hackathons.
Since the hackathon requires some portal/platform knowledge we usually see platform teams leading it, but they involve the other stakeholders (developers, devsecops, finops) in some of the teams or in the evaluation or ideation process.
We’ve seen hackathons created specifically for:
- A scoping exercise for the portal
- Presenting different use cases of the portal to developers to get their thoughts
- Focusing on individual use cases for the portal in teams
- Working on a specific integration for the portal (in one really interesting case, an organization connected Port with their GPT-like tool to query Port’s catalog in natural language!).
Get the most out of your portal hackathon
Different hackathons may have similar objectives, planning processes and stages, but you may need to make yours fit an internal developer portal. That’s why we’ve put together this list of tips for creating a portal hackathon:
1. The hackathon is about developers, not platform engineers
When planning a portal hackathon, make it clear that the event is all about improving developer work lives. Define what the issues are (eg. too many tools and too much context switching). Encourage participants to think about the frustrations developers face and what portal features could make their jobs easier; not what would make devops lives easier.
Get developers to join using fun slogans like "This Hackathon is All About You" to show that their ideas and needs are the focus. This way, developers will feel more motivated to participate and come up with great solutions to enhance their daily work.
Consider sharing observations about developer needs - from surveys, interviews and more. You can even define types of solutions you’re looking for - the hackathon doesn’t have to be a free-for-all.
2. Learn from brainstorming principles
Go in with the mindset that all ideas are good - this way you can open your mind to the many options that portals present.
3. Clarity is key
Another important tip for your hackathon is to ensure that all participants are familiar with the developer portal and its four main pillars, which they can use to build new features. Consider organizing a brief training session or providing some reading materials ahead of the event.
These pillars include:
- Software Catalog - significantly improves discoverability and visibility of all services and resources
- Self-service actions - enables developers to self-service what is done today through a ticket or other interface (such as Jenkins) and contains golden paths and guardrails
- Scorecards - to set and track compliance with standards
- Automations - to eliminate repetitive, manual work
What the business objectives and (perhaps most importantly) how the portal will benefit them.
It’s worth remembering that developers may not necessarily engage with the business objective of “improving developer experience” or “boosting developer productivity”, nor will they necessarily care if you are reducing the number of tickets that they need to file. But, they will care about being able to do things like scaffold a new microservice, provision a new cloud resource, or find out information about multiple services without having to context-switch. In other words, when you’re presenting developers with the portal and its features, make sure you show them what it means for them.
4. Provide access to the documentation
On the last point, there’s no better way to provide clarity than to give your developers access to the relevant documentation.
They can then get a better idea of what building the portal is likely to entail, as well as the myriad of possibilities it enables.
(You can find Port’s documentation here.)
5. Call in portal experts
It’s not enough to just present your ideas; you need to be prepared to answer a range of different questions - and sometimes you may not have all of the answers. Getting a portal expert to support the team can be helpful. Our customer success and solution engineer teams have been asked to support in the past, and you can feel free to request some help from them.
You can also have the team check out Port’s open demo to get ideas about what solutions can look like.
6. Working on user stories are vital
Defining exactly what user stories (or use cases) consist of, is a great hackathon exercise. It could be around API management, AppSec, or Kubernetes, for example.
We’ve had an organization that held a portal hackathon where they split the platform team in three smaller sub-teams, and each worked on one user story for 24 hours. What they achieved in such a short time frame was incredibly impressive.
Here are some specific guidelines for this tip:
Plan ahead
It’s worth considering building a minimal viable product (MVP) first. That means first defining what would go into the MVP and what should come after that. If you need help getting started, check out this blog.
And if you’re looking for inspiration for use cases and want a template for your roadmap, you can use our roadmap planner, which can be used to identify and prioritize user stories, and build a roadmap which can then be shared with stakeholders.
Consider how the portal’s pillars could benefit your use case
For example, if they wanted to implement just in time permissions, they could create a self-service action to get permission for access to cloud resources that auto terminate. They could also create a catalog of all the permissions given, to provide visibility, and automations to automate the permissions process for on-call engineers.
Link your use case to your objective
User stories should factor in the overall objective and the metrics that can help you to achieve that objective. For instance, your use case could be to ‘get JIT permissions to production’, which links to the quantifiable metric of ‘improving incident response time’, which links to the overall objective of enhancing security and compliance. In short, your use case has to have the end goal in mind.
7. Teams should be heterogeneous
Make it a requirement that the teams for your hackathon include a mix of personas. Ideally, you’ll want developers, DevOps (or platform), product, DevSecOps, FinOps and more.
8. Don’t underestimate the power of prizes
Your teams are likely to be more competitive than you think. Competitiveness breeds competence; by offering prizes for the best ideas, you’re likely to benefit from a better portal. Implementing the best feature ideas is a great prize in itself for your developers, and should fill them with a sense of pride (but you should give them a separate prize, too!).
9. Make some noise about your hackathon
Before and after your hackathon, make sure everyone that needs to know about it is aware. Ask your internal comms team to talk about it in the newsletter, put up flyers in the office, make a Slack channel for it - whatever works best to gain traction inside your company. Once the hackathon is over, use similar tactics to ensure you make noise about the key takeaways, the next steps, and the prize winners.
10. Get feedback to make your next hackathon even better
Perhaps your first portal hackathon is focused on scoping your portal, and your next is about your MVP, a specific use case or integration. Get feedback from your participants on what they think worked with the hackathon and how the next hackathon could be improved. You can do this at the end of the hackathon or as an (anonymous) online survey.
11. Most importantly - make it fun!
This isn’t just any day of work. Keep your participants engaged throughout by making it fun. The prizes will help you to do this. You should also break up the day with different activities. Provide snacks, pizzas, drinks or coffees for the whole team. Perhaps you can keep a scoreboard to keep track of individuals/teams for all your hackathons.
Hosting a hackathon can be a game-changer. It not only raises awareness among stakeholders about the portal but also helps them fully grasp its potential. Watch as adoption rates soar and excitement builds, transforming how developers interact with your platform.
Have you run a portal hackathon? Tell us about it here! Or discuss it with others who are in the same boat by joining our Community.
Check out Port's pre-populated demo and see what it's all about.
No email required
Contact sales for a technical product walkthrough
Open a free Port account. No credit card required
Watch Port live coding videos - setting up an internal developer portal & platform
Check out Port's pre-populated demo and see what it's all about.
(no email required)
Contact sales for a technical product walkthrough
Open a free Port account. No credit card required
Watch Port live coding videos - setting up an internal developer portal & platform
Book a demo right now to check out Port's developer portal yourself
Apply to join the Beta for Port's new Backstage plugin
It's a Trap - Jenkins as Self service UI
Further reading:
Example JSON block
Order Domain
Cart System
Products System
Cart Resource
Cart API
Core Kafka Library
Core Payment Library
Cart Service JSON
Products Service JSON
Component Blueprint
Resource Blueprint
API Blueprint
Domain Blueprint
System Blueprint
Microservices SDLC
Scaffold a new microservice
Deploy (canary or blue-green)
Feature flagging
Revert
Lock deployments
Add Secret
Force merge pull request (skip tests on crises)
Add environment variable to service
Add IaC to the service
Upgrade package version
Development environments
Spin up a developer environment for 5 days
ETL mock data to environment
Invite developer to the environment
Extend TTL by 3 days
Cloud resources
Provision a cloud resource
Modify a cloud resource
Get permissions to access cloud resource
SRE actions
Update pod count
Update auto-scaling group
Execute incident response runbook automation
Data Engineering
Add / Remove / Update Column to table
Run Airflow DAG
Duplicate table
Backoffice
Change customer configuration
Update customer software version
Upgrade - Downgrade plan tier
Create - Delete customer
Machine learning actions
Train model
Pre-process dataset
Deploy
A/B testing traffic route
Revert
Spin up remote Jupyter notebook
Engineering tools
Observability
Tasks management
CI/CD
On-Call management
Troubleshooting tools
DevSecOps
Runbooks
Infrastructure
Cloud Resources
K8S
Containers & Serverless
IaC
Databases
Environments
Regions
Software and more
Microservices
Docker Images
Docs
APIs
3rd parties
Runbooks
Cron jobs