I have been quiet over the last week, because I was busy doing coaching calls with subscribers. Many told me about their “passive income” dreams:”Maybe a course I can sell, or maybe investments.”

I have some strong opinions on this, and let me tell you what I really think.

“Don’t sell your time for money.” You probably heard about this. “Build passive income. Escape the 9-to-5. Create a product that makes money while you sleep.”

Here’s the inconvenient truth they don’t tell you: There is no such thing as truly passive income.

• The “passive” course you sell? Requires active marketing content, updates, and community engagement.

• Your “passive” stock portfolio? Requires research, monitoring, and active decision-making about market conditions.

• The “passive” product business? Requires constant updates, customer support, and marketing.

I met a founder friend who built an interview coaching business. Now he has a team and works about 20 hours a week, leaving time for his hobbies. It took him over five years to get there.

He feels great about the freedom, but to stay fulfilled, he’s still looking for new things to do.

This is why many financially successful people get bored or depressed. You get used to the freedom, and then you realize fulfillment comes from actively spending time on things you enjoy, and where you feel you have an impact.

The question isn’t how to make money passively. It’s: What work do I enjoy enough that I’d happily spend my time on it?

I met someone who figured this out.

He quit investment banking—the long hours, high stress, great money—to start a corporate hiking tour business.

Now he sells his time for money, taking groups on mountain hikes and facilitating team discussions in nature.

He makes less money than he did in banking. But he’s outside. He’s moving. He’s doing work he loves.

That’s not passive income. That’s active income doing something that makes him happy.

Here’s what people get wrong about “the dream”:

They think the goal is to work less. To make money with minimal effort.

But the real goal is to have agency over your time.

It’s not about working 4 hours instead of 40. It’s about choosing work that fulfills you—even if it takes 50 hours a week.

It’s about having the freedom to say: “I’d rather make 80% of the money working 50% of the time on something I love, because I own that time.”

This is the shift I want to help you make in 2026.

You’re not looking for a “get rich quick” fantasy; you’re looking for a plan. We will build the strategic roadmap to discover your next path while fully protecting your current income.

That is why I’m launching The “Options Ladder” Mentorship.

This program is for 15 motivated senior-level Tech ICs or Executives who feel stuck, unappreciated, or unfulfilled in their 9-5, but aren’t ready to quit yet. You have the patience and motivation to build something meaningful.

This is direct, hands-on mentorship to play the “Double Game”:

• Maintain high performance at your current job.

• Simultaneously build your professional optionality with focus and intent.

In this program, we will:

• Discover The Fulfilling Path: Identify work you genuinely enjoy and are naturally good at, leading to a more fulfilling career direction.

• Create Your First Offer: Build your product/service and a roadmap to your first $10k — giving you immediate proof of concept and leverage.

• Master the Double Game: Strategically prioritize high-leverage work to free up time, grow your Personal Brand, and attract opportunities.

I transitioned from my job at Amazon to build a 300k+ following and my own business. I will show you exactly how I created those options.

If you are ready to dedicate 2026 to moving past the stagnation and building your Options Ladder, here is what to do to apply:

Reply to this email or email daliana@dalianaliu.com with your LinkedIn + why you want in (in 1-2 sentences, keep it simple, don’t overthink 😎 )

If you are a good fit, I will send you the full details, and we can determine if this mentorship is the right fit to define your next chapter.

To your optionality and fulfillment,

Daliana

Let me tell you what’s really happening in 2025:

There are no employees anymore. Only contractors. Let me explain why.

“Full-time” job just means the contract could last a bit longer. “Full-time” employees are just contractors working with one client at a time.

Most people don’t realize they’re already living in the Contractor Economy:

• Companies hire contractors from cheaper countries

• Layoffs hit even profitable tech companies

• The average person changes jobs every 2-3 years

• Re-orgs mean finding a new “contract” within your company every 18 months

• AI replaces roles that seemed secure two years ago

The Illusion of “Ownership”

Your company calls you an “employee” and gives you stock options to make you feel like an “owner.”

But 0.0001% equity in a trillion-dollar company doesn’t make you an owner - it makes you a contractor with performance-based compensation. You don’t feel your impact touches customers, nor does it impact the stock market.

You were always a contractor. They just gave you golden handcuffs and called it “equity.”

The Skills Gap That’s Costing You

Every successful contractor knows something you probably don’t: your technical skills are table stakes. What actually protects you are marketing, sales, and client management skills.

Like any successful independent contractor, you should be able to have a funnel and line up multiple clients. When you shift how you see yourself, you become the CEO of your own career, and you need to start adopting new skills.

The 3 Skills Every Contractor Needs in 2025

1. Personal Branding (Marketing) Can people find you when opportunities arise? In the Contractor Economy, your next client finds you through reputation, not resumes. My coaching client got his clients with < 2000 LinkedIn followers. It’s not about becoming an influencer, it’s about creating useful content for your clients, telling your stories, so they trust you.

2. Knowledge Packaging (Sales) Can you sell your expertise beyond hourly labor? The highest-paid contractors don’t just trade time for money. They package knowledge into consulting, courses, or products that scale beyond their hours.

Start small. Document what you’re learning. Share frameworks you’ve developed. Answer questions publicly. You’re building assets that create income streams beyond your primary contract.

3. Client Management (Relationships) Can you manage stakeholders like the clients they actually are? Your manager, stakeholders, cross-functional partners - they’re all clients. Treat them like it.

Manage expectations. Communicate proactively. Deliver value they understand. Send weekly updates before they ask. Translate technical wins into business impact. This is how contractors keep clients happy and renew contracts.

The Reality Check

I’m not saying this to scare you. The Contractor Economy isn’t coming - it’s already here. You can either panic about job security, or you can start playing by contractor rules.

In 2025, your security isn’t your job title. It’s your ability to:

1. Get another offer anytime you need one

2. Build income beyond the 9-5

3. Position yourself so opportunities find you

Stop thinking like an employee waiting for security. Start thinking like a contractor building optionality.

Introducing: The Contractor Economy Starter Kit

I’ve packaged everything I learned going from unknown Amazon data scientist to building multiple income streams — the exact strategies that got me featured in Business Insider, VentureBeat, and Amazon Science, while getting approached by Meta and OpenAI for full-time roles, tech startups for contracts, and senior leaders for coaching.

You get 3 courses:

📱 1. Personal Branding From 0 to 1 — My proven framework for building visibility as a tech expert so opportunities find you instead of you chasing applications.

💰 2. Knowledge Packaging System — How to turn your expertise into consulting, courses, or products that generate income beyond trading hours for dollars.

🤝 3. Client Management Masterclass — Stakeholder management tactics that get your work recognized, supported, and rewarded (the same strategies I used to fast-track promotions at Amazon).

For this upcoming Black Friday only, I created a special offer of the “Contractor Economy Starter Kit” for $195 — and you can apply it as a credit toward any of my 1-on-1 coaching programs. These modules are normally only available in my $1,500+ programs.

Join this week and get a BONUS: 1-on-1 Strategy Session with Me — a 30-minute private call to discuss your specific situation and create your personalized roadmap. This is something I wish someone could offer me 5 years ago to save me time and give me the tools and the confidence to build my optionality.

Want this special offer? Reply “Starter Kit” and I’ll send you the next steps.

Your current contract might end tomorrow. Are you building skills that last beyond it?

To your independence & power,

Daliana

His promotion had been denied for over a year. His manager kept giving vague feedback, with no specific examples of what needed improvement. No clear path forward.

I recommended that he set a deadline for himself: 6 months. If there’s no clear path forward by then, start looking. He followed through. Got an offer. And it completely changed the dynamic.

He told his manager he was ready to leave. The same manager who said he wasn’t ready for a year fast-tracked his promotion: “Please don’t leave. I’ll get you promoted.”

Suddenly, the “impossible” promotion materialized in 48 hours.

Should you threaten to quit to get promoted? Does this strategy help or hurt your career? After working at Amazon for 7 years and coaching dozens of senior ICs, let me tell you how this works.

Story time: when I asked for a raise, one of my managers at Amazon — who genuinely wanted to help me — told me there wasn’t much he could do within the salary range. But if I got a competing offer, that would give him another data point to advocate for me with HR.

This conversation doesn’t happen for everyone. My manager only told me this because we had a good relationship and he knew I didn’t actually want to leave the team.

But it revealed something about the corporate world:

People call this ‘boomeranging,’ and it happens at the highest level in big tech: engineers or PMs who couldn’t get promoted to Principal internally leave and join another company, then get hired back at the principal level a year later. Sometimes it’s easier to get hired into a high-level role than to be promoted internally. Same company, same work — but now they’re valuable because they left.

If you actually want to get promoted through good work:

First, evaluate whether your manager wants to help you grow. Do they give you specific, actionable feedback? Do they help you expand your scope? Do they tell you when promotion cycles open and actively work on your promotion documents?

In a healthy team, promotion isn’t just about the title. It’s about growing with your manager and team, creating more impact together. Your new title helps you become more influential when negotiating with stakeholders. It’s a win-win situation.

I don’t recommend threatening to leave as a negotiation tactic in a healthy team.

But if your manager isn’t taking action, if you’ve asked for clarity repeatedly and gotten nothing, then building external options becomes necessary.

Here’s the key: When you hand in your resignation, you can’t be bluffing.

Using an outside offer to pressure your manager into a promotion damages your relationship with them. So the moment you present that offer, you need to be genuinely ready to leave and take it.

This only works when you actually feel you have a better option. That’s when you have real power to negotiate, not when you’re pretending. The client I mentioned earlier accepted the offer instead of the promotion. He doesn’t trust his manager anymore.

To managers:

When you only act after someone has an offer, you’re teaching your team that loyalty doesn’t matter—leverage does. They’re watching. And taking notes.

If you’re in this situation right now:

