"Internal" teams VS "External" teams for data scientists (a deep dive)
"Internal" teams VS "External" teams for data scientists (a deep dive)
Which one works for you?
Hello everyone,
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:
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.
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.
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.
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:
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.
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:
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.
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:
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.
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.
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:
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.
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.
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.
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
