Developers are creators, but in many companies they also wear a couple of other hats. They are buyers, purchasing software for their teams or even the organization. And they are influencers, often with a say on which vendors make the short list and which tools get the nod. For the makers of B2B enterprise technology, these three roles translate to one imperative: the developer is someone you really want to reach.

But like surgeons and sturgeons, developers come in different types. They work in different parts of the tech stack and for different kinds of companies—whether organizations born in the cloud or still brimming with legacy tech. So reaching—and wooing—this community requires more than a “developer relations” placard above some cubicles down the hall. It means uncovering and leveraging the nuances: identifying the developers that matter most to your business, understanding what matters most to them, and getting the word out that you deliver.

One Size Doesn’t Fit All

For many tech companies, the need to win over developers is more important than ever. Through organic growth and, notably, acquisitions, vendors increasingly are wading into areas, and making products, that require the skills and engagement of developers. IBM’s acquisition of Red Hat, Microsoft’s purchase of GitHub—the trend has been hard to miss. From 2010 through 2017, developer-focused M&A amounted to some $8 billion in deals. From 2018 through April 2021, the figure was approximately $58 billion.

There’s another trend to note, too. More and more, we are seeing a bottom-up dynamic when companies buy enterprise tech. As creators, buyers, and influencers, developers have become instrumental in deciding what products pass muster. Ultimately, the C-suite may call the shot, but the developer is often guiding its aim.

To be sure, the growing clout of developers hasn’t gone unnoticed by enterprise tech players. Companies like Red Hat and Datadog have teams—sometimes dozens or even hundreds of members strong—dedicated to developer-focused initiatives. But too often, vendors view developers as a monolithic block. They don’t explore or make the most of the nuances: the different needs, priorities, and influence levels among different types of developers. This leaves key insights—and the value they can generate—on the table.

So how do you take a more fine-tuned approach? The first step is to understand the different kinds of developers. While not an exhaustive list, the general breakdown looks like this:

• Network engineer. Designs, develops, optimizes, and implements software for networking equipment.
• Automation engineer. Automates solutions for operational aspects of IT, such as on-call monitoring, performance and capacity planning, and disaster response. Also has responsibility for application maintenance and management.
• Front-end developer. Creates an application’s user-facing code—for example, the user interface and experience for a mobile app or video game.
• Data engineer (or data scientist). Ensures the storage and organization of data (which may include database design, data migration, security, and performance monitoring). Also builds the data analytics models that power AI-based applications.
• DevOps engineer. Manages code releases across the software development life cycle, using special tools like Puppet and Datadog. With its emphasis on automation, collaboration, and continuous improvement, DevOps helps companies deploy new features and updates with greater speed and efficiency.
• Security engineer. Develops and manages systems such as firewalls that help prevent breaches at all levels of the tech stack. In the cloud-native world, this role is shifting to DevSecOps, an evolution of DevOps in which security is a shared responsibility and integrated at every stage of the software development life cycle, instead of something a dedicated team “tacks on” near the end.
• Cloud-native application developer. The most technically advanced of the three types of application developers (with IT/business developers and “citizen” developers, below, rounding out the group). Works in both front-end and back-end languages and has deep knowledge of cloud-native architecture, including app platforms like Amazon EKS and Google Cloud’s Anthos.
• IT/business application developer. Utilizes a platform as a service (PaaS) offering such as Salesforce Lightning or SAP Cloud Platform to develop a company’s applications without worrying about the underlying complexity (storage, servers, and virtualization, for example).
• “Citizen” developer. Uses a low- or no-code development platform (such as Microsoft Power Apps or Google Cloud’s AppSheet) for quick deployment of simple applications. A rapidly growing developer segment.

Different developer segments will operate in different levels of the stack. (See Exhibit 1.)

A front-end developer, for instance, generally will work only in the application layer and, to some extent, the data layer. Automation and DevOps engineers, by contrast, generally work in all layers except the application layer. Keep in mind, too, the impact of the “shift left” mindset, where issues that traditionally came into play later in the software development process—like performance and maintenance—are now “early on” considerations. Accordingly, many cloud-native application developers now work in, or at least think strategically about, all levels of the tech stack.

