That leads me to meet stakeholders where they’re at: in Excel. And modern data warehouses like Snowflake make it really easy to do so. It’s an easy win if you’ve invested in Analytics Engineering to create clean datasets in your database. Let’s bring those datasets to your users.
Here’s how to connect Snowflake into Excel and enable live connections pivot tables in minutes. These are instructions for Windows specifically.
Step by Step Instructions
(1) Install the ODBC Driver
Click on the “Help” button in the Snowflake UI, go to “Download…” and select “ODBC Driver” and “Snowflake Repository”. Install from the file that downloads.
(2) Configure ODBC Driver
Go to your start menu and type in “ODBC” and click on ODBC Data Sources (64 bit)
Under User DSN, select Add…
Select SnowflakeDSIIDriver from the menu
Fill in the boxes as follows – though your individual situation may vary. My example uses SSO when an organization doesn’t allow direct usernames/passwords for Snowflake. Lots of options here and Snowflake has full documentation of options here.
Click on Test… to confirm it worked. Here’s the dialog if it did:
(3) Connect to database in Excel
Open Excel and go to the Data tab, click on Get Data and choose From Other Sources and pick From ODBC
From the window that pops up, pick the Snowflake connection and select OK
If successful, you’ll see a window with a dropdown showing your available databases. Use that dropdown to pick the database you want.
IMPORTANT: There is an easy way to load data directly into a Pivot Table at this point (thanks Jacob for this tip!) which will save you and teams time.
Once you select the database / schema / table you want, go to that “Load” button on the bottom and click the little down arrow next to it. Choose “Load to…”
The next menu that pops up will give you various options – pick the second one down saying PivotTable Report
DONE. You’re there. The data is now connected live to Snowflake and is available to pivot. I used Snowflake’s sample “Weather” table which I just learned has basically nothing in it, but that’s besides the point.
There are a couple interesting tidbits to pass both to your stakeholders as well as anyone concerned about Snowflake compute cost & data security.
(1)Stakeholders can refresh data live from Snowflake any time. By right-clicking the pivot table and selecting “Refresh”. No more stakeholders asking you for the latest data – they can just get it anytime.
(2) Data is cached on the local machine, reducing compute costs & keeping things snappy for stakeholders. This satisfies worries from both stakeholders on performance (it’s REALLY snappy, even for huge tables) as well as those concerned on cost (compute only happens on refresh).
That’s it! Just a few installations and clicks and you’ve connected Snowflake live into Excel for any stakeholder. Happy self-serving.
Up to this point, I’ve largely written for those looking to break into an analytics career. Today I’ll go beyond that and discuss the most powerful lesson I and many others learned — something I wish I fully understood starting out:
Start your analytics project as simple as possible and iterate from there.
This strategy borrows a lot from Agile software development not because I’m a student of it, but because I learned the values of Agile through trial and error. Only after I stumbled upon this strategy did I learn how closely it aligns to the Agile methodology.
The Common Mistake
I’m going to assume you’ve already solved the toughest issue in analytics: identifying an ambiguous problem. Congrats! Now you need to figure out how to make it happen. This is where things can go wrong.
Many analysts (myself included!) are then tempted to:
Retreat to your office
Gather & clean all the data you think everyone needs
Build the World’s Best V1 Dashboard
Schedule a meeting to present the dashboard
Receive unanimous praise for how amazing it is
Watch as everyone uses your dashboard daily
What really happens:
Retreat to your office
Gather & clean only some of the data people need
Spend way too long building the Dashboard No One Really Wanted
Stakeholders email you intermittently asking if you’re making progress
Schedule a meeting to present the dashboard
Entire meeting spent fielding questions like “Why don’t I see X or Y?”
Get the cold sweats realizing you don’t have what they need
Stakeholders frustrated that so much dev time was wasted
You’re frustrated that they are “changing what they need”
Retreat to your office
Why Does This Happen?
Every data analyst/scientist makes this mistake. It will continually happen throughout your career, even after you think you’ll never make that mistake again. No one is immune.
There is one core reason why this happens: You assume you understand what the stakeholder wants.
Except you likely don’t. Especially when you’re early in your career. You’ll think you’re on the same page with your stakeholder, but you aren’t. You think you know what data points the stakeholder needs, but you don’t (hint: the stakeholder likely doesn’t know either!). You think you know what kind of visuals the stakeholder will find most useful, but you don’t.
In fact, it’s so difficult to get everything right the first time, you should assume you don’t fully understand the request. That one time you actually do build “The World’s Best V1 Dashboard”, celebrate the unexpected success – it won’t happen often.
Strategy: Start Simple
There’s a solution to this problem: Start your analytics projects as simple as possible. This results in less wasted time in development and happier stakeholders at the end. The process looks like this:
Agree with stakeholder on an MVP (Minimum Viable Product) – something small that can be done quickly
Your stakeholder may not know exactly what they want, so you may have lots of freedom here
Gather & clean only the data you need for the MVP
Create MVP dashboard
Ask your stakeholder questions here, too! You don’t need to go radio silent and many times they’ll appreciate the feedback loop
Present MVP dashboard to stakeholder
Gather feedback from stakeholder
Start process over again
This process is designed to be quick, with small iterations should building on each other until everyone agrees the dashboard fits the needs of the business. The more interactions with stakeholders the better – you’ll quickly identify misalignments, missing data, new requirements, changing business needs and more.
The advantages should be clear. Stakeholders will feel ownership over a product they helped develop (leading to better adoption!). The end product will be closer to what the business needs (leading to better adoption!). And stakeholders will remember the success of the project and give you a call for the next one.
Don’t try to build Rome in a day on any analytics project. You’ll rarely succeed. Instead, iterate and build on a project until it becomes something useful – and likely looks nothing like what you thought it would starting out.
Analytics is a dynamic field. Don’t fight upstream with how quickly things change; set up your work process to allow for quick changes. Your company & future self will thank you.
OK OK, I’ll admit it. I’m on a contrarian streak. For good reason – I want to help you with your analytics career and there are common potholes such as overrated technical ability. Analytics degrees are a close second and worth an in-depth discussion.
When I mention “degree” I mean any of the following:
Bachelors/Masters in Analytics
Analytics Boot Camps
*There are a few exceptions to this advice, though they are very case-by-case. There may be a specific position you want at your company that requires a degree to get in or you may have a personal to accomplish. I’m not speaking into those situations but still want to acknowledge they exist.
The Allure of Education
It’s logical why many have a thought process like this:
I am interested in analytics
I do not have analytics experience
Hiring managers want to see experience and/or education
Education is the next best option
I will fill in gaps in my resume with education
At face value, this makes complete sense. In other career tracks, education teaches crucial skills and gives you an entry into that industry. Want to get into law? Get a law degree. Want to become a doctor? Get a medical degree.
This is absolutely not the case in analytics. A Masters Degree, Analytics Boot Camp or MSSQL Certification will not give you a leg up for analytics positions. I see post after post after post on data science forums discussing analytics education. A key assumption is rarely called out: “Education will help you get an analytics job.”
Why Classes Struggle to Teach Analytics Skills
I had the privilege representing BI/Analytics on a panel for the University of Washington Information School. I centered on one basic point: it is near impossible for a classroom setting to prepare you for the reality of an analytics career.
Think of it this way: in college, the “game” is well-known. The teacher gives you specific concepts. Your job is to apply those concepts on your homework, tests and/or projects. The requirements are clear and tie back to the class syllabus. Data is typically clean or requires trivial amounts of cleaning to get ready.
Analytics careers are nothing like that. I wrote about how ambiguous data problems are. There’s no syllabus. Clear questions are rare. Even if questions are clear, your stakeholder often asks the wrong question. Data may not exist and any existing data is a mess. The world is ambiguous and cloudy and hard to navigate.
Imagine a college class that tried to replicate this. No syllabus. Little to no data provided. You may or may not have a test, and that test may require you to answer questions not even on the test. Even if there were questions, they may not be the ones the teacher wants you to answer. What a mess of a class!
I’m not sure how to structure a college course to capture the ambiguity in the every day life of an analyst. As Jacob wrote, there are four key soft skills for analysts and I’d be interested to hear of any creative strategies from teachers/professors to teach them. Certainly some get closer than others, but no matter what there is no replacement for the real world.
Why Degrees Don’t Matter
You may have already connected the dots. If courses can’t teach key analytics skills, then various degrees will not make a resume stand out. It’s rare for technical ability to stand out as the reason to hire someone.
Combined with the time & expensive involved with degrees, their value diminishes. Put another way, if you can get better experience AND get paid for it, consider that option first.
In Conclusion – What Now?
Experience is king, period. You may be asking “But how do I get experience without getting my first job?” Great question! This is what I referred to as the ‘Great Filter’ on landing your first analytics job. That post will cover most of what you should do instead of getting a degree.
A note from Jacob: For more on this – lots of good discussion on data twitter & in the Locally Optimistic slack.A snippet of a thread just yesterday is below.
Was just talking to someone looking for tips on preparing for data science interviews and realized I couldn’t give them any concrete answers (“should I study stats? programing? analysis? which models?”) since every single interview is radically different. Unless you’re preparing for a FAANG-style interview where they literally give you a packet of possible questions and guidance, I have no idea how any of us know what to study and get jobs in this industry. I was reminded of @tdhopper‘s great post on this topic. https://tdhopper.com/blog/some-reflections-on-being-turned-down-for-a-lot-of-data-science-jobs
This is meant as a companion post and reply to the most common response to Technical Ability Is Overrated. Specifically, “Analysts need technical ability to do their job, and that means it’s important.” I wholeheartedly agree – and while you can’t win a job on technical ability alone, you certainly may lose it.
That means I would be remiss to cover the basic SQL concepts which will put you in a good place in most any Analyst interview. You need to know SQL to apply your business acumen and soft skills and that’s why it’s consistently tested in interviews. Generally if you know the SQL basics, the hiring team will be confident you can refresh/learn any knowledge gaps later on.
However — if you find positions that would disqualify you if you didn’t know something outside of these concepts, that should be a red flag. Those organizations focus too heavily on technical ability and/or the position is more in line with a Data Engineer than a Data Analyst.
Note: I am writing this using Snowflake SQL syntax; there are variations and quirks to each SQL version so some of this may be close but not exact to the environment you are in.
Where to brush up on SQL skills
There are tons of great SQL learning resources online now. One of the best out there is SQLZoo, with great examples and the chance to practice writing SQL to check your syntax. W3Schools also has a great set of tutorials for all sorts of SQL queries.
(0) Demonstrate Previous SQL Work
OK OK, this isn’t one of the four. But if you can demonstrate non-classroom SQL ability either through previous work or on the potential job’s take-home exercise, that’s worth its weight in gold. Mostly people want to know that you can use SQL to solve problems and if you can speak to using complex SQL to get stuff done previously, that goes a long way in checking the box
(1) Left/Right/Inner/Outer Join
These joins are the bread and butter of the SQL world – especially Left and Inner. You need to be able to explain the difference between each quickly and succinctly, as well as pick out which to use if/when tested. I’ll add a quick visual & code example of each borrowed from W3Schools. Read the in-depth explanations at W3Schools or SQLZoo for more details.
SELECT Customers.CustomerName, Orders.OrderID
LEFT JOIN Orders ON Customers.CustomerID = Orders.CustomerID
ORDER BY Customers.CustomerName
SELECT Orders.OrderID, Employees.LastName, Employees.FirstName
RIGHT JOIN Employees ON Orders.EmployeeID = Employees.EmployeeID
ORDER BY Orders.OrderID
SELECT Orders.OrderID, Customers.CustomerName
INNER JOIN Customers ON Orders.CustomerID = Customers.CustomerID
SELECT Customers.CustomerName, Orders.OrderID
FULL OUTER JOIN Orders ON Customers.CustomerID=Orders.CustomerID
ORDER BY Customers.CustomerName
(2) Aggregate Functions
Basic SQL functions involve returning a set of rows that match some criteria (“Show me all transactions from yesterday”). Sometimes, you’ll need to aggregate your data to answer summary questions (“Show me how many transactions we’ve had by day this year”). This is true for situations where you need to count, sum, average or find min/max.
Key Concept 1:Understand query level of detail
If you need to sum up every transaction from a single store, that’s easy – the level of detail is at the day + store level. However, if you want to see how many of each product was sold at each store on each day, suddenly you have three levels of detail (product + day + store). The more details someone needs in the data, the less aggregated it’ll get. Seems obvious but undoubtedly you’ll run into funky results when you THINK you understood the aggregation level but did not understand in reality.
Key Concept 2:Leverage GROUP BY
You need to tell SQL the level of detail in order for it to know how to aggregate your data. It won’t read your mind and if you leave any ambiguity, it’ll either fail to process (which is fine – at least you know) OR it will aggregate a ‘wrong’ answer (which is bad, you might not catch this!)
For example, let’s say you want that store data. If you don’t use Group By you’ll type it out something like:
//Example - this will fail
SELECT order_date, count(transaction_id)
However that’ll return an error – SQL doesn’t see a GROUP BY statement and will tell you as much. It doesn’t know what to do with “order_date” and that ambiguity makes the query fail. That means you need to add in one more line to make it execute:
//Example - Show count of transactions by date
SELECT order_date, count(transaction_id)
GROUP BY order_date
Key Concept 3: Filter aggregations with HAVING
Let’s say someone wants to only see days where there were at least 100 transactions. If you aren’t familiar with aggregations, you might write something like this:
//Example - this will fail due to using WHERE instead of HAVING
SELECT order_date, count(transaction_id)
WHERE count(transaction_id) >= 100
GROUP BY order_date
SQL will throw you an error. The WHERE clause is to filter out individual rows – except the count() function looks at multiple rows at once. It won’t know what to do! Someone doing a SQL test will see if you pick up on this when whiteboarding a problem – this is a common ‘gotcha’ question.
SQL provides the HAVING clause to allow you to filter on an aggregated column, like so:
//Example - Dates with at least 100 transactions
SELECT order_date, count(transaction_id)
GROUP BY order_date
HAVING count(transaction_id) >= 100
Notice that HAVING comes after GROUP BY – while not absolutely critical to remember the order of these, it’s a ‘nice to have’ if you can on the fly remember the order in which SQL clauses execute.
This is typically the upper limit of SQL testing for Data Analyst jobs. Commonly you will need to use a subquery to pull in data into the SELECT, FROM or WHERE clauses. SQL is a very flexible language and you can use a subquery to define a secondary table with its own select/from/where logic that is separate from your main query.
For instance, let’s say that we want to adjust our query from part (2) and now we want an additional filter – a list of all days with at least 100 transactions AND at least one customer was from California. It may seem simple at first, but it turns out this requires a subquery.
Let’s say you initially try just adding
//Example - Initial attempt, adding in Customer table and...
//...adding in a filter for customers from California
count(transaction_id) as "TRANSACTIONS"
FROM transactions t
LEFT JOIN customer c on c.customer_id = t.customer_id
WHERE c.customer_state = 'CA'
GROUP BY order_date
HAVING count(transaction_id) >= 100
The above will return a result but it’ll be wrong. When you put the California filter in, the SQL script filters down to only rows with California customers. All other sales are removed. This means your numbers come out very low. In fact, now your query is returning a list of all days with at least 100 transactions solely from customers in California.
So, how do you use Calfornia as a filter in the aggregate without having it be part of your base query? This is where a subquery comes in. Let’s rewrite this as a sub-query in the LEFT JOIN statement and THEN use it in a where statement.
//Example - Add Subquery into WHERE clause
count(transaction_id) as "TRANSACTIONS"
FROM transactions t
//Add in Subquery into WHERE clause
WHERE t.order_date IN
FROM transactions t2
INNER JOIN customer c on
c.customer_id = t2.customer_id AND
c.customer_state = 'CA'
GROUP BY order_date
HAVING count(transaction_id) >= 100
There are two crucial pieces here: (1) I created a subquery finding days with sales to California (2) I put that subquery into the WHERE clause to filter to those days
This is the flexibility of subqueries – I got to use a different level of detail to filter my base query. This is one of the most complex concepts you may be tested on. I considered subqueries to be right at the edge of “Expected” and “Nice to Have” and that line can be blurry elsewhere – so preparation is key here.
Common Table Expressions (CTEs) are becoming more and more popular. In fact, so popular that I’ve shunted the more complex subqueries in favor for CTEs. They essentially allow you to make something that acts and feels like a table, but only exists for as long as your query lasts. It is extra readable (think of how complex some subqueries can get in a long set of code!), and that readability is what makes it so powerful.
While I won’t cover the comparison fully today, I’ll save this discussion for a future blog.
If you come to an interview with examples of previous SQL work and/or a knowledge of Joins/Aggregate Functions/Subqueries, you’ll do fine on the technical assessment for most roles. This is the basic toolset needed for analysts to get the job done and allows you to leverage your business acumen and soft skills.
Duelers’s Note: Jacob here. I’ve found it incredibly useful to keep a book around for reference purposes that I can dog-ear, highlight, and otherwise markup. Since I’m primarily in the MS stack, I heartily recommend “T-SQL Fundamentals” by Ben-Gan Itzik.There are great references for other SQL flavors too – but you will need to do your own research to find them.
The past two Data Duel blogs deemphasized technical ability and touted soft skills as crucial for an analytics career. My goal is to bring the discussion out of the theoretical and into a practical example from my own career where I applied those four soft skills in an analytics context. In fact, the lessons I learned in the following example are ones I regularly utilize 6+ years later.
To define terms, “Ambiguous Problem” is one which no one clearly defines and for which no one provides a clear solution.
Let’s go back to 2014. I’m working at a manufacturing/distribution company. Growth is starting to explode, and I’m working as the org’s only data analyst. Reporting into the SVP of Sales, my desk is on the sales floor in the middle of ringing phones and reps busy entering orders into our system.
After a few months I notice something interesting. Nearly every rep has an Excel spreadsheet called the “Sales Catalog” up when they’re on the phone, showing various items for sale. Sometimes the row says “In Stock” and sometimes in red it says “Out of Stock”. I also heard grumbling – the sheet isn’t right. They’ll tell a customer “Yes that item is in stock” but when they go to order it, the system denies the request. Yikes, not a great experience for the customer or rep.
The process to correct data errors was also bumpy. Excel only allows one person to update a shared network file at once, and that person is the SVP’s Executive Assistant. Reps would call or ping the EA, telling them what update to make to the Excel file. Then all the reps had to close & re-load Excel to get the up-to-date information.
As I noticed these issues stacking up, I heavily leveraged empathy and curiosity to understand what the reps wanted to accomplish and why we ended up in this rather inefficient place. I talked to multiple people across the organization – sales reps, sales managers, systems – to make sure I had a grasp of everything.
These conversations let me take an ambiguous problem and define it:
Reps can’t get accurate and timely in-stock data to their customers.
Crucially, no one told me about this data problemor how to solve it. It was up to me to define and solve it
Developing a Solution
With the problem defined, it was time to work on a solution. This is where organization became crucial. As you may have noticed, there isn’t a single solution to this problem. Instead, I needed to break it down into sub-tasks:
(1) Figure out where the true ‘In Stock’ data in the system is stored (2) Create SQL script to retrieve that data (3) Get that data into Excel for the sales floor (It’s OK to keep something in a format familiar to them, even if it’s not fully optimal) (4) Make the report better! (Wouldn’t it be cool if instead of just saying ‘out of stock’ it said when it would be back in stock?) (5) Discuss V1 with leadership & iterate as needed before launch (6) Launch new tool with training/documentation
Each of these steps was non-trivial. I had to dive into our database and really understand how the items moved into and out of stock. I had to figure out how to write an accurate SQL script to replicate those movements. I had to figure out how to connect SQL tables into Excel and create a reliable pipeline. All while making sure I kept a similar form-factor for the sales floor to maximize adoption.
In the midst of completing each step, I made sure to understand the accuracy needed. “Good Enough” data wasn’t necessarily clear. For instance, I added in some buffer to what ‘In Stock’ meant due to how fast-moving the data was. Items went into and out of stock quickly. I wanted to minimize scenarios where my document said ‘In Stock’ and yet the system didn’t let the customer put in an order. Additionally, I needed to hedge on when an item would be ‘Back In Stock’ — more on this in a later post!
Critically, I also went through development cycle with leadership and other trusted Sales team members to make sure what I made would match their needs. They would see an early draft, give feedback and I would fix that before starting the cycle again. This is again where empathy came into play – I needed to understand their problem and make sure what I created actually solved it, rather than assuming.
Analysts provide massive value by identifying and solving ambiguous data problems. I learned that early on with this Sales Catalog example. I liberally applied each of the four soft skills to go from problem identification to problem solution:
Curiosity: Dug into what the reps were trying to do and what problems their existing solution created
Accuracy: Determined the tolerance of “Good Enough” data, both due to database limitations and hedging where I would prefer inaccuracy to rest
Organization: Broke down the problem into sub problems, which built into my final solution
Empathy: From start to finish, I made sure to listen to many voices across the team – both in understanding the problem and making sure my solution actually made their work lives easier
This same cycle has served me well time and time again in an analytics career. If you can proactively discover analytics problems and solve the important ones, you’ll quickly provide value to any company lucky enough to have you aboard.
If you were to ask someone “What skills are the hallmark of a data analyst?” the answers consistently center around technical ability: SQL, Python, R, Tableau, Power BI. The same shows up on most job postings – technical ability listed first.
That means it’s unsurprising when aspirational analysts focus heavily on “What technical skills / certifications do I need to be competitive for an open position?” To hammer the point home, I took a look at the Weekly Entering & Transitioning post at the Data Science subreddit. While not Data Analyst specific, there is a ton of overlap between people interested in Data Science and Data Analytics. Here are some excerpts:
“How are entry level prospects for someone with a bachelors in data science?“
“The main concern is that I don’t have any basic knowledge in any C language.“
“I have been teaching myself SQL/Python/HTML through CodeCademy pro“
This repeats week after week after week – never ending inquiries about the technical side of the job. In the words of Morpheus – what if I were to tell you…that technical ability will not win you an analytics job? This has held true both for me getting into analytics jobs, as well as interviewing many others for analytics positions.
There’s far more to a well-rounded Data Analyst, as someone in that same Reddit thread rightly identified: “While it’s easy to find resources to learn technical/mathematical skills, which I have been doing. Are there any resources for practising problem solving in the context of data analysis“
The Two Axes of an Analyst
Below is a quadrant depiction of how analysts are assessed in interviews and in their day-to-day. “Technical Ability” isn’t listed here.
Don’t get me wrong – technical ability is absolutely important. If you have no technical ability you’ll struggle to get the data you need to do your job.
But technical ability is just a means to an end. And it’s the most teachable type of skill out there! Even if there’s a gap, it’s easy to overcome with training. Business Acumen and Soft Skills are much more difficult to uplevel. I learned this lesson firsthand:
The Smartsheet Director of BI interviewed me three years ago for a Senior Analyst position. At the end of a 45 minute discussion, I realized I hadn’t been asked a single technical question. Not one check for SQL, or Python, or Tableau skill. So I asked, “Why didn’t you discuss my technical ability? Are you just trusting I know my stuff?” The director sat back, chuckled, and replied, “I only need to know how you think — if you have technical gaps we can fill those quickly.”
Technical Ability as a Multiplier
So, what place does technical ability have if it isn’t what analysts are measured on? It’s a multiplier – a 21st century career rocket fuel.
There are countless business leaders who have excellent acumen and soft skills. The C-Suites and corner offices are filled with those individuals.
As a data analyst you leverage technical ability to multiply how well you apply your soft skills and business acumen. Suddenly you’ll find yourself at tables you otherwise would never have seen, discussing critical business questions with C-Level individuals. Finding patterns in data requires technical ability, and data-driven stories are phenomenally powerful when wielded with strong soft skills.
There is a massive focus on technical ability when really that’s just a multiplier for the core skillsets a data analyst brings to the table. As you read in last week’s post, Data Analysts help the business make better decisions leveraging data. That involves connecting the data to business problems utilizing Business Acumen and effectively/persuasively communicating findings with Soft Skills.
The analytics space is rapidly growing & evolving, and this fast growth has led to a convoluted web of job titles which are overlapping and contradictory. I’m here to help you sort through some of those job titles and even open your eyes to different types of Analytics job you may not have considered. Data Scientists get all the press – but there are many more roles out there which may be a better fit for your interest & skills.
You will rarely find consistency from company to company. In fact, I’ll start with a couple disclaimers:
Disclaimer 1: Keep in mind that my opinion on the separation between these jobs has no bearing on how the HR department of a company defines their positions.
Disclaimer 2: This list is not exhaustive. There are lots of substructures to these roles as well as other data-adjacent or niche jobs which exist.
Keep In Mind When Applying
Make sure you absolutely understand the job description and ask many clarifying questions during interview rounds to fully understand what you’ll be doing. If you aren’t thorough in evaluating the job, you may not end up with the work you thought you’d be doing.
Example Job Titles
Data Scientist (Related: Statistician) Data Analyst (Related: BI Analyst) Data Engineer (Related: BI Architect, BI Engineer) Business Analyst (Related: Technical Project Manager) Machine Learning Engineer (Related: Software Engineer)
While there is no one-size-fits-all structure, there are general trends:
Data Scientist/Data Analyst/Business Analyst
These roles may report to any part of the business, depending on how centralized the data organization is. The more centralized, the more likely they are on the same team. Sometimes they may be their own team entirely, rolling to the CEO independent of any other C-Suite leader. Other times they may roll up through the COO or CTO.
Other times, they may be decentralized and be scattered across the company with no specific structure.
Data Engineer / Machine Learning Engineer
Typically these fall under the CTO. Data Engineers may be under IT, or may be their own division. MLEs typically fall into Software Engineering — see below for more discussion.
Overview: This is the most-publicized job title out there and therefore is the broadest; it can mean many things at many places.
Data scientists are forward-looking and focus on predictive analytics. They certainly can do descriptive analytics, but their value comes from modeling/classification/etc.
Due to the emphasis on modeling, data scientists typically have advanced degrees in statistics, applied math, information science, or similar.
Example task: Predict how much stock of each item a company should order from its manufacturers in advance of the holiday season.
Overview: While Data Scientists are generally forward-looking, data analysts are generally backward-looking and more entrenched in the business. Their job is to help the business understand what has happened up to this point and provide data in a clear & concise way for decision making in the future.
Typically data analysts focus heavily on making visualizations and presentations for the business and bridge the gap between the business and the data.
Data Analysts are also more jack-of-all-trades. It’s common to do a bit of data science, analytics, engineering, and PMing in a single role.
Example task: Create a flexible Tableau dashboard for leadership to track trial conversion to paid users over time
Overview: Data engineers work on the databases that the other members of the analytics org use to get information to stakeholders. They are responsible for bringing data from the business into some form of data warehouse in an accurate, timely and secure fashion.
This means the typical customers of data engineers are the data analysts/scientists at the company. They also may work directly with different parts of the business as they want their own data ingested automatically into the larger data warehouse.
This role is typically more technical and code-heavy in order to move massive amounts of data around at scale. There is less interaction with the business than other parts of the analytics organization.
Example task: Mirror Salesforce data in a schema in Snowflake, updated every 5 minutes, for analysts & scientists to analyze/visualize
Overview: Business Analysts are sometimes called a “project/product/program manager”, or PM. No matter the name, they are distinct from Data Analysts/Scientists in an important way. They coordinate and organize data projects across the business.
This role typically doesn’t exist early on in a data team’s existence. Usually individual analysts/scientists take this on until the burden of project managing starts outweighing time spent actually doing analysis. Eventually, the role of Business Analyst comes along.
Business Analysts are not expected to code or be as savvy on the technical side. Rather, their job is to identify problems, gather requirements, allocate resources and coordinate expectations between the data team and the business. This is no small task as many technically minded individuals are great at doing an analysis when there’s a clear question, but struggle to work with non-technical individuals across the organization.
Example task: Sales wants standardized KPI dashboards across their worldwide teams available for next quarter’s SKO
Machine Learning (ML) Engineer
Overview: This is a bonus position added in, largely since I see Machine Learning discussed commonly on Analytics forums and many of you may be wondering how it fits into a data org. The short answer: this role doesn’t fit into the data org per se.
Specifically, this role is commonly found on the Software Engineering (SWE) org and is more of a Software Engineer with an ML focus than anything else. This role is most similar to a data scientist and usually is more involved with implementing models within the production code of the company to solve whatever problem has been identified.
Example task: Predict which users on the website may want to know about Feature X, which will prompt an informational pop-up
There are all sorts of roles to explore and this list is by no means exhaustive. As I mentioned at the start, the names above may be conflated with each other at any given job you apply to. Regardless, this gives you some guardrails around what sorts of roles are out there — from non-technical to technical and everything in between.
As I mentioned in The Wandering Path to an Analytics Career, there is a ‘Great Filter’ in Analytics. It looks something like this:
Lots of people want to break into an analytics or data science career, yet not many are able to. This leaves a glut of competition for entry level positions, and not enough qualified applicants for mid-level to senior positions. Once you get your first few years of experience, you’re golden! You have your pick of many options within the data world – but you have to get past the Great Filter.
This rings true for me in an anecdotal sense – I have experienced this as a job seeker, interviewer and in discussions with data hopefuls. Given this is a blog devoted to data, I wanted to quantify the interest in a analytics positions just posted on LinkedIn. Unsurprisingly, you’re swimming upstream if you’re just blanket applying to analyst jobs – dozens to hundreds of applicants within a day or two of posting. See below:
For a fantastic & further in-depth analysis, I highly recommend reading the “Glut of New Data Scientists” section of this blog by Vicki Boykis.
Applicants Focus on the Wrong Things
As I’ve combed through resumes, cover letters and LinkedIn messages for the past five years, I’ve noticed applicants consistently missing the mark on what will set them apart. They consistently point to technical ability:
Those things are all great, but they don’t differentiate you from the pack. Everyone has some nominal experience in these things, you likely don’t have experience in all the tools the company needs (What if they use Looker instead of Tableau?) and even if you didn’t much of this can be taught on the job.
When I interviewed at my current position, I wasn’t asked one technical question. When the Director of Analytics stopped to see if I had any questions, my first one was “Why aren’t you asking me any technical/SQL questions?” I’ll never forget his response: “If you’re missing any technical skills, we’ll teach you.” Wow.
This seems counter-intuitive. Isn’t data analytics/data science more technical? Don’t you have to code? Of course you do! But those aren’t the most sought after skills; they’re a means to an end.
What Top Applicants Demonstrate
Analysts that shine on applications and interviews show they can persuasively communicate complex ideas using data. The job of a data analysts is to work with a stakeholder to generate business value. That doesn’t happen through coding – that happens through understanding the business, understanding the problem (even if it’s not directly stated!), breaking that complex problem down and communicating what the data says to do. Technical ability is solely leveraged to get there.
This is in the realm of “soft skills” is learned quickly on-the-job and is tougher to gauge for someone with no experience. How effectively can you work with non-technical stakeholders? Will people like working with you? Can you distill an ambiguous question into an actionable insight?
Top applicants can point to experience showing they can handle these scenarios and that’s why they rise to the top.
Tough to Teach in Classes
Classes are unfortunately a poor place to learn and/or demonstrate critical analytics soft skills. Teachers ask you very precise questions and give you very precise datasets to see if you’ve understood explicit topics listed in the syllabus. In the real world, this isn’t how analytics works.
Sometimes you aren’t even told there’s a question. If you’re asked a question the person may mean an entirely different question. The data might not exist, or it might sort of exist, or you might need to make it yourself. Your presentations are to a potentially skeptical crowd who doesn’t care what methods you used to arrive at your conclusion.
You can see the pattern – it’s near impossible for a teacher to create this sort of ambiguous and dynamic setting in a classroom. Imagine not knowing what day a test was coming, or if there were even questions on the test, or if the questions on the test were the ones you were supposed to answer!
This stuff is learned on-the-job, hence the need for experience.
OK OK, I get it. What do I do?
Now we’re to the crux of the matter – is there anything to give yourself better odds at landing that first job?
Yes. There’s one overarching tactic, with three options you can do today to gain experience that will make a difference in an application.
Option 0 – Network, network, network!
This applies to all three other tips. If you’re throwing your resume into the ether of hundreds of applicants, you’ll find less success than networking with the leverage of the tips below
Option 1 – Start doing analytics in your current job
This is where many of us (including me!) started. You know how there aren’t enough good analysts out there? Take advantage! That means your company needs data people. Your boss, or some other boss needs help. Discuss their data issues and see if you can take something solvable. Don’t overcomplicate this. Use Excel to start, it’s a great place to iterate and extremely flexible. Move from there – find a pain point someone has with data and try to solve it. Start small and build. This is phenomenally effective, and you can point to this experience when applying to jobs later on (or move to a data position at your current place!).
Option 2 – Work on a data project you are passionate about
I see tips everywhere saying “take on a personal data project” but rarely see much helpful advice beyond that. My top recommendation is to think of a hobby or interest you have and create an end-to-end analysis. Do you love a particular sport? Try to predict something that will happen. Have a favorite hobby? Think of a dashboard you could create to display your time spent/skill improvement. The more interested you are in the data, the further this will take you and the more time you’ll put into it. The options here are endless, but should be regarding something you love.
This gets you experience across the entire analytics pipeline – finding/cleaning/enriching data, asking good questions, visualization. Tableau Public is a great way to publish your results and iterate. The options are endless, and you can demonstrate skill and passion in an interview pointing to a portfolio of data projects. It doesn’t matter what tools you use, though my only recommendation is SQL and some sort of viz tool be involved.
Option 3 – Take online courses to brush up on technical ability
I’ve spent a significant amount of time saying that technical ability won’t separate you. That’s true, but you do still need some technical ability or you may be disregarded as not technical enough. If you don’t know SQL at all, you can take some basics online as part of doing Option 2. Do some basics on Tableau or Python or whatever strikes your fancy. This certainly is the least helpful option for standing out, but it also is a prerequisite if you lack technical ability. Typically if you’re doing Options 1 and 2, you’ll end up needing to do this option anyway.
Breaking into analytics isn’t easy. But there are methods to get past the Great Filter and get your first job. It’ll take hard work and some luck and the goal is attainable. Companies need passionate and smart people to make sense of their data, and you can step into that role. Make it happen!
I consistently receive the same questions from people seeking an Analytics career: What classes should I take? What certifications should I get? Should I learn SQL, Python or R?
Behind those questions there’s a consistent assumption: “There must be a clear path to an analytics career.”
I’m here to challenge that assumption. There isn’t one clear path to work in analytics – most of us got there through a winding, wandering series of career moves. My story is one of many – ask someone in Analytics and you’ll hear something similar.
Typical Wandering Path
(1) Get a college degree or other training – not super relevant (2) Work for a while in some job non-analytics related (3) Recognize interest in analytics (4) Start doing basic analytics at work (ideally) or on own time (5) Leverage that experience into first analytics job
I’ll call out each step as it happened in my career journey.
My Wandering Path
Initial Career (Years 1-4)
Coming out of college I shared the assumption that careers were linear. After all, life to that point was linear, so why wouldn’t careers be the same?
Except, my linear plans fell apart two days before my wedding in 2011. I’d studied International Economic Development (Step 1), interned in Latin America, become fluent in Spanish and was planning to move with my soon-to-be wife to Bolivia. In one phone call and several subsequent conversations, that potential life and career ended. I was sitting in a dead-end job I thought I’d be leaving and had to figure out Plan B.
At first it wasn’t obvious – what else should I do? I was a Customer Success Manager (Step 2) but didn’t really want to do that as a career. I’d worked in sales departments, but didn’t really want to be a salesperson. But then I had an epiphany – there was a part of each of my first few roles that I loved that never was part of my job description.
I was consistently making little analytics & reports (Step 4 – which ironically for me came before step 3!). I’d turn 2,000 customer emails into a digestible summary for the product team. I’d make Salesforce forecasts & dashboards for the executive team. I made a Google Sheet for my Rosetta Stone team to help management track & manage renewal rates for their teams. This stuff was fun! I liked it! (Step 3) But what now?
The Great Filter: Landing First Data Job
Have you heard of the concept of the ‘Great Filter’? It’s part of the Fermi Paradox, which ponders why there is no extraterrestrial life given the seeming high probability it should exist in the universe. Within the Fermi Paradox, it’s the step getting from non-living matter to living matter (abiogenesis). The Great Filter is a catchall for “it’s hard to get past this point.”
I argue there is a Great Filter for those trying to get into Analytics – getting your first job. In fact, I’m devoting my next blog to this topic, so consider this a lead in to next week.
Passing Through the Great Filter
I realized I had an uphill climb ahead. Perhaps this is where many of you are – how do you get a company to take a chance on you?
I asked lots of current analysts via informational interviews at local coffee shops. They all said “I got here via a pretty random series of events.” Sound familiar?
They gave me a breadcrumb trail, though: “You have to get enough experience together and communicate about it well enough to get someone to try you out.” Easier said than done, but I did have some experience already in my current role.
I applied everywhere. I was told by recruiters/HR multiple times “Hey, I guess you could be an analyst but I think your future is in sales based on your resume.” Leads fizzled out until one day I got a call.
The Meeting That Changed Everything
“Can you show up at the office in an hour? The CFO and SVP of Sales want to talk.”
I got that call from Jacob — the same Jacob here at DataDuel. He was working at Funko, a quickly-growing collectibles company north of Seattle. They didn’t have a position open yet, but there was interest in getting analytics going. Before going into the meeting, here is all I knew:
The position was planned to be part-time Analytics and part-time something else until analytics skills were proven
The position was planned to be a contract position (not great – I’d just bought my first house and wasn’t looking for a contract spot)
There would be minimal support since no data team existed, so a self-starter attitude was needed
Given those three bullet points, I had three goals going in:
Communicate my potential to be great at analytics if given the chance
Sell them that I was worth a shot as an employee & not a contractor
Demonstrate self-starter attitude to analytics from previous roles
I quickly threw on a dress shirt, re-learned how to tie a tie on YouTube and flew out to the car.
The rest is history and full of the content I’ll fill this weekly series with. The conversation went really well and they decided to take a chance on me a couple weeks later (Step 5!). While I got a full-time position, I took a 10% pay cut because I needed to prove myself. I knew the temporary sacrifice would be worth it – I just needed my first position to get past the Great Filter.
There’s no one path to analytics – there are many. I’ve used my path as an anecdote for the infinite options out there.
The general path, though, is to start doing some analytics in any fashion you can, and leverage that experience to get your first position. It isn’t easy – there’s a Great Filter out there which prevents many from getting in.
Come back next week and I’ll dive into the Analytics Great Filter in more detail, and provide some practical options of how to overcome it.
Do you enjoy working with data in your current role? Are you interested in a Data Analytics career? Are you currently a Data Analyst?
Good news! This weekly series is for you. It’ll cover all sorts of topics within analytics, including advice for aspiring analysts, best practices, key skills/tools and industry updates.
Initial blog topics include:
The Many Wandering Paths to Analytics
Analytics Job/Role Types
Key Skill Sets for Analysts
Visualization Best Practices
Measuring Success of Analysts
How to Prioritize Your Work Backlog
Much of this will be written from my perspective as an Analyst. There are other perspectives out there for unique positions like Data Scientists and Data Engineering, and while I’ll touch on those regularly (and will write an entire post on the difference between those roles), the focus here will be Data Analysts.