Hacking Recruiting by Peter Soderling - Transcript on Engineering PR

Announcer: Okay, so our next speaker is Pete Soderling. He is the founder of G33kTalk, which is—I don’t know, I guess, I think it’s going to be like a multimedia empire in a little bit, but he has a really good mailing list that sends out some really interesting articles, mostly technology  articles, a little bit on technical leadership, as well. I’m not sure how he does it, like he operates both in New York and San Francisco. He actually records meetups, and so he puts some of the videos up on his website, as well. And so, he’s certainly somebody that’s very much embedded in the community. He gave the—well, a longer version of this talk at QCon, because recruiting is also something that he is good at in addition to multimedia and stuff. So, without further ado.

Pete Soderling: Thank you. Hey, guys. You’ve been sitting here for a while, so I’ll try to keep it to the point. I want to introduce you to the concept of Engineering PR. First of all, who am I, and why the hell am I up here? I’m an engineer from the first bubble, a hacker before that. I turned programmer in the mid-90s, and I ended up turned entrepreneur in 2003, so I’ve seen and hired lots of engineers over the last fifteen years, and now, I do consulting with top startups in New York and the Bay Area, and the CTO’s directing, helping them figure out how to build the best engineering teams. I’m also the founder of G33ktalk, as John mentioned, Keith mentioned, and now, I’ll tell you more about that, as well.

So why should you care about hiring? If you’re an engineer who’s already in leadership, you know exactly why because it’s important to build the best team. If you’re an engineer who wants to get into leadership, this is the single most important thing that you can learn that you might not already know. I do a lot of career coaching with engineers, and, being originally a self-taught engineer myself, it’s become apparent to me that some of the softer aspects of leadership management, hiring, recruiting, retention, team building—these things are crucial, and it’s especially hard in the current market because the market dynamics are quite lopsided.

Chief Engineers are like the hot girls at the bar. You can decide that you’re just going to go in hard. And you can do that. Or, you can take a step back, and you can comb your hair, and wash your clothes and tuck your shirt in, and figure out if there’s some way that you can possibly make yourself more attractive to the audience or the department that you want to engage. So, as you’ve heard some snippets already tonight, companies are already doing this. The smartest companies and the best companies are doing this, and they’re doing it at scale. We saw this like before, actually.

Do you know where Code as Craft actually came from? Five years ago, Etsy couldn’t hire any engineers. And so, they dug deep, and they said, all right, how can we attract engineers? What do engineers care about? And, as engineers yourselves, and as I know, as well, engineers care about two things. They care about multiple things like perks and salary, and mission. Those are all important things. When it comes down to it, you can distill the two things that they likely care most about as being really hard technical challenges, like the gnarly kind of hard technical challenges, and working with other people who are smarter than they are,the hallmark of a great engineer.

So Etsy said, all right, no engineer want to touch us with a ten-foot pole because we’re this online, artsy bazaar site that no engineer thinks is cool. How are we going to solve this problem? So they started to talk about one particular problem they had. It was their search problem. And so the message of Etsy went something like this: All right, Mr. Hotshot Engineer, or Miss Hotshot Engineer, you think you don’t want to come and work here? Well, why don’t you try to tell us how to build a search engine that goes against 200,000 skews, all user-submitted, of products that are completely amorphous, and have no normalization or parameters. How do you do that? And the engineers, they all stood up, sat up and took notice and said, oh, my God, I want to go work for Etsy, to solve their search problems.

So after that—that was the search story. After that, it became DevOps, which you're all familiar with. Etsy is very public about that. Then, they branded the whole thing Code as Craft. Then, they went after female engineers, which was awesome, diversity is important, and you’ve got to assume there’s probably some PR benefit there, as well. So they layered one thing after the other, after the other, after the other. And now you see Code as Craft, but no, that was strategically designed to be with an engineering powerhouse from the very beginning. And Etsy learned to do it quicker than others. Of course, there’s other stuff floating around. Facebook has an engineering team in New York now. They’re driving their brand and the presence specifically. Twitter—everyone has an engineering blog, right? But here’s what it really looks like. We did a survey of the top six engineering teams in New York, and these are all the different channels they’re using: engineering page, blog, conference meetups, their own tech talks, hackathons, open source, API, schools, recruiting, social media, media presence—they’re all doing it all. So, if you want to compete, it’s time to expand your strategy.

