And you may find yourself in another part of the cloud
And you may ask yourself, "How do I work this?"
And you may ask yourself, "Where is that large conceptual model?"
And you may tell yourself, "This is not my beautiful data warehouse"
And you may tell yourself, "This is not my beautiful data model"
Same as it ever was, same as it ever was
Same as it ever was, same as it ever was
LOL.
As you mentioned, my feeling is it is part practitioner knowledge that is really not taught well, but really learned by experience of several roles in an application and data environment. The forethought of a good foundation and getting a head start on down stream BI and Analytical needs. The enterprise data architecture forethought and planning of where the data fits in the conceptual model, and how it will be combined and harmonized in a data platform. Every project needs that data planning up front, understanding reporting and analytical needs upfront. In many companies there is push back about talking data needs, saying well, we will get to reporting and data needs in phase 2, or phase 3. I have found too many times, the quality improves and defects decrease when the business analyzes reporting data up front.
PS - Joe, what was the book you mentioned? - "How Big Things Fail", I could not find that one, I did see a well liked book called "How Big Things Get Done" that looks interesting.
Thanks for diving deeper into the topic, Joe. It's a bit of a depressing view, but I like your point on pushing more on the offense. Otherwise, those discussions that we all in data have time and time again are really like preaching to the choir. All of us nod in agreement, and we go on.
I can already imagine being in my sixties and seeing some young people writing on whatever platform they will be, and that data is seen as a cost center. This is exactly the vibe I got from Tom Redman (awesome guy, has been working on this for such a long time), when I talked to him about current data problems.
Anyways, thanks again and many greetings from over the pond :)
I haven't rebooted my long-form post machinery (though my posts can't be called short either), but I can pile on this "ME #staynerdy TOO" movement. Below is a post from last month.
I live this reality every day, dealing with the "technical debt" of data done "just to get done" while resources were disproportionally spent on serving the opulance of the flavor of the quarter shiny tool or deliverable thing. Having been doing gigs in this exact space since 1999, I can support with absolutely certainty Joe's "prediction" of saying the same in 60 months or so.
"Start playing to win. This is easier said than done. What does that look like? It means integrating with the business and tying data to critical initiatives. This is surprisingly foreign to quite a few practitioners I talk with. They’d rather passively provide reports and dashboards. Then, they wonder why the business does not recognize their data team’s work. Or they’re confused when the data team’s headcount is reduced. It all comes down to stopping the buck-passing and becoming actively involved in the business. Again, it's easy for me to sit in my fancy Aeron chair and type this motivational message to you. The reality is most of you won’t do this. It’s hard. And I’ll probably write the same thing in five years. Same as it ever was."
What are some suggestions you have for "playing to win?" What does it look like? What risks do you take on as you move in that direction? Do you risk being blamed for poor outcomes?
Dude....I literally wrote a post about this exact topic. It's like we're one dysfunctional data family https://thewongway.co/are-you-playing-to-win/
Omfg, too funny
okay I will byte. ;)
And you may find yourself living in a data swamp
And you may find yourself in another part of the cloud
And you may ask yourself, "How do I work this?"
And you may ask yourself, "Where is that large conceptual model?"
And you may tell yourself, "This is not my beautiful data warehouse"
And you may tell yourself, "This is not my beautiful data model"
Same as it ever was, same as it ever was
Same as it ever was, same as it ever was
LOL.
As you mentioned, my feeling is it is part practitioner knowledge that is really not taught well, but really learned by experience of several roles in an application and data environment. The forethought of a good foundation and getting a head start on down stream BI and Analytical needs. The enterprise data architecture forethought and planning of where the data fits in the conceptual model, and how it will be combined and harmonized in a data platform. Every project needs that data planning up front, understanding reporting and analytical needs upfront. In many companies there is push back about talking data needs, saying well, we will get to reporting and data needs in phase 2, or phase 3. I have found too many times, the quality improves and defects decrease when the business analyzes reporting data up front.
PS - Joe, what was the book you mentioned? - "How Big Things Fail", I could not find that one, I did see a well liked book called "How Big Things Get Done" that looks interesting.
Yeah, I misspoke in the podcast. It’s how big things get done
lmao I love the adaptation
Thanks for diving deeper into the topic, Joe. It's a bit of a depressing view, but I like your point on pushing more on the offense. Otherwise, those discussions that we all in data have time and time again are really like preaching to the choir. All of us nod in agreement, and we go on.
I can already imagine being in my sixties and seeing some young people writing on whatever platform they will be, and that data is seen as a cost center. This is exactly the vibe I got from Tom Redman (awesome guy, has been working on this for such a long time), when I talked to him about current data problems.
Anyways, thanks again and many greetings from over the pond :)
Great comment. I’ll be in my fifties soon, and that’s close enough for discomfort
I haven't rebooted my long-form post machinery (though my posts can't be called short either), but I can pile on this "ME #staynerdy TOO" movement. Below is a post from last month.
I live this reality every day, dealing with the "technical debt" of data done "just to get done" while resources were disproportionally spent on serving the opulance of the flavor of the quarter shiny tool or deliverable thing. Having been doing gigs in this exact space since 1999, I can support with absolutely certainty Joe's "prediction" of saying the same in 60 months or so.
https://www.linkedin.com/feed/update/urn:li:share:7241339849973121024?lipi=urn%3Ali%3Apage%3Ad_flagship3_feed%3BE9qaawKoSsaU4ZlBLYyq2w%3D%3D
Yeah, it’s a safe bet
“Gee whiz insights” and “playing not to lose”, these are gold Joe.
Ha, thanks!
"Start playing to win. This is easier said than done. What does that look like? It means integrating with the business and tying data to critical initiatives. This is surprisingly foreign to quite a few practitioners I talk with. They’d rather passively provide reports and dashboards. Then, they wonder why the business does not recognize their data team’s work. Or they’re confused when the data team’s headcount is reduced. It all comes down to stopping the buck-passing and becoming actively involved in the business. Again, it's easy for me to sit in my fancy Aeron chair and type this motivational message to you. The reality is most of you won’t do this. It’s hard. And I’ll probably write the same thing in five years. Same as it ever was."
What are some suggestions you have for "playing to win?" What does it look like? What risks do you take on as you move in that direction? Do you risk being blamed for poor outcomes?