Category Archives: Analyst Life
My Q1 2022 research agenda
This is the time of year when AR professionals ask analysts what they’re planning for next year. I don’t plan a year in advance. I tend not to even plan a quarter in advance. I write when the mood seizes me, which is probably unfortunate, but given that I write a lot it’s… okay-ish?
But I have a bunch of things drafted (either fully or partially) and that should get released in Q1 of next year. I have a general goal of trying to ensure that I back the advice I write for cloud architects with something for the CIO and other executive leaders that provides a bottom-line strategic summary, and/or material for the other teams the architects work with, so that I publish stuff as part of a set, either alone or in collaboration with analysts in other areas.
Cloud resilience (January): It’s increasingly common for clients to ask about architectural standards for HA/DR in the cloud. This note dissects why cloud services break, how to set architectural standards for HA and DR/failover (i.e. when to be multi-AZ, when to do cross-region failover, etc.), and some basic guidance on stability patterns (use of partitioning, bulkheads, backpressure, etc.)
Cloud self-service (January): Thankfully, most organizations are moving away from a service catalog-driven approach to cloud self-service in favor of cloud-native self-service. This note is about how to empower technical teams with self-service, while still providing appropriate governance.
The cloud operating model (February): Many clients are asking about how to organize for the cloud. This will be a triple-note set — one on designing a cloud operating model, one on implementing the operating model, and a colorful infographic summarizing the concept for the CIO and other executive leaders. It combines my previous guidance on Cloud Center of Excellence (CCOE), structuring FinOps and cloud sourcing, etc. with some new work on program management, and takes a deeper look at all the ways you can put this stuff together.
Cloud concentration risk (March): Concentration risk is a hot topic right now, especially in regulated industries. This concern spans IaaS, PaaS, and SaaS, and the dependencies are not always clear, so many organizations have concentration risk they’re not aware of. I intend to write a baseline note that other analysts have committed to contextualizing for audiences in different industries, as well as for cloud managed and professional services providers. While the sourcing risk of concentration remains minimal, the availability risks of concentration can be meaningful. An organization’s risk appetite and the business benefits of concentration should determine what, if any, steps they take to address concentration risk.
IaaS+PaaS provider evaluation update (April): Getting updated vendor evaluation research out in April basically means spending a good chunk of the first quarter doing that evaluation. (My January notes have already been written. And the February ones are mostly complete, so the schedule above isn’t implausible.) We are not currently discussing the form that this evaluation will take. Gartner management will communicate appropriately when the time comes (i.e. please don’t ask me, as I’m not at liberty to discuss it).
An analyst day in the life: Plague Year edition
I was chatting with someone in vendor analyst relations the other day, who was jokingly asking me about a “day in the life” glimpse at what I do. I thought that might make an entertaining post from pandemic-land. So this is what that day looked like.
8:30 am: Woken up by munchkin, who wants a snuggle, presumably to generate enough cuteness to have videos unlocked on the iPad. (It’s spring break at his preschool, but my husband and I are working, and therefore anything that buys silence is worthwhile.) Get up, get dressed, view the munchkin’s “Dino Center” which has been erected outside the master bedroom door as a set of plastic dinosaur landmines waiting to be stepped on by unsuspecting parents.
8:45 am: Starting-the-day tasks, which occupy all the time until my first meeting of the day.
- Work email: Respond to inquiry-routing requests. Contribute to various research community discussions, including consensus on the recent Azure Active Directory outage. Answer various other internal questions. Do some back-and-forth with vendors about research projects I’m working on.
- Catch up on Teams messages: Interesting stuff on what’s been seen the previous day on cloud contracts, cross-team discussion on the right HA/DR patterns in cloud architectures, miscellaneous salespeople wanting help with a client.
- Prep for the day’s client calls: Read request, supporting docs, company background, past inquiry history, etc.
- Personal stuff: Look at personal email, glance at Facebook, check in on social Slack, do daily tasks on an iPad RPG game (gotta hand it to those guys for ensuring daily addictive habits are maintained).
10 am: Weekly one-hour team meeting. Various administrative matters. Eat breakfast on call.
11 am: One-hour vendor briefing on new product release.
12 pm: 30 minutes of “free” time, which will be my only respite until the end of the work day. Order lunch. Answer email/Teams, check in on Twitter. Work on responding to peer review comments on a doc.
12:30 pm – 4 pm: Back-to-back inquiries with 6 different clients. This runs from everything from a 30-minute chat with the CTO of a major global outsourcer (who wants to know about the latest trends impacting cloud adoption) to spending an hour with a cloud architect who’s dealing with the merger of two companies (one of whom is all-in AWS and the other is all-in Azure) and needs to untangle wide swathe of multicloud issues. While on the phone:
- I feed lunch to the munchkin (who eats his fries, but none of his grilled cheese sandwich, it will turn out later), and get a few bites of lunch myself.
- Cope with munchkin bombarding me with drawings of invented “Pokemon” with increasingly weird names (and evolutions that look like they belong in Pacific Rim rather than cute anime), done in the style of his dog-eared Pokedex encyclopedia, complete with type, region, and diet.
- Navigate minor crisis created by munchkin’s uncertainty over how to spell “region” (thank you, mute button).
4 pm: 30-minute break so I can drag munchkin onto a Zoom call for his Suzuki violin lesson. Bribe him to cooperate with the promise of one forkful of pie if he also stays quiet until I’m done with calls for the day. Yay, bio break.
4:30 pm: Another inquiry.
5 pm: Talk to reporter in-depth regarding breaking news plus a longer-form article they’re working on.
5:30 pm: Check back in on Teams. Discuss breaking news, load-testing in the cloud, pricing comparison between cloud providers, data protectionism, the role-change of a colleague, and other miscellany.
6 pm: Faceplant. (Count for the day: Seven inquiries, plus three other meetings.) Husband works from the master bedroom, so there is background grumbling at his code. Munchkin reminds me that I still owe him pie.
7 pm: Order dinner. Promise munchkin he can also have ice cream if he cooperates with violin practice. Painstakingly teach munchkin to memorize exactly two lines of a new piece of music. Reward munchkin with precisely one bite of pie. Read various violin-related things for myself.
8 pm: Family time. Which is:
- Dinner (and ice cream). Insist munchkin consume some protein.
- Cleanup. Munchkin protests mightily at being told to clean up the floor, which is absolutely blanketed in faux-Pokemon drawings (sometimes cut out and taped to popsicle sticks to make “puppets”). Floor largely remains Study in Deconstructed Japanese Monsters.
- Bedtime negotiation. Munchkin points out that since he went to bed properly the previous night (rather than staying up reading surreptitiously in his closet out of the view of the camera), he has earned the fifth reward-chart star necessary to get the next book in the “Bad Guys” series, and that therefore I must order it from Amazon (despite the abject failure to actually get the reward system to produce a good habit). This is book #10 in the series; I admire the ability of children’s chapter book authors to turn out infinite content. Also, while he’s at it, he wants books on calligraphy and making “realistic” drawings rather than cartoons.
- I place the next of what has been a seemingly unending stream of Amazon orders for books and household supplies. This reminds me of doing a series of executive dinners all over the US years ago, where the icebreaker was “tell us the last thing you ordered from Amazon”. That turned out to be an unexpectedly intriguing glimpse into lives in different parts of the US, especially differing gender-role expectations.
- Ordinarily this would be (virtual Zoom) Scottish fiddle jam night for me, but a shoulder injury has left me largely unable to play, so PT exercises instead.
9:30 pm: Post-Munchkin bedtime, where the adults stare wearily at the TV and then do more work. So:
- Episode of The Good Doctor while multi-screening other stuff. Match-3 games on the iPad. Facebook, other social media, and reading. Chat on LinkedIn with someone interested in working at Gartner.
- Respond to more work email. Work on responding to Editing’s edits of a doc in the publication process. Do paperwork for previous day’s inquiries; send followup emails and research to clients. Prep for next day’s client calls.
- Write a letter to the board of directors for the community orchestra where I’m the concertmaster, inquiring as to post-pandemic plans.
- Write this blog post.
1:30 am: Bedtime.
Transitioning roles at Gartner
I’m excited to announce that, as of yesterday, I’ve joined the Gartner for Technical Professionals (GTP) team here at Gartner. For years, I’ve enjoyed working closely with Kyle Hilgendorf, Eli Khnaser, Mindy Cancila, Doug Toombs, Marco Meinardi, Alan Waite, and many others in our GTP research division, and I’m looking forward to deepening this collaboration.
Those of you who have known me for a while might remember that I spent more than 15 years in Gartner’s Technology and Service Provider division, and then, for the last two and a half years, I’ve been in the Infrastructure Strategies team in Gartner’s IT Leaders group. Throughout all of these years, I’ve written a lot of deep-dive research for both managerial and technical audiences, and spent a lot of time talking to everyone from the CIO to the sourcing managers and engineers in the trenches, as well as vendors and investors. I’ve always enjoyed being more hands-on, though, and the move into GTP will give me a chance to write more in-depth practical advice.
For the next couple of months, I’ll be in a state of transition. I’ll be doing both types of inquiry for a while, but in the future, clients will need a Gartner GTP “seat” to speak with me. In the next month or two, you’ll see me publish a bunch of research into the ITL agendas, as I finish up that work, and then rethink my previously-planned agenda (much of which will still likely be published, albeit into GTP). I’ll be at the Gartner Catalyst conference in August, with my first GTP presentation, called “Improve Cloud Operations with Site Reliability Engineering”, focused on how to take the principles, practices, and tools used to manage massive cloud-native applications, and apply them at an enterprise level for cloud operations at a more typical scale.
The cloud IaaS team at Gartner is exceptionally collaborative across our divisions and teams, and I expect to continue working very closely with all the awesome analysts that I’ve worked with over the years. Gartner is backfilling my previous role, and I highly encourage any cloud IaaS experts out there to reach out to me if you’re interested. Here’s the job req: https://bit.ly/2JBagOb
My 2016 research agenda
At the beginning of February, as part of a little bit of organizational deck-chair shuffling here at Gartner, some analysts were transferred to teams that better reflect their current research focus. I am one of those people; I’ve been transferred from our Technology and Service Provider (T&SP) division to our IT Leaders division’s Infrastructure Strategies team, reflecting the fact that I’ve mostly been serving the IT Leaders constituency for several years now.
My planned research agenda for 2016 remains the same, and I’ll continue to work with the exact same people and clients, but I now have a new team manager (Rakesh Kumar — and hopefully a better alignment between the things that I’m actually doing and the way Gartner sets goals and incentives for analysts.
I will continue to write research for both our end-user (IT Leaders) clients, as well as for our T&SP (Business Leaders) clients. Vendor clients should note that my transfer does not change access privileges to my documents targeted at vendors, or inquiry access. You will still need to hold a Business Leaders seat to read T&SP content that I author, or to ask inquiry questions related to that content.
My research agenda for 2016 centers on five major themes:
- The managed and professional services ecosystem for cloud providers
- Large-scale migration to the cloud
- Excellence in governance
- The convergence of IaaS and PaaS
- The adoption of containers
I’ll talk briefly about my interests in each of these spaces.
Managed and professional services
The MSP ecosystem, especially around AWS and Azure, is a vital part of driving successful cloud adoption, especially with late-majority adopters. This is my primary research focus this year, as I build out both research for end-users (IT Leaders clients) as well as service providers and technology vendors. This is largely a run-up to a new Magic Quadrant slated for Q4 2016 publication.
Large-scale migration to the cloud
Customers have begun migrate existing workloads to cloud IaaS at scale (i.e., migrating entire data centers or substantial portions of their existing infrastructure estate). This is no longer just early pioneers, but mainstream, non-tech-centric companies, often in the mid-market, usually with the assistance of third parties. These customers typically articulate needs that have been more commonly associated with outsourcing in the past — cost-optimization, better management of infrastructure and apps, staff reduction, keeping pace with technology evolution, and the like.
This is my next greatest priority in terms of writing this year. I’m building research aimed at clients who are evaluating migrations, as well as those who are in the process of migrating. I’m also writing research that is aimed at the vendor/provider side, since this new wave of customers has different requirements, necessitating both a different go-to-market approach as well as different sets of priorities in service features.
Excellence in governance
As organizations grow their use of the cloud, the need for governance is vital. Governance is not control, per se, and IT organizations need assistance in understanding the emerging best practices around governance. The vendor ecosystem also needs to build appropriate products and services that help IT organizations implement good cloud governance — which differs in some vital ways from traditional models of IT governance.
The convergence of IaaS and PaaS
As the IaaS and PaaS markets move ever closer together, customers need guidance as to how to best adopt integrated offerings. Moreover, this has implications for providers on both sides of the spectrum (and their ecosystems), as well as vendors who sell technology to build private clouds.
Containers
Last year, I spent just about as much time talking to clients about containers as I did about cloud IaaS — that’s how much of a hot topic it was. This year, as container coverage is dispersed across a lot more analysts, it’s become less of a focus for me, but I remain deeply interested in the evolution of the ecosystem, not just in the cloud, but also within traditional data centers.
Other Work
While these topics are some key broad themes, I’ll certainly be thinking about and writing about a great deal more. I tend to be a more spontaneous writer, and so I might sit down in an afternoon and rapidly write a note about something that’s been on my mind lately, even if it’s not part of my planned research. Indeed, I tend not to plan research except to the minimum extent that Gartner requires (generally “big rock” items like Magic Quadrants and so forth), so if you have feedback on what you’d like to see me produce, please feel free to let me know.
Yet more reasons to work at Gartner with me
The TL;DR: My team at Gartner has an open position for someone who has a strong understanding of cloud IaaS — someone who has experience architecting for the cloud, or who has worked on the vendor side of the market (product management, solutions architecture, engineering, consulting, etc.), or is an analyst at another firm covering a related topic. If you’re interested, please email me or contact me on LinkedIn.
The details:
A few years ago, I wrote a blog post on “Five reasons you should work at Gartner with me“, detailing the benefits of the analyst role. I followed it up last year with “Five more reasons to work at Gartner with me“, targeted at women. Both times we were hiring. And we’re continuing to hire right now.
We’re steadily expanding our coverage of cloud computing, which means that we have multiple openings. On my team, we’re looking for an analyst who can cover IaaS, and if you have a good understanding of cloud security, PaaS, and/or DevOps, that would be a plus. (The official posting is for a cloud security analyst, but we’re flexible on the skill set and the job itself, so don’t read too much into the job description.) This role can be entirely work-from-home, and you must work a US time zone schedule, which means candidates should be based in North America or South America.
Previously, I noted great reasons to work at Gartner:
- It is an unbeatably interesting job for people who thrive on input.
- You get to help people in bite-sized chunks.
- You get to work with great colleagues.
- Your work is self-directed.
- We don’t do any pay-for-play.
In my follow-up post for women, I added the following reasons (which benefit men, too):
- We have a lot of women in very senior, very visible roles, including in management.
- The traits that might make a woman termed “too aggressive” are valued in analysts.
- You are shielded from most misgyny in the tech world.
- You will use both technical and non-technical skills, and have a real impact.
- This is a flexible-hours, work-from-anywhere job.
I encourage you to go read those posts. Here, I’ll add a few more things about our culture. (If you’re working at another analyst firm or have considered another analyst firm in the past, you might find the below points to be of particular interest.)
1. People love their jobs. While some analysts decide after a year or two that this isn’t the life for them, the ones that stay, pretty much stay forever. Almost everyone is very engaged in their job, works hard, and tries to do the right thing. Although we’re a work-from-home culture, we nevertheless do a good job in establishing a strong corporate culture in which people collaborate remotely.
2. We have no hierarchy. We are an exceptionally flat organization. Every analyst has a team manager, but teams are largely HR reporting structures — a support system, by and large. To get work done, we form ad-hoc and informal groups of collaborators. We have internal research communities of interest, an open peer review process for all research, and freewheeling discussions without organization boundaries. That means more junior analysts are free to take on as much as they want to, and their voices are no less important than anyone else’s.
3. We have no hard-and-fast coverage boundaries. As long as you are meeting the needs of our clients, your coverage can shift as you see fit. Indeed, to be successful, your coverage should naturally evolve over time, as clients change their technology wants and needs. We have no “book of business” or “programs” or the like, which at other analyst firms sometimes encourage analysts to fiercely defend their turf; we actively discourage territoriality. Collaboration across topic boundaries is encouraged. We do have some formal vehicles for coverage — agendas and special reports among them — but these are open to anyone, regardless of the specific team they work on. (We do have product boundaries, but analysts can collaborate across these boundaries.)
4. We have good support systems. There are teams that manage calendaring and client contact, so analysts don’t have to deal with scheduling headaches (we just indicate when we’re available). Events run smoothly and attention is paid to making sure that analysts don’t have to worry about coordination issues. There’s admin and project manager support for things that generate a lot of administrative overhead or require coordination. Management, in the last few years, has paid active attention to things that help make analysts more productive.
5. Analysts do not have any sales responsibility. Analysts do not carry a “book of business” or any other form of direct tie to revenue. We don’t do any pay-for-play. Importantly, that means that you are never beholden to a vendor, nor do you have an incentive to tell a client anything less than the best advice you have to give. The sales team understands the rules (there are always a few bad apples, but Gartner tries very hard to ensure that analysts are not influenced by sales). Performance evaluations are based on metrics such as the popularity of our documents, and customer satisfaction scores across the different dimensions of things we do (inquiries, conference presentations, documents, and so on).
If this sounds like something that’s of interest to you, please get in touch!
Shooting squirrels from the roof
I’ve been spending the last week revising the combined service-provider survey for our Magic Quadrant for Cloud IaaS, and the new regional Magic Quadrants for Cloud-Enabled Managed Hosting.
With every year of revision, the way I ask questions becomes lengthier and more specific, along with the boldfaced “THESE THINGS DO NOT COUNT” caveats. These caveats almost inevitably come from things vendors have tried to claim count as X, with varying degrees of creativity and determination.
I consider my behavior part of a category I’ll call “shooting squirrels from the roof”. It comes from a story that a friend once told me about a rental agreement on a house. This rental agreement had all the usual stipulations about what tenants aren’t allowed to do, but then it had a list of increasingly specific and weird directives about what the tenant was not allowed to do, culminating in, “Tenant shall not shoot squirrels from the roof.” You just know that each of these clauses came from some previous bad experience that the landlord had with some tenant, which caused them to add these “thou shalt not” behaviors in great specificity to each subsequent lease.
So, I use the phrase “shooting squirrels from the roof” to denote situations in which someone, having been burned by previous bad experiences, tries to be very specific (often in a contract) to avoid being burned in that way again.
When I look at customer contracts for managed hosting and indeed, for services in general, I sometimes see they’ve got “shooting squirrels from the roof” contract clauses, specifying a list of often-bizarre, horrible things that the provider is not allowed to do. Those customers aren’t crazy (well, at least not entirely); they’ve just been burned before. No doubt if you’re in the services business (whether IT or not), you’ve probably had this experience, too.
Five more reasons to work at Gartner with me
A couple of years ago, I wrote a blog post called “Five reasons you should work at Gartner with me“. Well, we’re recruiting again for an analyst to replace Aneel Lakhani, who is sadly leaving us to go to a start-up. While this analyst role isn’t part of my team, I expect that this is someone that I’ll work closely with, so I have a vested interest in seeing a great person get the job.
Check out the formal job posting. This analyst will cover cloud management products and services, including cloud management platforms (like OpenStack).
All of five reasons that I previously cited for working at Gartner remain true:
- It is an unbeatably interesting job for people who thrive on input.
- You get to help people in bite-sized chunks.
- You get to work with great colleagues.
- Your work is self-directed.
- We don’t do any pay-to-play.
(See my previous post for the details.)
However, I want to make a particular appeal to women. I know that becoming an industry analyst is an unusual career path that many people have never thought about, and I expect that a lot of women who might find that the job suits them have no idea what working at Gartner is like. While we have a lot of women in the analyst ranks, the dearth of women in technology in general means that we see fewer female candidates for analyst roles.
So, here are five more good reasons why you, a woman, might want a job as a Gartner analyst.
1. We have a lot of women in very senior, very visible analyst roles, along with a lot of women in management. We are far more gender-balanced than you normally see in a technology company. That means that you are just a person, rather than being treated like you’re somehow a representative of women in general and adrift in a sea of men. Your colleagues are never going to dismiss your opinions as somehow lesser because you represent a “woman’s point of view”. Nor are people going to expect a woman to be note-taking or performing admin tasks. And because there are plenty of women, company social activities aren’t male-centric. There are women at all levels of the analyst organization, including at the top levels. That also means there’s an abundance of female mentors, if that matters to you.
2. The traits that might make you termed “too aggressive” are valued in analysts. Traits that are usually considered positive in men — assertive, authoritative, highly confident, direct, with strong opinions — can be perceived as too aggressive in women, which potentially creates problems for those types of women in the workplace. But this is precisely what we’re looking for in analysts (coupled with empathy, being a good communicator, and so on). Clients talk to analysts because they expect us to hold opinions and defend them well.
3. You are shielded from most misogyny in the tech world. You may get the rare social media interaction where someone will throw out a random misogynistic comment, but our analysts aren’t normally subject to bad behavior. You will still get the occasional client who believes you must not be technical because you’re a woman, or doesn’t want a woman telling him what to do, but really, that’s their problem, not yours. Our own internal culture is highly professional; there are lots of strong personalities, but people are normally mature and even-keeled. Our conferences are extremely professionally run, and that means we also hold attendees and sponsors to standards that don’t allow them to engage in women-marginalizing shenanigans.
4. You will use both technical and non-technical skills, and have a real impact. While technical knowledge is critical, and experience beings hands-on technical is extremely useful, it’s simply one aspect of the skillset; communication and other “soft” skills, and an understanding of business strategy and sales and marketing, are also important. Also, the things you do have real impact for our clients, and potentially can shape the industry; if you like your work to have meaning, you’ll certainly find that here.
5. This is a flexible-hours, work-from-anywhere job. This has the potential to be a family-friendly lifestyle. However, I would caution that “work from anywhere” can include a lot of travel, “flexible hours” means that you can end up working all the time (especially because we have clients around the globe and your flexibility needs to include early-morning and late-evening availability), and covering a hot topic is often a very intense job. You have to be good at setting boundaries for how much you work.
(By the way, for this role, the two analysts who cover IT operations management tools most closely, and whose team you would work on, are both women — Donna Scott and Ronni Colville — and both VP Distinguished Analysts, at the very top of our analyst ranks.)
Please feel free to get in contact privately if you’re interested (email preferable, LinkedIn okay as well), regardless of your gender!
The meta-info of my OpenStack note
I’ve been reading the social media reactions to my recent note on OpenStack, “Don’t Let OpenStack Hype Distort Your Selection of a Cloud Management Platform in 2012” (that’s a client link; a free public reprint without the executive summary is also available), and wanted to respond to some comments that are more centered on the research process and publication process than on the report itself. So, here are a number of general assertions:
Gartner doesn’t do commissioned research. Ever. Repeat: Gartner, unlike almost every other analyst firm, doesn’t do commissioned resesarch — ever. Most analyst firms will do “joint research” or “commissioned whitepapers” or the like — research where a vendor is paying for the note to be written. About a decade ago, Gartner stopped this practice, because management felt it could be seen as compromising neutrality. No vendor paid for that OpenStack note to be written, directly or indirectly. Considering that most of the world’s largest IT vendors are significant participants in OpenStack, and plenty of small ones are as well, and a bunch of them are undoubtedly unhappy about the publication of that note, if Gartner’s interests were oriented around vendors, we certainly wouldn’t have published research practically guaranteed to upset a lot of vendors.
Gartner earns the overwhelming majority of its revenue from IT buyers. About 80% of Gartner’s revenues come from our IT buyer clients (we call them “end-users”). We don’t shill for vendors, ever, because our bread-and-butter comes from IT buyers, who trust us for neutral advice. Analysts are interested in helping our end-user clients make the technology decisions that are best for their business. We also want to help vendors (including those who are involved with free or commercial open-source) succeed in better serving end-users — which often means that we will be critical of vendor efforts. Our clients are asking about OpenStack, and every example of hype in that note comes directly from client interactions. I wrote that note because the volume of OpenStack queries from clients was ramping up, and we needed written research to address it.
Gartner analysts are not compensated on commissions of any sort. Many other analyst firms have incentives for analysts that are tied to revenue or publicity — be quoted in the press X times, sell reports, sell consulting, sell strategy days with vendors, etc. Gartner doesn’t do any of that, and hasn’t for about a decade. Our job, as Gartner analysts, is to try to offer the best advice we can to our clients. Sometimes, of course, we will be wrong, but we try hard. It’s not an academic exercise; our end-user clients have business outcomes that ride on their technology decisions.
Gartner doesn’t dislike open source. As a collective entity, Gartner tends to be cautious in its stances, as our end-user clients tend to be mid-market and enterprise IT executives who are fairly risk-averse; our analysis of all solutions, including OSS, tends to be from that perspective. But we write extensively about open source; we have analysts devoted to the topic, plus everyone covers the OSS relevant to their own coverage. We consider OSS a business strategy like anything else. In fact, we’ve been particularly vocal about how we feel that cloud is driving OSS adoption across a broad spectrum of solutions, and advocates that an IT organization’s adoption of cloud is a great time to consider replacing proprietary tech with OSS. (You’ll note that a whole section of the report predicts OpenStack’s eventual success, by the way, so it’s not like this a prediction of doom, just an observation of present stumbling-blocks on the road to maturity.)
Gartner research notes are Gartner opinion, not an individual analyst’s opinion. Everything that Gartner publishes as a research note (excluding things like blog posts, which we consider off-the-clock, personal time and not a corporate activity) undergoes a peer review process. While notes do slip through the cracks (i.e., get published without sufficiently broad or deep review), our internal processes require analysts to get review from everyone who touches a coverage area. My OpenStack note was very broadly peer reviewed — by other analysts who cover cloud infrastructure, cloud management platforms, and open source software, as well as a bunch of related areas that OpenStack touches. (As a result of that review, the original note almost quadrupled in size, split into one note on OSS CMPs in general, and one note on OpenStack itself.) I also asked for our Ombudsman’s office, which deals with vendor complaints, to review the note to make sure that it seemed fair, balanced, and free of inflammatory language, and they (and my manager) also asked questions about potentially controversial sections, in order to ensure they were backed by facts. Among other things, these processes are intended to ensure that individual analyst bias is eliminated to as large an extent as possible. That process is part of why Gartner’s opinions often sound highly conservative, but when we take a stance, it is usually neither casual nor one analyst’s opinion.
The publication of this note was not a shock to the vendors involved. Most of the vendors were aware that this note was coming; it was a work in progress over the summer. Rackspace, as the owner of OpenStack at the time that this was placed in the publication pipeline, was entitled to a formal review and discussion prior to its publication (as we do for any research that covers a vendor’s product in a substantive way). I had spoken to many of the other vendors in advance of its publication, letting them know it was coming (although since it was pre-Foundation they did not have advance review). The evolving OpenStack opinions of myself and other Gartner analysts have long been known to the vendors.
It would have been easier not to write anything. I have been closely following OpenStack since its inception, and I have worked with many of the OpenStack vendors since the early days of the project. I have a genuine interest in seeing them, and OpenStack, succeed, and I hope that the people that I and other analysts have dealt with know that. Many individuals have confided in me, and other Gartner analysts, about the difficulties they were having with the OpenStack effort. We value these relationships, and the trust they represent, and we want to see these people and their companies succeed. I was acutely careful to not betray any individual confidences when writing that report, ensuring that any concerns surfaced by the vendors had been said by multiple people and organizations, so that there would be no tracebacks. I am aware, however, that I aired everyone’s collective dirty laundry in public. I hope that making the conversation public will help the community rally around some collective goals that will make OpenStack mainstream adoption possible. (I think Rackspace’s open letter implicitly acknowledges the issues that I raised, and I highly encourage paying attention to its principles.)
You will see other Gartner analysts be more active in OpenStack coverage. I originally picked up OpenStack coverage because I have covered Rackspace for the last decade, and in its early days it was mostly a CMP for service providers. Enterprise adoption has begun, and so its primary home for coverage is going to be our CMP analysts (folks like Alessandro Perilli, Donna Scott, and Ronni Colville), although those of us who cover cloud IaaS (especially myself, Kyle Hilgendorf, and Doug Toombs) will continue to provide coverage from a service provider perspective. Indeed, our coverage of OSS CMPs (CloudStack, Eucalyptus, OpenNebula, etc.) has been ramping up substantially of late. We’re early in the market, and you can expect to see us track the maturation of these solutions.
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.
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?
CloudPundit: Massive-Scale Computing 