A crescente influência dos desenvolvedores nas vendas da Enterprise Tech

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.

Mas, como cirurgiões e esturjões, os desenvolvedores vêm em diferentes tipos. Eles trabalham em diferentes partes da pilha de tecnologia e para diferentes tipos de empresas - sejam organizações nascidas na nuvem ou ainda cheias de tecnologia herdada. Portanto, alcançar - e cortejar - essa comunidade exige mais do que um cartaz de "relações com desenvolvedores" acima de alguns cubículos no corredor. Significa descobrir e alavancar as nuances: identificar os desenvolvedores que mais importam para o seu negócio, entender o que mais importa para eles e divulgando a notícia de que você entrega.

One Size Doesn’t Fit All

For many empresas de tecnologia, A necessidade de conquistar os desenvolvedores é mais importante do que nunca. Através do crescimento orgânico e, principalmente, aquisições, os fornecedores estão cada vez mais entrando em áreas e fabricando produtos que exigem as habilidades e o envolvimento dos desenvolvedores. Aquisição da IBM de Red Hat, compra do Github pela Microsoft - a tendência tem sido difícil de perder. De 2010 a 2017, as fusões e aquisições focadas em desenvolvedores totalizaram cerca de US $ 8 bilhões em acordos. De 2018 a abril de 2021, o número foi de aproximadamente US $ 58 bilhões.

Há outra tendência a observar também. Cada vez mais, estamos vendo uma dinâmica de baixo para cima quando as empresas compram tecnologia corporativa. Como criadores, compradores e influenciadores, os desenvolvedores tornaram -se fundamentais para decidir o que os produtos passam. Por fim, o C-suite pode chamar a foto, mas o desenvolvedor geralmente orienta seu objetivo. Empresas como Red Hat e Datadog têm equipes-às vezes dezenas ou até centenas de membros fortes-acrescentados a iniciativas focadas em desenvolvedores. Mas, com muita frequência, os fornecedores veem os desenvolvedores como um bloco monolítico. Eles não exploram ou aproveitam ao máximo as nuances: as diferentes necessidades, prioridades e níveis de influência entre diferentes tipos de desenvolvedores. Isso deixa as principais idéias-e o valor que eles podem gerar-na tabela.

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.

Então, como você adota uma abordagem mais ajustada? O primeiro passo é entender os diferentes tipos de desenvolvedores. Embora não seja uma lista exaustiva, a quebra geral se parece com o seguinte:

• Engenheiro de rede. Projeta, desenvolve, otimiza e implementa o software para equipamentos de rede.
• Engenheiro de automação. Automatiza soluções para aspectos operacionais dele, como monitoramento de plantão, planejamento de desempenho e capacidade e resposta a desastres. Também é responsável pela manutenção e gerenciamento do aplicativo. Cria o código voltado para o usuário de um aplicativo-por exemplo, a interface e a experiência do usuário para um aplicativo móvel ou videogame. Garante o armazenamento e a organização dos dados (que podem incluir design de banco de dados, migração de dados, segurança e monitoramento de desempenho). Também cria os modelos de análise de dados que alimentam aplicativos baseados em IA.
• 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. Gerencia as liberações de código em todo o ciclo de vida do desenvolvimento de software, usando ferramentas especiais como Puppet e Datadog. Com sua ênfase na automação, colaboração e melhoria contínua, DevOps ajuda as empresas a implantar novos recursos e atualizações com maior velocidade e eficiência.
• Engenheiro de segurança. Desenvolve e gerencia sistemas como firewalls que ajudam a evitar violações em todos os níveis da pilha de tecnologia. No mundo nativo da nuvem, esse papel está mudando para o DevSeCops, uma evolução do DevOps, no qual a segurança é uma responsabilidade compartilhada e integrada em todas as etapas do ciclo de vida do desenvolvimento de software, em vez de algo que uma equipe dedicada “se agrada” perto do final. Os mais avançados tecnicamente dos três tipos de desenvolvedores de aplicativos (com desenvolvedores de TI/negócios e desenvolvedores de “cidadãos” abaixo, completando o grupo). Funciona nos idiomas front-end e back-end e possui um profundo conhecimento da arquitetura nativa em nuvem, incluindo plataformas de aplicativos como Amazon EKS e Anthos do Google Cloud. Utiliza uma plataforma como uma oferta de serviço (PaaS), como o Salesforce Lightning ou o SAP Cloud Platform para desenvolver os aplicativos de uma empresa sem se preocupar com a complexidade subjacente (armazenamento, servidores e virtualização, por exemplo)
• 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. Utiliza uma plataforma de desenvolvimento de baixo ou sem código (como aplicativos de energia do Microsoft ou o AppSheet do Google Cloud) para implantação rápida de aplicativos simples. Um segmento de desenvolvedor em rápido crescimento. (Consulte o Anexo 1.)

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.