So what is engineering PR? Engineering PR, as I mentioned, is focusing on the things that engineers really care about and learning how to tell that story. So it’s essential that your company comes up with your own specific engineering story. This is challenging. It could be a story like Etsy’s search foundation. It could be something about how your team has pushed the envelope of UX and the front end of engineering on multiple devices in different platforms. It could be something like, an engineer sat across table from lunch with me a couple of weeks ago. I said to him, why did you go to work for this little Canadian startup? He was doing big data stuff I’d never heard of. And he said to me—in two minutes, he gave me the whole pitch. He said, the reason I went there is because they’re doing awesome stuff with vertical scaling Hadoop. I said, okay, I don’t know what vertical scaling Hadoop is. And he explained it to me. They’re trying to get as much throughput as they can in a single box, instead of going horizontal across the cloud, which made perfect sense. But this guy was able to, in two minutes, tell me exactly why an engineer would want to go work for that company.

So, if you don’t have the story, it’s time to figure out what it is. You’ve got to reach deep, you have to figure out the most interesting engineering stuff that you’re working on, and try to figure out how you can position yourself and your projects as you make it special in the world of technology and the other teams that you’re competing with.

Another big part of this was touched on tonight already: develop an OS project or program. I’d like to encourage companies to develop an OS culture. It’s important to realize that open source is not just something you consume. I didn’t realize this until a few years ago when I guess we all knew that Linux was going to sort of eat into Microsoft’s market share, and we kind of realized that open source is here to stay, but as it turns out, the best companies do not just advertise for its projects , but they develop a culture that’s not only taking open source internally, and they’ve learned to give back. Now, that could be open sourcing your own stuff, or that could be some smaller steps along the way.

Internal hackathons—there’s companies in New York that develop amazing features and amazing products that come purely under their internal hackathons. Of course, you can host public hackathons as well. Have a company GitHub page and publicize, at least internally, all the cool site projects that your engineers are working on. Do stuff to show engineers internally first that open source is important to you. Inspire them and encourage them to build their own stuff. Even if it’s not company-sanctioned stuff, get them to be public about open source stuff. Publicize the GitHub profiles of your engineers internally and externally if you can. And that will start to push you along the road of finally figuring out and putting your finger on something internally that could lead to open source as a company project. Nathan Marks built Storm inside Twitter. Storm was really successful as a stream processing platform. It ended up on Twitter, three months ago, four months ago. You might not know that. Twitter still has value by association of the fact that Storm was built there. And smart companies are becoming the vanguard of open source, and they’re doubling down on it and commissioning their engineers to contribute into these projects in a strategic way.

Bit.ly did the same thing with NSQ by the way, so go check that out. They wrote it in Go, just so that they have a story to talk about later. They were solving their engineering problem, but, before they did it they took a step back and said, all right, this is going to be a nine -month engineering project. When it goes out the door, we have smart engineers here, so we know it’s going to solve our technical problems, but how can we strategically crack this project to be most interesting to a broader audience?” And they were very forward thinking—this was a year ago, and they chose to write it in Go, and now they’re out there talking all about it. And it’s drawing huge attention in the engineering world. It was a very smart decision.

