A Taxonomy of Technology Partnerships

Few buzzwords in the tech sector are as ubiquitous and fractally complex as “partner.” Nearly every software company’s marketing website has a page devoted to their partner program or ecosystem. In presentations, analysts can count on seeing a slide in their promotional deck touting a series of auspicious names (usually featuring AWS, GCP, and Azure) with which they are partnered. These partners are more than just super-clients: they are instrumental to a firm’s business and marketing strategy. However this industry’s dynamism is causing partnerships to expand from the well-known vertical model of Channel partners.

Today, packaging is often at the heart of tech partner relationships. Instead of cobbling together several isolated products (DB, microservices, observability tools, cloud storage), which may or may not play nicely together, partners market known, tested solutions by assuring consumers that their offerings are complementary. This is an absolute boon in this complex and diffuse market. Here at RedMonk we have long argued that packaged products are a tremendous draw for consumers, and partnerships simplify the selection of a fully packaged solution.

Partnerships also enable vendors in the sprawling tech space to leverage their individual strengths. By partnering, enterprise firms can offload the burden of in-house development of niche services. At the same time, smaller companies benefit from the brand recognition that larger companies boast.

It is noteworthy that vendors have moved away from lumping all partners together in the Channel container. Partnership models are increasingly hyper specialized in the tech market, and should be referred to as such.

My taxonomy outlines and defines several of the common partner relationships that I have encountered in the wild. These relationships among tech vendors usually appear in strategic conversations concerning marketing and GTM, and they represent an evolution from the established Channel partner program model. In other words, these relationships are not new, but the what, where, why and how is shifting.

1. Co-marketing Partner: This type of partnership emphasizes complementary solutions. One of the most famous is IBM and Red Hat’s co-marketed products, which preceded (and possibly heralded) the acquisition. These partnerships enable companies to pool their resources (customer lists, advertising) while acknowledging each participant’s unique advantages. For instance, in their more hardware focused days, IBM partnered with smaller, regional companies because it was not strategic to reach outside their core product areas.
2. Defensive Partner: Recently, partnerships have arisen as a defensive strategy. This partnership model emerges from the broader coalition theory of partnerships. Importantly, at GoogleNext 2019 several companies announced a special partnership between those threatened by AWS. As my colleague Stephen O’Grady wrote: “Among the commercial open source providers that have been concerned enough about AWS to make changes to their license structure are Confluent, Elastic, MongoDB, Neo4j, and Redis Labs. On Tuesday, Google announced “strategic partnerships” with the same companies: Confluent, Elastic, MongoDB, Neo4j, and Redis Labs – along with DataStax and InfluxData.”
3. Implementation Partner: We typically see this type of partnership with System Integrations firms and consultancies. Partners are preferred third parties that pair up in order to make their products work. Accenture, for instance, boasts an extensive list of what they term “ecosystem partners.”
4. Reselling Partner: one of the most financially significant partner relationships is that of reseller. Verified partners can sell a third party’s product(s), usually with a commission, without involvement with this partner’s sales team. This relationship is often the consequence of acquisitions (think Microsoft and GitHub). The reselling partner’s importance has resulted in the rise of the Partner Manager role as well as Partner Relationship Management (PRM) applications like PartnerStack and Allbound for keeping track of these relationships. Both AWS and RedHat, for instance, have marketplaces where customers can purchase partner products. This marketplace isn’t always lopsided, in the sense of large firms selling small company’s products (AWS can sell VMware; RedHat sells Redis).
5. Technical Partner: This subset of the co-marketing partnership is intended to fill gaps in a product or service’s technical capabilities. These partnerships tend to anticipate and address practical developer problems, and as such are often geared more towards practitioners than the C-Suite. Technical partnerships ensure that vendors group their software offerings to meet developer needs, and increasingly have taken the form of cloud integrations. Tools connecting applications, repositories, and IT environments for data and processing benefit particularly from technical partnerships between individual vendors. Dynatrace’s DevSecOps Automation Alliance Partner Program is a useful example of an integration-focused technical partnership.

The relationships outlined above are not mutually exclusive. A reselling partner might also be a co-marketing partner and a technical partner. However, I find the exercise of parsing partner types useful for gaining an understanding of these significant relationships.

Am I missing any partner relationships? Please educate me in the comments section below.

Disclosure: AWS, Datastax, Dynatrace, GitHub, Google Cloud, Microsoft, MongoDB, InfluxData, Neo4J, IBM, RedHat, Redis, and VMware are RedMonk clients.