Discover more from Data Analysis Journal
What Is the Best Advice You Have Ever Received? - Issue 145
What advice changed or transformed your career? Take some advice from analytics industry leaders.
Hello, and welcome to my Data Analytics Journal, where I write about data science and product analytics.
This month paid subscribers learned about:
Introduction To Event-Based Analytics - How to manage and leverage event-based data for analytics. The best practice of setting up events, properties, and attributes for user activity tracking, and how not to get lost in the event data noise of toggles, hoovers, and scrolls.
How To Get Average Logins Per User Per Day in SQL - A continuation of the user engagement analysis series. How to get the average number of logins, actions, transactions, or likes per user per day and segment it on paid, in-trial, and free user types.
Introduction To Problem-Solving And Critical Thinking: nailing problem-solving and informed decision-making. How to develop critical thinking and strengthen your analytical intuition. Common methods and types of analysis.
This newsletter is a little special ⭐.
Once per year, I reach out to my network of analysts and data experts with one question - what is the best advice you received that changed your career? Today I wanted to share some of the wonderful responses I got. I hope they will inspire all of us to grow in analytics and get empowered with data.
What Is the Best Advice You Have Ever Received?
Look for ways to replace yourself. Early in your career, you get ahead by being the best analyst -- the person who knows the data better than anyone else. That quickly changes. To truly advance you need to find ways to hand off your responsibilities to someone else. It'll be painful in the short term. You'll feel uncomfortable. You'll need to rethink your work identity. But it's what unlocks your ability to be proactive, rather than reactive, and to point out opportunities to improve that nobody else sees. If you're not uncomfortable, you probably aren't growing.
I would say - that I need to focus. I am too curious, so naturally, I dig into 100 topics at the same time.
What it changed - I picked one topic - tracking setup - and spent my energy on investigating it as far as possible. This brought me to a framework for tracking design and gave me plenty of great feedback when I wrote about it.
I stick to this now, that I try to pick one central topic and write about it. It does not always work out 😁
Here's a piece of advice that was useful to me, from my good friend Erik Goldman, founding CTO of Vanta.
"When considering opportunities, reduce your decision space to one "got to have it" thing. Decision quality goes down when you simultaneously consider a composite of factors: wealth creation, technical development, adding well-known brands to your resume, people management opportunities. Far better to condense to one goal: "I want to learn about AI" or "I want to start a company after this". For example, before Eppo I knew I wanted to start a company, and thus indexed heavily on proximity to leadership, reporting directly to the CTO."
For the analyst-specific career path, my big recommendations are:
1. Write, both internally and externally. Give lots of presentations. Doing these will grow your brand and credibility, far more than painfully persuading business stakeholders one by one. Writing one external blog post at Airbnb has done more for my career than years of in-house IC work.
2. Think of analyst work as a stepping stone to another functional domain: product, eng, marketing. This isn't to say that you have to leave data work, but the highest impact analysts will be multi-brained with one of those.
I remember this one very well. I had joined a tech company and I wasn’t sure what direction to take in my career. I had been working with SQL and doing analytics engineering for a while and I had also worked on quantitative analytics.
I somehow had this notion that I needed to work on quantitative stuff in order to be closer to the business despite the fact that I didn’t enjoy it much. I enjoyed the engineering aspects much more.
I asked a director-level colleague about what he thought I should do and he plainly said: “Do what you enjoy and are really good at. You also happen to be very close to the business through the work that you do so why change careers? The business also happens to value your work as is since they’re already paying you for it.”
That advice was crucial to helping me continue to build my technical skills and eventually led to me writing my SQL patterns book.
The best advice I've gotten came from my skip manager at Wayfair, who told me:
"You should always try to work at places that you're really excited to work at." At the time, I remember thinking he was just trying to keep me at Wayfair, but in hindsight, I realized this was fantastic advice. When you enjoy your work, everything compounds. You learn faster, you advance faster, you're more creative. Plus, you're happier, which means more of the rest.”
Start with the problem, not the solution. Often times data teams get so wrapped up in complexity that they fail to step back and remember the work we are doing is not academic. If you always root work to clearly defining the problem, you will never have to worry about whether your projects deliver value or not.
And reflecting on advice responses I received last year:
“Every cutting-edge thing you learned in college will be stale in three years. Hence, take jobs where gaining new knowledge is a key part of being successful.”
Looking back, it has been proven to be true again and again and again. I've done my best in every role to stay close to the real work, and that has forced me to keep learning new skills. The alternative fate is I become yet another director/VP, whose primary success is driven by an ability to suck up or play company politics well.
For me, the best advice I ever got was to find real problems that I cared about answering.
There are lots of tutorials out there that teach technical skills on toy problems and sample datasets. These problems might teach you a few techniques, but they won't make you a better analyst, because learning to be an analyst requires asking questions, seeing a result, being curious about what that result tells you, asking more questions, and continuing to dig until you uncover something truly interesting and useful. With real data, on real problems that you care about you'll do this naturally; your curiosity will draw you further in. On sample problems, you'll often stop when you get to the answer in the back of the book—which, of course, doesn't exist for most questions you'll want to answer.
The best advice is to always ask oneself: "Do you want to be effective or do you want to be right?" This applies to both data and leadership.
Let's start with data.
This advice reminds me to take calculated risks because speed matters in business. Often the cost of having comprehensive data to make the right decision requires lots of work. For example, one can set the p-value threshold at 0.01 but it means that you need to run A/B tests for an extended period of time – sometimes you probably never hit 0.01 because when you extend the experiment period, you have to also consider seasonality, model drifting, etc. And that's why most companies set p=0.05. Even if such a threshold naturally introduces false positive treatment, the choice is much more effective.
Let's talk about leadership. This question can be applied in different contexts. I'm providing one example here. Often we are facing multi-choice options. Say, there's almost no right answer in designing an organization. When I have to introduce an org change, I often favor consulting only key people (senior leaders, my manager, HRBP, etc.) While it's absolutely possible to consult every manager in the org to gather more information, keeping the group small comes with benefits like speed and alignment. It would take months if dozens of managers are involved in the process. On the contrary, it would be a blind decision to make an org decision without considering different perspectives. The question reminds me to seek a compromise between gathering inputs, achieving alignment, and making timely decisions.
The best advice I got was to always ask questions about any request for data, metrics, analysis, etc, until I understand the ultimate decision that the requester is trying to make. All requests like these should ultimately be informing some decision, whether that it is a big one-off decision for the company or an ongoing decision, like metrics that inform a manager on whether their team's execution is on track. When you understand the decisions driving requests, you have an opportunity to figure out how best to inform the decision beyond the specific request and how to formulate it into the format that would be most effective for the decision-makers. It also helps with prioritization since the underlying decisions can usually be sorted for importance and urgency better than specific data requests.
The impact of doing this in my career has been that I moved from a tactical bit player with limited impact to someone who is driving strategy and has huge impact. It has also helped me coach my teams on how to have a bigger impact, which is generally a difficult thing for even pretty experienced data analysts to figure out.
The best lesson I got from possibly one of the worst managers I ever had “Never be victimized by your circumstances”
You have to own your situation. If things turn against you you need to figure out how to assess the position you are in, and identify who you need to work with to provide a solution to your customers!
35 years ago when I was in my first job as a high school language teacher (in Latin), my first mentor urged me to learn more about computers and programming because he thought it would become important and getting in on it in the early days would be both interesting and good for my career. He was more right that I think he could imagine, since that start everything for me.
The second advice was from my boss was to accept a posting London to help start a new company about 10 years ago. While there were various hassles for someone older to take a position like that, for me it was a great opportunity to expand my network and diversify my skills, which was valuable in later positions.
I have two pieces of advice that came to me at different times which I've never forgotten:
1) Before I got started, I asked an alumni of my graduate program something he wished he'd known before getting started and he said to me "there is no such thing as perfect data". It didn't mean a lot to me at the time, but definitely as I got out into the wild it made much more sense in that the best you can do is understand your data and "respect your data", so that you can handle it with care knowing there is always going to be some nuance to it.
2) Immediately after getting promoted to my first manager role I was told by the head of my vertical "people are unpredictable". This was meant in a way to prepare me for people management and knowing that you can't know everything about the way people work all the time, especially when the team gets large. What I took from this, though, is the importance of communication and creating an environment for openness where you can reduce the unpredictability, but you can never eliminate it fully.
Thanks for reading, and thank you to everyone who shared their learnings ⭐.