The Legal and Procurement Guide to Working With RedMonk

Welcome! If you’re reading this, you have likely been engaged as part of the process for purchasing a RedMonk subscription. We look forward to working with you and we are happy to answer any questions that you might have.

This document is the product of dozens of conversations and engagements with legal and procurement departments from companies large and small. It is intended to explain how analysts work broadly speaking, how RedMonk works specifically and to address the most common issues we encounter and how we have resolved them historically. There are a few principles RedMonk is unable to compromise on, as discussed below, but we try to be as flexible as we possibly can, understanding the importance of legal and procurement function’s role in this process.

Analysts are not “Contractors” or “Vendors” in the traditional business sense.

By far the most common problems we resolve in contract negotiations stem from the usage of overbroad and/or contracts rife with inapplicable provisions. For example, many large organizations begin by asking RedMonk to sign Master Service Agreements (MSA) that were originally designed for systems integration consultants, web-designers, vendors of specific products (like software or hardware), or other similar contractors. This intent can be inferred by provisions such as:

  1. The right to audit extensive work records to (ostensibly) determine accurate and fair billing;
  2. Extensive background checks on RedMonk employees;
  3. Unusually large liability, worker’s comp or other business-related insurance requirements;
  4. Overbroad assignment of RedMonk’s pre-existing intellectual property associated with the engagement;
  5. A complete ban on disclosing the existence of a commercial relationship between RedMonk and a client; and
  6. Requests for warranties on delivered products.

If you are contracting with external personnel who will be working onsite to build you a website or enterprise application, for example, these requirements are sensible. If they build an application for you, it is important that you own it; if they’re working onsite in moderate to large numbers, it is important that they are vetted and insured against injury or other potential workplace issues; if you have large teams working on large projects, you want the ability to examine what work was performed and why; if you have external contractors building applications for you, you may not wish to disclose this for competitive reasons; if you have a website, app or other product built for you it is important to have assurances that it works.

None of these apply to RedMonk, however, because RedMonk is an analysis firm, not an onsite contractor building something or delivering a product. Companies engage RedMonk and its professionals because they seek our advice and our expertise. The following sections explain why in more detail.

Auditing

Auditing policies are less common than some of the other provisions discussed here, and they are uniformly oriented towards large to very large projects. As any project of extensive scope is guaranteed to have a multitude of moving parts and opportunities for cost overruns and overbilling – either intentional or unintentional – it is natural that some companies have standard requirements for project audits.

This is both unnecessary in RedMonk’s case and impossible for us to comply with.

Taking those issues in order, let us first explain why auditing is unnecessary. In this regard, it has often been helpful to describe the nature of a standard engagement with RedMonk. Unlike large projects built over long periods of time by large teams, RedMonk’s engagements are often smaller by comparison. Advisory sessions, for example, are most commonly an hour or two in duration, and most often staffed by one or two analysts. More importantly, the hourly cost is agreed to in advance by the client before an advisory session proceeds. RedMonk recommends staffing and duration, and the client can decide to proceed, cancel, or modify the recommendation as they see fit. We try to be as transparent as possible in this regard. In fact, these recommendations are often included in our standard consulting agreements.

In this example, then, there is little or nothing to audit except the cumulative record of these interactions, which is already shared with the client by default or can be queried at any time via our account representatives. All of our engagements behave in a similar fashion; whether it’s an advisory session, a speaking engagement, quantitative research, a video or another project type, the same client-controlled workflow is used. That is why auditing is unnecessary: it would involve little more than a review of communications already in a client’s possession.

Additionally, we cannot agree to an audit clause because of the extensive non-disclosure and security agreements we maintain with numerous other clients. As a company that works with dozens of companies large and small, many of which are competitive with each other in some form or fashion, RedMonk relies on a reputation for being able to keep information shared with us confidentially confidential. If we agreed to an audit clause, especially an overbroad clause that grants access to all of our client records, in even a single agreement, our reputation would be irreparably damaged and we would risk breaching our legal non-disclosure obligations to other clients.

While committed to full transparency with our engagements, then, audit clauses are a non-starter.

Background Checks

Large corporations often conduct routine background checks on their employees. It is understandable that those companies, who also engage large numbers of contractors – many if not most of whom will be onsite long enough to be indistinguishable from employees – would want guarantees about the background of onsite contractors, particularly when they are working alongside with the company’s employees and working with or having access to highly confidential information.

As noted above, the overwhelming majority of RedMonk’s work, however, is remote and conducted by phone or video conferencing software. It is comparatively rare that RedMonk visits a client onsite, and when this occurs it is always and exclusively to conduct interactive, dialogue-driven sessions with clients. These sessions are frequently from an hour to half a day, and never exceed a single day in length.

Insurance

As with all professional businesses, RedMonk carries a variety of standard insurance packages ranging from general, errors and omissions and professional liability to worker’s compensation. The coverage limits have been fairly standard over the past decade or more, and are rarely if ever an issue.

Occasionally, however, a procurement department will request either a new package or liability limits far exceeding what we currently maintain and far exceeding a reasonable amount for a company of our size. While we are always willing to explore these requirements, in most cases anomalously outsized requirements stem from the aforementioned assumption that workers will be onsite for extended periods of time, and therefore employers want to safeguard themselves with higher insurance levels.

As discussed above, RedMonk is rarely if ever onsite, and never for more than a day’s time. This is why our existing clients are comfortable with the insurance coverage we maintain, and why RedMonk generally prefers to maintain these standard, industry-accepted levels.

Intellectual Property

