You’ve done it. You’re on the path of digital success! You’re in a leadership role at a large firm, working as part of a large effort to build a broad set of dev tools, APIs, UI components, analytics tools, design language standards, and quality measures, all in the interest of simplifying the ability to deliver amazing products to your clients.
But you find yourself with a few nagging questions:
Is it working? Will developers be able to use what we’ve built? Does this even make sense?
There’s a great way to start answering these questions: run an internal hackathon. At BNY Mellon, we decided to leverage our Global Innovation Centers and run a few hackathons ourselves.
That sounds deceptively simple, doesn’t it? You’re right to be suspicious, since a “hackathon” means different things to different people. So for starters, let’s try to define a hackathon. There’s a great definition in a post by George Krasadakis, where he defines a hackathon as:
An intensive, software-centric ideation, prototyping and presentation challenge on known or unknown problems or opportunities
That’s a great working definition, but I want to add that your hackathon goals can vary immensely. In our case, our internal hackathons have been about unconventional learning, dogfooding, and culture change.
The world is constantly changing, and especially when it comes to taking ideas and turning them into functioning software, the process of doing so can seem daunting. Running an internal hackathon gives your people an opportunity to learn, to explore, and to try new things. They’re a form of deliberate practice that differs from tradition.
Remember that time that your employee said they thoroughly enjoyed their required bi-yearly compliance training? Yeah, neither do I.
Hackathons break that mold. They’re messy, fraught with coding mishaps and failed ideas. They force you to work in constrained timeframes with people you might not even know, using technology and skills that you’re unfamiliar with. Hackathons are a form of experiential, hands-on learning that cannot be replicated otherwise.
We’ve built dozens of APIs, UI components, and developer tools. Now it’s time to put on our dogfooding hats.
First, for the uninitiated: what is dogfooding?!
Dogfooding, or, “eating your own dog food,” is the idea that people or companies should use their own products or services, in an effort to test them and make sure they’re actually usable in real-world context. You can check Wikipedia for more background, if you’re interested.
The hackathon version of dogfooding is like taking the engineering echo chamber and breaking it into a thousand pieces. There’s only one guarantee: people will try to use your software in ways you never thought of, and there’s no better test.
At BNY Mellon, we’ve decided to break the mold with our tech platform. Not only is it delivering financial services to thousands of clients worldwide, it’s powering our intranet. And guess what: your company intranet can be the best sandbox in the world.
At any company, the employees need to understand what they’re building, and to try it for themselves. This is especially challenging at B2B companies, where many employees may never use your software. That’s a problem. Whether you’re building machine learning APIs, a new camera app, an e-commerce platform, or a messaging service, your people need to test what you’re building. The engineers need the feedback, and your people want to be involved in the process.
Part of building a large product or platform is that the thought process around delivering value needs to change. It’s not about what you can create, it’s about what we can create together. How can you take an idea and a couple APIs and make it come to life? How can you consume and reuse, to take building blocks and put them together in unexpected ways?
It comes down to empowering your people to try something new, to test an idea, or to explore undiscovered talents.
Your hackathon might not be the same as our hackathon. For instance, in our most recent iteration, we had everyone go through a Design Thinking process, and the majority of people had never participated in a hackathon before. Truly understanding our users, and giving both our technology and non-technology people the chance to learn the process was one of the goals of the hackathon. The best idea isn’t always the one with the best code; often, it’s the idea that creates the best experience.
The hackathons were a great experience, and we accomplished much of the goals that we had set out:
Here’s the catch: hackathons are just the start. They’re a formalization of a hacker culture, where people are encouraged and pushed to always try new things, always continue to learn, always overcome limitations and create experiences that redefine perception.
For us, we’ll be taking the resulting hacks forward, establishing a way for people to get their ideas to go to production. We’re encouraging teams, managers, and leaders to give their people a chance to embody the hacker spirit not only as part of a formalized day or two, but as part of their work.
I encourage you to do the same at your company, no matter how big or how small. I work at a 233 year-old company. We have talented people, immense technology investment, and interesting problems that affect millions of people worldwide.
Give people tools, knowledge, and empower them to try their ideas. That’s all it takes.
On a personal note, I want to highlight that it takes a bunch of awesome people to make a hackathon come together. It doesn’t happen without a team!
If you’re interested in reaching out, I’m on LinkedIn, Twitter, Medium, and many other platforms.
Hacker Noon is how hackers start their afternoons. We’re a part of the @AMIfamily. We are now accepting submissions and happy to discuss advertising & sponsorship opportunities.
To learn more, read our about page, like/message us on Facebook, or simply, tweet/DM @HackerNoon.
If you enjoyed this story, we recommend reading our latest tech stories and trending tech stories. Until next time, don’t take the realities of the world for granted!