I have yet to meet anyone who grew up wanting to be an IT analyst. Doctor, yes; professor, yes; writer, yes; IT analyst, no. If you are an IT analyst, it’s a position that you migrated to via a combination of skill, luck, and timing. In fact, I’ve always considered the answer to the question, “So how did you become an IT analyst?” as fascinating as, “So how did you meet your spouse?”–you just never know what someone will say.

However, no matter how they arrived at the position, I would argue every great IT industry analyst has certain characteristics:

Enjoys and Understands IT Technology: As an analyst, you spend all your time analyzing and understanding IT technology. If you find the subject over your head or boring at times, being an IT analyst is not the job for you. To give you a feel for the level of geekiness involved (at least within Burton Group), here are some examples. In a previous life, I wrote seven Visual Basic sample programs (30,000 lines of highly commented code, some of which made their way into MSDN) to show how to use the imaging .OCXs that shipped with Windows 95 and 98. My job as a third-level Customer Support Engineer required only one program, but I just kept coding more sophisticated examples because I enjoyed programming. Another CCS analyst has a server in his basement–he bought it himself–to play around with open source projects and the latest version of SharePoint. Another Burton Group employee high in the management ranks builds Linux machines on the weekend for relaxation.

Knows How IT Works: I think it’s difficult to write reports that IT will find useful if you haven’t worked in IT yourself. Not all analysts have previously worked in IT, but I think it’s an uphill battle if you haven’t. I worked in IT for nine years, for a startup and some multi-billion dollar corporations; the other four CCS analysts have worked in IT as well. We know what it’s like to try to deliver a system while the business keeps changing its mind; we know the pressure of debugging a complex program within an hour, because if you don’t bring the system up by 5 AM the production line won’t come up. I recently had a client ask me how I decided what to include in my reports. I said, “Simple. I just write the report I’d want to read if I were back in IT.”

Can Write Clearly and Concisely: Analysts are teachers–and so must be able to write well to get their points across. Lifting the veil on vendor obfuscation is a common task–pointing out where the vendor is shading the truth, or compressing the 35 wandering words that the vendor used in the datasheet into five that are much clearer.

Can Create Frameworks: This is one of the least discussed but one of the most important tasks of the analyst. Besides writing about technology and making recommendations, analysts must create frameworks–ways of looking at the world–that help clients understand complex products and problems. A framework may be a maturity model, it may be a block diagram, it may be a decision tree–but whatever it is, it should help clients see the world in a clear and useful way. Often, a block diagram that frames an issue–for example, “There are five parts to this type of product”–will help a client work their way through a specific problem. In short, helping a client to become their own analyst is just as important as telling them what to do in a certain case.

Can Speak in Public: Part of analyst life is giving speeches to large crowds of people. If you freeze when talking to large groups, being an IT analyst is not for you.

Can Think on Their Feet: Clients will toss out questions all the time–in phone calls, at meetings, during a Q&A session after a speech–and you need to be able to field them quickly and well. I worked with an analyst who wrote excellent and incisive reports, but was a total failure when talking to clients, since he literally needed three minutes to marshal his thoughts. After several years, he left the analyst profession.

Is Willing to Take a Stand: I’ve worked with some analysts who just can’t make up their mind–the discussion is a perpetual replay of, “On the one hand, on the other hand.” Being able to see the many sides of a problem is crucial to truly understanding it; but at the same time, analysts ultimately have to give guidance to clients: “OK, here’s what you should do.” Furthermore, that stand must be defensible–analysts can’t wither under the vendor attacks that will inevitably come. Being an analyst, in some ways, is a lonely position, because you’re ultimately a critic–and not everyone likes a critic.

Can Take and Leverage Criticism: While an analysts are critics, they must also take criticism well. Of the three analyst firms I’ve worked for, every one has had a peer review process: before a report is published, it’s vetted by other analysts to make sure the arguments are sound. While collegial (usually), analysts are not bashful about pointing out errors or recommending changes in tone. If you can’t accept criticism–or marshal irrevocable arguments as to why your view should stand–you’ll never make it as an analyst. Shrinking violets need not apply.

So that’s my list of requirements. Being an IT industry analyst can be a great job–but it’s not for everyone.

Thoughts on What Makes a Great IT Industry Analyst

Guy,
Lovely post. Great to see you blogging up a storm.
The trait that I think is most essential for an analyst is curiosity. Seeking knowledge is what gets me up in the morning. Being an analyst is a good way to get paid to scratch that itch.

Must also be able to multi-task and switch subjects almost instantaneously. I remember the days of being an analyst – 30 minutes on IT minutae and then 30 minutes on strategy, followed by 30 minutes on vendor positioning…

Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.