Perhaps the biggest distinction between an analyst business, such as RedMonk, and vendors or contractors such as design studios or systems integrators, is in the nature of the work product. The latter’s output in virtually every case will be a tangible asset; a website, an enterprise or mobile application, an integration of two systems, or similar. As with a tangible, rivalrous physical good, it is necessary and appropriate that the client of one of these contractors wholly owns the work product. No bank, for example, wants to subsidize a competitor by paying a systems integration firm to build it a mobile app, only to see that exact same application sold at a discount to its rival.

RedMonk’s work product, however, is not a tangible good. RedMonk’s primary product research, analyses, and writings, all of which represent our ideas, expertise, knowledge, and experience; our intellectual property, in other words. Occasionally, we create materials at a client’s request. These might include a document, slide deck, or video, all of which RedMonk is more than willing to assign to a client. Every client that engages RedMonk does so because they want our analysis. How we apply that analysis to each client is unique and particular to that customer and their specific inquiry. However, we cannot cede carte blanche control of our intellectual property – which is, again, our primary work product – to clients in the way a systems integrator might a built application.

To provide a more concrete example, many customers have engaged RedMonk over the years to discuss our thesis concerning developers as the New Kingmakers. If we were to exclusively license the intellectual property behind the New Kingmakers to a client as many of the Master Service Agreements we see initially require, we would forfeit the right to this critical intellectual property, damaging our business in the process.

We are always willing, to the extent necessary, to grant non-exclusive licenses to leave behind materials such as documents or slide decks. But to continue operating, we have to retain full control of the intellectual property upon which our business is based.

Publicity

One of the most misunderstood requirements RedMonk insists upon in our agreements is publicity, or as we refer to it internally, the right to disclose. The majority of RedMonk’s clients see a benefit to being public about their relationship with our firm; they ask us, in fact, to have their logos listed on the website as clients and supporters because they want to be recognized by developers as supporters of developer-oriented research.

We absolutely do not require this, however, and in fact we have many clients who, for a variety of reasons, restrict us from using their logo, mark or otherwise. Whether the objections are based on a desire to not be seen as recommending a particular service or just a matter of overbroad corporate brand restrictions, we raise no objection to clients that do not wish to be cited as such on the clients section of our website, or in other promotional forms.

What we do require of every client, however, is the right to disclose the existence of a commercial relationship if or when said client is mentioned in a piece of RedMonk research. See the following, for one example:

This is not for publicity reasons, which is why we describe this as “disclosure” rather than the “publicity clause” common to large organizational agreements, but for the sake of transparency.

Our promise to every consumer of our research is that they will be able to make their own judgements about potential bias or undue influence by knowing that every piece of research that RedMonk produces will disclose who is and who is not a paid client of the firm. Because we have paid relationship with many companies covered, this transparency is essentially to ensuring the quality, trust and reliability of our research.

This policy, importantly, relies on the non-existence of exceptions. Every client that RedMonk takes on has agreed to this policy, and there have been a small number of companies that have either extensively delayed an engagement or that we have been unable to work with entirely because of this restriction. If we granted even a single exception, however, the transparency we rely on so heavily would be fatally and irredeemably compromised.

We do not disclose anything beyond the existence of a commercial relationship, importantly. We do not and will not disclose the nature of the work performed, the duration or size of a particular engagement, or even which of many products or teams we worked with either during or after an engagement.

Warranties

In cases where a contract governs the delivery of a tangible product, warranties are an understandable and necessary provision. Because RedMonk is not delivering a tangible product whose functionality can be tested and measured, however, warranties cannot be applied to the work product we deliver. It is impossible to warranty or otherwise guarantee the advisory assistance we provide or even the webinars, screencasts or other media we might deliver. As a result, warranty clauses don’t apply to our work.

Potential Remedies and Solutions

Hopefully, the above has provided some insights not just into some of the issues we face, but why they are common, and why they present issues for working with RedMonk. As mentioned, there are some issues such as disclosure that we are simply unable to compromise on in any meaningful way. That being said, there are some workarounds that we have found either in the substance or process that have been useful. They are listed below.

  1. Use an Appropriate Analyst Contract:
    Most large companies have, somewhere in the organization, an existing paid relationship with an industry analyst firm. We have found great success on certain occasions by dropping an ill-fitting consultant-style contract in favor of another designed for and with analysts in mind. Many of the above issues are retired immediately in this scenario.

    If at all possible, then, it is worth inquiring around the organization to see if a better contract is available because adapting it is less work than for one originally written for businesses with very different work methods and outputs than industry analysts.

  2. Override the MSA with the SOW:
    In many cases, organizations are unable for a variety of reasons to make substantive changes to a Master Services Agreement. Even in cases where individuals within legal or procurement departments have agreed it’s necessary, processes may just not allow for the agreement to be modified.

    In such cases, what we have had success doing is inserting the necessary modifiers into a Statement of Work with the provision that where the two conflict, the SOW has the ability to override the MSA’s policies and provisions. This has resulted in a process in which the MSA is agreed to without revision, but in which the requirements for an analyst firm broadly and RedMonk specifically are included and activated in a manner that allows the engagement to proceed in as frictionless a manner as possible.

  3. Leverage RedMonk’s Contractual Language:
    RedMonk is ready and willing to work with client legal teams to balance client and RedMonk needs with language protecting both. In some cases, however, this has slowed internal acceptance as our internal clients need to wait on legal to generate language meeting the designated requirements.

    While leveraging it is certainly not a requirement, it is important to note that we have existing clauses covering all of the above requirements. This language is not, unfortunately, industry standard in the way that an open source license might be, but it has been previously cleared and approved by many large, competent legal departments.

    If a client wishes to write their own modifiers, then, we are happy to review them. But it can be much more efficient to review the pre-existing language that we have relied on for many years with a large number of clients.