Influencing the Influencers

Different segments prefer—and look for—specific things when it comes to enterprise tech. For example, a recent BCG survey found that cloud-native application developers prioritize easy, self-service testing, as well as access to vendor resources when onboarding and scaling a new solution. (See Exhibit 2.)

Developer needs and preferences also depend on the type of company where they work. At companies early in their cloud transformation, developers typically prefer an end-to-end application platform—one that offers a simple, streamlined experience. Meanwhile, developers in cloud-native companies tend to prefer best-of-breed point solutions, so they can create their platform to their own specifications.

Thus, that key commandment of sales—know thy customer—really has two prongs: identify the developer segments most relevant to your product and understand what matters most to them. Catering to those needs can help you win over the developers who can help you win sales.

But keep in mind that influence isn’t a constant. We’ve found that developer clout varies across the spectrum of software. In our experience, developers are particularly influential at shaping purchasing decisions in two product areas: application platforms and infrastructure software. So it’s worth taking a closer look at these categories and the dynamics at play.

Application platforms fall into two broad types:

• Cloud-native application platforms. These platforms—which include Anthos, Amazon EKS, and VMware Tanzu—host a company’s application (think Uber running its mobile app) and provide tools for deploying and managing releases. An integral part of the development architecture, the platforms are of particular interest to DevOps engineers. Cloud-native app developers—the platform’s end users—are often influential, too, though how much so typically depends on their company’s cloud maturity. (See Exhibit 3.) Their influence can be indirect, as well. As creators (especially within the independent software vendor, or ISV, ecosystem), they develop the point solutions that help extend a platform’s functionality—and increase its appeal to potential customers.
  

Similarly, in the realm of infrastructure software, DevOps engineers and cloud-native app developers are the segments influencing decisions to purchase—or pass on—products:

• Observability solutions. Critical for organizations with distributed IT systems, these solutions (from companies such as Datadog, New Relic, and Splunk) give visibility into the tech stack and how apps and services are performing. DevOps engineers, who monitor and manage system performance, often advise leadership through the purchasing process, especially during shortlisting. But with the shift-left movement, cloud-native app developers are seeing their input—and influence on purchases—rise as well. They also play an important creator role within ISVs, building integrations to ingest data from a myriad of tools.
• Application security. These solutions, from vendors like HashiCorp and Snyk, protect applications through their full life cycle, minimizing threats to the relevant infrastructure, code, and runtime environments. As DevOps teams are responsible for runtime security and for providing a secure environment for app developers, it’s natural that they would influence purchasing decisions. But the role—and say—of cloud-native app developers is increasing, as more companies embrace the trend to integrate security testing with early-stage app development.
• Edge security. With many IT resources now located off-site, edge security (from companies like Cisco, Fortinet, and Zscaler) protects systems, devices, and users at the outer reach, or edge, of a company’s network. DevOps teams are the key developers here, as they help integrate a cloud-delivered security stack (specifically, a secure access service edge, or SASE) with the company’s network.

Creating a Developer-Focused GTM Model

Understanding developer preferences and influence can help you differentiate your products. But just as crucially, the insights help you shape—and optimize—your messaging. It’s not enough to meet the right needs of the right segments. You also must communicate that you meet them.

Getting that second part right means creating a developer-focused go-to-market model. To be sure, some vendors are on the right track here. They are looking at the four stages of the GTM process and shaping initiatives around developers’ behaviors and preferences:

• Awareness. Developers tend to prefer self-discovery through peer mentions, third-party reviews, and community discussions. To facilitate this, some vendors are scheduling launch events at global and regional levels, promoting developer communities (and providing incentives to join them), and creating dedicated teams to drive content discussions within communities.
• Shortlisting and testing. Developers like to try products without charge. In response, vendors are providing free trials or “freemium” offerings. Some are also simplifying the trial experience by providing a sandbox development environment, sample code, and robust APIs that integrate well with the user’s existing architecture.
• Purchase. Developers want to understand the finer points of a product and how it can help them in their day-to-day work. To this end, some vendors are reskilling their existing sales force (or creating a team of specialists) to better convey the functionality and benefits of product features.
• Post-purchase. Developers value strong support from the vendor to ensure rapid onboarding with a minimum of issues. They also like to leverage the community for support solutions (except in high-risk areas like app security). Vendor initiatives include providing robust documentation along with learning and discovery pathways. We are also seeing more long-term interaction with developers—via customer success teams—to boost adoption and retention.

But B2B tech companies can do even more to attract and win over developers. Again, it all comes down to letting the behaviors and preferences of developers inform strategy. And in this context, four strategies are particularly promising:

• Build a strong developer community by focusing on content moderation, personalization, and platform gamification. A vibrant developer community drives brand awareness, facilitates interaction among peers, provides crowd-sourced support, and generates valuable feedback. Not surprisingly, some B2B tech vendors are actively nurturing and contributing to such communities. But there are ways to bolster the effort. One idea: product integrations. Vendors should enable easy access, from within their products, to the developer community. Another best practice is to adopt scalable, best-in-class content moderation. By leveraging external services and AI models such as Azure Content Moderator or AWS Mechanical Turk, vendors can ensure that comments follow community guidelines, building trust and fostering more discussion among members.

Personalization is another smart move: tailoring content feeds, product updates, and recommendations (regarding training options, groups to join, and so on) to individual needs and preferences. And consider gamification. We’ve found that game-like experiences can be a powerful way to boost engagement within communities. They also can facilitate product exploration and even onboarding through gamified online tutorials.

• Contribute to open-source projects or release an “open core” offering. Community, of course, is a two-way street. Savvy vendors don’t build the arena and then sit on the sidelines. They become active participants. This is especially important when focusing on the cloud-native developer segment. These developers tend to value companies that contribute to open-source initiatives. With that in mind, vendors could choose from several approaches to build awareness and raise their standing. One idea—particularly suitable when differentiated product features drive competitive advantage—is to keep a product’s code proprietary but support and contribute to open-source projects, as Datadog has contributed to the open standards project OpenTelemetry. Another approach is to make the product’s core codebase open, allowing free use of a basic version while offering a premium version with additional, proprietary features. This model could work well for a new entrant that wants to build developer awareness while minimizing time to revenue. Finally, vendors could opt to make the product codebase fully open source. By doing so, the thinking goes, they can attract developers while sparking revenue for adjacent offerings.
• Provide free or low-cost consulting services during onboarding and implementation. Great products drive interest. Great relationships spark sales. Especially with newer offerings such as SASE, many developers appreciate strong support from the vendor. By providing consulting services at little or no charge, vendors can smooth the onboarding and implementation processes and also help boost adoption of the product within the enterprise. Smart companies in any line of business are always thinking: what can we do to make the customer’s journey easier, better, and ultimately more successful? Getting that right is a win for everyone.
• Focus acquisition efforts on offerings—and talent—most relevant to cloud-native application developers and DevOps engineers. Already, many vendors have turned their M&A sights to companies and products that are important to developers. But maybe it’s worth sharpening the focus. Since cloud-native application developers and DevOps engineers have particular clout in purchasing decisions, it may make sense to prioritize acquisitions around brands and products relevant to these segments. But dealmaking isn’t the only arrow in the quiver. Vendors that hire A-list open-source contributors (who often have large followings) may find that they’ve hit on an effective—and in the scheme of things, relatively low-cost—way to reach and woo developers.

Traditionally, developers have wielded code, not clout. But today’s developers are having an increasingly strong say in purchasing decisions. They’re not a monolithic block, though, and different developers have different needs, preferences, and influence. To reach—and win over—this key audience, B2B enterprise tech companies need a deeper, more nuanced understanding of how developers work and what they want to see, from both a product and its vendor. These insights can shape and propel marketing, outreach, and support strategies. And they can help spark growth. Developers are no longer just users, but decision-makers who can seal—or kill—the deal.