The other thing you want to do is you want to try and engage passive candidates. You need to engage passive candidates. And the simple reason for this is because all candidates are passive right now. Everyone's working at Google or Twitter, Facebook or Foursquare, so it’s essential that you figure out how they get in front of engineers, and how they give them value, without chasing them around LinkedIn and beat them overhead with your open job sites. So companies do this by having events which we’ve heard. Give back to the engineering community, don’t let your recruiters chase you with events, it’s not a good idea. I mean, you could point out a recruiter and say, hey, we’re here, we’re going to talk about this cool stuff, and, if you want to work for our company, go find a recruiter. But don’t let your recruiters run roughshod over engineers; they might talk among themselves and send the wrong message. But still figure out ways to engage them.

So, at G33kTalk, we did this in some interesting ways. We built engagement with candidates through—originally through our email newsletter, as Jean mentioned. Thank you, Jean. That’s a weekly list of—it’s a roundup of some of the top engineering content that we’ve found from around the web, as well as some original content from our platform that features companies talking about their engineering challenges, as well as meetups on some selected gigs from CQ, so they know we’re looking for awesome team members. And this has been a huge success—Content Marketing.

We also launched a series of CTO video interviews where I would sit down with top CTOs, sometimes underexposed. This is Dag, who’s the CTO of Tapad. Did this two years ago when Dag was new in New York. He’s from Norway. He’s a super smart engineer working at this small company with no brand. He was having a hard time recruiting talent. So I knew he was doing cool stuff. He was building an Adtech platform, high latency—or high throughput, low latency in Scala, This is a couple of years ago. So we did a video interview, we cut it up, he talked about why they chose Scala. He talked about various sequels to solutions they had stitched together and some of the brick walls they had. We turned it into an interview and threw it up on HackerNews, and it went to the front page, and engineers still come into Dag’s office today. And they say, oh, God, you’re the bald guy from the Scala video. I remember you. I heard about your company before. So it works.

This is an example of our G33kTalk platform. So, since we kind of figured out how to tell these engineering stories in the way that works, we decided to aggregate them all together in an online web presence, and we’re launching profiles of engineering teams between San Francisco and New York. It’s specifically focused around content of the way those teams are working, solving big data challenges at Twitter with Scala, or how to choose SQL technology at Adtech with Tapad. So we’re doing—this is sort of our business, and we’re doing this on-site, but it’s just another way that we try to build engagement with engineers who are not necessarily looking for jobs, but are interested in top teams and top technologies.

So the future—we're actually releasing a new, slicker company profile and we’ll feature open search projects from companies. We’ll also feature key team members and other things. I don’t want to spend too much time on that. You’ll see that launch in the next few weeks. Yeah, but I hope this has been inspirational to you. You can find me on Twitter at @petesoder, or feel free to shoot me an email if you’re interested in understanding how your own company can potentially benefit from tighter, stronger messaging surrounding your engineering projects. I'm happy to chat and offer any help that I can. Thanks.

Questions? Any questions?

Audience 1: If you encourage your experience with engineering…

Pete: Yes. We get this from clients often, and the truth is, you really don’t have any choice in the matter because they can get stolen anyway. And the best way that you can help your engineers—that you can add value to your engineers, is to help them build their brand. And that’s what I didn’t talk about here. Your company engineering team brand is one thing, which is essential. But forward looking companies, a) they’re not afraid to talk about their engineering challenges because they’re not really proprietary. And this is what an open source culture really means. It means there’s no proprietary tech anymore, if you really get your arms around what that means.

I mean, yes, there’s patents, and yes, it might be appropriate for your company to engage in that sort of secrecy surrounding one corner of the engineering process. But, in general, what embracing open source means is you being open about your challenges, your tech. And, if you could afford to do that, you can probably afford to be open about your team. And it’s going to attract other engineers to you because they’re going to realize that you’re the kind of company that’s going to help them build their brand, even if you’re going to risk losing one once in a while, which is going to happen anyway. So you know, if you don’t eat your own young, someone else will, is that a saying? I think Fred Wilson said that, so that must be okay.


