Vulnerability is a Data Analyst Skill
One of the hardest lessons I had to learn in my analytics career is that I didn’t have all the answers, I could never have all the answers, and I couldn’t answer challenging questions on my own.
That’s not to say I couldn’t write SQL code or build clean visualizations, but the tidy datasets and problems that guided me to clear “a-ha!” moments and excellent model fits I learned from in courses were gone.
When I started in this field, I had extreme impostor syndrome that led me to think I needed to know more than I did. I wasted a lot of time trying to reason my way through problems without complete information because I was too afraid to admit I was ignorant. The worst part about it was no one expected me to know everything.
That’s also not to say that you don’t get better as your knowledge of the data and business improves, but on day 1, week 1, month 1, or even year 1 of your first data role, if you find yourself plowing your way through an analysis or model building without asking your team and stakeholders for input, you’re likely leaving a lot of valuable insights on the table at best, and at worst you’re headed for complete failure.
There are a number of ways an analysis can go sideways, but the most avoidable one is trying to brute force your way through a problem you don’t fully understand, with data you haven’t worked with before, and presenting findings that either don’t add value or quickly fall apart when people start asking questions.
The context provided in courses is no longer given to you on a word doc or delivered in a brilliant lecture, it exists in other people within your organization. It’s not too hard to get if you are able to admit you don’t know everything and have the courage to ask what may seem like stupid questions. In other words, you need be vulnerable.
Here are a few places I’ve found its critical to be vulnerable:
Checking your Assumptions
Most real-world data doesn’t have the metrics we need rolled up in a tidy .csv file. Often, you are joining together multiple tables and aggregating metrics with complex logic. There are also often caveats or exceptions in the data that aren’t intuitive at all.
Asking questions like “Is this the correct logic for determining cancellation?” will save you a lot of time and credibility.
When someone asks you to analyze customer retention, you’ll inevitably need to calculate cancellation rate. You might simply try to do this by calculating sum(cancellation) / sum(total_accounts), based off of whether an “account_closed” column is null or not.
But is there also a “customer_reinstated” field? If the customer had a credit card expire and service resumed the next day, is that a cancellation?
What if there are multiple sub accounts, e.g. a child on their parents cellphone plan that stopped service when they moved out, while their parents remain?
Was the account that closed a promotional account that isn’t relevant to the bottom line? etc.
Someone in your organization has likely thought through these caveats in the past, and even if they haven’t, trying to think through this type of problem without the help of subject matter experts will likely lead to a better solution that what you build on your own. At the very least, you’ll have buy in and support in pitching your logic.
From a non-technical point of view, having someone you trust review your slides or presentation before you hit the big stage can help as well. You might do this with your manager, but asking a peer or someone who has a strong grasp of stakeholder needs can dramatically improve your storytelling and audience response.
Asking for Feedback
Corporate culture, team culture, and manager personality can all influence how often and frequently you get feedback. If you’re lucky, you will have a manager that gives you constructive feedback on a regular basis, but often you’ll find that if you don’t ask, and aren’t about to be fired, you get pretty generic feedback once a year in an annual review.
No news might feel good, but your professional development can be greatly hampered if you’re not identifying and working on your “opportunity areas” on a regular basis.
We need others to point out our “blind spots” in order to progress in our careers. Sometimes all you need is the courage to ask.
Building a Network
Cultivating relationships in an organization can do wonders for your career. A lot of my most cherished professional relationships have come from my first few months in a new role.
I knew nothing, and I was vulnerable enough to ask for help. Most people want to help, and when they do, they start to become invested in your success. People also usually enjoy being included in analyses that pertain to their functional area.
Imagine if someone wrote a biography about your life using only information on social media. They might get major facts right, but they wouldn’t say anything novel. You’d probably also feel pretty frustrated someone did that without consulting you. Being vulnerable enabled me to build partnerships that ensured my analyses were relevant and well-received.
These relationships might start with asking a simple technical or business question, but as you continue to build a rapport, you will find you’re starting to build a roster of stakeholders from different areas across the organization. That will pay dividends for your career down the line.
Your first data role will probably be overwhelming. There is a big gap between performing data analysis in courses and doing it in the real world where this is no obvious step by step guide. Acknowledging you don’t know everything, and having the vulnerability and courage to ask for help, will help ensure that you maintain your credibility as an analyst and continue to grow professionally.
If you liked this, we’d love for you to subscribe to our publication.
And drop us a comment letting us know what you’d like to see next. You can also submit your own writing for us to promote, so don’t be shy if you would like to become a contributor. Check out submission instructions here.
Happy learning!
