WEBINAR: Transitioning from CMO to CRO: Insights from the Front Lines.

Register Now

Blog

Developer Interview Series Part 2: Engaging with devs.

Read Time: 7 Mins

Not every developer is the same but almost every developer has a disinterest in anything that looks and feels like “marketing,” so how do marketers reach this crucial audience?

This interview series aims to help marketers better understand the developer perspective to find out what works and what doesn’t. In part 1 of this series, we asked members of our in-house engineering team about their solution discovery process.

Read part 2 below to see what they had to say about content preferences, product adoption, and how and why they would interact with companies.

 

Meet the devs.

The majority of Ezra’s time is spent managing projects, communicating with customers, building estimates, writing SOWs, and working on the Iron Horse engineering roadmap: initiatives, innovations, optimizations, infrastructure, quality control, and so on. He spends roughly 20-30% doing hands-on development, and the primary languages he uses these days are Javascript, ReactJS, SQL, and PHP.

 

 

 

 

Randy splits his time between hands-on programming and team management. Specifically, he repairs old code, optimizes database queries, refactors java code, and builds out internal tools for our customer support team. He also manages a log of the AWS infrastructure side including the continuous integration setup and overseeing our offshore team, performing periodic code reviews, and discussing implementation details for new features. Randy is commonly working with Java, Node/Javascript, Python, and SQL.”

 

 

 

Kenny spends most of his time at Iron Horse focused on building high-quality code for our customers, building web pages, landing pages, full company websites, virtual event websites, in-browser React Apps, and more. Somewhere around 10% to 20% of his time is spent communicating with customers and learning new skills. The languages Kenny uses on a daily basis are CSS/HTML, Javascript, React, and PHP.

 

 

 

 

The interview.

Getting developers to engage with content and/or with brands can be tough. Marketers should know that developers want content that helps to solve immediate problems. That’s easy enough to navigate, but now it’s important to know where and how developers want that content served up, and when and how they want to engage with companies.

 

Where do you like to get information about solutions and why?

Randy: I go to Github and/or Stack Overflow because I can evaluate the code and solutions, then make a decision on whether it’s an appropriate solution. It’s fast and helpful, and that’s what I want.

Ezra: I like email newsletters because they’re aggregate and automated, so there’s no effort on my end other than a subscription. White papers are also good because they are dense with data and more in-depth than blog posts, and they’re highly shareable. Lastly, I would say events are big for me. They are easy to consume and give developers like me the ability to interact with a community of like-minded people.

Kenny: I prefer websites where other developers have created the content. The platform doesn’t necessarily matter to me. I’ve found valuable posts on Medium, Stack Overflow, and CSS Tricks to name a few. If another developer has written the content, I know it’s going to be more applicable to what I’m working on now or something I will be working on in the future.

 

Do you participate in discussions on StackOverflow or other sites? What would make you join a discussion?

Kenny: There’s a joke that I’ve seen floating around recently: Two front-end developers walk into a bar. They have nothing to talk about.

The point is that technology is and continues to get more and more vast. Even in a niche profession, such as “front-end,” there are many different technologies. That said, if I’m going to have a conversation with someone I have to be able to relate to the topic at hand. To do that, the topic has to be relevant to something I have worked with a lot in the past or am learning about now.

Randy: Solutions that I don’t understand or I think can be improved. I will go into deep conversations about that kind of thing. At the end of the day, developers are problem-solvers. If you come to us to vent, expect us to propose solutions to whatever you’re complaining about in response.

 

Hypothetical situation: You’re looking for a new solution to solve X problem. In an ideal world, how would you find the solution?

Ezra: In the developer community, I feel referrals are a really strong motivator. One thing that’s nice about the developer community is that devs are often friends with other devs, so I can ask Kenny or Randy here if they have any experience with a certain problem and they can give me a couple of ideas that either solve it, of give me more to build on when I go on Google or Stackoverflow and to figure it out.

Randy: I don’t know any developer that doesn’t want to hear from another developer that’s had experience solving a similar, if not the same problem. Developer referrals are definitely big. Marketers need to find the Kim Kardashian of developers to be their influencers and they’ll be set.

 