influenciando os influenciadores

Segmentos diferentes preferem - e procuram - coisas específicas quando se trata de tecnologia corporativa. Por exemplo, uma pesquisa recente do BCG constatou que os desenvolvedores de aplicativos nativos em nuvem priorizam testes fáceis e de autoatendimento, bem como acesso aos recursos do fornecedor ao integrar e dimensionar uma nova solução. (Consulte o Anexo 2.)

As necessidades e preferências do desenvolvedor também dependem do tipo de empresa onde trabalham. Nas empresas no início de sua transformação em nuvem, os desenvolvedores normalmente preferem uma plataforma de aplicativos de ponta a ponta-que oferece uma experiência simples e simplificada. Enquanto isso, os desenvolvedores de empresas nativas da nuvem tendem a preferir soluções de pontos mais bem da raça, para que possam criar sua plataforma para suas próprias especificações. Atender a essas necessidades pode ajudá -lo a conquistar os desenvolvedores que podem ajudá -lo a ganhar vendas. Descobrimos que a influência do desenvolvedor varia em todo o espectro do software. Em nossa experiência, os desenvolvedores são particularmente influentes na formação de decisões de compra em duas áreas de produtos: plataformas de aplicativos e software de infraestrutura. Portanto, vale a pena dar uma olhada nessas categorias e o

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 Dinâmica no jogo. Essas plataformas - que incluem Anthos, Amazon EKS e VMware Tanzu - possuem o aplicativo de uma empresa (pense no Uber executando seu aplicativo móvel) e fornecem ferramentas para implantar e gerenciar lançamentos. Parte integrante da arquitetura de desenvolvimento, as plataformas são de particular interesse para os engenheiros do DevOps. Os desenvolvedores de aplicativos nativos da nuvem-os usuários finais da plataforma-também são frequentemente influentes, embora o quanto normalmente depende da maturidade em nuvem de sua empresa. (Veja o Anexo 3.) Sua influência também pode ser indireta. Como criadores (especialmente dentro do fornecedor independente de software, ou ISV, ecossistema), eles desenvolvem as soluções de pontos que ajudam a estender a funcionalidade de uma plataforma - e aumentam seu apelo a clientes em potencial.

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.
  
  

  1 / 1
• Plataformas de aplicativos de nível superior. Menos tecnicamente complexo que as plataformas de aplicativos nativas da nuvem, essas soluções-que incluem o Salesforce Lightning, o SAP Cloud Platform e o ServiceNow's Now Platform-reproduzem grande parte das bases (e fazem grande parte do trabalho braçal) para criar e gerenciar aplicativos. Os desenvolvedores normalmente não precisam de uma ampla experiência em codificação. Em alguns casos, eles não precisam de nada. Todos os três tipos de desenvolvedores de aplicativos desempenham um papel importante no processo de compra, embora suas necessidades sejam diferentes. Os desenvolvedores de aplicativos nativos em nuvem são os primeiros adotantes de novas ferramentas, mas exigem integrações robustas com sua infraestrutura em nuvem existente. Os desenvolvedores de aplicativos de TI/negócios (a maior subcategoria de desenvolvedores de aplicativos) são os principais usuários dessas plataformas em grandes empresas-e possíveis líderes de torcida para eles. E à medida que os departamentos de TI ficam magros, as empresas estão cada vez mais pedindo aos desenvolvedores cidadãos, que exigem soluções intuitivas de baixo ou sem código, para criar e personalizar aplicativos de negócios.

Da mesma forma, no campo do software de infraestrutura, os engenheiros de DevOps e os desenvolvedores de aplicativos nativos da nuvem são os segmentos que influenciam as decisões de compra-ou repassarem-produtos:

