By now hackathons are somewhat old hat—the term has been around since 1999.  Nevertheless, we managed to come up with a variation that we had not heard of before: we involved all our clients in our first annual Innovation Hackathon.  And it was a resounding success.

Innovation Partner

At Nearsoft we like to think of ourselves as innovation partners to our clients, but in practice we have had few opportunities to work on significant innovations.  Of course, together with our clients we work on very innovative products and business models.  But until now, we didn’t have a portfolio of tech innovations that originated with us. So, we decided to do something about it and we first came with an innovative twist to the Hackathon.

A Hackathon by Any Other Name…

According to Wikipedia,

A hackathon … is an event in which computer programmers and others involved in software development … collaborate intensively on software projects.

The same article describes various types of hackathons, organized around,

  • An application type
  • A specific programming language, API, or framework
  • A cause or purpose
  • A demographic group
  • Internal company hackathons

Circle representing hackathon with arrows representing independent individuals coming

These really collapse to  two types of hackathons,

  1. Independent people come together to create code around,
    1. A technology (e.g., The Game Hackathon)
    2. A social goal (e.g., Code for America).
  2. A Company's Product  Hackathon

  3. Employees of a company come together to create code around a company’s products (e.g., Salesforce’ Dreamforce hackathon).

Instead, we came up with a new type of hackathon that brought together Nearsoft and all its clients. In the Nearsoft Hackathon, our employees created original, innovative technologies for our clients.

Nearsoft Innovation Hackathon Future


The people participating in the Hackathon were strongly encouraged to not choose a challenge from their current client. One of the main goals of this exercise was to give people a chance to work on something new and out of the ordinary. What this meant is that the challengers were not familiar with the people who worked on their challenge. Likewise, the people in the team were not familiar with the technology they were going to work with. At the beginning of the week, each client pitched one or more “challenges.” There were no restrictions on what a challenge could be but in general they all turned out to be very interesting. One of our clients threw out a dozen challenges, others proposed only one, and most of them presented two or three challenges. This was done in 20-minutes pitches at the beginning of the week. By Wednesday night people had formed teams and chosen which challenges they were going to work on. Out of about 30-or-so challenges, eight were selected. They then started to work on Thursday morning and 36 hours later the teams presented their results to a panel of judges made up of client representatives.


Two of the projects were contributions to Open Source projects.  Two were pretty far out.  The other four were new features, alternative UIs, and the like.

Four projects won, one each in first and second place, and two unexpectedly tied for third place.

Two of the projects went straight into production (one was even showed off to our client’s Board).  Two were accepted as contributions to Open Source projects.

What We Learned: Presentations

The transition between presentations could have been smoother.  We need to get better at getting the next-team-up ready to present immediately after the current one finishes.

It was not always to the judges what challenge a team had worked on.  Next time we should probably have the person who proposed the challenge present it to the other judges before the team gets up to present the results.  (BTW, this might be enough to give us the time we need to switch the slides, etc., from one team to the next.)

It wasn’t always clear who or even how many people had worked on a particular challenge. Next time we are going to try having the MC introduce everybody in the team as they walk on stage.

What We Learned: Evaluation

The survey we used to evaluate the results was terrible. We need to come up with items that are clear and a well understood criteria for evaluation.  Traditional hackathons have teams all solving the same problem, so that the results can be more readily judged.  In our case, it was like comparing iPhones to Teslas.

What We Learned: Process

Doing a 15-minute challenge pitch and then having developers work for 36 hours without any further contact with the “challenger” did not work well for some of the challenges.  For example, for the more technically complex ones that were based on existing (OSS) code, it would have worked better for the challenger to work more interactively with the team throughout the hackathon.

This would have made the process more agile, lead to better results, and provide more of that collaboration that ultimately showcases the talent at Nearsoft.  For example, the challenger could plan to meet with the team three times over the course of of the hackathon, to provide feedback and solicit requirements.

This would also give a challenger a more personal connection with “her” team.

Future Possibilities

Bottom line, the exercise was a success and everybody involved wants to do it again in the future.  Our clients were very supportive and enthusiastic and have encouraged us to continue with this and other of our crazy ideas to promote innovation.

Nearsoft Innovation Hackathon Future

Future Nearsoft Innovation Hackathons

One possible twist for next time (or maybe the time after that) is to also include people from our clients’ local teams.  Or we could include other local talent from Hermosillo.  There are lots of questions around the mythical “IP” (Intellectual Property).  But figuring out this kind of thing is also part of the innovation process.

The magic will be in being able to unleash the combined creative force of people who normally work in boxes (i.e., their projects) inside silos (i.e., their specific company) and enabling them to work 1) on the things they are most passionate about, and 2) with like-minded talented people.

Will that work?  will it turn into a big, legal mess?  There’s only one way to find out and that’s by running the experiment.

Who knows what we will discover in the process?  And who would not want to find out?

The potential benefits, (i.e., financial, personal, and even spiritual benefits are so high that it is well worth trying.