How to engage engineers in a fully remote company

The key to creating connections, we’ve found, is to invest in team building—to make it one of our products. This includes a focus on transparency and investing in ways to communicate effectively across distances, but it also involves bringing our teams together in person. These meetups include working sessions, training, and, of course, some time just to connect and get to know each other. These get-togethers are a tried and true way to build relationships, but it’s important to be purposeful about them.

To that end, we ditched the usual slide decks for our most recent engineering team get-together and decided to hold a hackathon. What follows are the goals, plans, and structure of the event—as well as some challenges we faced—in hopes that we might inspire you to do something similar.

If you’re a fully remote organization, or team that’s struggling to bring employees together in a meaningful way, it’s worth considering. Not only did our hackathon inspire some of our most innovative ideas and bring us all together, but it also created some of my favorite memories as an engineering leader here at Moov.

Our goals for the event

We started by creating some high-level goals, ensuring that we addressed our pain points, and set some guidelines for what we hoped to achieve. For example, one of the challenges we were dealing with as an engineering team was rapid growth. In the six months prior to the hackathon, we’d more than doubled in size to over 50 people in Engineering. This meant that there were a lot of folks who were pretty new to our company, platform, and processes—but Moov also had engineers who’ve been with us from the beginning. We wanted to create an opportunity for each group to learn from each other, get more comfortable as a team, and build relationships beyond work.

1. To connect across teams

As a fully remote company, it’s easy to work in a silo with only your direct team. For this event, we needed to assemble groups of people who didn’t normally work with each other. We also wanted to keep our teams small enough to be close-knit and give contributors opportunities to take ownership of their work, but big enough to be functional and have a diverse pool of expertise.

2. To make the work matter

When you get a big group together to work on something, you want it to matter. Instead of bringing everyone from across the country to simply brainstorm ideas, we decided a hackathon could inspire our engineering team to build real solutions that would create real value for the company.

We decided that the hackathon would focus on projects that could address current real-world business challenges that needed to be tackled—and we used these goals to help determine the criteria for how we’d evaluate our teams’ projects (more on that later).

And, of course, we needed to be sure that the challenges could be addressed with projects that could be completed quickly over just a few days.

Our plans for the hackathon

While our engineering team has grown a lot, we’re still a fairly small organization with limited resources. It took a fair amount of time and planning to bring this all together in a way that addressed the goals above. Here’s how we made our hackathon happen.

1. How we brought everyone together

When your business is spread across more than a dozen states, it takes some planning to get as many people as possible in the same place at the same time. Flights, hotels, workspace, food—there are a lot of logistics to manage.

In our case, a lot of our folks happen to be in or near Denver. It’s also a place the people planning the hackathon were familiar with, and where we have some relationships with various vendors and office spaces. So, for us, Denver made perfect sense as our location. It’s also a city with fantastic opportunities for fun and food—and we wanted to be able to treat our teams for all their hard work.

Great location aside, we wanted to make the event accessible to those who couldn’t join in person. While we missed seeing some of our teammates face-to-face, we were able to bring together 51 Moovers in Denver, with another 12 attending remotely. We made sure to build the remote option into the agenda and program, ensuring we had the right technology and AV support.

For remote technology, we made sure the space offered large screens to make virtual attendees visible to everyone—not just through their teammates’ laptops. We also made sure our technology allowed remote contributors to lead teams and present solutions. Having that face-to-face interaction, even with those remote, really ramped up the energy and engagement for everyone involved.

I have to give a big shout-out to Rah Chalmers, our Executive of Administration, and Tammy Smith, our Accounting and Operations Manager, for their help putting all of this together. They handled a lot of prep work and brought a ton of positive energy to the event. Not only did we have all the essentials we needed to hunker down and build, but we also had a positive atmosphere in which to both collaborate and celebrate our shared successes.

2. How we built the teams

Payments is a complicated industry. Our engineering team works across a lot of different pieces of the payments puzzle—from card issuing and bank rails to ledgering, wallets, compliance, and more. To create cross-team collaboration and expose developers to products and concepts outside their daily purview, we took time carefully crafting our teams.