If you are new to a role, it’s normal to take 1-2 years to get promoted. But if you have already performed at the next level for a while and the promotion conversation has been brought up multiple times, you shouldn’t just keep waiting.

*One exception is that you feel you are still learning a ton on this team, or your projects can add massive value to your resume, and it might be worth it to stay longer.

But you should still set a timeline to re-evaluate. Because here’s what it feels like when you stay in this “career limbo”: Your confidence erodes. You start questioning your abilities. You internalize that negative feedback that might not be true.

Instead of waiting endlessly for someone else to decide your career trajectory, set a deadline. Three months. Six months. Whatever feels right. Start interviewing even if you’re not sure you’ll leave. Reach out to connections to see if they are hiring.

Getting external validation isn’t just about leverage; it’s about remembering your actual value and reclaiming your sense of agency.

Look, you can’t control whether you get promoted. But you can control your timeline and take back your power.

In today’s economy, there is no job security. Options could mean you are good enough that you can get an offer anytime, it could mean you have your own network or a personal brand to attract recruiters or kick start a consulting business.

There are two ways I can help you:

1. I offer a one-time 1-1 call, I’ll diagnose your situation, provide my advice for your brand, and a few options for your next step.

2. Get instant access to my “Trustworthy personal branding for tech leaders” course.

Reply this email with 1 or 2, and I’ll send you the details.

You don’t need permission to build your career. You need options.

Talk to you next week,

Daliana

In 2015, I had my on-site interview with Amazon in Seattle. After the interview, I got a sandwich and sat on the exact stool in the photo below, looking out at the water and mountains, thinking: If I get this offer, I’m moving here.

I was living in LA. When I told people I was considering Seattle, almost everyone had something to say.

The weather is terrible. You’ll be miserable. Did you see that New York Times article about Amazon’s culture? People cry at their desks there.

I got the offer. I moved to Seattle anyway.

Yes, there were overcast days. But when it’s sunny? It’s the most beautiful city with amazing hiking trails.

There were stressful days at Amazon, but I had supportive managers across five different teams over seven years. I learned a lot from working with talented people and met friends I still talk to today.

Everyone said I’d move back to sunny LA within a year. I stayed for four.

I built my career here. I started my first blog here. When I eventually moved away, it wasn’t because I regretted coming — it was because I’d gotten everything I came for.

Here’s what I learned — not just about cities, but also about life choices:

There is never a perfect company, role, or city. Every choice has trade-offs.

I didn’t hike much before Seattle. After moving, I went every other weekend. I took advantage of what the city offered instead of mourning what it didn’t have. I didn’t know what to do in the cold winter, so I took salsa dance classes. Now, I’m a decent salsa dancer, and I can go salsa dancing and meet new friends whenever I’m in a new city.

You can focus on what you’re losing or extract value from what you’re gaining. You just need to understand what the opportunity offers and take advantage of it.

If you want to go on an adventure like moving to a new city or taking a new role -- don’t let other people’s filters become your reality. Everyone’s shaped by their own fears and preferences. That’s very different from yours.

I never regretted anything I tried.

Talk soon, Daliana

P.S. It’s a beautiful sunny day, and I’m writing to you at Storyville, my favorite coffee shop by Pike Place Market.

What is something you did when people told you not to? Reply and I’ll read it!

My mentee recently shared that she received great feedback from her manager — someone who is too busy to provide sufficient context or answer her questions.

She was left with a lot of ambiguity, but the challenge is an opportunity for her to demonstrate her value. She turned ambiguity into clarity.

How? Because she started treating her manager like a toddler, and that's how everything changed.

Think about it: A toddler gets distracted by every shiny object, has the attention span of a goldfish, and melts down when overwhelmed. Sound familiar?

Now, here is how to treat your toddler manager right:

1.Always Give Context (Because Their Brain Is Mush)

A child has limited attention and memory — so does your manager! When you email or meet with them, ALWAYS remind them where things were left last time and why you need to work on this.

"Hey Sarah, following up on our discussion about the churn model from last Tuesday. You mentioned wanting to see the impact on Q4 revenue projections..."

Don't assume they remember your previous conversation. They've had 47 meetings since then and their brain is basically scrambled eggs at this point.

2. Don't Ask Open Questions (They'll Choose Ice Cream for Dinner Every Time)

You don't ask a child "What do you want for dinner?" They'll demand ice cream or stare blankly and say "I don't know." Then when you finally give them something, they'll take one bite and decide they don't want it anymore. Cue the tantrum.

Your manager does the exact same thing! Ask "What should I prioritize?" and you'll get vague responses or complete silence. Then they'll change their mind next week and act like it was your idea.

Instead, offer structured choices: "I researched based on XYZ evidence. Here are 2 options with pros and cons." Even if they reject both, now you know what they don't want—and you've helped their overwhelmed brain think through what they actually do want.

3. Spoon-Feed Everything (Make It Baby-Food Soft)

Don't give a toddler food that's hard to chew — they'll spit it out and have an epic meltdown. Your manager will do the same with dense, complicated emails, except their meltdown looks like "Can we schedule a meeting to discuss this?"

Nobody wants that meeting.

Pre-digest information for them like you're making baby food:

• Bold key dates and deliverables (make it pop!)

• Use bullet points, not paragraph walls of doom

