It seems like it happened slowly, then all at once. For some time it was the consensus that new data tools and technologies were going to be the thing that finally helped data teams break through, get executive buy-in, and drive the successful outcomes that we all knew they could. But in the past year or so, I’ve been seeing dissent. Commentators and thought-leader-types started asking if we’ve focused too much on technology, at the cost of staying in touch with the needs of the businesses we work in. Now there’s a healthy contingent of folks calling for us to focus on
Well said. I was one of those people who believed that the only way to make data gaining the spotlight at a company is to have data as the company’s product. It’s also true that I didn’t want it to be true because that painted a not so exciting picture for data folk as there are only so many companies powered by data as core product.
The “elbows of data” is a great manifesto for data folks and I cannot wait to share with my peers. This is the vision I want to believe to be true and will make true. It’s a much hopefully version too, and thanks for sharing this vision with the world.
This post really resonates with me. Glad we now have a term "elbow" to put on the banner!
Sorry to join the "fatalistic" camp, here is a description of my experience that being elbows is a necessary but unfortunately not sufficient condition for the data team to succeed.
I am curious, Katie, what do you suggest to do when a PM gets intimated by the data elbows?
I once had a job where I managed to elbow my way in, understand the domain, build a great relationship with the stakeholders, expand the data science work from one project to many, and grow the data team to execute the new projects. The elbow poster child!
It was all going pretty well... until my PM's boss asked me to stop contacting stakeholders directly - to forward all their emails to my PM to reply and to stop my weekly newsletter... A month later they moved me to another department.
Looking back at it now, me and my skip-PM really failed to build a relationship.
I was aware that they don't like some things I do. And I did nothing about it as I didn't want them to be involved in my work. A bit arrogant of me, huh?
Now, having experienced good working "Radical Candor"-style relationships, I would have solicited direct feedback from them, and emphasised how important [PM-data collaboration](https://www.youtube.com/watch?v=tzr6jNJqpDc) is to our joint success.
And I would have understood their incentives - following the organisational norm for software teams that "PM is the only stakeholder contact", and how this change was negatively affecting their work from their perspective.
This story of struggle for a great "engineer-end user" relationship against Product Manager/Owner gatekeeping is re-told a thousand times by the software engineering agile coaches. I think the data community can learn a lot from the [small-letter-agile](https://holub.com/reading/). For example, I learned that pairing/mobbing on data validation parts of the pipeline can do wonders for Data Science - Data Engineering collaboration.
Snipping out "And that’s the crux of the problem—...work for a company where data is the product because then data will finally be critical to the success of the business, but my inner contrarian also dislikes this advice. There’s only so many companies where this can be true, it really only works for folks who deploy to production,"
Consider the academic business of getting ahead of disparate data systems that work for the public its crossover into business is a like and incubator of data management.
https://www.luc.edu/ccj/aboutus/ is a starting point of reading to understand how Loyola University is implementing data to better understand "in the criminal justice system, equipped with knowledge about the causes of criminal behavior, formal responses to crime, and the consequences of crime and the criminal justice system on people’s lives – and a dedication to ensuring social justice in the criminal justice system"
Well said. I was one of those people who believed that the only way to make data gaining the spotlight at a company is to have data as the company’s product. It’s also true that I didn’t want it to be true because that painted a not so exciting picture for data folk as there are only so many companies powered by data as core product.
The “elbows of data” is a great manifesto for data folks and I cannot wait to share with my peers. This is the vision I want to believe to be true and will make true. It’s a much hopefully version too, and thanks for sharing this vision with the world.
This post really resonates with me. Glad we now have a term "elbow" to put on the banner!
Sorry to join the "fatalistic" camp, here is a description of my experience that being elbows is a necessary but unfortunately not sufficient condition for the data team to succeed.
I am curious, Katie, what do you suggest to do when a PM gets intimated by the data elbows?
I once had a job where I managed to elbow my way in, understand the domain, build a great relationship with the stakeholders, expand the data science work from one project to many, and grow the data team to execute the new projects. The elbow poster child!
It was all going pretty well... until my PM's boss asked me to stop contacting stakeholders directly - to forward all their emails to my PM to reply and to stop my weekly newsletter... A month later they moved me to another department.
Looking back at it now, me and my skip-PM really failed to build a relationship.
I was aware that they don't like some things I do. And I did nothing about it as I didn't want them to be involved in my work. A bit arrogant of me, huh?
Now, having experienced good working "Radical Candor"-style relationships, I would have solicited direct feedback from them, and emphasised how important [PM-data collaboration](https://www.youtube.com/watch?v=tzr6jNJqpDc) is to our joint success.
And I would have understood their incentives - following the organisational norm for software teams that "PM is the only stakeholder contact", and how this change was negatively affecting their work from their perspective.
This story of struggle for a great "engineer-end user" relationship against Product Manager/Owner gatekeeping is re-told a thousand times by the software engineering agile coaches. I think the data community can learn a lot from the [small-letter-agile](https://holub.com/reading/). For example, I learned that pairing/mobbing on data validation parts of the pipeline can do wonders for Data Science - Data Engineering collaboration.
In general, change in an organisation is hard. In addition to ("generate excitement") [https://lethain.com/hard-to-work-with/] strategy you mention, there is an awesome long list of ways to change an org in a book "[More Fearless Change](https://www.goodreads.com/book/show/23287939-more-fearless-change) I learned about it in a great [blog](https://www.lisihocke.com/2022/07/a-time-of-transition-eight-months-on-a-new-team.html) by Lisi Hocke on org culture change around software testing, and how to be a leader without having "management" in the title.
Two elbows in... great read!
Snipping out "And that’s the crux of the problem—...work for a company where data is the product because then data will finally be critical to the success of the business, but my inner contrarian also dislikes this advice. There’s only so many companies where this can be true, it really only works for folks who deploy to production,"
Consider the academic business of getting ahead of disparate data systems that work for the public its crossover into business is a like and incubator of data management.
https://www.luc.edu/ccj/aboutus/ is a starting point of reading to understand how Loyola University is implementing data to better understand "in the criminal justice system, equipped with knowledge about the causes of criminal behavior, formal responses to crime, and the consequences of crime and the criminal justice system on people’s lives – and a dedication to ensuring social justice in the criminal justice system"