Learning is not just something we enjoy; it is an integral part of our jobs as consultants. It is how we keep on top of trends and new developments in the industry, many of which influence the work we do for clients. Every year around the holiday season our development team plans a whole (or half) day meeting to catch up, discuss the year in review and make plans for the future. During this meeting, we often run small workshops where members present topics to the rest of the team. However, we decided to do something in 2016 that would let us: Capitalize on having (almost) everyone in the same roomFocus more on collaborating togetherProvide a risk-free way to experiment with tools we’ve discussed throughout the year To accomplish all of this, we held a half-day hackathon. What is a hackathon? “What is a hackathon?” you ask, “Sounds suspicious.” A hackathon is an event where individuals or teams collaborate on a programming effort. In nearly all cases, these are fun projects that aren’t necessarily meant to be used in any type of production setting. This was the case for our hackathon. What did each team build? Group 1: A tool to make coworker time-off data easily searchable within our internal messaging platform.Group 2: A test web application that enables users to play videos from YouTube or Vimeo in an uncluttered environment.Group 3: A prototype for a mobile web application that enables users to quickly access relevant, local data such as weather and access to SMS messaging. Specific hackathon goals Our main goal wasn’t to create “production-ready” projects. Instead, we focused on team- and skill-building that would translate into benefits we could pass onto our clients. Specifically, they were: Discover new and better ways to collaborate with each other (remotely and on-site)Encourage team members with different specialties to work with and teach one another new skillsProvide teams with a creative outlet to come up with project ideas that had no set parametersThings we learned The hackathon provided some insight into a number of things—some of which were unexpected and revealed some insightful things about our development processes. Think critically about “must-have” vs “nice-to-have” features. The four-hour time limit forced us to think about which components were essential to our projects and which were enhancements we could add later. This approach encouraged us to prioritize functionality over flashy features. A good example of this was the YouTube video player. It was crucial that the player could successfully play videos, pause and show a progress bar. However, speeding up or slowing down the video playback is an enhancement that could come at a later time. This is good practice for planning and executing projects for our clients—especially those on tight budgets or timelines. Understanding this helps us determine the absolute essentials of a project and identify the features that can add value down the line. Accurately estimate time needed for each project. We also learned to be wary of when we might be underestimating time needed to build out projects. Before the hackathon started, each project was approved on the idea that it could scale depending on how much time developers had. If there was little time, the base project would have value. If developers had additional time, the project could scale and add extra features. We found each project took longer than expected, so teams had to focus on building essential functions rather than scaling features up front. Additionally, each team used an API to interact with services like Slack and YouTube. However, getting these set up and functioning took—on average—around an hour or more. This left little time to add extra features and troubleshoot problems. This is good knowledge to have when estimating time for client work, especially for projects that involve multiple integrations. Expose team members to using APIs to send and receive data. Many developers don’t interact with APIs on a regular basis, so this was a perfect opportunity to expose our entire team to the process of connecting to and using one. When something wasn’t working properly, everyone could get involved and make attempts to troubleshoot the problem; it was a great team-building exercise. It also helped our developers who use APIs less often become more familiar with the process of authenticating and pulling data from the endpoints. Experiment with new tools by working on a no-risk project. Because we weren’t concerned with timelines or budgets, we had the freedom to try out new tools. Giving our team sandboxed projects allowed us to safely experiment with these services with little repercussion. This was an opportunity to explore brand new tools as well as to get more acclimated using some we are likely to use for future client work. The hackathon enabled us to work together and utilize tools and techniques we hadn’t applied before. It helped the team think critically about working under a tight deadline and how to focus on the essential pieces of their applications. The lessons we learned translate to skills we can use to help clients—including helping us to become a more collaborative team with a more seamless process. We certainly plan to do this again, perhaps even at a larger scale, with a longer timeline and with other teams. See what else we're building in The Workshop.