6 Soft Skills Mastered by Top Analytics Engineers
The secrets to advancing yourself to the next level of your career
Everyone with a computer science degree understands the technical aspects of data. However, not everyone with this degree knows how to talk to the business and create value.
This is what sets analytics engineers apart from your typical data engineer. They know how to communicate with stakeholders in a way that gets to the root of the problem. They can translate business needs into data products that stakeholders want to use. And, in the process, they increase the data literacy of the teams they are working with.
However, not all analytics engineers succeed at this. In fact, I think the majority don’t understand how to communicate with stakeholders. When they don’t know how to do this, they:
build products the business doesn’t need
spend too much time on the wrong problems
are unpleasant to work with
waste time by talking rather than listening
When you focus on soft skills as an analytics engineer, you can stand out compared to those who only focus on the technical aspects. Because, at the end of the day, the business cares about value more than anything.
Know when to listen rather than talk.
Listening is a super power in a world where everyone wants to make their voice heard. This is especially true when it comes to stakeholder management.
As an analytics engineer, you need to be an expert at gathering all of the information. The best way to do this is by listening to the people who need the data, who generate the data, and who understand the business problem best.
You don’t always have to talk. Be able to read the room and understand when your words aren’t landing with people or when it’s time to give the floor to someone else.
Adjust your language to your audience.
You shouldn’t be talking about cardinality and slowly changing dimensions with stakeholders. They won’t have a clue what you are talking about! Change your language depending on the person you are talking to.
Use these terms with other engineers, but with stakeholders, shift your focus to talking about value. Why would they care about these things? How do they affect the way they use data to create insights?
For example, instead of mentioning an SCD Type 1 vs an SCD Type 2, you can say something like:
“This project is important so that you have a history of each of he products in a pack at a given time. Otherwise, we wouldn’t be able to track sku changes within a single pack”.
Ensuring everyone around you understands what you are communicating is invaluable to how a team functions and stays aligned.
Bake data literacy education into your conversations.
You shouldn’t just solve stakeholders’ data problems and be done with them. Working with them should be a collaborative process to shape how data is being viewed in the company. You should make it your goal to teach stakeholders something new about data in every interaction you have with them.
Some examples include:
teaching them about naming conventions within their tools
showing them how to document
explaining why metrics need to be defined in one place
working with them on a documentation center of excellence
showing them how their actions affect data quality
Data quality starts with data processes. Stakeholders are often the ones owning these processes, so helping them understand how they fit into these will only enable better data standards going forward.
Don’t be afraid to ask for extra clarity.
Too many people are afraid of looking stupid. Instead of worrying about what everyone thinks about your question, worry about doing your best work possible. If you are unclear on what needs to be done, or what the exact problem is, you won’t be able to do your best work.
Here’s an example of how you may ask for clarification:
“Cassandra, I heard you mention an ongoing issue with the products source dat table. Do you mind expanding on that so I have the additional context I need to complete this product changes data model?”.
Ask more questions so that you can be clear on exactly the thing you need to do. This will lead to better outcomes for data teams and their stakeholders. Nobody will be thinking you are dumb for clarifying something you didn’t understand, especially if it leads to a better outcome!
Say no more often.
Saying no doesn’t mean your lazy. It means you know how to prioritize the right work. It means you know what is most valuable to the business.
I’ve seen so many data people get burnt out because they were afraid to say no. Don’t burn yourself out.
Instead, understand how to back up and support your reasoning for saying no. Learn to make stakeholders prioritize their requests rather than you being the one to have to prioritize them.
For example, if someone on the growth team asks you to add refunds to an MRR calculation but you’re also working on adding disputes to this for them, say something like:
“I am happy to prioritize adding disputes to this metric, but then I won’t be able to add refunds. Which is most important to you? Which one should I prioritize?”.
Here, you are politely saying you cannot do something and in turn asking the stakeholder which task is more important to them. This takes the burden of prioritization off of you!
Be kind.
Life is already hard enough. Don’t be an asshole to your coworkers.
Stay tuned for a special summer announcement next week…
Your summer is about to get turned up a notch!
Madison