You may have heard of Research Analysts or Industry Analysts in one way or another via GigaOm, Gartner, Forrester, etc. They’re typically the people speaking to vendors, learning about new products, performing case studies, and writing large research papers or whitepapers. You’ll also see them speaking at conferences, writing books, leading strategy and/or product at organizations, and leading a specific portion of the industry (cyber security, data, DevOps, etc.).

Research and industry analysts have been conducting their findings the same way for a long time, probably since the inception of the analyst space.

But what if there’s another way? A way to change the game for research and how we do it today.

In this blog post, you’ll learn about how I think about research and the steps I’m taking to sprinkle hands-on engineering practices on it.

What’s A Research Analyst

When you look at a research analyst, they’re the people leading the theory and sometimes even the evolution of the way the world sees a certain topic.

Let’s take Gene Kim for example, a successful researcher in the DevOps space. Because of books like The DevOps Handbook, The Phoenix Project, and Accelerate, the industry looks at DevOps from a certain light. The reason why is because Gene Kim is a tremendous influencer.

However, as we all know, DevOps isn’t as cut and dry as it is in the books. The way that engineers are practicing DevOps and how organizations are implementing it is vastly different from what you read in the books.

Why? Because a lot of research analysts are theoreticians and there’s absolutely nothing wrong with that. In fact, we need the theory of how things work before we can implement them (think theoretical physicist vs experimental physicist). But because a lot of the research is theory-based, it leaves room for gaps in how the real world is using it.

So, what’s a research/industry analyst? It’s someone who dives extremely deep into typically one topic (DevOps, cyber security, data, etc.) and attempts to understand the nature of it, how to help others use it, and how to predict what will happen in the future around the topic.

How Research Has Been Conducted

Research is typically conducted a few ways:

• Vendor briefings – vendors will talk with you, show a pitch deck, explain why the product is great, and perhaps even show a demo of the product
• Case studies – researchers will chat with folks and organizations using the product(s) to see its pros and cons
• Google – researchers will Google around, read blogs, watch videos, and perform their own research outside of chatting with people and vendors

Once the research gets collected, it gets written down. This is typically in the form of a long paper, white paper, or some sort of scoring on the product.

Once that research is done, it can be used in multiple ways. For a video, a webinar, a conference talk, a blog post, a podcast, and many other ways. The great thing about research is you can use it multiple times for various purposes.

Typically, research and industry analysts don’t really dive into a product. They conduct and write their research from data (vendor briefings, case studies, etc.) and that’s the way the industry has worked for a while. This type of research is pretty different from academic research where researchers actually go in and experiment with what they’re researching.

When I started my journey to becoming a research analyst, I wanted to take the same approach, and in the next section, I’ll talk about that approach.

There’s Another Way…

Whenever you do something in life, it’s typically always easier when you read about it vs when you actually do it. The “thing’ you do could vary. Let’s think about a few typical real-life examples:

• Mowing your grass – easy to read about, but when you do it, there are variables. Rocks in the way, uneven grass, different types of lawnmowers, etc.
• Taxes – reading about taxes is straightforward. Pop in some numbers and poof, you’re on your way. However, when you actually do your taxes yourself, it’s hectic. Claiming dependents, state taxes, write-offs, etc.
• Stocks – they look cool when you read about them. People throw money at a stock, sell it, and then poof, they’re driving around in a new Mercedes! However, it’s much different when you dive into day trading. When stocks are up, when to sell, what time of the day to trade, etc.

The point is, anything you read about and hear about in life is so much easier than actually doing it.

I believe that’s the same thing with research.

I want my research to be read and heard by people and they know that I understand, not from a theoretical perspective, but from a hands-on perspective. I want them to know that I’ve been in the trenches with products, understand how they work, and understand the hundreds of things that can go wrong.

That’s why as a research analyst, I conduct engineering-led training.

How I Think About Research

At this point, you may be wondering what does engineering-led training mean?

What I mean is I’m still an engineer. Yes, I’m still writing production-level code almost daily. I’m still working with all of the DevOps/SRE-centric tools and platforms. I’m still, to this day, implementing solutions for organizations.

I believe because I’m still hands-on and I’m still leading engineering efforts, my research comes off a bit different. It comes off from a theoretical perspective because I’m still conducting vendor briefings, case studies, etc., but I’m also working with the tools and platforms. That means I can speak about my experience in a white paper from a hands-on perspective. It allows me to be more conclusive and less generic in my research.

It’s clear that the research analyst industry isn’t used to researchers that are also engineers, but I think that’s where I can differentiate myself, and in turn, differentiate my research findings. I believe I can change the game of what a Research Analyst does and combine the process of being an engineer and an analyst.

Both analysts and academic researchers work with data and make data-driven decisions. However, while academic researchers work on both the front and the back end of data, performing experiments and interpreting the results, most analysts work on the back end of the research, compiling and analyzing data.

Because of that, I’m taking more of an Academic Researcher path.

How I’m Conducting Research As An Engineer

Here are the steps I’m taking to conduct research as an engineer.

First, I’m taking the standard analyst approach:

• Vendor briefings
• Case studies
• Reading about the products and the field
• Talking to others using the products and that are in the field
• Speaking to other analysts in the space

Second, I’m consulting:

• I still consult as an SRE and DevOps engineer on projects
• I’m still leading engineering efforts and implementing technologies
• I’m still hands-on

Third, I’m conducting experiments of my own:

• Creating labs in Azure, AWS, etc.
• Playing with products and different features
• Creating free trials of products and/or hosting them myself on systems

Combining the power of engineering and the power of an industry analyst, I believe, will be an unstoppable force for any research analyst that wants to be a thought leader in their space.