To accommodate our new employees, we made sure to spread out different types of expertise and varying levels of experience with our platform. The goal was to cross-pollinate in every way possible and essentially turn every team into a “super group.” We designed each team to include seasoned members with advanced permissions and product knowledge alongside newbies with fresh perspectives, then added a mix of skills from different feature teams. And just to ensure plenty of access to experienced folks, our principal engineers floated around to help advise teams and get them unblocked quickly.

Admittedly, building groups like this was tricky. For example, we had eight hackathon teams but only four front-end developers—so our front-end folks had to be on-call if other teams needed their input. We could’ve solved this by having fewer and larger teams, but at the end of the day, we wanted to make the smallest functional groups possible in order to create close-knit teams that would really own their work and depend on one another to get things done. So, we kept it small at five or six people per team.

Finally, we were very deliberate about mixing the old guard with the new. If you stack a team with a couple of seasoned veterans, for example, they may end up unintentionally excluding less experienced teammates. We wanted to give everyone the chance to step up and step out of their normal roles and team hierarchies. The point of a hackathon, after all, isn’t to mirror workplace dynamics. The idea is to empower everyone to share their experience, to open up the way they contribute, and to give them space to be creative.

Here’s an example of how we organized our teams:

• Team lead
• Front-end developer
• Back-end developer
• Infrastructure developer
• 2 engineers from different teams
• Principal engineer (these floated between teams as needed)

3. How we created goals for the projects

Work for the sake of work doesn’t inspire good work—or good working relationships. We didn’t want to get everyone together just to shovel dirt. We wanted to give them the chance to add actual value.

To determine what that value might be, we gathered a group of seven expert judges from our leadership team. We included people from product, finance, operations—all leaders who were very close to our business challenges. Inspired by the words of our VP of Product, Josh Sadler—“Fast is the best feature we could ever ship.”—we arrived at this goal: To find ways that will help the business go faster.

Then, before the hackathon, we set up a Slack channel to ask our judges about business pain points and what types of solutions would benefit them or our customers. There, the entire engineering group had the opportunity to join in the conversation, ask questions, and start thinking about potential projects.

Here are the business challenges our leaders identified:

• Eliminating toil through automation or tooling
• Removing manual work
• Reducing communication latency with customers
• Improving an existing system or service to make it better for its audience

We left the actual solution decisions to each team, allowing them to determine exactly how they would solve these challenges. Since all of the participants were in the same conversation with the judges, we assumed some of the solutions might overlap a bit—or be variations on a theme, which is fine. Some projects would likely work together and act as different legs of the same stool. Or we might be able to splice together the best parts of several projects later on.

4. How we judged the projects

Before we started, we asked the judges to define the criteria they’d use to evaluate our teams’ solutions, and here’s where they landed:

• Value – The solution provides either external value to our customers or internal value to other areas of our business.
• Innovation – The solution solves an existing problem in a new and meaningful way.
• Execution – The solution is well-polished and could ship today or is a solid start to a larger effort.
• Scalability – The solution will inherently scale with the business, resulting in little re-work in the future.
• Complexity – The solution has the appropriate level of complexity to solve the problem without being overly complicated.

Each judge would award teams a score between one and ten in every category, with the three highest cumulative scores winning the first, second, and third place in the hackathon.

A note on expectations: Hackathons have a reputation for pushing developers into long, sleepless, caffeinated days and nights as everyone tries to cram as much as possible into the competition—but we made it clear that no one gets to pull an all-nighter. Humans have physical limitations, we all have non-work obligations, and we didn’t want to create a demand for heroics. At Moov, one of our org-wide values is to “respect the craft,” and that includes consideration for the folks doing the work. Also, when all is said and done, working two days straight doesn’t necessarily produce the best results—and breaking developers is no way to build teams.

5. How we structured our agenda

On day one, the teams kicked off their hackathon projects remotely by gathering and sharing ideas—all based on the business challenges the judges had outlined. This remote time helped ensure that, once they were all together in person, they could hit the ground running and really focus on building and iterating.

When everyone arrived onsite on day two, we had a brief kickoff, re-introduced our judges and reviewed goals. We gave the floor to the teams to ask questions, then they got started. Our engineers worked from 8:30 am on a Monday to 2:00 pm Tuesday, with plenty of time for breaks, food, and getting to know each other. It was inspiring to see our unique teams coalesce, connect, and collaborate.

