A Beginner Analyst’s Perspective

alt Let me start by saying that the term “beginner” is very generous in describing my BPA chops. I have no real history in IT other than dabbling in HTML in elementary school and on my Neopets and MySpace accounts. I attempted a Computer Science degree, took one C++ course, and promptly changed majors. Oh—I once took off the side panel of my computer tower to wipe up the water I’d clumsily poured into it.

A term that better describes me and my knowledge of IT is probably “embryonic analyst.”

Yet somehow I found myself wanting to work in IT…but I had no clue what to do, how to get started, or even really what it entailed. I’m still learning. I don’t pretend to be an expert in being a beginner either, but I’d like to share a few observations and concerns that might be helpful to mentors of new BAs or other beginner analysts.

A Lack of Basic Knowledge

Recently, I was assigned the task of becoming certified in Google Tag Manager (GTM); being acquainted with GTM would allow me to provide targeted and meaningful ways of collecting data and to remarket as a result of that data. However, understanding GTM is contingent on an understanding of analytics as a whole—understanding what data is, how to collect data given a specific business objective and audience, and how to use that data to reinform your business practices. I did not have a clear understanding of any of that; I had an abstract one, but putting that knowledge into practice is something different entirely. So, I had to do training on Google Analytics before I completed the tasks I was asked to do.

So, I believe that one of the first steps in hiring an embryonic analyst like me is to assess your new employee’s level of knowledge and expertise. This knowledge and expertise could be about BI, software, basic business principles, company familiarity, or even just knowledge about the expectations you have as a manager or project lead. As someone who is completely new to a traditional office job, I have a lot of basic questions about, well, everything.

Your new, embryonic analyst is not only new to being an analyst, but they are also new to your company. They are not aware of the tools that established employees use every day. For example, when I was first hired, I asked if there were any templates for documentation so that I could become acquainted with them. The answer I received was a harsh and quick “NO!” Templates, I learned, have a negative connotation. However, my company did have a locally hosted network where all documentation lived called the Shares Drive. I did not learn about the Shares Drive until I’d been on the job almost two weeks. Had I known to word my question a little differently, I would have found out about the Shares Drive on the first day, but I was new—so I didn’t.

The lesson here to is make sure you equip your new employee with the tools they need to be self-directive on their very first day. Don’t expect that they’ll know to ask the right questions or that they will be able to locate the tools on their own.

I realize that asking experts to take a hundred steps back to the bare basics is challenging, so here are a few tips for generating ideas about what your new analyst might need:

  1. Think about what you use every day you’re on the job. No, not something like your computer, but perhaps a shared network, a useful program, an informational resource, or something you, as an individual, use to aid your analysis work.
  2. Identify other strong mentors within the company and make it a point to introduce them. I would be utterly lost without my mentors in the company who are patient with me, answer all my basic questions, and allow me to use them as a soundboard.
  3. Develop a list of commonly used phrases, acronyms, or methodologies that your company uses on a daily basis. If your analyst is anything like me, they were overwhelmed with what my manager calls “alphabet soup”—sentences comprised mostly of acronyms—and this jargon can quickly become a way to lose your analyst or bog them down.


Training is obviously a big part of any big career change, but moving into IT presented a number of challenges for me. As someone who is completely new to IT and the role, I had no idea of what I needed to know. As you might suspect, this idea is directly connected to the previous section: assess your analyst’s knowledge base.

I fancy myself a “go-getter.” I want to learn more. I want to do right by my company, future clients, and team members. So when I ran out of work, I wanted to productively fill my time; however, I didn’t know what I should learn. Then I had to ask myself, where do I go to learn those things? Often, this would cause me to be uncomfortably reliant on my manager or mentors for direction ad hoc. The lesson here is that identifying basic and core concepts for beginners is imperative.

In their down time, any good employee is going to want to fill their time with learning more about their job, but they might not know what are some critical skills or knowledges they should develop. For example, HTML, CSS, or basic database principals would be good for someone in my position to know, but in my first few weeks, I didn’t know that. (At this point you might be thinking that my company was very generous for hiring me, and to that I say, “Yep.”)

Giving new analysts this kind of information meant that they can have direction when you can’t be there to tell them what to do or where to go. In other words, give your new analysts enough information to be able to self-train if and when they have the time to. They will feel better for it.