Soft Skills Beat Technical Skills in Data Analytics
There is a common misconception amongst people entering the field that writing better code will make you a better Data Analyst. I'm here to tell you that just simply isn't true.
The most important function of a Data Analyst is to drive business value to an organization in a measurable way. And it doesn't mean you need an impressive technical solution to do it.
It's your role to interpret a business problem, craft a narrative for stakeholders that explains the reasons behind an event, and demonstrate its impact on the business. This can require a technical approach with advanced tooling, but that's not ultimately what matters.
Data Analytics is not:
"We've lost 14 customers this month".
It's more like:
"Customer churn experienced a 5% increase compared to last month, with 75% of the lost customers mentioning they switched to a competitor. These clients specifically pointed out that our product lacks a certain feature, which explains the decline."
The latter gives stakeholders something to action on, as should all the reports that you generate.
Taking the following Soft Skills into consideration will help you boost your effectiveness in this role and allow you to stand out.
A Strong Understanding of The Business Model
In other words, how does the organization generate revenue? and how familiar are you with the intricacies of delivering your product(s) or service(s)? Your domain knowledge should be focused on the area of the business that you report on (Finance, Operations, Marketing etc.) as well as holistically across the organization. The more knowledgeable you are about the business itself, the better approach you will have in generating an analysis and delivering impact.
This also means that you have an understanding of how source systems collect and validate the data that you are reporting on. You should know the ins and outs of the operational processes which comprise certain metrics, as well as the limitations of what questions can be answered on top of it. If you are an ecommerce business – how is a page view measured from Google Analytics? Or if you work in supply chain, what does "Time to Fulfillment" represent & how is it shown in SAP?
It's not uncommon for great Data Analysts to come from a domain specific coordinator / analyst role (ie. a Finance Analyst, Marketing Coordinator etc). This is an effective route because being on the ground level of a business process gives you much more insight on how the organization functions.
Think about it, if you worked for an airline company and you were developing a dashboard on flight bookings, don't you think it would be an unfair advantage to have worked in the reservation department? You would have an understanding of all relevant data points entered in their booking system, what they mean to the business, and challenges surrounding this process.
Communication and Collaboration
Inevitably, you are not going to have every answer to the business problems that you are presented with as a Data Analyst. Therefore, you are going to need to partner with other teams to get clarity on a specific piece of data that you need, or the business process behind how something is generated.
Data Analyst roles are also front facing to an organization, where you may be presenting your findings to peers, management, C-Suite, or external clients. You need to dust off your presentation skills and be able to communicate complex results in a meaningful way.
When it comes to communication, less is always more. Your peers, stakeholders, and management don't want to hear the details of how you've manipulated your Pandas Dataframe or how many common table expressions exist in your SQL statement. Rather, you need to be able to abstract the technical aspects of your work and only communicate what is most important.
Critical Thinking, Curiosity, and Observability
The problems you are going to be presented with are difficult. If they weren't, your organization wouldn't have hired you.
When approached with a business question to answer, you need to conceptualize what data is available, and how it can be transformed to answer that question correctly. It will not always be clear how to connect the dots between the initial problem statement and the available data, but having a continued curiosity behind the "why" will always allow you to succeed in this area.
For example, let's say your organization asks you to create a report on how many client contracts are being upsold each month. On the surface, this sounds like a straightforward question, but it gets more complex when you arrive at the available data. The first thing you need to determine is how a contract term is identified so it can be aggregated by month. Are you just referencing an end date on the contract record, or do you have to look in the billing system to verify if payment is still being collected? Perhaps it's a mix of both.
Then once you know how the contract term is identified- how do you determine if it's an upsell, downsell, flat renewal, or cancellation? Are we looking at the net change of the account before and after the term? Or is there another set of criteria we need to reference?
In a scenario like this, you need to be able to break down large problems into smaller pieces and organize yourself in the exploratory data analysis (EDA) stage.
Exceptional Stakeholder Management
Stakeholders are the clients of Data Analysts; they are the folks that benefit and action off of the reports that you generate. And just like anything else, if a client is unsatisfied with your service, they'll look elsewhere.
Data Analysts need to understand the roles of the people who they are delivering reports to. Think about the surrounding questions that your stakeholders might be fixated on & what they personally care about in their job function. Working in Operations and Finance domains, a common question I've pretty much always needed to have a response on is "Why doesn't X number tie to Y number?". Being able to break down this reasoning to my stakeholders has always helped the conversation move in a positive direction.
There is also a human element to being successful in working with stakeholders. Ask yourself the following:
- Are you personable to work with?
- Do you make it easy for them to communicate requirements to you?
- How difficult is it for them to understand the findings from your analysis?
- When you say you can hit a benchmark in your project by x deadline, can you deliver it? And if you can't (which is okay), can you be transparent with the blockers?
While you need to make sure you're answering everything that is asked of you, Stakeholder Management also means giving pushback in the right scenarios. But there is a fine line to this. You may have heard of the project management buzzword "Scope Creep". This is a valid concern when getting feedback on a project. During a dashboard or report review with your stakeholder, be sure to get a list of essential vs nice-to-have improvements as takeaways.
It's okay to ask, "Why do you need X metric?" because this could certainly start a meaningful dialogue. But if you find that despite your efforts to question this new feature, the conversation isn't progressing, it might be beneficial for you to set aside your disagreement and just prioritize completing the task.
A Final Thought
Yes, You Still Need Technical Skills, But No One Cares About Them
It's inevitable that you will need technical skills to be successful in your role. Data never comes in a format where you can just _SELECT * FROM perfecttable and call it a day. But just know that no one else but you will likely ever see the technical solution behind the report.
Of course, you still need to think about the scalability of a dashboard or report to ensure that its easily maintainable across your analytics team and dynamic. But don't over engineer something that doesn't need to be complex.
In one of my roles, one of our most highly viewed Tableau dashboards was developed by a sales manager. It wasn't pretty to look at, nor did it have anything advanced to it. But this dashboard addressed a crucial sales goal with remarkable simplicity and significance. The key to its success was the manager's profound understanding of the Sales team's primary concerns.
So yes, still go out and learn SQL, Python, Excel and Tableau. You're going to need it. But just make sure you understand why you need it.
