One of our core values at DataFox is empathy. We are driven to understand our customers’ problems first-hand and solve them. But how do you inspire empathy in the people who build your tools when they are not the target customer of your product?
We have a solution: empathy hackathons.
Hackathons have gained popularity in the last 10 years. They are usually a 24-hour period where engineers are free to hack together anything they like and then demo it.
Engineers love hackathons because it lets them exercise creative freedom and explore new ground. CEOs love hackathons because they create an explosion of new ideas. Marketing and sales love hackathons because they show off lots of new things to pitch.
Hackathons are amazing because they unleash engineers to creatively tackle problems. But which problems do they tackle?
The ones they know about, of course. The most obvious issues are the ones that engineers face every day. Of course, there’s nothing wrong with engineers solving their own problems; it can be great to speed up the build system or pay down some tech debt. But those aren’t customers’ problems.
So how do you get engineers to solve the right problems?
That’s where the empathy hackathon comes in. Rather than just turn the engineers loose to do whatever they want, we first spend a day teaching them firsthand about a customer pain. This gives them a host of problems to solve when it’s time to hack.
First we give the hackathon a focus area. Some examples:
- Customers in a sales prospecting role
- Internal tools and the people who use them
- Power users
- API clients and 3rd party developers
One engineer is then designated to coordinate the hackathon. First, they work with customer success and sales to plan a structured “empathy day” where the engineers learn about the target user and are trained do to do the work firsthand.
For example, Jon, our senior data ops manager, trained all engineers to use our news auditing tool, just as he trains our remote workers that use the tool. Some of these engineers had built the tool and knew inside-and-out, but they were also quite surprised by the exercise. Suddenly small bugs in the UI became massive hurdles. Performance lags felt painful. And we finally understood why the remote workers were so obsessed with tsv files.
The impact of the exercise cannot be overstated. Doing the work ourselves created empathy. And once engineers empathized with the requests, they got done. We spent the next day hacking away, building a handful of features and fixing dozens of bugs.
Running Your Own Empathy Hackathon
Here’s our recommended steps for an empathy hackathon:
Pick an engineer to organize. You can have multiple organizers in a large group, but pick one person to be ultimately accountable.
Pick a focus. This should be informed by customer and business needs.
Find allies on other teams. If you’re focusing on a customer problem, find advocates from sales, support or customer success to help teach engineers about the problem. This is a lot to ask, so make sure you explain how this will help them do their job and make their customers happy. Don’t forget to thank them for all their work!
Set up a training day.
Set up a hackathon, ideally 48 hours after the training day.
Demo to the results to other engineers and the company!
Making the Training Day Work
The key to a good training day is structure. Don’t just get people in a room and improvise. Engineering time is a valuable commodity. If your team comes out of the training knowing what your customers need, then this is worth it. If you just talked about problems, then you wasted a lot of time and money.
Have a schedule. Start with a overview from someone like the head of customer success or sales. Keep it short. The goal is to provide some context for the day: Who are these customers? Why do they matter? Get everyone pumped up to dive in!
Then break into smaller teams and do a two hour exercise. Ideally, have an in-house expert train the engineers. When we focused on sales reps, we sat with our outbound team as they used the tool to prospect. Get as close to the customer as possible. Let the engineers watch the experts and ask questions. But most of all, make the engineers do the work. Yes, it will be frustrating. Yes, it’s probably something they don’t want to do. (No, you don’t actually have to make engineers do cold calls.) But that’s the whole point: make engineers experience the pain firsthand.
Don’t be surprised if this two hour session does not feel productive. You should run into a lot of roadblocks. That’s the whole point. Remember that you’re trying to train engineers to do a job others spend weeks or months learning. Don’t worry if you fail to complete the task or are slow. But you should try.
Then break for lunch. (Make sure you provide food!) The goal is to get everyone to sit together and discuss what they’ve experienced. It may sound like complaining, but this is where ideas start to percolate.
In the afternoon repeat with another two hour session on another task so you get more exposure.
Lastly, wrap up with another quick pump up speech. Don’t worry if the engineers look frustrated and upset. This is how ideas form. No bug gets fixed faster than the one that annoys an engineer.
Making the Hackathon Work
I suggest putting 24-48 hours between the training day and the actual hackathon. This is enough time to let everyone sort through their ideas, but not enough time to for the inspiration to fade away.
At the set time, set off the firing gun and start the hackathon. Personally, I’m not a fan of all-nighter hackathons, but if that’s your speed go for it. Basic hackathon rules apply: engineers should not be interrupted by other teams and day-to-day tasks.
When the 24 hours (or whatever you choose) is up, make sure you celebrate. Ask everyone to demo their solution. If you’re on a large team, you may want to ask everyone to record a 60 second video just to streamline the process (this is also nice for letting others watch it on their own time).
If you want to assign prizes, then do so, but be careful that monetary rewards don’t overshadow the empathy. Remember, the point of a hackathon is that engineers love the chance to solve interesting problems and be recognized for their creativity. Making the event about competition and money can have the paradoxical effect of de-motivating the team. Instead, make the focus about the customers you are helping. If possible, make sure they are there for the demos. Don’t underestimate the power of a simple thank you coming from an end user.
It is always a challenge deciding what to do with the ideas from a hackathon. Some may be purely experimental while others are almost ready to be deployed. This will depend on your product prioritization process. We prioritize smaller features and fixes in the current sprint to ensure we maintain momentum. We also do our hackathons shortly before our quarterly planning so larger projects can be prioritized in the next quarter’s roadmap.
I hope to see other teams adopt this approach. Please tell us your results!