Why I participated in Hiver’s first Hackathon (and what I learnt from it)

When I completed my post grad in computers, I was inclined to take the most obvious path that suited my expertise: coding.

I tried coding for a couple of months and instantly knew that staring at a screen with lines of code was not for me. Perhaps it was my experience as a coder that led me to stay away from anything to do with coding in general.

When Hiver decided to host its first hackathon ever, I was approached by members of the development team to be a part of their team.

My first response was “What will I do?.” And right there, I had my first piece of learning:

You don’t have to code to be part of a Hackathon but that still does not make it easy!

My team members were looking for my help in choosing an area of improvement and above all pitch that improvement.

My sales skills were a bonus, what I did enjoy more was helping the team pick an improvement for Hiver and get to work as a product manager for.

In that one instant, I developed respect for what product manager’s do every day. My mind was filled with ideas, but I was instantly hit with the realization that we had only 1 day to build what we wanted and make it ‘production ready’.

This is exactly what every product manager also goes through. Product managers have so many things that they can build but they only ever pick stuff that is doable in ‘x’ amount of time.

Not to mention, I also realized that coding requires resources and that too are limited in every organization. Our coding team for the hackathon was 2 people strong — that also played a factor!

As a sales leader, I am always cribbing that some of the ‘fancier’ features not being picked up. I can see why now.

The second piece of learning that I picked up from the Hackathon was equally important. This is something people from the sales profession never get about developers, but I think I gained a certain amount of insight into this.

Not all code goes as planned

While we tried to shoot for the stars, we soon realized we had bitten off more than we could chew.

That is where we decided to go for something that was more functional than something that was probably not going to be completed on time.

This made me realize, that time lines for features were hard to commit and even harder to meet. The ‘why’ answered itself when we got down to building the improvement.

I can understand now, why code gets pushed, feature development is delayed and why QA is so important in the overall development process. Earlier, all I had was an outsiders view to this.

The final and the most important learning (rather a reminder) for me was:

You could have a strong sales team, but a great product will trump all

I think I nailed the pitch for the product. However, our team did not win.

Reason: The other teams had a much better idea than us and built a much better feature than us.

This was a reminder to me that a great sales team can only get you so far, the team that works in the background like development, support and product also need to be great.

Not to sound too philosophical, I lost but I think I learned a lot from the experience. That was my greatest winning.

Will I participate in the next Hackathon? Hell yeah! I already have a great idea.