What would make you recommend a product or solution with fellow developers?

Kenny: If the solution is tested, has good reviews, and has an active issues/support forum, then I am much more likely to recommend it. Longevity also plays a big part in it for me. For example, the Advanced Custom Fields WordPress plugin has been in active development for over 10 years, I believe. And it has a massive user base.

Ezra: I would never want to be the person that recommended that awful product that screwed everything up for you. I will recommend a product or solution if it makes life easier and has any or all of the following:

  • Good documentation
  • Reliable support
  • Solid reputation
  • Appealing presentation (website, branding, etc)
  • Affordable pricing
  • Financial backing
  • Large team

 

If interested in a solution, what information are you willing to give to a company to get it?

Randy: “Nothing. But, if it’s something I really need to check out then I prefer to give the bare minimum—name and email address. I’m not going to tell you my life story so I can see if your code can even help me.”

Ezra: “I’m willing to provide my first and last name and email. I don’t mind giving that stuff up, but it gets really cumbersome when the questions go on after that, asking for job title, company name, company size, what you’re interested in, and so on.”

Kenny: A lot of the time I will pass up on a resource if it’s gated and I don’t think it’s all that valuable. I come across a lot of gated developer content that just isn’t worth filling out a form, and certainly not worth a flood of emails afterward. A valuable resource worth sharing my information for would be something like a free toolkit or code sample. A case study or guide, not so much.

 

In what situations would you like to interact directly with a company?

Ezra: I will engage when I have a specific need and the product/solution that company provides fills that need. I think most developers do their full research before engaging with a company. It’s like buying a new car, I will talk to the sales person at the dealership when I’m ready and know exactly what I need, until then I don’t want to talk to them.

Randy: It’s always through email and usually it’s either to buy a license or because I need support. I’m not really interested in talking directly to the company unless I’m already invested. Also, when I’m having support/implementation issues, I prefer to talk to someone with the proper technical acumen. 

Kenny: When I do talk with a company about their product or solution it’s usually in their support forum to either ask how to do something or report a bug. Not sure I need to interact with a company other than to make a purchase or seek support. At the end of the day, if a company is providing good support for their product then I’m more than happy to talk with them. Also, if a company is putting on a webinar or event that provides information directly applicable to the technology I’m working with in my job, day-to-day, I’m much more likely to attend/engage.

 

What’s your biggest gripe about the way companies try to engage with developers?

Ezra: There’s almost never a quick and easy way to get my hands on a resource if it’s being advertised by marketers. They always redirect you to a form and typically that form asks way too many questions or questions I don’t want to answer. It’s simple: I have a problem and I need a solution. The way I get my hands on that resource shouldn’t be complicated or time-consuming because then I get fed up and look elsewhere. Also, I will continue to associate that feeling of complication and time-consumption with that brand moving forward. 

Kenny: Piggy backing on what Ezra just said, I would also add that too many of the resources being offered are stuck behind a form. A webinar or event makes sense, and sometimes certain code samples are a must-have so I can see those too, but any non-actionable piece of content should just be free to look at immediately. Maybe even the more light “actionable” content should be too. I would say having a form before a simple tutorial is pushing it, in my opinion. 

 

Okay, developers don’t really want to engage with companies, and would rather talk to other developers, but companies still want in on the conversations—so, what should companies do?

Randy: I joked about finding the Kim Kardashian of developers, but it would be worthwhile to find established developers to spread the word, give recommendations, and/or demonstrate common use cases with the products.

Kenny: Companies should look to engage developers by providing content that is valuable to them. Focus on the problems developers want to solve and provide the content for those problems. For example, code meetups, webinars that provide insight into the company’s product from a developer perspective, or online support forums. And free beer never hurts either.

 

Check out part 3 of our developer interview series for a software engineer’s POV on the importance of developer communities.

Related content.

Subscribe to our blog.
Get unstuck with the most interesting business ideas and our insights delivered to your inbox.

© 2024 Iron Horse. All rights reserved. Privacy Policy