Developer Relations for Your Internal Engineering Team 🤓💪

How and Why Hologram.io Srsly Loves Internal Hack Days

Developer Relations/Evangelism/Advocacy (DevRel) is a person or team dedicated to building a developer community around your product or service. It is an exciting role which bridges many departments (Engineering, Marketing, Strategic Partnering and even Sales). Most of the code helper libraries, tutorials, event talks, meetups, hackathons and technical partnerships come from these folks.

^ What a typical DevRel person looks like ^

So yeah, I think DevRel rocks. I love developing and those who knew me from the MeteorJS world know I also love playing a part in developer communities, always am stoked for public speaking, dabble in marketing and enjoy the mental stimulus from negotiating partnerships.

Check our Hologram.io and reach out to me to get hooked-up with some credit

A few months back when a DevRel opportunity came available I jumped on it and joined the awesome team at Hologram.io building cellular communication for IoT. What follows is a portion of my journey joining this team.

The Challenges 😬 … I Mean “Opportunity” 😇

There were a number of mountains needing to be climbed.

  • Full-time DevRel was new to me (future post on how I hacked it)
  • The Hologram team was new to me and I wanted new BFFs
  • Was familiar with IoT but not personally established in it’s community
  • Hologram has a killer platform but only had a handful of integrations
  • As with all startups, your runway is very real
  • We need to create helper libraries, content and partnerships now
  • The Hologram team is srsly stacked with amazing engineers but everyone was hustling on their own backlog mountain

To sum it up we needed to ramp up content and libraries creation and one man (me) could not do it fast enough alone. I needed more 🤓 💪 without negatively affecting our runway. It was time to apply some DevRel tricks!

The Solution 📈

DevRel is all about congregating and motivating external developers. I thought to myself, “self, how can I apply what I know about external DevRel and encourage my awesome internal team?”

Then it came to me… do a typical DevRel hackathon, but for my internal team only! I know what you’re thinking, it is genius! 🙄

All geniuses have convos with themselves, ex: Brian Finch in Limitless

So we launched an internal Hack Day and have been iterating on it for a few months. Hack Days have become an integral part of our company but it took a handful of adjustments to hit a good stride. Here is what we found for getting the most out of internal Hack Days.

Internal Hack Day Tips & Tricks ⚗

Purpose: First thing first, Hack Days need to make sense to it’s participants. How did we convince peeps of our fast pace startup to take time for “hacking”? It was harder than you would think. Our team is so dedicated to improving our platform many of them find it difficult to switch gears. Here are some tips that instilled purpose into our Hack Days.

  • Clear value proposition: Define what need these Hack Days have the potential to meet. To my team I found they valued leveling-up their own skills in prep for an upcoming sprint and/or working on something that has the potential to directly affect our future product offerings (R&D).
  • Get executive promo: At our weekly all-hands meeting the CEO, CTO and myself reiterate the value props for these events and highlight great examples.
  • Be flexible: Hack Days are advertised as a whole company thing and everyone is heavily encouraged to participate but we purposely make it optional. I find the more we make non-participants feel appreciated (being aware of any perceived shaming), the more likely they’ll participate when available. Remember, if they are not doing a Hack Day it’s because of working on our platform. They deserve appreciation.

Awesomeness: Second thing second, Hack Days need to be awesome. Everyone should know how to make events awesome, here are some of my ideas.

  • Free lunch: Normally everyone needs to fend for themselves come lunchtime but not on Hack Days! This is also a great time having everyone taking a break together. Food = Joy!
  • Encourage teams: Naturally people will work alone on their wild ideas. As a facilitator I manage a spreadsheet of Hack Day projects each member is interested in. I try to connect the dots between these proposed projects, forming teams around a consolidated project. It is not always possible which is fine. Don’t go it alone!
  • Show appreciation: The following business day after Hack Day we have a 30 minute show-n-tell meeting. It has been super cool seeing all the encouragement teammates give to one another. From my end, some projects become candidates for content. Creating content around one of my teammate’s creations is an awesome way to show appreciation.

Content: Developers really like to develop but most aren’t as thrilled about creating blog posts. We learned this the hard way. Our very first iteration had one day a month as Hack Day followed in two weeks by a Content Day. Lets just say Content Day was not very popular and required too much management. We eventually dropped Content Day in favor of adding more Hack Days to a month. There really is only one tip for this topic…

  • Don’t force content: We separated content creation from Hack Day and put it on the shoulders of those whose job is creating content. We appreciate when peeps make their own content but it is no longer required.

Management: People are creative and when given a Hack Day they can think of some really crazy shit. Thats cool but there needs to be a balance so goals can be met whilst having a crazy fun time.

  • Find your cadence: We do Hack Days every other Friday (90/10 time). Eventually we may get to a point where it is every Friday and achieve an 80/20 work schedule. For now every other week turns out to be our sweet spot. Any more would be an annoyance and fewer would slow the momentum of ongoing Hack Day projects.
  • Publicly track projects: we have a public spreadsheet listing each project and tracking various details about each one. Teammates are encouraged to update it before each Hack Day. This is a huge help to track and identify any projects or teammates who might need extra support.
  • Define project categories: In life a person needs goals and goals need structure in order to see it accomplished. I have goals for Hack Day (results section below). I use categories as a major tool for structuring projects to meet my goals. Here are the categories we currently use: [ “OSS Library/Integration” , “Training/Experimenting” , “Creating IoT Tut/Kit” , “Creating Other Content” , “Other Platforms Research” ]
  • Prep and advertise: Make sure to remind the team when Hack Day is coming up. Ask peeps to update their projects in the shared spreadsheet. Reach out to each team making sure they have the tools needed to execute. I rush order anything they may need so Hack Day can be as smooth as possible.
  • Show-n-tell meeting: I talked a bit about this before. In addition providing encouragement it gives me a chance to check in with everyone, take notes and update the project tracking spreadsheet.

Results: My fingers are getting tired so I’m gonna make this short. How we define value and measure results…

  • Team cohesiveness: Peeps are closer, fewer conflicts in normal stressful day-to-day operations.
  • Better educated team: Teammates feel confident estimating tasks since they had time to play around with technology thats new to them.
  • Larger public presence: Ultimately as a company we want to grow our OSS libraries and repos, have more content and create stuff to socially share.
  • Happiness and excitement: And the biggest impact is joy. Hack Day gives us the much needed break we need from the daily grind. If we conduct Hack Day correctly it should be a day of intellectual refreshment.

Going Forward 🔮

I’m sold out on the idea of Internal Developer Advocacy (👈 is that a thing, can I coin that phrase?). About 20% of my efforts going forward will be going towards empowering and serving our internal engineering team. The benefits has proved to be foundational.

Hope this has convinced you to take the pill and do some Internal DevRel

I’m thinking of doing a bi-weekly blog post following each event discussing any iterations we make and a roundup of projects. Should I do that?

👨: “Yes do it but loosely commit, you do not want this to become a ball-n-chain.”

👱: “Thanks self, that sounds perfect.”

Ok so stay tuned for upcoming, potentially sporadic, posts about how awesome our Hack Days are going.

P.S. Watch Limitless the series on Netflix. One of my favs!