Author Archives: Lydia Leong
Vendors, Magic Quadrants, and client status
I’m writing this blog post for vendors who are in Magic Quadrants or who are hoping to be in Magic Quadrants, as well as the Gartner account executives (AEs) who have such vendors as clients and prospects. It’s in lieu of having to send an email blast to a lot of people; since it’s more generic than just my own Magic Quadrants, here it is for the world.
So, to sum up:
Whether or not a vendor is a Gartner client has no bearing on whether they are on a Magic Quadrant, or how they are rated. Vendors should therefore refrain from attempting to use pressure tactics on Gartner AEs, and Gartner AEs should be careful to avoid even the appearance of impropriety in dealing with vendors in a Magic Quadrant context. Vendors should conduct Magic Quadrant communications directly, using the contact information they were given.
And here’s the deeper dive:
Vendors, you’ve been given contact info for a reason. Please use it. As part of the process, every vendor being considered for an MQ is given points of contact — generally an admin coordinator as well as one or more of the analysts involved in the MQ. You’re told who you should go to if you have questions or issues — often the coordinator, lead analyst, or some specific analyst designated as your point of contact (POC). You should communicate directly with the POC. Do not go through your Gartner AE, other analysts that you deal with, or otherwise attempt to have a third party relay your concerns. Also, communicate via the contact you designated as the responsible party within your organization; we cannot, for instance, work with your PR firm. Gartner has a strict process that governs MQ-related communications; we ask that you do this so that we can ensure that all conversations are documented, and that your message is clearly and directly heard.
Yes, we mean it. Please contact us with questions and issues. If you’ve read everything available to you (the official communications, the Gartner documentation on how MQs work, any URLs you were given, and so on), and it doesn’t answer your question, please reach out to us. If you have an issue, please let us know. The analyst is the authoritative source. Anything you hear from anyone else isn’t. Gartner AEs don’t have any kind of privileged knowledge about the process, so don’t depend on them for information.
A vendor’s client relationship is of no relevance. The analysts do not care if a vendor is a client, how big of a client they are, whether they’re going to buy reprints if they get a certain placement, will become a client if they’re included on the MQ, or about any other attempt to throw their weight around. Vendors who try to do so are likely to be laughed at. Gartner AEs who try to advocate on behalf of their clients will annoy the analyst, and if it doesn’t cease, strongly risk having the analyst complain about them to the Ombudsman. In general, analysts prefer not to even know about what issues an AE might be having that may in some way be impacted by the MQ. It may even backfire, as the analyst’s desire to avoid any appearance of impropriety may lead to much closer scrutiny of any positive statements made about that vendor.
In short: Vendors shouldn’t try to go through Gartner Sales to communicate with the analysts involved in a Magic Quadrant. The right way to do this is direct, via the designated contacts. I know it’s natural to go to someone whom you may feel is better able to plead your case or tell you how they think you can best deal with the analyst, but please avoid the urge, unless you really just want a sounding board and not a relay. If you want to talk, get in touch.
Specific Tips for Magic Quadrant briefings
This is part 2 of a two-part post. The first part contains general tips for Magic Quadrant briefings, applicable to any vendor regardless of how much contact they’ve had with the analyst. This second part divides the tips by that level of contact.
Richard Stiennon’s UP and to the RIGHT, which provides advice about the Magic Quadrants, stresses that preparation for this process is really a continuous thing — not a massive effort that’s just focused upon the evaluation period itself. I agree very strongly with that advice.
Nevertheless, even AR professionals — indeed, even AR professionals who are part of big teams at big vendors — often don’t do that long-term prep work. Consequently, there are really three types of vendors that enter into this process — vendors that the analyst is already deeply familiar with and where the vendor and analyst maintain regular contact (no client relationship necessary, can just be through briefings), vendors that the analyst has had some contact with but doesn’t speak to regularly, and vendors that the analyst doesn’t really know.
Tips for Vendors the Analyst is in Frequent Contact With
In general, if you have regular contact with the analyst — at least once, if not several times, a quarter — a briefing like this shouldn’t contain any surprises. It’s an opportunity to pull everything together in a unified way and back up your statements with data — to turn what might have been a disjointed set of updates and conversations, over the course of a year, into one unified picture.
Hit the highlights. Use the beginning of the briefing as a way to summarize your accomplishments over the course of the year, and refresh the analyst’s memory on things you consider particularly important. You may want to lay out your achievements in a quarter-by-quarter way in the slide deck, for easy reference.
Provide information that hasn’t been covered in previous briefings. Make sure you remember to mention your general corporate achievements. Customer satisfaction, changes to your channel and partnership model, financial accomplishments, and other general initiatives are examples of things you might want to touch on.
Focus on the future. Lay out where you see your business going. If you can do so on a quarter-by-quarter basis (which you may want to stipulate is under an NDA), do so.
Tips for Vendors the Analyst Knows, Without Frequent Contact
If the analyst knows you pretty well, but you haven’t been in regular contact — the analyst hasn’t gotten consistently briefed on updates, or been asked for input on future plans — not only do you want to present the big picture, but you want to make sure that they haven’t missed anything. Your briefing is going to look much like the briefing of a vendor who has been in frequent contact, but with a couple of additional points:
Tell a clear story. When you go through the highlights of your year, explain how what you’ve done and what you’re planning fits into a coherent vision of the market, where you see yourself going, and how it contributes to your unique value proposition.
Have plenty of supplemental material. Because the analyst might not have seen all the announcements, it’s particularly important that you ensure that your slide deck has an appendix that summarizes everything. Link to the press release or more detailed product description, if need be.
Tips for Vendors the Analyst Doesn’t Really Know
Sometimes, you just won’t know the analyst very well. Maybe you’re a new vendor to the space, or previously been too small to draw attention from the analyst. Maybe this space isn’t a big focus for you. Maybe you’ve briefed the analyst once a year or so, but don’t really stay in touch. Whatever the case, the analyst doesn’t know you well, and therefore you’re going to spend your briefing building a case from the ground up.
Clearly articulate who you are. Start the briefing with your elevator pitch. This is your business and differentiation in a handful of sentences that occupy less than two minutes. The analyst is trying to figure out how to summarize you in a nutshell. Your best chance of controlling that message is to (credibly) assert a summary yourself. Put your company history and salient facts on an appendix to the slides, for later perusal. Up front, just have your core pitch and any metrics that support it.
Pare your story to the bare essentials. Spend the most time talking about whatever it is that is your differentiation. (Example: If you know your product isn’t significantly differentiated but for whatever reason they love you in emerging markets, sweep through describing your product by comparing it to a common baseline in your market, and conceding that’s not where you differentiate, then focus on your emerging markets story in detail.) If your differentiation is in your product/service and not in your general business, focus on that — you can assume the analyst knows what the common baseline is, so you can gloss over that baseline in a few sentences (you can have more detail on your slides if need be) and then move on to talking about how you’re unique.
Be customer-centric. Explain the profile of your customers and their use cases, and make it clear why they typically choose you. Resist the urge to focus on brand-name logos, especially if those aren’t typical or aren’t your normal use case. Logo slides are nice, but they’re even better if the logos are divided by use case or some other organizing function that makes it clear what won you the deal.
Ensure you talk about your go-to-market strategy. Specifically, explain how you sell and market your product/service. Even if this isn’t especially exciting, spend at least a slide talking about how you’re creating market awareness of your company and product/service, and how you actually get it into the hands of prospects and win those deals.
Provide a deep appendix to your slide deck. You should feel free to put as much supplemental material as you think would be useful into an appendix or separate slide deck for the analyst’s later perusal. Everything from executive bios to a deep dive on your product can go here. If it’s in your presentation for investors, or part of your standard pitch to customers, it can probably go in the deck.
General Tips for Magic Quadrant briefings
Three years ago, I wrote a blog post called “What Makes for an Effective MQ Briefing?” This is a follow-up, with my thoughts somewhat more organized.
For AR and PR people, before you do anything else, if you have not read it, get and read Richard Stiennon’s UP and to the RIGHT. I cannot recommend it enough; Richard has seen the process as both a Gartner analyst and as a vendor, and it is chock full of good tips. It will help you understand the process, how the analysts think, and how you can best present yourselves.
This is part 1 of a two-part post contains the general tips. The next post contains tips that are applicable specifically to each of the three types of vendors. Every single one of these tips comes with one or more horror stories that I can tell you about past Magic Quadrant briefings. What seems obvious often isn’t.
General Tips
Pick the right presenters. You don’t need your most senior executives on the phone. You do need people who can present well, who thoroughly know the source material, and can answer whatever questions arise. Ensure that your presenters will have a good clear phone connection (use of cellphones or speakerphones should be strongly discouraged), and a quiet environment. If possible, choose presenters that speak fluent English and do not have accents that are difficult to understand — even if that requires using someone more junior and simply having the expert or executive on hand to take questions. You may even want to choose presenters that speak relatively quickly, if you feel time-crunched.
Send the presentation in advance. Ensure that you have emailed a copy of the presentation deck, in PowerPoint format, a day in advance of the briefing, to the administrative coordinator (who can take care of distributing it to the analysts). Be prepared to quickly resend it to anyone who has not received it. Do not send PDFs; analysts like to take notes on the slides. If you’re relying on a web conference, make sure that you still send the slides in advance — and get set up on it ahead of time and use a single PC to drive the whole presentation so you don’t waste time and possibly run into technical difficulties switching from screen to screen.
Be on time, and don’t waste time. Make sure that your dial-in number is distributed to everyone who needs to be on the call. Dial into the bridge early if need be. Have someone available to wrangle your executives if they’re running late. Have a backup presenter if you have an executive who’s notorious for not making meetings on time. Do not waste time making introductions. A presenter can briefly state their name and functional role (“I’m Joe Smith, and I run our support organization”) before starting their portion of the presentation. If you think your executive bios are important, include them as an appendix to your slides. Do not spend time having analysts introduce themselves; there are bios for them on Gartner’s website, and they will state their names when they ask questions.
Watch the clock. In a Magic Quadrant briefing, you typically have one hour to present your thoughts. Analysts are almost always scheduled back to back, so you will not have one minute extra to present, and may in fact have several minutes less if for some reason the analysts are held up from a previous meeting. Also, you want to have some time left for questions, so you should target a 45-minute presentation. If you think you have too many slides, you probably do. Rehearse to make sure you can get through your material in 45 minutes, if need be. Do not expect to be given the opportunity to do another briefing if you fail to finish in your allotted hour.
When an analyst prods you along, move on. One or more of the analysts may cut you short and ask you to move to the next slide or even skip a few slides. Listen to this and move on. By the time someone has gotten to the point of cutting you off, the analysts, who are almost certainly in an IM conversation with each other, have all already agreed that what you are saying is collectively useless to them, and that this part of the presentation is dull beyond enduring. If you think that there’s a really important point somewhere in what you’re saying, make it and move on. Or incorporate it into some other part of your presentation. Do not keep plodding along.
Focus on this particular Magic Quadrant’s market. If you have a broad solutions portfolio, that’s great, but remember that the analysts, and this Magic Quadrant, will be focused on something specific. The broader solutions portfolio can be worth mentioning, especially if it allows you to deliver higher-value and directly-relevant highly-integrated solutions, but not at the expense of focus on this Magic Quadrant’s topic. That topic should always be front-and-center. If you’re finding yourself wanting to instead talk about this somewhat-related market that you think you’re much stronger in, don’t — re-focus on the core topic.
Don’t talk about the market in general. Any analyst involved in a Magic Quadrant is, at least in theory, an expert on the market. They don’t want or need to hear about it. The only exception might be if you serve some specialized niche that the analyst does not often come into contact with. Your perspective on the market should be made clear by the specific actions that your company has taken, and will take in the future; you can explain your rationale for those decisions when you go through them, without doing a big up-front thing about the market.
Focus on your differentiation. The analysts want to know what you think makes you different, not just from the market leaders, but from your closest competitors. They want to know who you’re locked in bloody-knuckled combat each day, and why you win or lose those deals. But focus on explaining what you do well and where you intend to be superior in the future — don’t waste time badmouthing your competitors.
Be concrete and incorporate metrics whenever possible. Analysts hear broad directional statements all the time, and are usually unimpressed by them; they’re interested in the specifics of what you’ve done and what you’re going to do. Analysts love numbers. Their lives are full of vendors making grandiose claims, so they like to see evidence whenever possible. (For instance, are you claiming that your customers are much happier this year than last year? Show last year and this year’s NPS scores, ticket closure times, whatever — concrete evidence.) You don’t need to read the metrics. Just make the general point (“customer satisfaction has increased greatly in the last year, as our NPS scores show”), and have the metrics on the slides so the analysts can dive into them later. You can request that the metrics be kept under NDA if need be.
Disclose your future roadmap. A one-year or two-year roadmap, especially one that’s quarter-by-quarter, is going to make a much bigger impression than a general statement about aspirations. If you have to state that part of the briefing is under NDA, that’s fine; the analysts will still factor that information into the rating, implicitly. You may have great things planned, but if the analysts don’t know about them, you’ll get zero credit for those things when they consider your vision.
AR contacts for a Magic Quadrant should read everything
Something for analyst relations folks and the PR firms that help them, to take note of when participating in a Magic Quadrant:
Read every communication that you’re sent, in its entirety.
One might think this would be a simple thing, but multiple years of experience have shown that this is not the case. Granted, sometimes these communications are long, but they are long because they contain lots of information. The information is not gratuitous; it is information that you need to know.
Many vendor AR folks have told me that these communications essentially fall into the TL;DR category — they’re only glanced through. I recognize that it is only human to skim long emails, and even more human to skim through lengthy Word documents. I am resigned to the fact that you may completely ignore even the things that are in boldface type, especially if they’re in the middle of the message or at the bottom. I also recognize that it is only human to ask questions, rather than spending the time to read what you are sent.
But I must also point out that for many vendors, the Magic Quadrant is viewed as a high-stakes exercise that will consume a tremendous number of hours of your time and the time of your executives. You do yourself a disservice if you do not read every single word of every single communication that’s sent to you with regard to the Magic Quadrant. You don’t have to do so instantly, but you probably want to carefully read what you’re sent within a business day — and to take the time to mark deadlines on your calendar, add contacts to your address book, and so forth.
Gartner tries very hard, through the prescribed form-letter formats that it requires that analysts use for Magic Quadrant communications, to make sure that you get all the information that you need. It is true that we generally err on the side of providing too much detail, rather than being overly succinct. This is because we generally try to anticipate the questions that you are going to ask. Also, sometimes we are constrained by the form letter, which requires that we provide certain information in a certain format, which might not be the most concise possible approach.
Many of the analysts try to deal with your collective reluctance to read by making use of boldface and colorful text to highlight critical information, and in longer communications, to put a summary up-front so it’s instantly in front of you. However, in the end, glancing through the highlights and the summary is often not sufficient. There’s simply no substitute for reading everything.
To make sure that you do not drop critical communications into your spam folder, ensure that you whitelist the admin coordinator at Gartner (who will usually be your point of contact and will send out most of the official communications), along with each of the analysts involved in the Magic Quadrant. Analysts don’t do general email blasts. You should even consider just whitelisting gartner.com email addresses.
By the way, if you can spare the time, you also want to read the research that’s been published by the analysts who will be involved in the process, and more broadly, about your market. Some of the analysts blog, so looking through their postings may be helpful as well. Again, it’s time-consuming, but if Magic Quadrant placement is important to your company, it can give you a good idea of what the analysts will care about in their evaluation.
The art of the customer reference
In the course of my career at Gartner, and my pre-Gartner life as an engineering director who spent giant piles of money on purchasing technology that was often very early-stage, I have spoken to an awful lot of customer references. I’m about to soon dive into the reference-a-thon that a Magic Quadrant represents (we call as many as 5 references per vendor), and it’s leading me to think about what makes for a good or a bad reference, from my personal perspective. So, here are some thoughts, targeted at vendors and service providers.
Make sure your references like you. Nothing will create a worse impression than a reference that isn’t happy with you, and hasn’t been happy with you for some time. It’s fine for a reference to currently be having a transient problem, or even to have experienced some kind of disaster — that sometimes even makes for good stories about how good your support has been during the crisis. But a reference that isn’t a promoter is hugely problematic, because not only does it create a negative impression, it makes it clear that you have failed to keep track of this customer’s sentiment, and to communicate internally about it, to the point where you’re using an unhappy customer as a key reference. You should get in touch with your references on a regular basis to make sure they’re still delighted with you.
Your references should be engaged customers. Engaged customers know why they chose you (and can talk about the competition they looked at and why your solution was the best fit for them), have an opinion on their ongoing use of your product and service, and are passionate enough about it to talk about the good and the bad, what you do well and what they’d like you to improve. Customers who are just, yeah, we selected these guys and it all works okay — fine, you’ve checked the box on “you haven’t actively sucked”, but they’ve really said nothing interesting. This can be fine if you’re just offering a reference to a prospective customer (who wants to make sure that you’ve done an implementation similar to the one he’s contemplating and that it went fine), but it’s deadly in an analyst reference (because the analyst is interested in getting a first-hand picture of what it’s like to deal with you and your product/service, and someone who is neither enthused nor analytical makes for a deathly-dull and not very useful reference).
Your references should be targeted. If you are offering a reference customer to a prospect, the reference should be as similar to that prospect as possible, in terms of solution, industry, approach, and role (likely in that order). If you are offering references to an analyst, they should represent a spread of customers — different use cases, industries, and length of time they’ve been customers (from new implementations to long-term customers).
Your references should be representative. If you’re dealing with an individual customer, your references should be as close to that customer’s expected implementation as possible, even if that is exotic. But if you’re dealing with an analyst, the references should be representative of typical use cases, implementations, and customer types. If you choose to offer some more exotic outliers, great, but make sure the analyst knows that they’re not typical of your customer base. You don’t want to give the analyst the wrong impression about who you normally serve.
Your reference list should be periodically refreshed. You want references that are still actively engaged with you, and represent the current state of your business, in terms of version deployed, use case, and experience with your company. While long-term customers are sometimes nice to talk to (especially in a space where customers sign very long contracts, like 7-year outsourcing deals), for products, or for services bought on shorter contracts, current references are very important. If you are offering references to an analyst, especially in the context of a yearly process like a Magic Quadrant, do not repeat references from year to year; not only will the analyst prefer to talk to someone new, but he will wonder why you can’t easily produce new reference customers.
Ignore client relationships with analyst firms. When offering references to analysts, don’t worry about whether or not a reference has a client relationship with their firm. Reference interviews are typically conducted under NDA, and as far as I know across all research firms, without any regard to client status. Even if an analyst helped a client through the process that resulted in your being selected, he might not have gotten any feedback from the client about what has happened since. Even if the analyst has an ongoing relationship with that client, it’s usually in the context of inquiry, where the analyst, constrained by the 30-minute timeslot and the client’s specific questions, rarely gets to satisfy his curiosity. Reference interviews are very different, and the analyst conducting the interview might not be the same one as previously helped the client.
Consider supplementing references with a customer list. A list of customer logos and, if possible, a one-sentence description of their use case, can be extremely helpful for getting a better general understanding of who you serve, and what they use you for. If providing this list to an analyst, it can usually be done under an NDA.
Foundational Gartner research notes on cloud IaaS
In light of the upcoming Magic Quadrant work, I thought it would be useful to highlight research that myself and others have published that is important in the context of this MQ. These notes lay out how we see the market, and consequently, the lens that we’re going to be evaluating the service providers through.
I want to stress that service providers do not need to agree with our perspective in order to rate well. We admire those who march to their own particular beat, as long as it results in true differentiation and more importantly, customer wins and happy customers — a different perspective can allow a service provider to serve their particular segments of the market more effectively. However, such providers need to be able to clearly articulate that vision and to back it up with data that supports their world-view.
That said, if you are a service provider, these are the research notes that it might be helpful to be familiar with (sorry, clients only):
Pricing and Buyer’s Guide for Web Hosting and Cloud Infrastructure, 2012. Our market definitions are described here, in case you’re confused about what we consider to be cloud IaaS.
Competitive Landscape: New Entrants to the Cloud IaaS Market Face Tough Competitive Challenges. This describes the competitive landscape and the challenges of differentiating in this market. It also profiles two sucessful providers, Amazon and CSC, in detail. This is critical reading to understand what we believe does and does not differentiate providers.
Market Insight: Structuring the Cloud Compute IaaS Market. This presents our market segmentation; each segment is associated with a buyer profile. While our thinking has refined since this was published in early 2011, it is still an extremely important view into our thinking about customer needs.
Evaluating Cloud Infrastructure as a Service. This seven-part set of research notes describes the range of IaaS capabilities offered across the market, from the technology itself to how service is done. This provides important terminology, and is also useful for determining how competitive your offering really is. (Note that this is an early-2011 note set, so the state of the art has advanced since then.)
Evaluation Criteria for Public Cloud IaaS Providers. Our Technical Professionals research provides extremely detailed criteria for large enterprises that are evaluating providers. While the customer requirements are somewhat different in other segments, like the mid-market, these criteria should give you an extremely strong idea of the kinds of things that we think are important to customers. The Magic Quadrant evaluation criteria will not be identical (because it is broader than just large-enterprise), but this is the kind of thing you should be thinking about.
Market Trends: Public and Private Cloud Infrastructure Converge into On-Demand Infrastructure Fabrics. This describes our view of how the service provider cloud infrastructure platforms will evolve, including providing a perspective on public vs. private cloud, and developer-class vs. enterprise-class cloud.
Best Practice: Evaluate Isolation Mechanisms in Public and Private Cloud IaaS. Many service providers are using “private cloud” in ways we consider actively deceptive. This note provides a warning to IT buyers, and discusses the kinds of isolation options that are available. This emphasizes our insistence that providers be transparent about their isolation mechanisms and security controls.
Less-critical notes that cover narrower topics, that you may nevertheless want to read:
Market Insight: Customers Need Hybrid Cloud Compute Infrastructure as a Service. This describes customer requirements for “hybrid” scenarios — the need for cloud bridging into the enterprise data center, physical-virtual hybrid environments, hybrid hosting, and multi-cloud environments.
Infrastructure as a Service in the Cloud Services Value Chain. This describes the overall place of IaaS in the value chain. It explains market evolution and how this impacts upstream and downstream technology vendors; it provides our viewpoint on the channel.
Toolkit: Mitigating Risks in Cloud Infrastructure as a Service. This provides a fairly comprehensive checklist for risk assessment. You may want to think about how well your solution addresses this list of risks.
Delivery Models for Application Infrastructure in the Cloud: Beware the Lure of False PaaS. This provides software and middleware licensing models, and contrasts IaaS vs. PaaS. Pay particular attention to the importance of software marketplaces.
If you are not a Gartner client, please note that many of these topics have been covered in my blog in the past, if at a higher level (and generally in a mode where I am still working out my thinking, as opposed to a polished research position).
What would make the Cloud IaaS Magic Quadrant better?
At the risk of opening up a can of worms:
As a user of the Public Cloud IaaS Magic Quadrant — either as a technology buyer looking to make a vendor decision, or as a vendor looking to understand the market, what would make the document better?
Understand that I cannot change the process itself (which Gartner explicates to its analysts in a lengthy, excrutiatingly detailed document with oodles of accompanying paperwork, and while internally we may discuss what improvements could be made, from my perspective from a practical standpoint of an MQ being done right now, the process might as well be handed down on tablets of stone).
However, there are plenty of things that are not covered by the process, from the way communications are done to the information contained in the document. I am genuinely interested in what I can do to make the document more useful, as we embark on the 2012 update.
(Yes, we’re on a faster-than-annual update cycle due to the speed at which the market is moving.)
Free free to comment on my blog, or email me privately.
UP and to the RIGHT
Richard Stiennon, a former colleague of mine (he was a security analyst at Gartner from 2000-2004), has just written a book, “UP and to the RIGHT: Strategy and Tactics of Analyst Influence: A complete guide to analyst influence“. It’s a good guide to analyst relations in general, but it’s focused on Gartner, and especially the Magic Quadrant. If you’re someone who deals with analysts, I highly recommend it.
Chunks of the book were laugh-out-loud funny to me (and I read parts of it aloud to my husband, who works for a vendor and whose commentary on the MQ process once led to me posting on How Not to Use a Magic Quadrant with a three-frowny-quadrant graphic). Although almost a decade has passed since Richard worked here (a lot has changed since then, not the least of which is the MQ process), he’s done an excellent job in doing the research to reflect how things have evolved here — it’s still the best bit of writing I’ve seen that reflects the way that Gartner analysts work. I don’t agree with him 100%, but I think that as a broad reflection of the company, its analysts, the Magic Quadrant, and what we’re influenced by, it’s pretty much right on the money, right down to the desperation for a break in the 1-on-1 room at conferences.
(Side note: Unlike Richard and many of my current colleagues, I actually love doing 1-on-1s at Gartner conferences. You talk to a different sort of buyer at conferences — lots of mid-market CIOs, especially. They’re great conversations. However, the sheer volume is exhausting. I can end up taking 16 to 18 meetings a day at a conference — starting at 7 am and ending around 11 pm, only to go back to my hotel room and still need to answer emails. If I’m really unlucky, I will be up before 7 am to take a phone inquiry or briefing. And at Symposium especially, with the bathrooms 10 minutes away from the 1-on-1 tent, any break time vanishes quickly, and good luck getting lunch. Much like Richard writes, though, I assure you that anyone who didn’t take every last minute, or didn’t mind me getting in a few bites of food while they were talking, I remember fondly. I also clearly remember the folks who complained when I had to take an emergency bathroom break, shortchanging them five minutes of their 1-on-1 slot.)
Richard does an excellent job of emphasizing that the process of analyst influence is a long-term, year-round thing. If you’re starting it only when the MQ cycle is formally initiated, it is too late. (I’ve noted this before in my blog post about effective Magic Quadrant briefings.)
One important thing that Richard has missed, I think, is the importance of Gartner’s acquisition of the Burton Group back at the end of 2009. Gartner now calls that product “IT Professionals” (ITP), and its analysts are still a separate cadre but part of the larger research community on any given topic. ITP focuses on practitioners, and their analysts tend to be very hands-on. Many of Gartner’s recent hires into the general analyst cadre are also practitioners (i.e., folks who were in architect roles, rather than IT directors). That means that you can increasingly expect that at least one analyst involved in an MQ will work with the products hands-on to some extent, although that’s not likely the case with anything that really requires a complex implementation (like ERP, for instance).
The guerilla tactics that Richard describes are clever. I don’t know how well they work, but I suspect they exert a subtle mental tug. I can tell you that the more deeply I am acquainted with a vendor and the more frequently we interact — which does not, by the way, even require being a client — the more meaningful their Magic Quadrant write-up (although that doesn’t necessarily reflect dot placement).
Magic Quadrants are always going to be a subjective process, because in the end, rating and reviewing products, services, and companies is a subjective process. What’s important to one person is not necessarily important to another; the market viewpoint represented will reflect the consensus opinions of the analyst team involved but may also heavily tilt towards the lead analyst’s perspective on the market. In the end, even the most pedantic approach to quantitative scoring still requires judgment to award points — if five vendors all implement the same feature in slightly different ways, someone has to make a judgment call that stack-ranks them. Having experimented previously with Magic Quadrant spreadsheets that had ninety rating aspects per vendor, I can say that it was mostly a waste of time to get super-granular, as well. The Magic Quadrant is ultimately a graphical representation of a thought process; it is not a function-point analysis.
Call for vendors – 2012 Cloud IaaS Magic Quadrant
We’re about to kick off Gartner’s 2012 Cloud IaaS Magic Quadrant.
A pre-qualification survey, intended to gather quantitative metrics and basic information about each provider’s service, will be going out very soon.
If you are a cloud compute IaaS provider — that means you offer, as a service, fully-automated, self-service compute, storage, and network infrastructure that is available on-demand (think “by the hour” and not “by the month”) — you did not receive a survey last year, and you would like to receive a survey this year, please contact me via email at Lydia dot Leong at Gartner dot com.
Note: This is not hosting and this is not data center outsourcing. You should have a fully-standardized offering — one that is identical for every customer, not a reference architecture that you customize — and customers should be self-servicing (i.e., they go to your portal and push buttons to immediately, with zero human intervention, obtain/destroy/configure/manage their infrastructure), although you can optionally provide managed services.
Also note: This is not for software or hardware vendors. This is for service providers.
Bottom line: If you don’t consider yourself to be in competition with Amazon EC2 or the Terremark Enterprise Cloud, to take two well-known examples, this is not your Magic Quadrant.
Please note that receiving a survey does not in any way indicate that we believe that your company is likely to qualify; we simply allow surveys to go to all interested parties (assuming that they’re not obviously wrong fits, like software companies without an IaaS offering).
Corporate culture and women in IT
So, I want to start this blog post by stressing that, like all of my posts, according to Gartner’s policies, it is strictly personal opinion. But I feel like this issue is important, and that I can say something constructive in the conversation around the role of women in technology and the culture of technology as it relates to women.
Last month, Dell held a customer and partner summit in Copenhagen, Denmark. During that event, keynoted by CEO Michael Dell, “entertainer” Mads Christensen delivered a set of comments throughout the afternoon that began with, “The IT business is one of the last frontiers that manages to keep women out. The quota of women to men in your business is sound and healthy,” (and asking the women, “What are you actually doing here?”) and ended with telling all the men in the room to promise him they’ll go home and say, “Shut up, b*tch!”
Journalist Christiane Vejlo live-tweeted and blogged the event, and it’s since started something of a growing firestorm on the Internet. Dell acknowledged in a tweet that the remarks were “inappropriate”, and today has issued an apology — in the relatively private confines of Google+.
I find the entire incident to be appalling. I’ve attended conferences in Copenhagen in the past, and indeed, all over the world. I cannot imagine another global technology company which would have scheduled this speaker for an event. (VMworld Europe is in Copenhagen. Can you imagine VMware hiring that guy to entertain?) I’m somewhat surprised they actually allowed him to continue speaking once it was clear that he was going to be offensive — or for that matter, not issuing an official apology from the stage at the time, or even stopping the “show” early. These are not borderline-offensive remarks. These are outright hostile, and I imagine that any line manager at Dell caught uttering them to his staff would be promptly escorted out the door by HR. Given that, the apology should have been issued in Dell’s normal press release channels, and not in the limited-viewership world of Google+.
However, in reading the comments threads on the various news articles about this, I’ve been struck by a lot of the commentary — from the doubting this-is-a-feminist-lie “show video or it didn’t happen”, to “women are biologically less fit to be in technology”. It makes me reflect upon my career in technology, the conferences I’ve been to, the client organizations that I’ve seen, and the way that I’ve been treated.
This is a shortened form of the much longer post that I originally wrote, in the interest of not writing an epic; I may post the rest separately at some later date, but for this, I’ll focus on just one observation.
Corporate Culture Makes a Crucial Difference
I’ve spent over a decade at Gartner, and I’ve dealt with an incredible array of IT organizations, and in each of those organizations, you’ll find a different attitude towards women — and therefore a different proportion of women, especially at the mid- and senior levels. (Note that I’m talking about the IT operations and development, excluding the admins, procurement, non-technical project managers, etc.)
However, in most of the IT organizations I’ve dealt with, there are either plenty of women, or there are a handful of women (maybe even zero or one woman in a technical role); there’s very little in-between. Note that this can be different in different parts of the organization; you might have a team that for whatever reason is particularly good at hiring and keeping women, but in general, if it’s just a team, that team is anomalous in an otherwise male organization.
For instance, there are a huge number of successful women in US federal government IT — and, for that matter, minorities historically severely underrepresented in IT (i.e., non-Asians). Rigorous nondiscrimination, along with the availability of successful mentors, leads to hiring and promoting women — in technical and technical management roles that require ‘hard’ skills as much or more than ‘soft’ skills. This includes places that you would normally expect to be male bastions, like the 3-letter agencies — and in traditionally enormously male-dominated specialties like InfoSec. Teams are mixed-gender and mixed-race; the balance suggests that these organizations attract an enormously disproportionately high percentage of qualified women and underrepresented minorities. My experience is that those people are just as competent, if not more so; quality is not being sacrificed, probably because they get a better hiring pool.
On the other hand, I’ve also visited a Fortune 500 company where the Gartner salesperson was explicitly told that they weren’t comfortable with a woman telling them what to do, and that we shouldn’t bring any more female analysts by to visit them — they said would rather deal with a man, even if that man did not have the same level of subject-matter expertise. Unsurprisingly, I didn’t meet a single woman in IT there. (That’s not an isolated incident; I have many more stories of this sort, although that one is notable because they had dealt with multiple superbly-expert female analysts.)
But most corporate cultures aren’t so blatant. Instead, there are subtle and not-so-subtle indicators about the degree to which women are welcome and respected; these messages come from the top, but may also be reflected in the culture of an individual team, especially given the attitude of a line manager, technical lead, or influential engineer. These things generally directly correlate to the probability of hiring, retaining, and promoting women.
I find it to be an interesting indicator of a company and individual’s assumptions when they’ve read my official Gartner bio (which emphasizes my background in operations and engineering) and how much they ‘talk down’ to me technically nevertheless — particularly when I frequently also had a male analyst colleague on the phone without a technical background, despite having the bios, there were still plenty of people who would de facto assume he was technical and I wasn’t. (Note to AR folks: I hate this.)
Conferences are one of those places where the company’s hidden attitudes come to light. Does the company make use of booth babes? Does the company respect a code of conduct that ensures that presentation material (including from outside speakers) doesn’t contain unprofessional imagery and examples? Is the entertainment particularly targeted towards men? (Note that yes, IT demographics encourage targeting men, but perpetrating this also ensures that it will remain men.) There are comfort things for women, as well — for instance, does the conference provide adequate security and response to harrassment?
And of course: Does your company CEO witness your company-hired entertainer make grotesquely offensive remarks, and not apologize instantly on behalf of your company, to your partners, clients, and employees, for having been party to this?
If you work in technology, regardless of whether you’re male or female, ask yourself: What do I really think about women in technology? And the lack of women in technical roles? How do my attitudes influence my actions, in subtle and not-so-subtle ways?