If your first response when you’re given the keys to the castle of a new data team is wondering what shiny toys you’ll get to use.
You’re probably headed in the wrong direction.
Don’t get me wrong, we all love shiny toys.
But they can also be a distraction to what the business needs.
Sometimes, it’s the businesses themselves that distract us and use the terms they’ve heard or read about and demand that we deliver possible solutions that aren’t needed or that the business is not ready for.
I do believe part of the data team's role is to help consult in these situations. Don’t just be a task taker, be a strategic player. If you want to be part of a strategy, you have to act on it.
To be clear, you’ll still face businesses and CEOs that will continue to treat you like a task taker. Sometimes this can be fixed by taking ownership and leading with limited power, and other times you’ll be trusted right away.
Wherever you are on that spectrum, I believe
once put it that you only have so many strikes. You only have so many chances until you’re relegated to task taker no matter what you do or else your team is fired and replaced.In order to have your data team taken seriously, you need to know a lot more than just read Kimball or DDIA.
Let’s talk about how you can be taken seriously and seen more as a trusted partner.
Take Ownership By Asking Why
Sometimes we get so excited when the business tells us they need a real-time dashboard or AI or something that sounds really challenging technically.
So we skip past asking why we are even being asked to build said project.
Then a few weeks or months later when we deployed the solution we were asked to build, guess what–it never actually met the business requirements because no one ever really knew what they were.
So although me saying “ask why” might come across as repetitive in my writings, it is the key to taking a project to the next level.
It’s also crucial from the stance of ownership. If data people don’t want to be treated like a cost center or simply as a task completer, they have to take control and ownership of the work they do.
That starts with caring and owning the work you’re given.
If you’re being asked to do something that you believe is a bad idea, question it and be able to defend why you think you shouldn’t do it.
If you see an area to improve the company and you haven’t been asked to do it, take ownership of it.
In the end, part of owning a process or workflow is understanding it both technically as well as from a business perspective.
Understand The Business
During an interview for one of my first roles, I recall being asked what my plan was to get up to speed on the industry I was going into. They knew I had limited knowledge of the space, and so they really wanted to ensure that I knew it was important to go beyond just understanding the technical bits.
In this case, I was going into healthcare, so I spent the first few weeks(and months) not only digging into all of their infrastructure but also into various articles about how claims work, how billing in hospitals functions, various coding practices, metrics etc.
We as data people must have a good enough grasp of what the business is trying to do so we can actually create impactful end results, whether that is metrics or a data product that people will use.
If we just build based on what we are told to do, we limit ourselves to only the businesses perspective of the problem. That’s why it’s important that we also understand what is going on in the company.
What are their current challenges, how is the industry as a whole tracking, what is going on with the current stakeholders.
Much of which starts with communication.
Communication, Communication, Communication
In order for the data and business teams to be aligned, they need to talk to each other.
Frequently.
Obviously, as a data engineer by trade, I am not suggesting we overload anyone with meetings. Work still has to get done. But if you have efficient and organized meetings that have clear goals, a lot can get done!
And those meetings shouldn’t just be with the data analytics team.
As Shachar put it, you’re going to want to spend a lot of your time early on speaking with non-data people. That way you can establish a solid understanding of what is going on in the business, and where your data skills will be put to the best use.
Here are a few more tips to ensure you both get on the same page with the business while also making sure they are aligned with what you are doing as well.
Set-up Initial Interviews with Key Stakeholders - At the start of any project or when you start a new role, schedule one-on-one interviews with key stakeholders to understand their specific pain points, goals, and expectations. I recall a finance director who was hired to turn around an organization I worked for early on spent their first few weeks interviewing almost everyone(including me and I was a junior). They really made sure everyone felt heard and understood.
Be Transparent With Reporting Out Challenges And Successes - All projects will face challenges or obstacles. Be open and transparent with what your team is facing. It can be tempting to minimize project delays and technical issues. But that doesn’t help the project get unblocked.
Set-up Weekly or Bi-Weekly Meetings with Key Stakeholders - Schedule consistent meetings with stakeholders to ensure ongoing alignment and communication. These meetings can be used to discuss project updates, address any issues, and gather feedback. Which should stated in the agenda. I also really liked how
added that you need to “ensure people know why they’re invited” to meetings. Don’t just hold meetings, own them.Post Regular Updates on Project Progress - This was something I started doing at Facebook in particular as it helped my stakeholders keep connected with the project. I’d send out weekly or bi-weekly progress reports outlining what has been accomplished, what is in progress, and what the next steps are. Also when you can include visual aids such as charts, graphs, and dashboards to provide a quick overview of progress.
Reducing Technical Friction
It can be tempting when you first start leading a data team or data project to look into what technology or techniques you should use. But these are just tools that can help reduce technical friction(as Abhi Sivasailam put on our panel last week). They don’t solve the actual problems unless applied correctly.
Take a quick pause and make sure you’ve also spent time talking to stakeholders to understand what their actual problems are.
With that, thanks for reading!
Join My Data Engineering And Data Science Discord
If you’re looking to talk more about data engineering, data science, breaking into your first job, and finding other like minded data specialists. Then you should join the Seattle Data Guy discord!
We are close to passing 7000 members!
Join My Data Consultants Community
If you’re a data consultant or considering becoming one then you should join the Technical Freelancer Community! I recently opened up a few sections to non-paying members so you can learn more about how to land clients, different types of projects you can run, and more!
Articles Worth Reading
There are 20,000 new articles posted on Medium daily and that’s just Medium! I have spent a lot of time sifting through some of these articles as well as TechCrunch and companies tech blog and wanted to share some of my favorites!
Round 2: A Survey of Causal Inference Applications at Netflix
At Netflix, we want to ensure that every current and future member finds content that thrills them today and excites them to come back for more. Causal inference is an essential part of the value that Data Science and Engineering adds towards this mission. We rely heavily on both experimentation and quasi-experimentation to help our teams make the best decisions for growing member joy.
Building off of our last successful Causal Inference and Experimentation Summit, we held another week-long internal conference this year to learn from our stunning colleagues. We brought together speakers from across the business to learn about methodological developments and innovative applications.
End Of Day 130
Thanks for checking out our community. We put out 3-4 Newsletters a week discussing data, tech, and start-ups.
Thanks for the Kimball mention. See TDWT 2nd Ed, p. 4:”behave like we’re a hybrid DBA/MBA”
Agree with all these things and glad you mention them the way you do Ben. Also pumped to see my face/ comments in there!
My one question I have is how can Data Engineers gain the stakeholder trust to ask for the business needs? I think the link is much more obvious to business stakeholders when it is analysts/ scientists given they normally interact with the front-end. Any advice on this?
Also, given you use my LI comment, I'm taking that as permission to share my recent Substack article on the Business Needs, including the exact questions and how to ask them to make sure you get the right info (sorry for the plug, but love this topic way too much to not share <3 ): https://thedataecosystem.substack.com/p/issue-8-deliver-on-the-data-needs