Forketing
About six months ago, I competed in a hackathon in New York City. If you’ve been to a hackathon, you already know the drill. For those who instead spend their weekends socializing and, you know, having wholesome non-masochistic fun, let me lay it out for you.
Hackathons are competitions that can last for as long as a week, requiring coders to build projects from scratch that meet certain criteria. They’re hacking marathons, where, just like a real marathon, your chance of winning is inversely proportionate to the amount you sleep. Suffice to say, Red Bull is probably the biggest beneficiary of hackathons.
Most hackathons rely heavily on corporate sponsorships. In return, sponsors are generally able to collect résumés for recruitment as well as demo their technologies at the beginning of the event, offering prizes to teams that best utilize their respective APIs.
Basic concept, I figured. Hackathons enable brands to recruit talent and crowdsource innovative ideas. But for some organizations, there’s more than meets the eye.
With noble intentions, my team voted to develop our project using sponsor’s technologies with which we had absolutely no experience. At about the time at night that most people on the East Coast reach REM, we finally realized we had goofed badly. About a dozen hours spent tinkering with NoSQL databases had us questioning time and space conundrums, wondering why we didn’t just major in the social sciences.
And then a door opened. Literally.
At about 3AM, two developers from SendGrid, an email deliverability service, came strolling into the room, going table to table. We ignored them at first because we weren’t utilizing their API.
When they made it to our table, one of their developer evangelists, Mike Swift, asked us if we needed help.
No thanks, we said. We aren’t using an email service for our project.
But Swift didn’t just turn and walk away. He followed up with more questions. What were we working on? What technology stack had we chosen? What did we need help with?
He then worked us through our issues, step by step, introducing us to little-known online tools, resources, and best practices, many of which he had contributed to or independently written.
About an hour later, we had a substantially better hold on the stack, finally able to make some progress on our project. The sun had yet to peek over the horizon, so we were actually in decent shape.
It wasn’t until days later – after some recuperation and at least 48 hours of abstinence from Red Bull – that the episode with Swift began to intrigue me.
Why did developers from SendGrid spend hours in the middle of the night to help us and other teams work on projects that had absolutely nothing to do with SendGrid? Given their extensive knowledge of the technologies we were using, didn’t they have somewhere better to be and something better to do? Further, why did SendGrid not mind their developers clearly spending a substantial amount of time and effort forking random projects on GitHub and publishing unrelated open-source projects?
And, perhaps most intriguingly, why was SendGrid one of the very few companies so actively involved in engaging the hackathon participants?
Stack Overflow recently released a new feature called ‘Company Pages.’ The feature essentially gives companies the ability to share their story with the 20,000,000 developers on Stack Overflow’s Q&A site. But, as I learned, the product addresses a much larger trend.
“In the past, we’ve seen a lot of developers use GitHub to fork and contribute open-source projects, which act sort of as their résumés,” says Stack Overflow product manager, Will Cole.
Cole’s team was instrumental in the design and implementation of Company Pages.
“But now we’re noticing a new trend. When talented developers seek employment, they are attracted to opportunities where they can work with other smart developers,” Cole states.
That’s why Stack Overflow built Company Pages – to enable organizations to showcase their talent. A section called “Who you’ll work with?” lets outsiders check out developers on Stack Overflow from a particular organization. Job seekers can evaluate the projects and answers of potential coworkers.
“The funniest thing is that almost no company approaches developers with this strategy in mind,” Cole says with a chuckle. “Most companies are still stuck in having an HR person reach out with an opportunity. They sell them on salaries and benefits, but rarely on having A-team players. Imagine if the company instead led with ‘This is how awesome our company is.’”
Cole’s perspective resonates with me. As the co-organizer of the Rutgers Mobile App Development meetup, one of the largest mobile app meetups on the East Coast, we are bombarded with inquiries from corporations that want to send HR representatives to pitch employment opportunities. The problem is that when they come to speak, everyone falls asleep.
The announcement of the Stack Overflow feature prompted me to reach out to Mike Swift, the developer from SendGrid (he’s since left SendGrid) who helped us at the hackathon earlier in the year.
“We go around helping participants to strengthen our brand. People see me doing something good and they associate that with SendGrid,” Swift tells me. “It builds social capital.”
It begins to make sense.
SendGrid’s unique involvement in the hackathon was to build brand awareness from the inside out. Instead of simply collecting résumés to then pass onto a faceless HR department, as is the prevailing strategy for most of the sponsors, SendGrid utilizes their product team to intimately engage developers.
“We’re in the business of making friends,” Swift tells me. “That’s the gamble — hoping that one day the investment pays off.”
So that was it then. This trend of investing resources to establish expertise is simply a ploy to impress potential employees, I supposed.
Fair enough.
One afternoon at our Agile Sprint planning meeting, our project manager tells the team that it’s time to begin researching email deliverability services. He asks if anyone has any preference for a particular vendor.
Almost subconsciously, I muttered “SendGrid.”
What was that?
“SendGrid.”
Have you ever used it?
“No.”
I don’t understand…how can you recommend it then?
“I’ve met some of their developers and seen random projects they’ve worked on. They seem really talented and I can’t imagine their product is anything less than great.”
Okay, we’ll try it.
Fast-forward – my team loved SendGrid. (Disclaimer: we currently use a competitor but only because we get a discount through an accelerator and we’re cheap, err um ‘lean.’)
If you haven’t already figured it out, I’m about to take things about three steps further.
Was it actually possible that I was driven to recommend a product I hadn’t used simply because I knew the mechanisms of manufacturing said product (in this case, its developers) were reliable? Was this a one-off real world case of mind ninja inception or was there something more to it? If the latter, what does this mean for everything we believe to be true about brand evangelism?
All this time, we’ve let one group of people build a product, and an entirely different group of people market that product. In many cases, those two groups have had little to no direct interaction. In fact, often the product team has specifically been kept away from those who, well, actually want to use the product (i.e. customers).
What if instead of having sophisticated marketers advertise, spam groups on LinkedIn, and pass out data sheets, tech organizations drove brand evangelism by having their developers answer questions on Stack Overflow and fork projects on GitHub?
“If companies are making their technical team part of their marketing strategy to hire people, it’s eventually going to become part of their marketing strategy to get people to try their products,” theorizes Cole. “It’s the next step.”
Now we’re talking. I’m not crazy. At least not because of this.
Swift opens up: “At a certain point, we just realized that having these things, these open source libraries and projects – whether directly or indirectly related to SendGrid – had some sort of payoff. But I think street cred with developers may only be the tip of the iceberg.”
Brand evangelism driven by developers – what a novel concept! So what do we do now?
“It’s really important that we find a way to quantify these initiatives and measure their importance to our business,” Swift warns. “The content that developer evangelists create will long outlast them at their current positions. We need to record and engage these metrics.”
As I’m working on this very hypothesis, our front-end developer begins working on adding client-side photo editing to user image uploading on our site. He’s really excited because he’s found this great open-source library that lays out the groundwork for the task. It’s got issues and limitations, but he’s already most of the way through fixing it and extending its functionality.
“Don’t forget to fork it on GitHub,” I tell him.
He turns to me and asks why. Who cares?
I’m not all that sentimental and thus not very good with ceremonious occasions. I don’t know the channels to consult or how to go about the proper rituals of inventing a word, so I’ll just use it unashamedly until it takes off any day now.
“It’s great forketing,” I tell him.
