From Spark to Production, a Hackathon Story

Have you ever participated in a hackathon? What are the first steps to “Get things done”? This is a short story of my hackathon team’s effort, from a requested idea to its eventual end come.

I am an engineering team lead in Tipalti.
My team is made of great developers, production, or automation.
I’ve joined Tipalti about 3 years ago, and have been a team lead for 2 years now.

This was my 2nd hackathon in Tipalti, and it went great.

Our yearly hackathon

My company, Tipalti, has a lovely tradition of a yearly hackathon. I love this tradition because it breaks a lot of everyday habits:

  • It lets me do things I don’t usually do;
  • It lets me engage and work with different people I don’t usually work with;
  • It lets me do a different impact than my daily work.
  • It changes the way I think.

The rules

  • Form a team of at least 4 people
  • Pick an idea beforehand: Your idea, or someone else’s.
    Everyone can suggest ideas, and there are usually “bounty hunts”: ideas requested by upper management.
  • You shouldn’t work on the hackathon before hackathon day, but you can prepare, have a preliminary meeting, etc.
  • Everyone participates.
    This includes All Engineering (Devs, architects, etc.), Product managers, DevOps, IT, TechSupport, HR, and so on.
    I think the only non-participants are the judges. (Or people who are not interested)
  • We have 24 hours. That’s it.

How things started for my team

I had a grand idea. The best one. It was super.
I even talked with one of our DevOps people, and we teamed up.
This hackathon, I decided, my team’s project is going to go “live”.

Then another team lead had approached me. He had brought to my attention a request made by our Senior VP RND, head of Engineering.
The request included some integration between Slack and our deployments framework. I lit up.

I’m really glad for the quick change I made from “my idea is the best” (It wasn’t), to “This idea is much better”.

So we went for it.

Building up a team

My first action was syncing with my DevOps team member. We needed a DevOps person either way and since I teamed with him first, it was important (and polite) to see we’re aligned.

What else?

Part of the competition is presenting the product. Devs are great at technical thinking, but a product is more than that.
So we went on “hiring” a PM.

Not much long back, I got an opportunity to work with another group’s senior PM. She’s professional and direct, and this seemed like a good opportunity to work on another project together.

Is that all?

No. I tried to think of a balance: How much work we’re going to have? How many people do we need?
Take too many people, and we lose focus or people are left “with no work”.
Take too few, and we have no chance of reaching a viable product on time.

We had 2 team leads (Senior developers), 1 DevOps, and the amount of work was estimated at 2–4 developers.
So we reached out.

Part of being a team lead is encouraging my team to participate.
It’s a fun activity (Good food, great vibes), that allows us to bond with new circles and experience new tech.

One of my team’s seniors agreed to join us.
In retrospect, it was great — he had a past with the other team leader (A long time back), which made this even more fun.

Last, but not least

Lastly, another PM had joined us. She had shown interest in the previous idea, and Slack communication was slow.
We asked her to join this one instead, and she agreed.

We now had 1 DevOps, 2 Product managers & 3 Senior developers,

First team meeting

We had 2 meetings.
The first was an interview with our client: our boss.
It was his idea, and we wanted to see that we understand what he expects and what we can bend to reality and our abilities.

Then we met and digested. It wasn’t long, but we rolled with ideas, planned how to first act, and prepared a map of components. A design and a plan.

Now we knew what we don’t know.

Research, and more research

As mentioned earlier, writing the product is not allowed.
While it is not enforced, I think abiding by this rule is important — keeps us focused on our current work, and prevents everyone from ending up in a pre-competition that eats our private time.

But research? Research is not strictly forbidden.

In my previous post, I’ve talked about “Research” in “Research & Development”. The biggest issue I saw us facing in this project is how to integrate with Slack.

Yes, we could start learning on the actual day how to work with SlackBots, but this is soft ground to work on.

The days before actual hackathon day, I started collecting links and suggestions on how to create a SlackBot. I didn’t do actual work on it but I learned some tidbits on how to do things right. (To an extent)

I found the balance between pre-research without actual work so it didn’t affect my personal life or work.

Hackathon day

Our team was ready.
We had a good plan, good research, a good product, and a great team.
We start with reviewing our development steps.
Now that it all felt very close and solid, our Product managers asked questions we didn’t think of initially.
It was evident they see things differently from us and it complemented our perspective.

Our, now sharper, plan was ready. We knew what was a “must-have” and what is “nice to have”.
Both are important to know, as not always everyone has busy hands.
“Nice to haves” are great for that, and sometimes more than just “nice”.

As we talked, we drew our plan on a whiteboard and it helped us focus during the day.

Our Product team started with preparing a presentation strategy & information collection.
We devs have started working per our plan. Each did a different task, so we could work in parallel.

It wasn’t trivial. The research was intentionally not deep, and it took some more research to do things correctly.
But we had a good pace, breakthrough after breakthrough allowed us to overcome tiny details: How should the backend service work? How to work with the result of Slack’s form, etc.

Our efforts trickled to the start of the night, with the team leads taking a break, and the senior developer striding through.

But in the end, we had a working, end to end, solution.
We made it!

And the winner is…

Well, it had to be us.
We did a great job, we managed to provide a working product, requested by upper management (That we devs needed). The presentation was great.
How can we not win?

Well, we didn’t.

There were other great ideas, possibly better presentations, and some judges were more inclined to other types of projects.

So, what now?

First, we shared our knowledge.
Now that the competition is done, sharing knowledge wouldn’t impede our chances to win.

Second, we were all proud of our product nonetheless.
A real win for us is “reaching production”.
We knew some of the winning teams wouldn’t reach that phase despite winning.
We didn’t just work to win. We worked to make an impact.

We expressed our intentions to our head manager and met to present him with the actual product, and what we have.
We learned from him what was an MVP so we can start making an impact.

We also defined phase 2 & phase 3.

Today, it’s already working and serving everyone.

And later?

The first instinct of our senior developer was to share the knowledge before the hackathon started. We decided not to do that, so different teams could approach things differently.

In retrospect? We should have done that.
A real win is everyone getting more progression done.
First place is immaterial, global impact is the real win.

So I’m looking forward to the next hackathon.
My vision is a coalition of teams, sharing knowledge and reaching viable products.
Maybe my team won’t win, but if someone else is making a positive impact, our whole company wins.

Hackathon tips summary

  • Pick an idea you love
  • Pick a team fitting for that idea, and people you want to work with
    Working with new people is also great! This is a great opportunity to get to know them.
  • Plan your steps. Know what you want to do before you start.
    It is true for a startup, and true for a small hackathon team.
  • Research. Find the tools you need for your project, and learn how to use them.
  • Put your plan on the wall. Make it visible so you can look, refocus, and return to work.
  • If relevant, share your knowledge!
    The competition is nice, but the wide impact is amazing!
  • Have fun!

Thank you for joining me on the recollection of my hackathon experience!

--

--

--

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

THM Linux Fundamentals PT 1

Exceptions & Exception Handling in Java/Selenium

Pooling Connections in Node.js & MySQL

Blazor WebAssembly I18n from Start to Finish

What the hell is PostgreSQL’s Bitmap Heap Scan

Torah Community Manager Recruitment: Looking for someone who dares to try!

3 common mistakes companies make when adopting cloud

The Big-O Breakdown

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Ori Nachum

Ori Nachum

More from Medium

Integration of Huawei Analytics Kit and Ads Kit in Book Reading Android app (Kotlin) — Part 2

Voice Command Authentication for a multi-page website using Alan AI

First Phase — Introduce yourself

An exercise with MinIO & Imgproxy