• Add red arrows to screenshots (they literally don't know where to look)

• Include charts directly in emails — never assume they'll click attachments

As a content creator, I knew email click rates are usually under 50%. Any extra step creates friction. Important chart? Screenshot that baby right into the email body!

The 3-3-1 Rule (Their Busy Brain Can't Handle More)

Just like a toddler can't remember a 10-step bedtime routine without losing their minds:

• Maximum 3 key points (they won't remember more, trust me)

• Maximum 3 questions (they won't answer them all anyway)

• 1 clear "so what" and next step per email

The Bottom Line (You're Now a Professional Manager Whisperer)

Your manager isn't trying to be difficult — they're overwhelmed and operating in pure survival mode.

Some managers say "help me help you"—make their job easy so they can unblock you and champion your work.

The data scientists who get promoted aren't necessarily the smartest coders or ML modelers. They're the ones who make their manager's life easier by communicating like seasoned parents who've mastered the art of toddler management.

Stop expecting your boss to be a mind reader. Start being their patient, strategic, slightly amused caregiver.

Are you tired of feeling like your great technical work goes unnoticed because you can't communicate effectively with leadership?

My mentee didn't just learn these "toddler management" skills overnight. We worked together on exactly these communication frameworks in my DS/ML Career Accelerator program. She now has templates for stakeholder updates, knows how to translate technical wins into business impact, and has mastered the art of managing up.

💫 I have spots for 5 data scientists who are committed to mastering stakeholder communication. If you're ready to get the recognition (and promotions) your work deserves, reply “toddler” (or email daliana@dalianaliu.com) and I’ll share the details with you.

Until next time,

Daliana

I recently coached a data scientist at Uber who improved her ML model's precision and recall by ~ 10%. Solid technical work, right?

But when she presented to business stakeholders, they barely reacted.

Business leaders care more about what this means for them:

• What does this mean for churn rate?

• How does this translate to revenue?

• What's the actual business impact?

In my career accelerator program, I shared a template for translating technical improvements into business language. She used it in stakeholder presentations, and they were more engaged than before.

It works. However, this only solved 50% of her problem.

She told me, "I tried setting up meetings with stakeholders to get more alignment, but they are so busy. They skip my meetings. I'm having trouble getting their feedback. I feel invisible."

Then I shared this story with her:

At Amazon, I had a coworker who sent weekly product updates every Friday. Simple, consistent communication about progress, blockers, wins, and customer feedback.

In a team meeting, our director mentioned it was his "favorite email to read on Fridays."

Here's why this worked:

You might not always get 30 mins from your director’s calendar, but you can always send an update. No one likes to read another email, but this one is short and structured, saving the director’s time. His project received more visibility and support than teams relying solely on scheduled meetings.

My client took this idea and started sending weekly updates to her stakeholders. The results were immediate: stakeholders became more engaged, and she gained significantly more visibility with leadership.

She "trained" her stakeholders to expect regular updates, and they began to see her work as important and strategic rather than just another technical project.

When stakeholders have to chase you for updates, you've already lost trust.

But when you proactively communicate progress using language they understand, you position yourself as a “trusted advisor” who thinks strategically about business impact, not just technical execution.

Why this matters more than perfect code

Your productivity isn't just about technical execution. Maybe 50% of your time is coding, but the other 50% is getting buy-in, securing resources, and ensuring your work doesn't get derailed.

The most productive data scientists aren't the ones writing the most code. They're the ones who:

• Give context regularly

• Send mid-process updates

• Show "ugly" work early to get feedback

• Keep stakeholders informed about progress and blockers

That "invisible" work - communication, relationship-building, stakeholder management - often determines whether your technical work actually makes an impact.

You can write perfect code, but if you don't communicate progress effectively, your project can still get pushed aside.

The visibility advantage

The data scientists who advance fastest aren't necessarily the most technically skilled - they're the ones who translate technical excellence into business language and build relationships with key stakeholders.

Having great code won't be enough if people don't understand its value.

Ready to turn your technical expertise into the career visibility you deserve? I'm opening my Strategic Visibility program for 10 data scientists and AI/ML professionals who want to position themselves for senior roles, and become the go-to experts in their organization and in the industry.

Over 6 weeks, we'll build the exact communication and positioning skills that turn technical excellence into influence and authority.

Apply Here

If you qualify, I’ll schedule a 30-minute 1-on-1 consultation call with you to see if you are a good fit.

Your technical skills are brilliant. Now let's make sure people know it.

Daliana

I wrapped up the "Visibility Playbook" last week, and one of my coaching clients shared an interesting story with me.

Someone called him a fraud for posting on LinkedIn.

I can’t wait to share what happened with you — and why his response might change how you think about online criticism.

Alright, so he is a tech executive who shared how AI has transformed his coding approach. Pretty common stuff these days, right? While most people supported him, some tech leaders called him a fraud. They claimed AI is just a fad and that he was misleading people.

So, I asked him: "How do you feel about this?"

His answer completely surprised me.

"I actually see these comments as high-quality engagement. Strong resistance is just as powerful as strong agreement - because I made them FEEL something. I challenged their status quo."

This hit hard. In my coaching program, I teach people how to write technical content online that makes readers feel something - curiosity, recognition, even mild disagreement. But watching my client apply this mindset to actual criticism? That was next-level thinking.

He didn't see haters. He saw people having a strong emotional reaction to his ideas.

Here's what's really happening behind those angry comments:

A lot of people are resisting the changes AI brings to our industry. And what's driving that resistance? Fear. Insecurity. Worry that their expertise might become obsolete.

When someone calls you a "fraud" for embracing AI tools, they're not really attacking you. They're defending their own identity and career investment.

Or they simply don't like change.

Instead of arguing with the critics in the comments, my client did something brilliant. He DMed them privately, suggested coffee chats, and asked if they were open to hearing his perspective.

This is real leadership - welcoming people who disagree with you into the conversation. Instead of seeing them as haters, he tried to help them and connect with them.

This is what happens when you share your genuine opinions online: you venture into unknown territory first. And that unknown is going to scare some people.

They might disagree with you. They might even attack you.

But that's exactly the point —

Building your presence online isn't about going viral or getting everyone to love you. It's about having real impact on the people who need to hear your message.

When you share your genuine perspective - especially about controversial topics like AI in tech - you're essentially saying, "I'm willing to go first into uncertain territory."

That act of courage gives others permission to do the same. Some people will follow your lead. Others will challenge you. Both reactions mean you've moved the conversation forward.

When I went from being a quiet senior data scientist at Amazon to having 300,000 followers on LinkedIn, I faced criticism, too. But here's what happened over time: I got invited to speak at conferences, companies try to hire me for unique roles tailored to my skill sets, and education platforms invite me to create courses.

The opportunities are unlimited when you stop hiding your expertise and start sharing your perspective boldly.

This client also transitioned from being scared to post online to creating blogs, building websites, and engaging executives with his content. He's on track to launch his own product soon.

All because he reframed criticism as opportunities for engagement and connection.

Now, if you're tired of being invisible at work while watching louder voices get all the opportunities, it's time to stop hiding your expertise.

The AI era rewards individuals who can clearly communicate their value and build genuine relationships — not just those who can write the most effective algorithms.

Ready to find your voice and create your competitive edge? I'm looking for 12 people to join my next DS/ML Career Accelerator, where we work on communication skills, personal branding, and designing your competitive edge.

I’ll share more details with those who qualify. Apply in the survey below if you want to get in early ( < 2 mins):

Start Survey

Your expertise deserves to be seen,

Daliana

P.S. I'm moving some of my content to Substack, and that’s why you are reading this newsletter in this format. Leave a comment or reply to me directly!

Happy Friday! After 7 years at Amazon and countless hard-learned lessons, I finally cracked the code of what truly separates great data scientists from the rest. Today, I'm sharing the principles I wish someone had taught me before I made all those mistakes on my journey to becoming a senior data scientist.

1. Technical Excellence Is Just The “Entry Fee”

❌ Myth: Senior DS = More Complex Models

✅ Reality: The real complexity lies in solving ambiguous business problems and building systems that scale. Many senior projects focus on improving data pipelines or ML iteration systems - not researching cutting-edge algorithms.

2. Your Job Isn't Building Models - It's Being a Trusted Advisor

❌ Myth: Stakeholders know exactly what they want

✅ Reality: It's our job to ask the right questions, show different solutions, and guide them in the right direction. The most impactful work often doesn't even look like 'data science.'

3. Speed Without Strategy Is a Career Killer

❌ Myth: Urgent requests need immediate action

✅ Reality: Lost trust is harder to fix than any bug. If they've waited 3 hours, they can wait 30 more minutes for accuracy. Counter-intuitively, the more 'urgent' the request, the MORE questions you should ask.

4. Simple Solutions > Complex Models

❌ Myth: Advanced algorithms = Better solutions

✅ Reality: Being highly technical doesn't give you the privilege to look down on simple solutions. If an Excel IF-THEN statement solves the problem, that's perfect. Stakeholders don't care about LLMs vs. rule-based algorithms - they care about results.

5. Translate Technical Jargon Into Business Impact In Plain English.

When talking to non-tech stakeholders:

❌ Don't say: "The model has 85% accuracy in predicting churn."

✅ Say: "We could save $1.2M annually by preventing 850 customers from leaving."

6. Help Your Stakeholders Become Heroes to Their Bosses

❌ Myth: Great analysis sells itself

✅ Reality: Package your work so well that your stakeholders can't wait to present it to their bosses. Create presentation-ready slides, craft compelling narratives, and tie everything to their KPIs. Your stakeholders should be able to walk into any meeting and confidently champion your work without needing to translate a single insight.

7. Success Is Measured in Adoption, Not Accuracy

❌ Myth: High model accuracy = Project success

✅ Reality: If stakeholders don't trust you or understand your solution, even a 99% accurate model will fail. It’s also important to make it easy for the stakeholders to adopt your solutions with their tech stack. The best model isn't the most accurate one—it's the one that gets implemented.

🎯 Ready to put these principles into action?

I'm opening my complete Senior Data Scientist Playbook, where I share the exact frameworks and communication strategies that helped me and other data scientists transform from 'technical experts' to 'trusted business advisors'.

You'll learn how to:

• Master stakeholder management and effective communication

• Lead high-impact data science & ML projects with confidence

• Position yourself for senior-level promotions

⏰ Only 11 spots left. Join the waitlist: https://dalianaliu.kit.com/dscareer

What do you think about these principles? Reply with your thoughts or any questions about the course.

See you next time,

Daliana

The LinkedIn update was immediate, and the congratulations poured in, but as the initial excitement faded, a familiar voice haunted me: "Now what?" The idea of another promotion cycle suddenly felt exhausting, as I’ve done this twice.

No one told me I had to know the answer right away, but I was so used to eyeing something new immediately after reaching a goal — the perfect recipe for burnout. Today, I’ll talk about 3 roles in Amazon I explored during my final year. I’ll share my entire thought process and explain why I eventually quit Amazon.

This takes about 15min to read. Have your cup of coffee ready ☕️.

While the path to the senior data scientist is more straightforward, the path beyond the senior level is less defined. If you want to stay in data science, you typically face two options:

1. the IC (individual contributor) route to the Principal Data Scientist

2. the leadership track to management.

While pondering what was better for me on a Friday afternoon, I chatted with a coworker about weekend plans. He said he was excited about reading a new research paper on Saturday. His eyes literally lit up when he talked about the paper. Me? I'm itching to finish the Disney CEO (Bob Iger) biography, and I'm more fascinated by business negotiation stories than cutting-edge ML algorithms.

This small conversation made me realize how different I am from a passionate data science researcher. Although I could probably work hard and grow to the principal level, it’s not where my superpower lies.

This moment really hit me.

It’s the first domino in a series of realizations that will reshape my entire career trajectory. I want to find my niche, a path that feels like play. To find this ideal path, I spend a lot of time thinking, "What's something hard for others but easy for me to do?"

My New Career Criteria

I still enjoyed data science, but after seven years, I craved something that involved more strategic thinking, relationship-building, and less hands-on work. It was also the year I grew to 100k followers on LinkedIn and started my podcast. I often felt like I was juggling two jobs and couldn’t keep up with my never-finished to-do lists.

The team where I got my promotion was perfect for rapid career growth. Being customer-facing, we had to constantly deliver machine learning solutions within 3-6 month cycles. This environment provided many opportunities to practice various algorithms across different industries. However, the short project cycles also made it the most stressful team I'd ever been part of. After two years, I could not maintain that intensity. But I still want to stay at Amazon because I have already built my network here, and exploring other roles is easy.

It doesn’t matter what path I choose; the first decision was clear — I need a different team within Amazon. So, I came up with three criteria to help me find this ideal role:

1. No tight deadlines and a more flexible schedule

   1. Allow me to have energy working on content creation after work

2. More leadership, strategic thinking, and less hands-on data science work

3. It values both my technical skills and my communication skills.

   1. Ideally, this can create a win-win situation for my day job at Amazon and my side hustle.

With these, I started a journey through three different roles, each teaching me a unique lesson. Buckle up, because this ride through the corporate jungle is about to get interesting 🎢

My first stop:

Data Science Manager

Looking back at that Friday chat, I pretty much crossed off the principal data scientist path right away. Management seemed like the obvious way to go.

· The Hope

I thought being a manager would be awesome - handing off work, cooking up big-picture strategies, and mentoring people. You know, all the stuff I love. So, I hit up a manager friend at Amazon and spilled my wishlist. He was like, "Hey, I know just the team for you!" Next thing I know, I'm interviewing for a gig in the Shipping org.

The whole process was quick, and I clicked with the manager. He is a product management guy who gets data science and ML. Plus, he wanted me to own some high-impact projects. Besides, he was totally cool with me keeping my podcast going. He said, "Work on your own time, no worries."

So, after two awesome years, I had to say goodbye to my old team. It was bittersweet, but I was ready for a new adventure. Next thing I knew, I was diving into this supply chain management team, ready to build a kick-ass data science team from scratch.

Some context about Amazon’s manager development process: you don’t grow to be a manager right away. First, you need to act as a tech lead manager, managing a team while still doing some hands-on work. So, my manager wanted me to do 30% to 50% hands-on work and gave me one direct report to start.

It sounded perfect: less hands-on work, more flexible time, the opportunity to shape a team's strategy, and a new domain to learn and grow into. What could go wrong?

· The Challenges

1. The Mental Juggling Act

From day one, I was thrown into the deep end — stakeholder meetings, planning roadmaps, and reviewing docs left and right. Talk about a reality check! I realized pretty quickly that I'd totally underestimated what management was all about. The stress didn't go away; it just changed its outfit. I now grappled with ambiguity, team goals, and my direct report's success.

The flexible schedule I dreamed of was a mixed bag. Sure, I could step away to record a podcast, but my brain was always on duty. Back when I was just responsible for myself, I could silence Slack for hours for focused work; as a people manager, I needed to be on standby, especially to help out my new direct report when he got stuck.

2. The Administrative Burden

I dreaded writing review documents for my direct report - a common struggle for many managers. It's like trying to write a Yelp review for your best friend's cooking - you want to be honest, but you also don't want to hurt their feelings. And that's just the tip of the iceberg. Throw in salary talks, legal mumbo-jumbo, and immigration paperwork, and suddenly, I'm drowning in a sea of admin tasks.

3. Domain Knowledge and Passion Mismatch

Here's the kicker: even in data science, different domains are like different planets. Supply chain management is all about optimization algorithms, which I'd never touched before. I was basically learning a new language and rocket science at the same time.

The real gut punch is that I just couldn't get fired up about our business problems. In my previous roles, I was that nerd working on projects over weekends. Now, watching all-hands meetings from my couch, I felt numb to our business goals.

· The Silver Lining

Don't get me wrong, it wasn't all doom and gloom. Mentoring my direct report was definitely the highlight. I got a real kick out of helping him map out projects, nail milestones, and push his boundaries.

I found real satisfaction in watching him grow.

· The Decision

However, while I enjoyed mentoring people, it was not enough to sustain me in the full scope of a managerial role. It was a bittersweet reminder that sometimes we can excel in certain aspects of a role without it being the right fit.

I shared my delemma with my manager, explaining although I enjoyed working with him, my direct report, and my peers, that I couldn't balance my creative drive with the demands of the role. To my surprise, he suggested I create content within the team to scratch my creative itch. While I appreciated his effort, I knew the team needed someone fully dedicated to supply chain optimization - someone who could get excited about the nitty-gritty details. That someone, I realized, wasn't me.

The decision to leave after just three months was agonizing. My manager even offered a raise, but I knew it wouldn't fix the fundamental mismatch.

· The Lessons

As I started to look for other roles within Amazon, I reflected on what I'd learned.

1. Managing isn't just about developing people; it's about developing strategies you believe in—and being willing to live with the constant mental juggling act.

2. Passion for the business is crucial for effective management, at least for me. Without genuine excitement for the problem space, it's challenging to sustain the energy required for leadership.

3. Delegation of work and flexibility of schedule don’t translate into reduced stress. Writing documents, attending meetings, and developing strategies require significant mental effort. Ultimately, you own the team's goals and outcomes.

I could not have learned these lessons by reading about others' experiences; I had to step into the role to truly experience them for myself. So, I don't regret trying it.

Months after I left the team, I received an appreciation note from my former direct report sharing the news of his promotion. That moment of pride and happiness confirmed that while I decided not to grow into a data science manager, I had made a positive impact during my brief tenure. It also reinforced my passion for coaching and mentoring, a skill I would continue to develop and eventually turn into a career.

After realizing that neither data science management nor the principal IC path was for me, I looked beyond traditional data science roles.

Enter my second try…

The Developer Advocate

Inspired by data science content creators who became developer advocates or tech evangelists, I explored this hybrid role that blends technical expertise, public speaking, and product marketing.

· The Hope

I reached out to the Developer Relations team at AWS. The team publishes O'Reilly books, creates tech tutorials and even Coursera courses, and speaks to thousands of people. "Finally, a role where my content creation skills and technical knowledge can merge!" I thought.

· The Challenges

This time, I decided to do my homework. I mean, this role was pretty different from my usual data science stuff. So, I started chatting with folks who'd been there, done that. Wow, I was surprised. My first convo was with this senior developer advocate at Amazon who was about to jump ship back to engineering. Talk about timing! He spilled the tea, and after chatting with a few more people, I started to see a pattern. Turns out, this dream job had four big hurdles that nobody was really talking about.

1. Career growth bottleneck

The hybrid nature of the role, juggling between tech and marketing, make it difficult to grow in a company. Reporting to the marketing team often leads to a decline in technical sharpness. For those who joined out of love for tech and sharing knowledge, the heavy marketing focus can feel unfulfilling. Unless you're aiming for a marketing leadership role, advancing to a tech VP or principal engineer position becomes increasingly difficult.

2. Difficulty in measuring impact

Success metrics in this role are often not well-defined. Some teams focus on event attendance or social media views and end up pitting team members against each other as they compete for audience attention.

Compounding this issue, leadership often struggles to define success: Is it measured by session attendance, social media engagement, or revenue impact? The long-term nature of top-line marketing's value often clashes with companies' desire for immediate ROIs, creating a lot of stress and confusion for the team.

3. Burnout

The role demands a diverse skill set: creating tutorials, giving talks, and providing product feedback. Sometimes, you have to travel to conferences. With frequent leadership turnover and shifting goals, the workload seems endless. Almost everyone I spoke to mentioned feeling burnt out.

4. Conflict of interest

As a content creator with my own platforms, I was concerned about potential limitations on my personal expression. Some developer advocates shared that their companies restricted them from discussing competitors' products on their personal social media, highlighting the blurred lines between professional and personal brand in this role.

· The Lessons

Content creation for yourself is art; for a company, it's commerce. Representing a company's products and driving revenue requires a completely different skillset than personal expression.

Realizing it might not be as glamorous as it seems, I decided not to transition into this role. But I still learned 3 valuable lessons:

1. Your passion project isn't always your ideal profession. Just because you excel at something doesn't guarantee it'll be a fulfilling full-time job. A large social media following doesn't equate to enjoying social media as a career.

2. Your daily tasks matter, but your success metrics rule. Understanding how your performance is evaluated is as crucial as knowing your day-to-day responsibilities.

3. Don't fall in love with a job description; fall in love with the reality! Meet the team, talk to your network, and don't let the allure of a trendy title cloud your judgment.

Subscribe now

Here comes my final stop at Amazon:

Machine Learning Instructor

· The Hope

As my connection to business goals waned, I turned my attention to a role in the AWS training team. The ML instructors give full-day training sessions to AWS partners, with no hands-on work and a structured 9-to-5 schedule, which seemed like the perfect solution. I'd always enjoyed teaching data science and machine learning, often playing the teacher role in my previous positions. Although this role offered less leadership and strategic thinking, it promised the work-life balance I craved.

I thought, "This is it - a chance to share my knowledge, use my communication skills, and finally turn off my brain after work."

Third time's the charm, right? The interview process involved a technical presentation using storytelling techniques. I prepared for a week using one of my previous ML project and nailed that interview. I knew I could do it.

· The Challenges

1. Creative Constraints

This reality hit hard once I started. The course material was fixed, leaving little room for creativity. While I could add personal anecdotes, the bulk of the content was predetermined. The course creation team is a separate team, they take our feedbacks, but there is a length process. I couldn’t use my creativity to change the structure or topic.

2. Repetitive Nature

Basically, I totally underestimated how much the repetition would get to me. Picture this: you're teaching the same 3-day course over and over. It could get old real fast.

Even in my current "data science career accelerator," I've learned to pre-record the fundamentals and focus on the fun part - interactive coaching. But in this gig? Even though we had some Q&A time with students, most of the job was just repeating the same slides, day in and day out. I’m sure I could keep improving my delivery skills, but it’s too static for me.

· The Decision

I grappled with the guilt of a quitter, again. But I had to trust my instincts. I knew I wouldn't be truly happy in this role, even if I could perform it adequately.

I feel a bit ashamed that when I was joining this team, deep down I hoped for a role that I could “coast”, I could do the bare minimal, but I realized I wouldn’t respect myself if I did that — either do it well or don’t do it.

· The Lessons

• Creativity isn't a luxury, it's a necessity for me.

I severely underestimated my need for creative freedom at work. A role without room for innovation, no matter how comfortable, quickly becomes stifling.

• I’m not built for 'coasting'

I thought I could find a role where I could "coast" and then focus on my passions after hours. But I'm not a robot - I can't just switch off my brain at 5 PM. If I'm not passionate about my 9-to-5, I waste my time and energy.

I get it, not everyone can work on what they truly enjoy. Sometimes, in the early stages of a career, you need to do things you don't always enjoy to learn. But after 7 years at Amazon and building a social media following, I realized I had options. I want to dream bigger. It was time to leverage my experience and platform to craft a path that aligns with my passions.

What finally made me decide to leave Amazon…

This experience made me realize that my journey at Amazon had come to an end. After seven years, leaving felt like losing a piece of my identity—as ridiculous as that sounds—but I knew it was necessary.

Throughout this wild ride, a recurring theme emerged: my struggle to balance my growing side projects—my podcast and LinkedIn following—with my full-time role. Each career move was an attempt to find a job that would complement, not compete with, my personal brand and creative pursuits.

I started to ask my network to help me find such a role, and I met the founder of an ML startup. He crafted a position tailored to my skills: a blend of senior data scientist, open-source developer advocate, and tech content creator.

This opportunity proved that sometimes the ideal role isn't found; it's created.

Although my time in this new role lasted only a year, it was exactly what I needed at that point in my career. I’ll write about this experience in the future.

Final Thoughts

This journey taught me valuable lessons about balancing passion, integrity, and professional growth:

1. The career compass should be your superpower, not other people's expectations.

After I got promoted to senior data scientist, I was wondering if the typical data science career path still fits me. So, I asked myself, "What's something hard for others but easy for me to do?" This question prompted a wild year of career soul-searching within Amazon.

It wasn't easy to know the answer, but it’s the only way to 10X your career growth when the game is in your favor.

2. Quitting isn't failing, it's recalibrating.

I explored 3 different teams before I finally quit Amazon. I felt like a quitter. But I learned that quick job changes aren't signs of failure, but of self-awareness and courage. "It's better to be a quitter than a bitter." Always give your 100%, but be honest when it's not the right fit.

3. Don't fall in love with a job description; fall in love with the reality.

Meet the team, talk to your network, and don't let the allure of a trendy title cloud your judgment.

Understand not just your daily tasks, but how your success is measured in the team. If you find the success metric too stressful, you won't enjoy the day-to-day even if it's your "dream job".

4. “Coasting” is unrealistic.

I thought life would be easier if I could just find a team to coast. Doing the bare minimum might seem tempting, but it erodes self-trust and long-term confidence. If you feel like coasting, maybe it’s a sign of burnout, or you need a new job.

5. Don't climb the ladder. Build your own.

Don’t be afraid to tell people what you truly desire in a role. Maybe someone is looking for the exact combo of skillsets you have. It's not rare when a manager crafts a unique role to attract talent.

To be clear, I still believe it's important to know how promotion works and to get the recognition you deserve. But at the end of the day, you should be the architect of your own career. That’s why I cover both aspects in my coaching course.

These lessons aren't just my story—they're a roadmap for anyone feeling stuck, undervalued, or uncertain in their tech career.

Phew! What a ride, right? If my story resonated with you, or if you're feeling stuck in your own career, I've got something that might be useful for you:

I'm running my "Data Science Career Accelerator" again, which will give you more specific guidance on how to get stakeholders' buy-in, create more impact, and get the promotion you deserve so you can become the senior data scientist every manager wants.

Space is limited. Enroll now and get a 15% early bird discount: https://maven.com/dalianaliu/ds-career?promoCode=dscareer15

Does this journey resonate with you? I'd love to hear your thoughts in the comments.

I recently talked to my friend Jason, who did research at Uber AI Labs, and later, he cofounded a startup doing ML for wind farms. Here is my friend's take on ML in the academia vs in the industry:

As an ML researcher, your products are paper. Essentially, you're selling an idea, you're selling a story, you're selling a narrative. You hope it sticks in the market when people understand it. You want other researchers to adopt it, and it changes their research trajectory. And you get an exchange -- citations. The metric is popularity.

In the industry, the more product-based world you're selling products, and your products have to work. They have to bring value to someone, to some customer. The metric is revenue, not popularity. There are many successful companies out there that you've never heard of because popularity doesn't matter to them! They make some widgets and they sell them by the millions. They make tons of money and nobody knows about it. It's a different world.

Researchers sell ideas and papers, while ML practitioners in the industry sell products.

It's not that one track is better than the other; it depends on what you want in the current stage of your career. If you are interested in research and want to do a PhD, my friend also shared his experience as a PhD at Cornell University.

He spent six years getting his PhD and it's full of learning. However, only 25% of that learning has to do with the topic that you're working on. Besides the technical skills, you learn how to communicate, how to write, how to speak. But more importantly, you learn how to look at the world to figure out two things:

1. What questions could you ask that are interesting?

2. What strategies do you use to answer them well and answer them convincingly?

Some people learn and some people don't. It is to learn to see research results completely disconnected from your own ego. Maybe it's helpful to discuss the difference between science and engineering.

In engineering in the real world, the question you're mostly asking is, can we build something that works as well? And then you answer it by building something that works that well. And if you don't, then you feel like you've failed; you tried to build it and your latency is not good enough, or the memory is too much, or there are so many bugs in the system.

As a scientist, you try to ask questions, answer questions, and then you try to disconnect your ego from the answer so that you try to answer the question. Whatever the data is, you look at it and you say, "Oh, that's interesting; this works; this doesn't work."

Some people still connect the ego to the answer when they really want their research to work, and they're not as effective as scientists. They don't have the ability to look at the data and see the results as it is, and they might get frustrated when something doesn't work the way they want it to work.

Scientists want to learn; engineers want things to work.

Today, many PhDs have also become founders to build things, especially in the Gen AI area. There are companies acquiring researchers from labs of universities to get access to talent and tech. I don't think a lot of PhDs today still stay in academia, and there are a lot of investors trying to network with researchers in labs and the journey from a researcher to a builder is getting easier and easier.

One thing a lot of researchers are learning when building companies is to focus on how to make things work, even if the methodology is boring.

What's your experience with academia and the industry? Reply and let me know what you think! (Don't forget to register the LLMs for inventory and review data here!)

I'm going to publish my episode with Jason this week to talk more about his experience at Uber AI Labs and ML for wind farms. Subscribe on Apple, Spotify, or YouTube if you don't want to miss it.

Until next time,

Daliana

(I'll write more about different ML/DS roles, and emerging AI careers, stay tuned!)

I just got back from my trip! I got access to ChatGPT Plus, and I'm going to play with the generative models. If you want to learn more about OpenAI and voice cloning, here is a free webinar tomorrow (Oct 13th) on "How to Build Generative Voice Clone Applications with OpenAI." Register here (you'll get the video even if you can't show up as long as you register).

Today, let's talk about the pros and cons of working in internal product teams versus external product teams as a data scientist. I have worked in five different teams while I was at Amazon. Let's dive into the differences here so you don't pick the wrong team for your career!

Internal product team:

If you work for a large tech company, there are teams that build tools to support other teams. For example, I was on a team that builds and maintains the A/B testing platforms in Amazon, and my customers are other data scientists and engineers. I know many companies have internal machine learning systems, and there might be a big team of data scientists and engineers working on this system.

Although employees use this platform to test features for Amazon's external customers, we don't interact with them directly. The success of this type of internal team is also evaluated differently compared to teams serving external customers. Let's first talk about the pros and cons of working in an internal-facing team as a data scientist.

Pros:

1. Usually lowers stress. You are working on projects for internal customers, and they are your colleagues, so if you need to change things or move a deadline, as long as it doesn't directly affect any external launch dates, people can usually work with you.

2. Your customers are more collaborative. Even if you are building a tool for your customer because you work for the same company, and sometimes the two teams share resources, they might even lend you a few data scientists and engineers if they want to deliver things faster.

3. Easy to expand your network across the company. If there are multiple teams using your team's product, you'll get to work with data scientists, engineers, and PMs to understand their business use cases. You probably need to host training sessions or office hours to educate your customers and help them succeed. Sometimes, their recommendations for your promotion weigh more than those of colleagues from your own team -- because it shows that your customers recognize your work. They are also more open to giving direct feedback.

4. More opportunities for long-term research projects. Internal teams usually have more resources to research new tools and methods. If you are okay with experimental projects that might fail and want to try state-of-the-art ideas, internal teams usually allow you to take more risks.

Overall, it's easy to discuss timelines and work through bugs when you work in an internal team.

Cons:

It might be hard to measure impact. Although internal products are essential for other data scientists' productivity, they are considered "supporting products," and they don't always translate directly into business impact. It's not uncommon to measure the success of an internal tool just by how many teams adopted it. Of course, it's nice to have anecdotes of how a team uses this tool and increased X% revenue, but the impact might not be attributed easily.

Sometimes, X team that owns the central products builds things based on their goals before talking to potential customers. In order to meet their goals, and they need to "sell" the tool to A, B, C teams to use their product, and sometimes this product is just not what they need. No matter how good this product is and how advanced the models they used, if it doesn't solve a real problem, it's hard to generate impact. This problem exists because some organizations create goals without taking customer feedback. The researchers on the internal team sometimes have to publish more papers or write more blog posts to compensate for the lack of real impact.

If you want to join an internal team, make sure you understand who uses their product and whether they established a good "customer feedback intake process".

External product team:

Most data scientists work in external product teams. For example, if you work at Apple, your team focuses on the forecast of Apple Watch's supply chain, or your team tries to improve the engagement of Apple News. Your work directly impacts your company's external products.

Pros:

1. If you are lucky, your career might be linked to the launch of a "superstar" product. Especially when this product grows really fast, your work might directly contribute to, say, the launch of X product in the Asian market. Even if you are working on a small feature in Google, you can impact millions of people at least. It's good for your resume, and it's very fulfilling.

2. While working in an internal product team builds your breadth, working in an external product team builds your depth in the business. You really need to understand the production, marketing, and sales of a product you work on, and after a few years, you could gain a lot of domain expertise for this product. Because as a data scientist, you work with data from different sources and present it to different stakeholders working on this product. Maybe there will be competitors of your company trying to hire you because of your in-depth experience in this niche.

Cons:

1. It doesn't matter how good your data science work is, if the product sucks, you won't get much recognition for your work. If it's an area that you feel passionate about, you should still join the team to learn and explore your curiosity. Make sure you document your analysis and models to showcase your value, and make sure you have a story to tell recruiters even if the product didn't work out well.

2. Your team might focus on the business, and you might need to wear different hats - PMs, data engineers, or whatever gets the job done. As a data scientist, you might feel frustrated for not being able to work on research projects, but if you focus on the business impact, this could be a great learning experience for you to grow as a tech lead.

Besides internal product teams and external product teams, there is another type of team that could exist in large tech companies: external service teams.

External service teams:

Examples: cloud providers like AWS, Google, and Azure all have their external facing service teams. I used to work on such a team while at AWS. We are basically data science and ML consultants helping external customers use our products. We are not working on a specific product but to help customers use our products to achieve their goals. In some companies, those roles are called "solution architects", "solution engineers", or "sales engineers".

Pros:

1. You gain knowledge quickly across different industries. Because your customers might come from industries you have never worked on, and you must deliver results quickly, it pushes you to learn about those sectors quickly. Because it's hard to earn back external customers' trust if you lose it, your work is held to a higher standard. It's a huge plus for your future career when you can showcase your previous achievements in different industries. You learn more about what you like and what you don't like through this journey, and it might help you find an industry you really like, and you can build your career on top of it.

2. You learn more about communication and leadership. How do you handle customer requests that are impossible? How do you push back on deadlines? How to make your customers feel comfortable to adopt your solution? It's an art to communicate your standards while making your customers feel comfortable. It's more delicate than talking to your internal customers.

3. Some of your work might be featured in a customer's joint blog post or media coverage with your company. Generally, you can't talk too much about your work, but for those types of projects, you might be able to add a public blog post or paper to your profile. This is not guaranteed, but companies usually try to ask for a reference after the completion of a project if the company is open to it.

Cons:

1. It can be stressful compared to working for an internal product team. A lot of times, you need to "learn how to fly the plane while building it." If you are assigned a project that requires a skill you didn't know, you have to learn it quickly.

2. You deal with ad-hoc requests from customers. You might need to do whatever it takes to help your customer succeed, as it might affect your sales team if something doesn't work. The external service team generally works along with account managers and sales teams. Compared to an internal customer, you probably need to respond to your external customers faster.

3. You might not go deep in an area. While you get to work with a diverse pool of customers, each engagement might be only a couple of months, and you might not be able to dive deep into a use case or methodology. It might feel like you are doing five hackathons a year. It could be exciting for some people, but if you enjoy doing research for the same project over a long period of time, this type of work might not suit you.

4. Sometimes, customers might want to drop a project because of internal changes and won't tell you why, and it might be frustrating for data scientists who have already invested in this project, but "customers are always right," and you can't force them to complete it.
   ​

Note: having more points in the "cons" doesn't mean this is not a good career choice, and not all the points are weighted equally. I just want to list them out for you to have a holistic view of this type of role.

I don't think one role is better or worse than the other; it all depends on what YOU want in your career. I learned different things in different kinds of teams, and I'm especially grateful for the time spent on the external service team.

What's your experience in different data science teams? Reply and let me know your experience! Here is a photo of me from a safari in Kenya! I'm back in San Francisco now, and if you want to meet me in person for a happy hour + panel hosted by me on Oct 26, secure your seat here at the Data Observability Summit.

What do you think about today's newsletter? Let me know what you think!

Until next time,

Daliana

Do you know this newsletter is not my first newsletter?

Back in 2016, I built an internal newsletter about "A/B testing case studies" that grew to 1000+ subscribers (including VPs) while working as a data scientist. Here's the crazy part - no one asked me to do it.

Why did I do it?

In 2016, I worked with a team that provided A/B testing tools for all retail teams. My main responsibility was to help other teams analyze their results and advise them on product decisions. It was a fun job as I got to see how teams change the colors of buttons, messages of Prime deals, and different layouts of the pages, and it really opened my eyes to marketing and consumer experiences.

Part of my job was consulting. We host office hours to answer questions from our users - software engineers, product managers, and other data scientists at Amazon. I noticed that they often ask similar questions and even want to test similar features. However, because the users come from different teams, they don't know what each other is testing, and it's hard for them to learn the lessons to gain new perspectives and avoid the same mistakes.

At that time, my manager and I wanted to start a new project - a meta-analysis of all the experimentations running over the past year. I don't recall the exact number, but it's in the hundreds. We ranked the experiments based on p-value, sample size, and other criteria to identify the experiments that drove the most significant changes.

We quickly realized that we were the only team with access to ALL the learnings from the experiments. When I think about the questions our users asked, I know that if we share those learnings with them, explain what happened in those successful experiments, what best practices they followed, and what new things they tested, other teams will be inspired and develop better ideas.

However, this means it'll take more time to write an essay on what I learned in addition to the data science work I need to do. My manager suggested I treat it as a side project if I had time. I thought it was an interesting idea, so I said "yes".

If you have ever written anything, you know that you'll always underestimate how much time you'll spend on writing. So did I. It's not just a report; I really want my readers to take action after reading it. And because nobody asked for more work emails from their inbox, I spent a lot of time thinking about how I tell an interesting and useful story, how many statistical details I should leave there, and how I fact-check my assumptions about why some treatments perform better than others.

I took it as my weekend project as well, and I even signed up for a writing course for this. It took me more than three weeks to write my first newsletter; we had a very serious reviewing process involving not just my manager but our senior manager as well.

After I sent out to the users and asked them to subscribe to the list if they wanted to get future ones, we immediately got positive feedback -- from A/B testing users to directors and VPs. This gave us more confidence that sharing the learnings from our meta-analysis as a deep-dive helps our customers. So I continued to write the second, third, fourth... I wrote eight letters in total, and at that point, we had over 1,000 internal subscribers, and some of them subscribed their entire team.

This is the information our users didn't know they needed.

We saw the impact, and my manager let me spend more time on it and gave me more resources. I got help from one technical writer and one research scientist.

I also got a "Learn and be curious" award during the all-hands of our org meeting. Although this was not the most technical project I worked on while I was on that team, it was the project that had the most impact and visibility, and it helped me get my promotion.

If you have been reading my newsletter for a while, you can probably tell I enjoy sharing my learnings with others and helping people grow. I wasn't thinking about getting an award, nor did I plan it for my promotion. I did because I felt it was like withholding a big secret for success if I didn't share those A/B testing stories and best practices with the users.

You don't have to start a newsletter at work as I did, but if you feel something you learned through your work can benefit the broader team, share it during a "lunch and learn" session, or just write an internal doc and share it with the team. It helps you think in a more structured way when you write it down, and it is a great way to document for future project reviews, annual reviews, onboarding for new team members, or as a part of your promotion doc. Other team members might find it on your internal wiki and invite you to collaborate with them on similar topics, and this is the way for you to build influence - even if you don't have a senior title.

You don't need 1000 people to read your article or attend your session; it might help one teammate and help them save 20% of their time - that's huge.

And that’s how you create more impact; that’s how you create your own scope and grow your influence without the title.

What are some things you want to write down and teach your team? What kind of impact will it have on them and your own career? I know you probably have something you have on your mind for a long time, and I hope this article will finally motivate you to get started.

Share your idea with me in the comments!

Daliana

Is 'Product Data Scientist' just a new term for 'Business Analyst'? Not quite -- and you'll see exactly why after reading this post. I also asked ex-Google data scientist Dan Lee for a step-by-step strategy to handle interview questions for product DS. While product data scientists don't build many machine learning models, it's essential to keep updated on new developments of LLMs for their business impact. There is a free hands-on workshop on "how to build GenAI App using Llama Index" on the 25th (Mon). Register and broaden your skillset here.

Already, let's get to it!

Sooo, what exactly is a product data scientist?

A product data scientist leverages data (e.g., user activity, profile, and monetization) to inform decisions on a company's product development. Unlike traditional data scientists who might focus on a wide array of problems, a product data scientist specializes in understanding user patterns, designing AB experiments, and scoping potential areas of product improvement.

Day-to-Day: A product data scientist's day might involve:

• Collaborating with product managers to understand and define key metrics.

• Building dashboards to monitor the success and health metrics of a product.

• Analyzing A/B test results to evaluate new features.

• Using predictive modeling to forecast user growth or product adoption.

• Using clustering or segmentation to create user profiles.

While there is some overlap, the role is not merely a rebrand of the data analyst role. Data analysts primarily focus on descriptive analysis that involves building dashboards and charts. Product data scientists primarily focus on predictive and prescriptive analyses that involve hypothesizing product improvements and validating ideas using experiments and modeling.

What’s the pay range? How does it compare to MLE?

The pay for product data scientists can vary widely based on factors like geographic location, company size, and individual experience. In the U.S., the average salary might range from $90,000 to $150,000 or more for senior roles.

MLEs tend to have a higher pay scale due to their specialized skills for deploying, monitoring, and scaling machine learning models in production environments. Depending on the same factors, their pay might range from $100,000 to $170,000 or more for senior roles.

However, it doesn't mean that data scientists are less valuable than MLEs because MLEs have a higher pay range. If you feel passionate about identifying patterns to advise business decisions and designing A/B tests to help the product grow, the product data scientist role is right for you.

What are the core skillsets of product data scientists?

• Technical Skills: Proficiency in SQL, Python, or R, data visualization tools like Tableau or Looker, and basic knowledge of machine learning algorithms.

• Statistical Analysis: Understand statistical tests, hypothesis testing, and A/B testing methodologies.

• Product Sense: Ability to understand and anticipate user needs and behaviors.

• Communication: Translate complex data findings into actionable insights for non-technical stakeholders.

What is the structure of the interview process?

A typical technical screen for a product data science interview is the following:

• ⏰ 45 to 60 minutes

• 💭 Senior/Staff Data Scientist or Data Science Manager

• 📝 Video Call with or without virtual document (e.g., Word Doc)

• 📚 3 to 7 cases consisting of product metrics, AB testing, and product modeling questions.

The onsite portion will consist of the same format but 2 to 3 product-focused rounds at startups and FAANG companies.

How do you prepare for product DS interviews?

• Technical Prep: Review SQL queries Python/R scripting, and brush up on fundamental statistical concepts.

• Case Studies: Be prepared for product-related case studies. For instance, how would you measure the success of a new feature? Or, how would you design an experiment to test a product hypothesis?

• Behavioral Questions: Reflect on past projects and collaborations with product teams. Understand the product lifecycle and how data influences decision-making.

• Stay Updated: Know about the company’s products and any recent features or changes they’ve made.

What kind of questions do I expect in product DS interviews?

Product-based experiments are often complex, as reflected by these case questions by three companies.👇

[Cash App Interview] Suppose a referral program is launched that offers $10 credit to a Cash App user and $10 credit to the friend once the user has signed up. How would you design an experiment to measure the effectiveness of the referral program?

[YouTube Interview] How would you measure the impact of a new video recommendation algorithm on the YouTube homepage?

[Meta Interview] The Messenger team proposes a feature that enables users to receive recent messages either unread or unresponded. How would you measure the effectiveness of this feature in an experiment?

Let's do a deep dive using the Meta Interview question above as an example. Here is a structure you can use.

1. Define the Objective

Before diving into the experiment, it’s essential to clearly define the new feature's objective. For this feature, the objective is to increase user engagement by ensuring users do not miss or neglect important messages.

2. Select Key Metrics

Primary Metrics:

• Response Rate: The percentage of users who respond to unread or unresponded messages after seeing the notification.

Secondary Metrics:

• Open Rate: The number or percentage of users who open the message notification.

• Retention Rate: Check if users who are exposed to the feature return to the app more frequently than those who aren’t.

3. Experiment Design

Random Assignment: Split your user base into two groups:

• Control Group: Users who do not receive the new feature.

• Treatment Group: Users who receive the new feature.

Ensure that these groups are randomly selected and that they’re statistically comparable in terms of demographics, user behavior, etc. Set the significance level at 0.05, statistical power at 0.80, and MDE at 1% relative lift from the baseline response rate.

4. Run the Experiment

Run the experiment for 1 to 2 weeks to achieve the desired sample size, which is calculated based on the significance level, statistical power, and MDE.

5. Launch Decision

Analyze the results:

• Check for statistical significance to ensure that observed differences are likely not due to chance. Check for the practical significance to see if the lift is meaningful for the business.

• Consider confounding variables or external factors that might have influenced the results.

If the treatment group shows a statistically significant improvement in the key metrics without adverse effects on secondary metrics, the feature can be deemed effective. If not, further analysis or iteration might be needed.

What’s the career trajectory for product DS?

The career trajectory for a product data scientist is as follows:

1. Entry-Level / Junior Data Scientist:

   • Focuses primarily on data cleaning, exploratory data analysis, and learning company data infrastructure.

   • Begins to get involved in smaller product projects and may assist senior members in bigger initiatives.

   • Gains experience in tools and methodologies relevant to the company’s products.

2. Senior Data Scientist / Lead Data Scientist:

   • Provides leadership on major product initiatives, making high-level decisions based on data.

   • Mentors junior data scientists.

   • Collaborates with senior management and becomes a key stakeholder in product strategy discussions.

   • May begin to focus more on advanced modeling or experimental design.

3. Principal Data Scientist / Staff Data Scientist:

   • Recognized as an expert within the organization.

   • Drives innovation in data science methodologies and tools (e.g., research and develop an experimentation framework)

   • Often involved in long-term strategic planning and ensuring the product roadmap aligns with data-driven insights.

4. Data Science Manager / Director:

   • Manages a team of data scientists, setting priorities and ensuring team growth.

   • Engages in hiring and talent development.

   • Collaborates with other leaders in the organization on overarching business and product strategies.

Since a product data scientist operates closely with the business side, it offers opportunities for business leadership roles, making it a great career choice for various paths. I just interviewed a manager of product data science at Meta, and he transitioned from MLE to product DS because of his passion for business impact. If you want to start preparing for interviews, Dan Lee, who helped me with today's post, offers a 10% discount for you when you study his interview courses here using code "daliana10off".

What else do you want to know about the role of a product data scientist? Just hit reply and let me know!

Before you go, don't forget to register for the "Building GenAI App using Llama Index" workshop -- you'll get the recording even if you can't make it.

Until next time,

Daliana

I just finished my month-long trip to New York City and met 20+ data scientists. There are still a lot of data scientists working in tech companies like FAANG, but you'll also meet many DS working in finance, and the roles are quite different. Today, let's talk about the DS roles in finance vs. tech. If you are interested in data science in finance, here is a great webinar on "building a stock market advisor chatbot using OpenAI." Register here if you want to learn OpenAI APIs and FinTech use cases.

My opinion is based on anecdotes, not big data, but I think you'll get a better sense of the DS roles in tech and finance after reading this. Let's dive in!

#1 More levels; bigger titles

In the finance world, there are more levels than those in tech. A friend of mine works at American Express, and he told me there are levels from 30, 35, 40, and all the way to 90. While in tech, the level is more flat. The junior data scientist is usually level 3 or 4, and the principal is 6 or 7.

You'll meet data scientists and engineers with "VP" in their titles, which is different from the VP in a tech company, who usually manages multiple directors, and it's a senior leadership role. However, the VP could be an individual contributor (IC) in a finance firm, and it's equivalent to a senior role in a tech company.

A friend told me that the VP title for tech IC roles is because some finance-related regulations only allow employees with the VP title to work on certain projects. I haven't verified this, but let me know if you know other explanations.

#2 There are more diverse roles

Instead of "data," you see the word "quantitative" in many titles.

• Quant Researcher

In the financial sector, quant researchers design and develop models and strategies to answer complex questions, predict market movements, and identify investment opportunities.

Similar to the data scientist or research scientist role in a tech company.

• Quant Engineer

They implement, optimize, and maintain the algorithms and models developed by quant researchers. They bridge the gap between theoretical research and practical application by ensuring that models run efficiently and reliably in real-time trading environments.

This is generally less popular than the quant researcher role but provides much value to the team. It's more like a data science engineer or MLOps engineer role.

People use this to transition to a software engineer role if they started in data or statistics but didn't have enough development experience or the other way if an engineer wants to transition to quant researcher but didn't have much experience in data science and ML, they can learn from this role.

It seems like there are rarely principal levels for quant engineers, and the closest senior IC role for this function is a software architect.

#3 You can't stay IC forever

In tech, you can tell your manager you don't want to become a manager and want to be an IC after you reach a senior role as long as you deliver results.

But in finance, a very senior IC role is rare. Your company will encourage you to become a manager, and that's the way they grow.

And they want you to grow, get promoted, and move up the ladder. If you stay at the same level for too long, you might not survive.

A few other things

• When it comes to hiring, they focus more on whether they like working with this person. Technical skills matter, but they also want to ensure you are likable and have good communication skills.

• More focus on compliance if you work in finance. The risk of the model is not just losing money, but you might break laws for things you build; there are more due diligence processes and standard procedures. In tech, teams can push a new model in production after A/B testing and don't need to think much about the law.

• You'll get a yearly bonus on top of your base salary, while in tech, some companies don't give bonuses, and it's base + equity.

What do you think about the differences between DS roles in tech and finance? If you have your own experiences, I'd love to hear from you. Simply reply to this email.

That's it for this week. Before you go, if you don't want to miss the webinar on AI in FinTech, secure your seat here.

Now I'm in LA writing to you. Heading back to San Francisco in a few hours.

Until next time,

Daliana

Preferences Unsubscribe​

I used to work in Amazon's central experimentation team for three years, and I have analyzed over 100 A/B tests. My coworkers and I also hosted office hours for product owners to help them with A/B testing best practices. Today, I will share three common biases I observed and how you can avoid those.

I'm actually traveling while writing this article, and I'd love to meet you in person! If you live in NYC, meet me here this weekend. If you live in LA, meet me there next weekend.

If you can't meet me in person, here is a great virtual event on ChatGPT for Product Led Growth (PLG): Talk with Your Salesforce or Segment Data; you can register here. You'll Learn how to build an app using Langchain and a vector database, best practices on data privacy, and how to handle multi-model data.

Alright, let's get started.

#1 Bias in the data quality check

When the experiment has statistically positive results, everyone wants to celebrate. However, when the results show that the new feature is not a good idea, the owner of the experiment usually says: "Based on XYZ, we think this is a winning feature! So, is there any data quality issue here? Or is this random? Should we re-run the test?"

People like to believe their assumptions about the features are correct.

However, more than 60% of the time, they are wrong. And that's okay -- that's the reason we need experimentation.

The thing is, how do you know your "successful" experiment is a real success?

In large companies like Amazon, Google, and Facebook, experimentation could affect millions of customers, so most of the percentage lift you see is small. It won't surprise me if the lift is <0.1%. So, when you see an experiment with a lift > 3%, that should raise an alarm.

The data quality check in A/B testing shouldn't only be triggered when the result is not as expected or "bad." In fact, there are no "good" or "bad" experiments. You always learn something about the customer.

What should you do?

The team should develop mechanisms to check data quality regardless of how the metrics move. Create an alarm if the absolute value of the percentage lift is too large. Don't celebrate too early when you see a 5% positive lift - it's probably too good to be true.

#2 Bias in choosing metrics

Here is an example. When a product owner designed an experiment, their key metric was the number of purchases. Later, they found that the number of purchases didn't move much after the experiment finished. However, some categories they didn't pay attention to had significant results - more customers purchased shoes, or maybe Android users had more sign-ups. Looks like a reason to launch the feature!

Let's take a step back.

How A/B tests work is that you are testing an assumption, or in some cases, a few assumptions. That means the criteria of the product launch need to be determined before you kick off the experiment.

Changing your success metric after observing the experimentation data to support the launch decision is called "cherry-picking." This invalidates the statistical tests.

What should you do?

If you slice the data thin enough, some small subgroups might always move in the direction you want. It could be totally random and you should stick to your original launch criteria. But what if those new observations are real effects?

Take this observation and create a new experiment with this assumption -- using the new metric as your launch criteria. But don't use this metric as an excuse to launch your current experiment.

#3 Bias in boosting A/B testing productivity

Online experimentation needs to run for at least a week. In order to have enough statistical power, some need almost a month. Sometimes, product leaders think it takes too long for them to innovate and want to see if they can "get more bang for the buck" through one experimentation.

• 3.1 Testing more than one feature

There are no rules on how many features you can test in an experiment. So, if you have more than one idea about a feature, why not test them all together? Let's have 10 groups??

When you split your traffic, you might not have enough sample size for each feature, and you might not detect the change even if there is one. You also increased the chance of false positives.

In general, we don't recommend people to test more than 3 features, and you need to run additional statistical tests and adjust the p-value to avoid getting false signals. It'll be counter-productive if you test too many features at the same time.

• 3.2 Stacking multiple changes in one group

Okay, so if I can't split into too many groups, how about I run a two-sample test where I combine all the changes I want into one feature for the treatment group? I'll move this button to a different location on the page, change its color, and add a banner.

I don't need to worry about not having enough traffic anymore!

However, what if this experiment doesn't show any significant changes? You only learn that this combo doesn't do anything for your customers, but you won't understand how customers react to the new color, button location, or banner, respectively.

You might get lucky that this experiment has significant results, but it's dangerous to launch it without understanding how each change contributed to the lift.

Instead, test one change at a time. Don't stack things you want to test.

In A/B testing, less is more. Be patient.

Design the experiment in a way that you can learn something, so you don't waste time betting on winning features.

I know it's hard to overcome those biases when you have worked on a product for so long and don't want to "kill" your baby.

When you find it hard to stick to the best practices, think about the end goal -- you want to create something useful for your customers. Even if you launch the product by manipulating the data and report a 'win' for the team, eventually, your business metric will suffer because you launched something the customers don't want.

That's it for today. I have many more stories about A/B testing; stay tuned!

Hope to see you in NYC or LA! If not, reply to this email to say hi or check out the Gen AI workshop.

Until next time,

Daliana​

Today I want to share some lessons I learned from leading my first computer vision project. I learned computer vision from an internal bootcamp I did while at Amazon. As a data scientist, you have to keep learning on the job - building the plane while you are flying it. Today, a lot of data scientists want to learn LLM from the ground zero, so before I start today's story, I have an LLM related workshop to share -- “How to Build a Llama 2 Fully-Private GenAI App.” You'll learn the inner workings of Llama 2 but also discover how to create a fully-private and air-gapped Gen AI application. Get access here.

Alright, let's get started!

I still remember the nervous excitement on my birthday in 2020. My manager asked me to lead a computer vision (video recognition) project for an AWS customer. I knew I would learn a ton in this project, but the feeling of uncertainty was palpable.

Why? Because as my first computer vision project, video recognition is more challenging than image recognition. Also, I'm also leading two very experienced data scientists as a first-time team lead.

In today's letter, I'll share some challenges I faced, how I tackled those, and some lessons learned.

1. The first challenge: data labeling

The ML task was to predict whether there might be a soccer goal in the next few seconds, and we need to cut the clips before the goals actually happened. We were provided with the entire video of soccer games, so we need to identify the timestamps a few seconds before it happens. The only thing we have are a small time interval of when the goal happened.

As we want to make sure we pinpoint the exact timestamps leading up to the goals, for the first 2 weeks, we were just focused on labeling those pre-goal moments.

The best (or maybe the worst) part of the job is that we each watched about 200 soccer goal moments in a few days 🤣 after that I didn’t feel like watching soccer for a while.

At the same time I have more empathy for the data labelers working for YouTube and Meta flagging violent content, imagine watching those as a full time job. So, it really wasn’t that bad.

We told our customers we'll have our first model within the first two weeks, and we had to delay that because of the data labeling process. As a data scientist, you never know what kind of data labeling process you need to go through. It's important to assign enough time in the data pre-processing phase of the ML project - there almost always is something unexpected.

2. Betting on the Right Strategy

Once our data was prepped, we need to figure out the model architecture.

A team member proposed an ambitious strategy, but this one is more of a "moonshot", and we can't afford failing for the customer. As there are not a lot of literature on this type of problems, I sought insights from colleagues with similar project backgrounds. They recommended a tried-and-tested method, albeit less glamorous than the “moonshot”: we might not achieve really high performance metrics, but it's a safe bet and it works 70% of the time.

Which strategy should I choose?

Rather than opting for a singular approach, I saw our project strategy as a diversified portfolio. The bulk of our efforts—similar to investing in stable stocks/ETFs—focused on the reliable return. Simultaneously, we allocate a portion of our resources to explore the moonshot possibility, akin to investing in high-risk, high-reward assets. So, me and one team member worked on the tried-and-tested method, and the other team member who proposed the "moonshot" method got to work on it.

The outcome? Our "safe" strategy worked, and while the "moonshot" didn’t pan out, it offered invaluable insights into our data.

There is benefit to have people work on the same project in a different approach and just give someone the freedom to explore.

The key is to know it might fail and not blame the person, and treat it as a learning opportunities and have a baseline solution that works.

3. Translating a complex problem to simple solutions

There is one part of the solution where we need to identify different types of soccer activities during the game. It includes players entering the field, taking breaks, talking to referees, etc. Ideally, we'd like to identify all those activities. Still, it requires more data labeling effort and we are wondering if we have enough time - even if we do, those activities need more examples than regular soccer activities. And while we are still at the beginning of the ML project, we want to quickly build a baseline model to test whether the model we use would work in action recognition and differentiate different activities.

So instead of trying to identify all those activities, we simplify a multi-class classification problem to a binary classification - we only train the model on the clips a few seconds before the goal happened where players are attacking the opponent and the clips where players are walking around on the field (not in any intense activities)

My thesis was that if the model couldn't even differentiate those two significantly different actions, it wouldn't be able to recognize the other classes I mentioned.

So, we started with the binary problem after we labeled two classes of clips, and our first model had ~ 70% accuracy. And later, we improved this binary classifier, which became our final model.

There is always a perfect solution you can go for, and we always have limited time and resources. Start simple in your first baseline model; think of a way with low effort to quickly test your strategies before you go for the more complicated solution. And a lot of times, you'll realize the simple solution works the best.

Take-aways

1. Allocate more time in data preparation

2. Diversify the risk of your ML strategies - treat it as a portfolio

3. Figure out a low-risk simple solution before diving into complex problem

(Also, don't miss the GenAI workshop, get access here)

That's it for today! I'm in New York right now writing this newsletter to you. I'll be till early September. I'm thinking about organizing a meetup if you are interested in. Reply to this email if you'll be around.

What do you think of today's newsletter? I read every reply, would love to get your input!

Until next time,

Daliana

I know I haven't updated for a while, today I have a very import newsletter that will bring your data science career to the next level 🚀.

Here are the 3 things you should do before, during, and after a project.

1. Before the project: ask how your data science project is going to fit in the bigger picture.

Don't just put your head down once your manager ask you to do an analysis. Ask why they need this analysis.

Why? Because when managers need an analysis to make a business decision, they don't know the details of the limitation of the data. Or, they don't have the data science background to think beyond the very few methods they know.

By letting them explain the big picture, you'll often identify that the analysis they ask for won't solve their problems. It's important to brainstorm with them, and make sure the analysis is not just what they think they need, but what helps them achieve their goal.

Don't treat your data science project like a 'lego piece'.

Think like a business owner, ask why. You want to make sure your analysis is going in the right direction before you dive in the hard work.

Take time to align with stakeholders might seem to be time consuming in the beginning, but it'll save you a lot of headache down the line.

2. During the project: get feedback early.

Data science projects often fail because the data is not good enough to solve the problem, or sometimes it's because the business requirement changes.

When you start a project, don't just have the verbal confirmation, but also have a written documentation of the agreement on the problem you are trying to solve, and what are the goals you try to achieve.

Every time the object changes, make sure it's reflected on paper, so everyone is on the same page.

If you only get feedback from your stakeholder when you finish 50% of it, it might be too late.

Get feedback early.

Your first demo doesn't need to be perfect. It could be as easy as showing them your code and visualization on a Jupyter notebook. Don't need to spend too much time to make a perfect presentation.

The goal is to see whether the stakeholders think it's going in the right direction.

Most people are visual. When you present, have a table or a diagram, not just bullet points. Again, the goal is not to show a pretty graph, but to help other people see your point.

Stake-holder alignment work doesn't just happen in the beginning of the project, you need to keep doing it throughout the project, and never assume that the objective of the project stays the same.

3. After the project: follow up to make sure it's successful and get the measurement of the impact.

I know you hate writing documents after a project, you just want to move on.

But what if your manager asks you details about it 3 months later, can you remember it?

What if you need documents for your promotion, can you provide a concrete report from 'problem statement' to 'model evaluation'?

Just push yourself a little more, block a few days to finish the documentation!

Besides, always have follow-up meetings with the engineering teams/PM teams that use your analysis. Make sure it's successful.

Because sometimes the launch of a data science project can be blocked because of lack of ownership. I know on paper your project is completed, but it's worthwhile to be a leader in the last sprint to make sure it's in production. You might also need to educate them how to use your analysis, and provide support.

It's your job to ensure the data science project generates business impact, instead of staying as an analysis report. Your responsibility doesn't stop at the analysis phase. So, follow through.

After the launch is successful, schedule periodically sync up with the stakeholders to ask for feedback to improve your future analysis.

Ask them about the metrics to measure your impact. Not just the statistical performance, but how much revenue your work generated, how much time you saved, or how much better the decision making process is because of your report.

Those learnings will help you design your next data science project better, and you need to document those metrics for your future performance review before you forget.

To summarize:

1. Don't treat your data science project as a lego piece. Ask why

2. Get feedback early from the stakeholders. Iterate.

3. Follow up after the project is done. Make sure it is useful and collect performance metrics.

Look, the 3 things are not related to your technical skills, but your communication and leadership skills.

I want to share more with you, but I need your help. If I were to create a course to help you go to the next level of your data science career, what do you want to learn from me?

Tell me in this 1-min survey. 😊 I'll really appreciate your feedback and your answer means a lot to me!

As always, you can also reply this email, I read all your messages.

Until next time,

Daliana Liu