Audience 2: I think that you're, if anything, understating how you can use open source to actually get really amazing performers. I mean, just in terms of what I’m doing, I have, like, the most amazing senior grade people on the planet collaborating on just the open source elements of my business. It’s not just actively dog-fooding—being serious about, like, open source of… products. If you are actually doing something that’s interesting, and you are open about it, you actually get really amazing people sometimes—not always. but sometimes, working with them and helping them like for the past hour you were focused on one where it looks like you may have the best algorithm on the planet, for something that’s important to why I’m doing this business. Just because I've been collaborating with him and helping him with his other open source procrastinations. It’s not just, oh, we do open source because it looks good. If you are actually having some problems that matter to someone, you'll get rally amazing insights if you are engaged in—with, like, a really good community. And sometimes you actually do something that’s even better than interviewing or hiring. You get to know people, because really there’s this process for getting to know people in a way that isn't statistically durable. Repeat interactions are the best way to ever evaluate any one for any role, ever. And I just—you didn't really emphasize that one.

Pete: I totally agree. Companies are not figuring out how to twist their culture towards a culture of open source contributions, they’re stupid. Well said.

Audience 3: Question. So let’s say you’re an early stage startup here, just kind of ramping up. You have to put all you resources to producing the product initially. Is it smart, at that point, to contribute to open source, to develop your projects? Well, is it smart?

Pete: Yeah, we have a story about that, we’re actually taking steps. G33kTalk is a bootstrapped seed-stage business and one of the ways that I actually was able to enter into a relationship with an engineer, to build part of our platform, is by promising that we, the company, will open source part of the corner of the framework that he was going to work on. And not only did he know that we were serious, then, about community and engineering and sort of we’re interested in doing the right thing in giving back, but he also knew that we were the type of company that he wanted to work with. And he even cut his rate just because he knew that he would get some publicity from being part of the open source project, as well. I didn’t even go into it, necessarily, sort of all that laundry list of potential benefits. But I think any company, no matter what size you are, if it truly is an interesting engineering project, that can sometimes be the challenge, and you have to make sure you’re working on something that’s interesting enough, as our friend said, that attracts engineers, but definitely desperately truly try and dig in and find that. You can do that if you’re a small company or a large company.

Audience 4: Could you give us an example of—because a lot of us, you know, aren't working on the next generation … We're just making programs for people. So what's any good example of something you can find of ordinary web site product that will lead to that kind of, you know…

Pete: Yeah, I mean, you have to, like, worth with—you have to work with your engineers to figure that out. I try to help companies, like, push companies towards mobile stuff because some mobile engineering is somewhat underexploited in terms of frameworks and analytics, and there’s not as many webby type frameworks as we’ve seen. So that can be one idea. But, to be honest, with some businesses, you’re not going to find much at the end of the day. You’re not doing anything that’s so crazy or interesting. In those cases, probably best to focus on your engineers’ side projects, and try and sort of use that to exhibit your culture. There’s a great meetup here in New York. It’s called Hack and Tell, and, if you’ve never been, it’s super awesome, and it’s very cool. It’s engineers getting up and giving five-minute pitches of their side projects, and they can’t be commercial. It’s better if they’ve been open sourced, and it’s just a way for engineers to sort of get together and talk about hacks and cool stuff. So, if you can’t figure out which corner of your platform you can open source, I would try to encourage engineers to collaborate or be public with the company or the team about site projects. I think that can be a close substitute.

Audience 5: In my personal experience, to answer your question, the open source projects that you or your team is using have problems. And you said you fixed the problems with the open source software that you’re using, and you contribute that back to the project. So rather than use, it’s not as good for branding, but you’re still getting your name out there. Because you’re an individual and your leaders are getting in, they’re feeling like they’re contributing to open source projects. It’s just not all about branding by your company. Though it’s good for your team, they’re getting their name out, and then, if they’re blogging about it, because now they’re like one of the authorities on Open Source Project X, it’ll come back to your company sooner or later.
Pete: Yeah, absolutely, and it’s that. You don’t have to own the open source projects. Teach your engineers to contribute to open source projects they find out there. That stuff is a great point.

Thank you.