That’s a good one. I’ve been suggesting The Kimball Group Reader, 3rd Ed which collected 20 years of articles by Dr. Kimball and others including Margy Ross, his primary coauthor.
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
Great article. I loved the way you mentioned the need to know more than just Kimball and DDIA. As a Data leader, it's not enough to be technology/methodology fluent but it's equally important to be business fluent.
I have witnessed the temptation to jump right into the technical solutions and the urge to show an output as early as possible.
As I progressed in my career, when I work with business stakeholders who aren't themselves clear of the end goal of the data product, I ask them what is your MVP (Minimum Viable Product) for this quarter? What is considered a meaningful progress in this quarter?
These questions will ring bells in their brains to think practically and realistically and not think of data teams as magicians who will spit out an all solving data product that will just make their life easier.
Setting expectations and make them accountable to think data product as a journey not a destination.
Thanks for the Kimball mention. See TDWT 2nd Ed, p. 4:”behave like we’re a hybrid DBA/MBA”
That's a solid line! IN all fairness I forgot to include this line from kimball
Pitfall 10. Become overly enamored with technology and data rather than focusing on the business’s requirements and goals.
That’s a good one. I’ve been suggesting The Kimball Group Reader, 3rd Ed which collected 20 years of articles by Dr. Kimball and others including Margy Ross, his primary coauthor.
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
hahaha glad you liked it, and all good, I'll have to include one of your articles in the future!
Great article. I loved the way you mentioned the need to know more than just Kimball and DDIA. As a Data leader, it's not enough to be technology/methodology fluent but it's equally important to be business fluent.
I have witnessed the temptation to jump right into the technical solutions and the urge to show an output as early as possible.
As I progressed in my career, when I work with business stakeholders who aren't themselves clear of the end goal of the data product, I ask them what is your MVP (Minimum Viable Product) for this quarter? What is considered a meaningful progress in this quarter?
These questions will ring bells in their brains to think practically and realistically and not think of data teams as magicians who will spit out an all solving data product that will just make their life easier.
Setting expectations and make them accountable to think data product as a journey not a destination.