To help our teams organize the presentations they’d make to the judges, we gave everyone a slide template that outlined the “anatomy” of a hackathon presentation—from an explanation of the project and its value prop to a demo, conclusion, and Q&A. Teams were given seven minutes to present their solutions and respond to questions.

Moov’s leadership and judges were all floored by the ingenuity and collaborative spirit we saw. It was like magic happening right before our eyes. It proved how incredible our people are and reminded me how lucky I am to work with such talented contributors.

The solutions were thoughtful and well-crafted, especially considering the time constraints. It was clear that the relationships between teams were stronger than ever. So, even though the judges had to pick three winners, it was pretty clear that, in some very important ways, we all won.

As for the actual hackathon winners, the judges tallied their scores after all the presentations were done and the teams who came in first, second, and third place were awarded cash prizes. Then, it was time to celebrate their victories and our collective accomplishments.

We spent the remainder of our time together taking a much needed break and blowing off steam. We had a big get-together for everyone, and the venue included lots of activities like board games and a golf simulator; everyone had a chance to try it all out or to just sit back and relax. That night I felt really grateful at our after-hackathon party. It gave me time to digest how much we’d just built and the problems that we’d solved in just a few days’ time. I have to say that this team is amazing!

What Moovers had to say

“I enjoyed engaging with the teams, sharing pain points and pieces of what I do every day—while also getting to learn more about their creative processes. So much takes place behind the scenes that it’s easy to forget how much talent and hard work our engineers bring to the table. It was a real privilege to be a part of it.”

“This was, hands down, my favorite team-building experience while working at Moov. I’m always a sucker for a challenge, but what I really loved was getting to meet people I’d never worked with before. In a remote environment, it really made me feel more connected to the Moov team at-large. When you get to interact with people from other teams, it really gives you a sense of camaraderie—and it’s exciting to know we’re all in this together, working to make Moov great!”

“The Hackathon was a terrific way to bring the whole Engineering organization together in one spot. We had recently added a number of new people to the team, and the Hackathon was a great way for people to connect and learn firsthand about Moov. It also provided an opportunity for people to collaborate with others outside of their teams. It was awe-inspiring to watch them work. The solutions they came up with were fantastic. They made our jobs as judges very challenging. I’m also happy to see that much of the work done during the Hackathon ended up being the seeds for larger scale projects.”

Why it worked

Unlike some companies, Moov didn’t “go remote” when lockdown occurred. We were built to be fully remote and we’ve done it well because we’ve invested in it—not just on the tech side, but with learning opportunities and home office stipends, plenty of interaction via Slack, and with virtual and in-person meetups. It’s been important from day one that our remote culture creates a level playing field—no one gets left out of the room, because we all have equal access to the same people and resources. And radical transparency is one of our core values. In short, we practice what we preach—the sharing of knowledge, expertise, and access.

All that said, the on-site hackathon was a perfect way to level up our remote collaboration. It was targeted time, apart from a lot of the day-to-day putting out of fires that we all get caught up in. It was fun, it was exciting, and it was a chance to be creative. And I’m really proud of the work our teams did and the way they came together to get it all done. Our real goal was to help everyone recognize that we can work better and be better together, whether we’re doing things remotely or in the same location. From that point of view, it was a huge success.

This kind of team building, like our remote culture, is an investment. The hackathon took time and effort and a lot of thought. And, like remote work, there are a lot of ways to do this sort of thing poorly. But by getting leadership aligned, setting clear goals, presenting opportunities to add value, and supporting the engineering teams throughout the process, our hackathon exceeded our expectations.

If you’re considering a hackathon or just looking for ways to engage in team building, I hope this has been helpful. If you’re interested in learning more about Moov’s approach, we’ve previously shared some thoughts on how we think about our engineering culture. Our team has also been recognized for our fully remote culture.

Or, if you’re looking for new resources for your dev team, be sure to check out our docs and developer tools. If you have any questions about this hackathon, or anything in general, feel free to message me on our Moov Slack channel.