Search
blog7f5

The power shift: Developers as decision-makers and influencers

Table of Contents

Back in the before-fore times in an era long lost to history (you know, 5 years ago), the development landscape was very different. Back then, developers weren’t typically the decision makers, and the software tool buying cycle was ruled by managers who didn’t always know what was best for developers. Developers were forced to toil away in the code factories using tools and processes that they had no hand in picking. It was a dark time, and a difficult one for developers, as they were forced to use whatever tech stack they were handed. And this was the way it was since the dawn of time (ie. The dawn of the Tech revolution because as we all know, life was pointless before that). So, how did developers come to be decision makers and influencers?

Somewhere in the mid 2010s, a shift started to happen. It was slow to start, but if you listened closely, you could hear the rumblings of change began to drum up. It all started when the way that software was sold started to change. Companies started to realize that their software selling approaches were losing their efficacy. Selling software is a one-time transaction of a product that’s easy to duplicate and share. But using that software to leverage the sale of other things—such as subscriptions, data, advertising—was a constant stream of income. 

"In other words, some of the biggest software firms aren’t considered software firms because they’re making money with software, not from it. Their software isn’t the commercial asset, but merely an enabler to an alternative business model."

It was now obvious to most organizations that giving developers a choice in the tools they used enabled them to create more interesting and ultimately more interesting applications. This created a feedback loop of more useful, cost-effective tools for other developers and has created the explosion of projects mentioned by O’Grady above.  

 

How did the software buying business model change? 

While the software development process was undergoing a revolution, the software business was faced with a dilemma. The shift from selling software to using software to sell meant that the price of software had to drop. No one was willing to pay top dollar for a tool that had a reasonable open-source alternative, or something that their own devs could make in a week. So, if you wanted someone to use your tool, you had to make it appealing. Free trials became the norm—because who would pay for a tool without being able to test it out? (Hint: Everyone before 2010).  

Teams could now try out new tools risk free. If they didn’t like it, they could toss it and try something else. This meant that tools had to be easy to use and instantly engaging, lest they be thrown in the trash with all the other subpar applications. Suddenly, if the developers using your product didn’t like it, the organization wouldn’t buy it. This was a massive shift. 

For the first time in recorded history, the developer’s opinion mattered. Instead of being told to use a tool and conforming to its limitations, the devs actually had a say in what they used. Through their tears of joy, they demanded more from their software, and it forced a change in the landscape. This forced sellers to cater their software to developers and keep developer experience at the forefront of planning. This changed everything from planning, to development, to marketing, and it led us to the world we see today—one in which developer relations matter. 

  

The rise of the developer and the evolving sales funnel

In those prehistoric times when Boy Bands ruled the airwaves and the cloud was simply something floating in the sky, selling software development tools was a much simpler process. All you had to do was convince one decision maker that your product was right for their organization. That’s it. You only had to convince a single person (who has probably never written a line of code) that your product can make them more money. Then they’d buy the product, throw it down to the developers in the mine, and tell them, “Look alive people, this is what we use now.” 

This top-down method is pretty straightforward, but it lacks a lot of subtlety. The managers and executives make the decisions, and the rest of the company falls in line. And in a simpler, less connected time, it worked. There were fewer tools to choose from, and software development was much harder, so any tool was probably an improvement. And accordingly, organizations focused their sales efforts on convincing management that they were the tool to help their business. After all, that’s how sales were made. But if you’re still trying to sell software this way, you are missing out on significant sales opportunities.  

 

Developers have sway and top-down tool purchasing is dead

In the new world, where developers have a say in the tools their organizations use, you need to reach developers. In fact, you need to do more than just reach them—you need to win them over. Of course, executives and managers still have the final say, but they listen to developers. And developers are very vocal about what they like. If you can convince them to try your product, and they like your product, they will let management know. That internal recommendation does more to drive a deal than any sales pitch you could possibly dream up. It’s this bottom-up approach that’s the new sales landscape.  

The catch is that speaking to developers is not an easy task. They’re a bit like house cats, you can’t come on too strong. You need to make them think they’ve found things on their own as hard sales pitches tend to fall on deaf ears. 

Successfully “marketing” to developers (“marketing” is in quotation marks because developers hate marketing so you can’t make your marketing look like marketing…you got this) requires a new approach and a new point of view, but it’s the key to driving sales of development tools and processes in today’s world. 

 

Understanding who has the influence: How are developer teams organized? 

Developers aren’t penguins—they aren’t identical. Understanding the developers you are targeting for your product means understanding the prospective users of your product. A senior back-end developer isn’t impressed by the fancy animations on your interface, and a junior front-end developer isn’t going to understand your C++ demo code. It’s important to understand a development team structure and get clear on who you’re targeting.  

Take a look at the chart below: 

As you move down the chart, each position has less sway when it comes to convincing top management. But as you move down the chart, you’ll find employees that are more hands-on with the development process. A team lead may be more likely to sway the organization to use your product, but if your product helps people create applications, then the team lead is probably never going to use it. If the novel part of your product is at the code level, you’ll need to convince the hands on devs. Getting that in front of team leads is no help to you. This means that it might take a bit of extra time for that information to move up the food chain. But if the devs like it, word will get out.  

If your product is more about organization and team efficiency, then you can aim further up. And in this case, keep in mind that you’ll need to speak to the leads and executives in a different way. More high-level, if you will. They need to be told how your product helps on an organizational level, as opposed to a daily working level.  

In the end, understanding who you are speaking to and how to speak to them is the true measure of quality and effective developer marketing. 

 

Tap into developer influence and purchasing power with the right approach

Properly engaging with a developer audience is a difficult thing to do. It takes a lot of nuance and care to create content meant to target the specific group for your project. It’s not enough to understand your product, you also need to understand the ever-changing developer landscape. You have to understand how developers discover and ingest content, what entices them, and what annoys them. It’s not enough to have a product that fills their need, you have to let them find it and see the value for themselves.  

It’s a complicated process, and it takes years of experience to get right. Knowing how to speak to this audience, how to draw them in, and ultimately how to convince them to try your product is a completely different skill set than most marketers are used to. In this case, it can help a lot by employing specialized tech writing companies like ContentLab. With a dedicated team of experienced writers and editors, we know how to take your product and get it in front of the eyeballs that matter: the users. You know your product is the best, let us help you show the world.  

Picture of Peter White
Peter White
Peter White is a seasoned full stack developer with over 15 years of development experience across a wide variety of different technologies. He is able to quickly understand new technologies, and loves diving deep into novel systems, and is able to communicate well with both technical and non-technical audiences. Peter has written professionally across a glut of different mediums in both a technical and non-technical capacity, including blogs, whitepapers, television, radio, and newspaper. Peter's technical and communicative skills make him ideally suited for developing technical content that really connects with developers and engineers across different frameworks.

Let’s talk about your pain points and content marketing goals.

Fill out the form to get in touch with us, and a member of our team will reach out via email within 1-2 business days.

Let’s talk content!

Book a free consultation

Share via
Copy link
Powered by Social Snap