At Consegna we pride ourselves on our experience and knowledge.  Our recently appointed National Client Manager has a knack for knowing virtually everybody in Wellington. This can be amusing if you’re with him as a 10 minute walk down Lambton Quay can take half an hour. We tend to now leave gaps that long between meetings. One of the questions he will ask people is one we probably all ask, “how’s business?”  The answer is always the same, “busy!”

 

Now sometimes that can just be a standard answer, but if it’s true and we’re all so busy then what are we busy doing? We would like to think we’re doing super innovative work but how much time do we actually dedicate to innovation? Most of the time we’re busy just trying to complete projects. Google famously scraped their “20% time” dedicated to innovation because managers were judged on the productivity of their teams and they were in turn concerned about falling behind on projects where only 80% capacity was used. Yet, the flipside of that was that  “20% time” formed the genesis of Gmail, Adsense and Google Talk.

 

So this leads on to thinking how can we continue to create when we’re all so busy? We have to be innovative about being innovative.  One solution that organisations have been working on is the idea of a hackathon. A short period of time, usually around 48 hours, for organisations to stop what they’re doing and work on exciting new things that traditionally might be out of scope or “nice to haves”.

 

Consegna was selected as the University of Auckland cloud enablement partner in 2017 and were recently involved with the University’s cloud centre of excellence team who wanted to promote and facilitate innovation within their internal teams. One answer to create more innovation was hosting a Hackathon with Auckland University internal teams. In total there were 17 teams of 2-6 people a team. They were tasked with trying to solve operational issues within the University – and there were a number of reasons we jumped at the chance to help them with their hackathon.

 

First and foremost we liked the idea of two days being used to build, break and create. We were there as the AWS experts to help get the boat moving, but deep down we’re all engineers and developers who like to roll up our sleeves and get on the tools.

 

Secondly, after watching larger companies like Facebook define why they use Hackathons, it resonated with the team at Consegna. “Prototypes don’t need to be polished, they just need to work at the beginning”. Facebook Chat came out of a 2007 Hackathon which evolved into Web Chat, then Mobile Chat which then became Facebook Messenger as we know it today. The end result of a hackathon doesn’t need to be be pretty, but the potential could know no bounds. Consegna were able to help Auckland University build something where its success was not judged on immediate outcomes, but on the potential outcomes to do amazing things.

 

Hackathons can also be incredibly motivating for staff members. For those of you who are familiar with Daniel Pink’s book “Drive”, you’ll know money doesn’t always motive staff like we traditionally thought it did. Autonomy, Mastery and Purpose are key parts of Pink’s thinking but also the key to a successful hackathon. The business is not telling you how to do something and in a lot of cases, the guidelines can be very fluid in that they’re not telling you what to build. A guiding question to a successful hackathon can be succinctly put as “what do you think?”

 

We applaud Auckland University for inviting us along to allow their staff members to pick our brains and learn new things. Want to know how to program Alexa? No problem! How can I collect, process and analyse streaming data in real time? Talk to one our lead DevOps Architects, they’ll introduce you to Kinesis. There was as much learning and teaching going on at the hackathon as there was building some amazing applications.

 

It’s important to be aware of potential pitfalls of hosting a hackathon and to be mindful you don’t fall for the traps. You want to make sure you get the most out of your hackathon, everybody enjoys it and that there are plenty of takeaways otherwise bluntly, what’s the point?

 

Hackathons as a general rule don’t allow for access to customers. If you’re wanting to dedicate just 48 hours to solve a problem then how can you have understanding and empathy for customers if they’re not around? If they’re not there to collect feedback and iterate can you even build it? Auckland University got around that problem by largely building for themselves; they were the customer. They could interview each other for feedback so this was a tidy solution so if you think a hackathon will offer a solution for customer-facing applications you might want to think about either making customers available for further enhancements outside of the hackathon or think of a different innovation solution altogether.

 

Before I mentioned how Facebook use hackathons to inspire innovation, but there is one downside – they’re unpaid and on weekends. Employees can feel obligated to participate to please hierarchies which forces innovation out of their staff. Generally, this is not going to go well. The driving factors Pink mentions are not going to be as prevalent if staff are doing it in their own time, usually without pay – to build something the business owns. From what I’ve seen Facebook put on some amazing food for their hackathons but so what? Value your staff, value the work they do and don’t force them to do it on their own time. Auckland University’s hackathon was scheduled over two working days, in work time and made sure staff felt valued for what ultimately was a tool for the University.

 

Over the two days, the 18 teams presented their projects and there were some amazing outcomes. MiA, the winner, used a QR code on a big screen so students can snapshot the QR code and register their attendance to each lecture. This was done with an eye on Rekognition being the next iteration and using image recognition software to measure attendance. Generally speaking, there’s not a whole lot wrong with how the University currently measures attendance with good old fashioned pen and paper but how accurate is it when you’re allowing humans to be involved and how cool is it for an AWS product to take the whole problem away?

 

In all, it was an amazing event to be a part of and we must thank Auckland University for inviting us. Also thanks to AWS for providing a wealth of credits so there was no cost barrier to building and creating.

 

If you’re thinking of hosting your own hackathon I wish you well. It’s a great way to take a break from being busy and focus on creating new tools with potentially unlimited potential. It will get your staff scratching a learning and creative itch they’ve been aching to get at.

 

Most importantly, always take time and make strategies to keep innovating. Don’t be too busy.