Why Project Managers Should Attend Hackathons Too

A few weeks ago, Viget hosted a Pointless Weekend. A “Pointless Weekend” is more or less a Viget-only hackathon. Those who want to participate gather together, brainstorm and select an idea on Thursday, and then spend Friday and Saturday making that idea happen.

Hackathons are pretty common these days and, if you’ve ever attended one, you know they are typically full of developers (front-end and back-end) and designers. Everybody involved is actively participating in the project and making sure it launches. Project Managers (PMs), on the other hand, are usually not found at hackathons which, if nothing else, is a shame for the PMs themselves.

I (a PM) participated in Viget’s Pointless Weekend in the Boulder office. I was part of a team of 3 developers, a designer, and another PM (and all of us teamed up with additional developers and designers located in our Falls Church office). I knew I could provide value by at least coordinating food and beverages (including Saturday morning mimosas); but, I wasn’t sure where else I could contribute. I’m not a developer, per se, and I might be even worse on the design side of things.

I was able to step in as a tester -- and, overall, I helped move things forward in typical PM fashion. The other PM involved here in Boulder was instrumental in actually creating the chromatic scales of the tones we used … but, that’s not why I think it’s important for PMs to participate in these events.

On client (or formal internal) projects, PMs provide value and are necessary because there are many constraints. Projects have budgets, timelines, specific requirements, and, usually, a set user base with expectations. We need to know all those constraints and help the team focus on the right things based on priorities. Events like hackathons, on the other hand, typically have one constraint -- time -- and the team members working on projects usually have a good pulse on it. They have an idea of what they can accomplish, and they seem to instinctively know when to move on from what they are doing in the interest of time. Many projects at hackathons are successfully launched without project managers.

So, then, why should PMs attend?

Watching the team work and communicate

During a normal work day, everybody is busy. We all have deadlines, things we need to do, and meetings we need to attend. So, understandably, we can’t be everywhere at once. Team members (hopefully) communicate with each other as they need to, and we aren’t always present (or able to fully digest the back-and-forth). What sort of conversations do the FEDs and DEVs have? Where do they need to collaborate and when do they need to just hunker down and work? What information is useful for a Designer to get going or for a FED to start integrating designs?

Going into this weekend, I felt like I had a pretty good understanding of those questions; but, coming out of it, I know I do. There’s no substitute for being a fly on the wall in those collaborative conversations. Simply listening gave me a better understanding of what I should be thinking about team communication-wise in my upcoming projects (including how I should be communicating myself).

Learning about the tools and technologies teams use

Certainly, we all feel the stress during a hackathon of trying to get something launched by the end of the weekend; but, that sort of timeline stress is not nearly as poignant as deadlines associated with client work. During the typical work week, many team members are actually working on more than one project at a time and have a looming deadline they need to focus on. That means asking questions that are strictly for our own benefit isn’t always a good idea. This means I can’t always ask someone to take the time and go through an in-depth description of what a new technology or tool is. At hackathons, not only does everyone seem to have more time to go into the details; but, in a lot of cases, they also need to explain it to each other -- so, it feels more of a natural conversation. I learned about some different uses of JavaScript and a new language elixir and know enough now to be able to participate more actively in conversations on future projects.

Team bonding

I’m a big believer in getting to know the people you are working with and in helping teams bond and come together, especially during tough projects. Still, bonding over tough projects or simply a beer after work isn’t the same as coming together and all working towards a goal we’ve defined and are passionate about. We didn’t create our new app for a client or for an internal stakeholder: we did it for us. This type of team bonding is tough to replicate in other environments and is a significant benefit of attending hackathons that your coworkers are going to. If your company doesn’t provide this opportunity, look for a hackathon in your area and get a team of your coworkers to go. You’ll get to know each other better, and you’ll likely walk away with a great experience.

Nobody wants to feel like an extra wheel or feel like they are getting in the way; but, sometimes, the answer to “why are you here?” is simply “to learn and get better,” and that’s okay. Everybody can bring value, even if it’s not immediately obvious, and sometimes that true value-added is most clear days and weeks down the line when we’ve improved our role and work as a result of our experience.