• Soluções de observabilidade. Os engenheiros do DevOps, que monitoram e gerenciam o desempenho do sistema, geralmente aconselham a liderança através do processo de compra, especialmente durante a lista restrita. Mas com o movimento de mudança de mudança, os desenvolvedores de aplicativos nativos da nuvem estão vendo suas contribuições-e influência nas compras-também. Eles também desempenham um papel importante do criador no ISVS, criando integrações para ingerir dados de uma infinidade de ferramentas. 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.
• segurança de aplicativos. Essas soluções, de fornecedores como Hashicorp e Snyk, protegem os aplicativos por meio de seu ciclo de vida completo, minimizando as ameaças à infraestrutura, código e ambientes de tempo de execução relevantes. Como as equipes do DevOps são responsáveis ​​pela segurança do tempo de execução e por fornecer um ambiente seguro para os desenvolvedores de aplicativos, é natural que eles influenciem as decisões de compra. Mas a função-e digamos-dos desenvolvedores de aplicativos nativos da nuvem está aumentando, à medida que mais empresas adotam a tendência de integrar testes de segurança ao desenvolvimento de aplicativos em estágio inicial. Com muitos recursos de TI agora localizados fora do local, a Edge Security (de empresas como Cisco, Fortinet e Zscaler) protege sistemas, dispositivos e usuários no Reto Exterior, ou Edge, da rede de uma empresa. As equipes do DevOps são os principais desenvolvedores aqui, pois ajudam a integrar uma pilha de segurança entregue na nuvem (especificamente, uma borda de serviço de acesso segura, ou SASE) com a rede da empresa. Mas, com a mesma forma crucial, as idéias ajudam você a moldar - e otimizar - suas mensagens. Não basta atender às necessidades certas dos segmentos certos. Você também deve comunicar que os encontra. Certamente, alguns fornecedores estão no caminho certo aqui. Eles estão olhando para os quatro estágios do processo GTM e moldando iniciativas em torno dos comportamentos e preferências dos desenvolvedores:
• 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:

• Consciência. Os desenvolvedores tendem a preferir Autodescoberta através de menções de pares, revisões de terceiros e discussões da comunidade. Para facilitar isso, alguns fornecedores estão agendando eventos de lançamento nos níveis global e regional, promovendo comunidades de desenvolvedores (e fornecendo incentivos para se juntar a eles) e criando equipes dedicadas para impulsionar as discussões de conteúdo nas comunidades.
• Shortlisting and testing. Os desenvolvedores gostam de experimentar produtos sem carga. Em resposta, os fornecedores estão fornecendo testes gratuitos ou ofertas de "freemium". Alguns também estão simplificando a experiência do teste, fornecendo um ambiente de desenvolvimento de sandbox, código de amostra e APIs robustas que se integram bem à arquitetura existente do usuário.
• Compra. Os desenvolvedores querem entender os pontos mais finos de um produto e como ele pode ajudá-los no trabalho diário. Para esse fim, alguns fornecedores estão resgatando sua força de vendas existente (ou criando uma equipe de especialistas) para transmitir melhor a funcionalidade e os benefícios dos recursos do produto.
• Pós-compra. Valor dos desenvolvedores Forte suporte do fornecedor para garantir a integração rápida com um mínimo de problemas. Eles também gostam de aproveitar a comunidade para obter soluções de suporte (exceto em áreas de alto risco, como a segurança de aplicativos). As iniciativas de fornecedores incluem fornecer documentação robusta, juntamente com os caminhos de aprendizado e descoberta. Também estamos vendo uma interação mais a longo prazo com os desenvolvedores-equipes de sucesso do cliente-para aumentar a adoção e a retenção. Eles também podem facilitar a exploração do produto e até a integração.

Mas as empresas de tecnologia B2B podem fazer ainda mais para atrair e conquistar os desenvolvedores. Novamente, tudo se resume a permitir que os comportamentos e preferências dos desenvolvedores informem a estratégia. E neste contexto, quatro estratégias são particularmente promissoras:

