On the Thursday of our engineering retreat, I found my new calling as a professional wrestler fighting my way to the top of the Luxor Hotel, in a live streamed pay-per-view event. All this to claim the coveted contract and millions of dollars. My teammates were right there with me, each showing off their skills in their gambit for the top prize.
Only it was a virtual Luxor, and we were playing The World Wide Wrestling roleplaying game (RPG). It was as ridiculous as it sounds, and we had a blast!
Our game day was one segment of a re-imagined retreat, after COVID-19 put the brakes on our in-person gathering in Vegas.
I hope our story can help other engineering teams set up a valuable retreat for fun and profit, even if pandemics or other challenges make meeting in person an impossibility. (Or if you're looking for a new team, we're hiring.)
Setting Goals for Your Retreat
Last fall, our remote company, Olark, had a retreat. The engineering team had a nice breakfast together and enjoyed playing trivia I’d made around our department numbers. But it left me and the team wanting more.
Since our team of twelve had split into multiple product teams, we’d lost the feeling of being one big engineering team, all relying on each other. I thought a dedicated engineering retreat could help bring that back. If you’re curious about the data, many have discussed the importance of connection to your team’s effectiveness. It’s something we deeply support at Olark.
We set three main goals:
- Work on something collaboratively.
- Build relationships and have fun together.
- Have a stronger sense of comradery and togetherness amongst the engineering team.
The coronavirus made us rethink a weeklong group retreat in Vegas, but it couldn’t keep us from connecting and building. We decided on a weeklong virtual retreat, with a few targeted activities:
- A multi-day hackathon
- A game day
- Demos and reflection day
Tips for Setting Up Your Retreat
General Planning
Preparing for a virtual retreat isn’t as time-consuming as a physical one. But it still requires some forethought. A few tips:
Protect your engineers’ space and time in advance. Months in advance, I included the retreat in quarter planning and set expectations with other departments that we’d be “away” for a week. We did a code freeze shortly before the retreat. I also made myself the point person for questions and concerns.
Cover your bases. We still had a team member on-call each day for emergencies, and made plans for addressing outages, etc. (Despite our best-laid plans, a couple engineers did get pulled away to work during the retreat, but that’s the real world.)
Set up your tools, based on your goals. We wanted to insulate our team from normal Slack channels, so we set up Discord for the week to do chat, video, and calls. We used Google Cloud Run for a sandbox-like infrastructure to easily contain the throwaway projects for our hackathon. And we picked a few game platforms like Minecraft and used Zoom for the wrestling RPG.
Consider timezones. If your team is cross-country or international, it could be very burdensome to have everyone be available in the same time zone. I don’t recommend it. We picked one 9am PT check-in time for everyone to align and feel connected, and that worked well for us. Depending on your team, you may want to have one or two scheduled times.
Hackathon-Specific Planning
The hackathon was the biggest activity of our retreat. Here’s what I recommend if you’re setting up your own:
Set realistic goals. Company hackathons can sometimes be bogged down by the idea that “we’re building something for our product.” In my opinion, this is the wrong way to approach one. Hackathons are about working together, inspiring each other, learning new frameworks, seeing what’s possible, and being proud of what you’ve built. We communicated that the specifics of these projects were not meant to be minimum viable products (MVPs), but fun experiments and “what if”s.
No, really. Let’s face it, something you make in 3 days is not going to be able to go directly into production. Let your engineers think outside the box and be excited about their creations. If you have a goal of production, sometimes the new creation just sits there, which can be really deflating to engineers. If you want to go this route, be sure to get company buy-in for working on the feature(s), well in advance of the hackathon.
Connect to company themes. Our engineers drew off two main product themes/problem spaces for our company to keep them grounded. A third component we added was looking at third-party APIs and other services to build on our product and add value. We encouraged engineers to look at what was on the market that they could learn about and use.
Provide structure. We provided a list of guidelines so it wasn’t total blue sky thinking. The last thing you want is for people to get stuck in idea mode. A week in advance of the hackathon, we brainstormed ideas together, then voted on the top ones (everyone picked their top two) to help keep projects constrained.
Group people who haven’t worked together much. We split off our team into groups of two to three, based on who wasn’t as familiar with each other. That way, we started to grow some new team bonds.
Make sure engineers feel successful. Each of our mini-teams had to make a demo that was as functional as possible. On the Monday after the retreat, our engineering team showcased their project demos to the rest of the company. We aimed to make their success point about sharing what they’d learned (rather than seeing their project used in a company product).
What We Built
Here are some concepts we explored. Maybe they can give you an idea of the scope you can tackle in 3 days and get your team’s creative juices flowing.
What if you could transfer your live chat to a telephone call?
- In their mobile app, one engineer put together a flow to “turn this chat into a phone call”
The request went to a Flask app with both numbers
The team explored the Twilio API, SMS, and tracking call state with webhooks
They demoed the chat to call functionality for us
What if you could be notified via a light when your site presence changes?
- One engineer used Pushover to send site presence notifications to his phone
- The other engineer implemented a weblook endpoint
- They demoed how the color of a lightbulb would change remotely based on status: blue meant an agent was offline, green was available, etc.
- The light could also change based on the ratio of chats in progress to available operators
What if you could hook Olark up to Google Assistant?
- One engineer dug into the Google Home API and setting up a dialogue There were some gaps in documentation, but they were able to get things working via Google Assistant mobile app
- Another engineer wired Google Assistant into Monkeybird’s agent service backend to get his agent status via voice
- They demoed getting Olark notifications via voice
What if you could funnel customer interactions from Facebook, SMS, etc. directly into Olark chats?
- Learned about Sunshine API via Zendesk
- The project provides an endpoint for webhooks, then ultimately becomes message our agent client can interact with
- A big challenge was that the model is asynchronous so online/offline didn’t make sense
- They demoed chatting with customers from multiple platforms, funneling into the same platform
We all learned a lot, had fun, and found that there are many cool third-party APIs with the potential to add value to our product in the future.
Lessons Learned
This was our first ever engineering-specific retreat! Here are a few of our best lessons:
1) A remote retreat cannot replace an in-person retreat. It’s unique, but still worth it. Despite having a great time and feeling the retreat was successful, several on my team mentioned they were sad not to meet in person. If you compare your virtual retreat to sitting at the same table with people, it won’t measure up. But if your only (or most viable) option is to meet remotely, it’s very much worth the time and effort. They’re different vehicles. Maybe your team is struggling and you need a reset to build collaboration. A remote retreat could be a quick way to get things going, and you could probably set it up in a month.
2) Connecting with the whole group daily is crucial. Right before our retreat started, one of our engineers suggested we do a morning coffee time. I thought it was a great idea and set a video chat meeting at 9am PT. It gave us half an hour every day to sync up with the entire team, hang out, and chat. Otherwise, people were working at different times on their hackathon projects. The coffee break turned out to be critical. If we hadn’t had it, engineers would have felt more connected to their own project teams, but not necessarily the whole team. It was also a breath of fresh air… engineers would go out in their backyards and we got to see some landscapes. One even biked out to a creek to take the call!
3) It can be tough to achieve separation from normal remote work. We switched to Discord to try to insulate our team from the daily remote grind. It was worth trying, but got mixed reviews. Many felt like it was just another chat channel they had to keep track of. Achieving separation is an issue to be mindful of if you’re already a remote team. It’s easier to do if you’re colocated. How can you make the retreat feel like a real “retreat”?
4) It’s not frivolous to have multiple fun days! (And not everyone will want to play the same game.) Our game day was really fun, and the day before it we also took our coffee break in Minecraft. We ended up spending a full hour walking around, building houses and teaching people to play (by the end people were also blowing things up). One engineer hosted and prepped our wrestling tabletop RPG that I mentioned earlier. Engineers thought it was great for connecting, and wanted more! One thing I realized was not everyone was interested in playing either of those games. Some didn’t participate, and that’s okay. In the future, I’d add both more time for games, and more options that people could select from.
5) Hackathon demos get people’s gears spinning in the best way. This was something we suspected, but our experience bore it out. When you see things working, it’s not just someone talking theoretically. You can see our chat product interact with an API and, say, make it into a phone call. It’s tangible now. Your team may not actively pursue the specific project, but it gives them exposure to other ways of potentially solving your customers’ problems and where they might start with an MVP.
Final Thoughts
All in all, the retreat was a big success! We were able to connect and make neat stuff, and felt way more like a team after than going into it. And with all that’s going on in the world, getting a reprieve from the stresses of normal work was also a welcome reset for engineers. I know this event will have positive ripple effects on us in the time ahead.
I’ll leave you with a few thoughts from the team (and yes, we have a lot of Nicks on our team):
Nick Hill said, “I got to step way outside of my comfort zone and play with a bunch of stuff I’d never played with before. I think that’s the whole point of these hackathons. I learned how to use GraphQL queries against an agent service backend, and got to dip my toes into NodeJS for the first time. It was a lot of fun!”
Nick MacInnis said, “Good times, really appreciated the mental break from normal work.”
Hector Urtubia said, “Playing Minecraft together was a blast. It definitely helped us build camaraderie. Also Olark Wrestling RPG was a total smash.”
Have you held a remote engineering retreat? What would you add?
Interested in learning more about what we do at Olark? We are looking for new teammates to help us build people-first software for small businesses.