• Construa uma forte comunidade de desenvolvedores, concentrando -se na moderação do conteúdo, personalização e gamificação da plataforma. Uma vibrante comunidade de desenvolvedores impulsiona a reconhecimento da marca, facilita a interação entre os colegas, fornece suporte de origem da multidão e gera feedback valioso. Não é de surpreender que alguns fornecedores de tecnologia B2B estejam ativamente nutrindo e contribuindo para essas comunidades. Mas existem maneiras de reforçar o esforço. Uma idéia: integrações de produtos. Os fornecedores devem permitir acesso fácil, desde seus produtos até a comunidade de desenvolvedores. Outra prática recomendada é adotar moderação de conteúdo escalável e melhor na categoria. Ao alavancar serviços externos e modelos de IA, como o moderador de conteúdo do Azure ou o AWS Mechanical Turk, os fornecedores podem garantir que os comentários sigam as diretrizes da comunidade, a criação de confiança e promovendo mais discussões entre os membros. E considere gamificação. Descobrimos que experiências semelhantes a jogos podem ser uma maneira poderosa de aumentar o envolvimento nas comunidades. Eles também podem facilitar a exploração do produto e até a integração através de tutoriais on-line gamificados.

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. Comunidade, é claro, é uma rua de mão dupla. Os vendedores experientes não constroem a arena e depois sentam -se à margem. Eles se tornam participantes ativos. Isso é especialmente importante ao se concentrar no segmento de desenvolvedores Native em nuvem. Esses desenvolvedores tendem a valorizar as empresas que contribuem para iniciativas de código aberto. Com isso em mente, os fornecedores poderiam escolher entre várias abordagens para aumentar a conscientização e aumentar sua posição. Uma idéia - particularmente adequada quando os recursos diferenciados do produto impulsionam a vantagem competitiva - é manter o código de um produto proprietário, mas apoiar e contribuir para Projetos de código aberto , como Datadog contribuiu para o projeto de padrões abertos OpenElemetria. Outra abordagem é abrir a base de código principal do produto, permitindo o uso gratuito de uma versão básica, oferecendo uma versão premium com recursos adicionais e proprietários. Esse modelo pode funcionar bem para um novo participante que deseja aumentar a conscientização do desenvolvedor, minimizando o tempo de receita. Finalmente, os fornecedores podem optar por tornar a base de código do produto totalmente aberta. Ao fazer isso, diz o pensamento, eles podem atrair desenvolvedores enquanto provocam receita para ofertas adjacentes. Ótimos produtos geram interesse. Ótimos relacionamentos aceleram as vendas. Especialmente com ofertas mais recentes, como a SASE, muitos desenvolvedores apreciam um forte apoio do fornecedor. Ao fornecer serviços de consultoria a pouca ou nenhuma cobrança, os fornecedores podem suavizar os processos de integração e implementação e também ajudar a aumentar a adoção do produto na empresa. Empresas inteligentes em qualquer linha de negócios estão sempre pensando: o que podemos fazer para tornar a jornada do cliente mais fácil, melhor e, finalmente, mais bem -sucedida? Obter isso é uma vitória para todos. Muitos fornecedores já transformaram suas fusões e aquisições para empresas e produtos importantes para os desenvolvedores. Mas talvez valha a pena afiar o foco. Como os desenvolvedores de aplicativos nativos em nuvem e os engenheiros do DevOps têm influência específica nas decisões de compra, pode fazer sentido priorizar aquisições em torno de marcas e produtos relevantes para esses segmentos. Mas a negociação não é a única flecha na aljava. Os fornecedores que contratam colaboradores de código aberto da lista A (que geralmente têm grandes seguidores) podem achar que eles atingiram um caminho eficaz-e no esquema das coisas, relativamente baixo custo-para alcançar e atrair desenvolvedores. Mas os desenvolvedores de hoje estão tendo uma palavra cada vez mais forte nas decisões de compra. No entanto, eles não são um bloco monolítico, e desenvolvedores diferentes têm necessidades, preferências e influência diferentes. Para alcançar - e conquistar - esse público -chave, as empresas de tecnologia corporativa B2B precisam de uma compreensão mais profunda e diferenciada de como os desenvolvedores funcionam e o que querem ver, tanto de um produto quanto de seu fornecedor. Esses insights podem moldar e impulsionar o marketing, o alcance e
• 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 Estratégias de suporte . E eles podem ajudar a despertar crescimento. Os desenvolvedores não são mais apenas usuários, mas os tomadores de decisão que podem selar-ou matar-o acordo. Parceiro sênior, líder do setor global, tecnologia