Sign up for Data Mesh Understanding's free roundtable and introduction programs here: https://landing.datameshunderstanding.com/

Please Rate and Review us on your podcast app of choice!

If you want to be a guest or give feedback (suggestions for topics, comments, etc.), please see here

Episode list and links to all available episode transcripts (most interviews from #32 on) here

Provided as a free resource by Data Mesh Understanding / Scott Hirleman. Get in touch with Scott on LinkedIn if you want to chat data mesh.

Transcript for this episode (link) provided by Starburst. See their Data Mesh Summit recordings here and their great data mesh resource center here. You can download their Data Mesh for Dummies e-book (info gated) here.

Guy's LinkedIn: https://www.linkedin.com/in/guytaylor/

Deep Work by Cal Newport: https://www.youtube.com/watch?v=xJYlhhT7hyE

In this episode, Scott interviewed Guy Taylor, Director of Data Science and Analytics, as well as the Director of Experimentation at Booking.com. To be clear, Guy was only representing his own views on the episode.

Some key takeaways/thoughts from Guy's point of view:

1. In general, "people want to do the right thing." Look to reward people that do the good, ethical things as part of their work product.
2. Always be asking "what is my part in this?" Ask for the expectations and try to be clear in your expectations of others.
3. Literacy is not only about an ability to read but also write. So with data literacy/fluency, we need to be able to use data but also create and share it. It's about learning how to share information - not just 1s and 0s - and share it well.
4. There are still major communication gaps between producers and consumers in many cases with data. Part of that is just not getting on the same page, really making sure both sides close that gap. Scott note: as Andrew Pease said, both parties should go more than half way to ensure you've covered everything.
5. If you don't align on expectations, you're far more likely to have a bad time :)
6. Data people need to stop trying to jump to the tooling to address a challenge first. Get the information necessary - what are people trying to accomplish to create value? - then look to how tools can drive towards capturing that value.
7. In tech and especially in data, there is a strong tendency or leaning towards taking action now. Sometimes no action or no action right now is the right answer. Often times, you need more information to make a better decision instead of patching the hole in the bottom of the boat with bread.
8. ?Controversial?: The way many organizations are trying to leverage data contracts won't lead to significantly better outcomes. There should be technology handling the interface but consumers still need to speak with producers to align on expectations and share their use cases.
9. ?Controversial?: There needs to be more accountability and responsibility on data consumers to actively participate in data work to drive towards the most business value.
10. Ethics in data is always a challenging but interesting issue. Start by creating a set of principles and try to frame potential choices within those principles. Your company ethics will evolve, update your practices as they do. Try to "do the right thing" and encourage others to check in on past decisions to reevaluate too.
11. It's crucial to consider cognitive load - people are most productive when they have time to spend on thinking. Work to give teams, especially those new to owning data, the time to learn, not just the information they should learn.
12. When people know there are expectations on them but they don't know what they are, that's unnecessary cognitive load. Look to make expectations more clear on domains about what data ownership means.
13. On data ownership, be very clear about how far it extends. Data producers should own sharing the information but the consumer has responsibility of ownership too. Scott note: for me, you need to be clear in every relationship but it can be the producer owning the data, the insight, or the insight and the 'so what' - you just have to be very clear!
14. In most organizations, teams are overloaded with work and with cognitive load. You can't just easily pull apart the complexity and fix that overnight. And in a lot of cases, it will be hard to do it at all. Look to prioritize instead of do everything. Saying no can be your ultimate productivity tool.
15. Be like Marie Kondo - 'does this spark value for your organization.' Don't be afraid to shut things down that don't spark value and refurbish your orphaned data generating processes that are valuable.
16. Time for innovation is crucial. It's on leaders to enable their teams to prioritize innovation and experimentation.
17. Always be delivering value. Look to use incremental value delivery methods - how do you break down a big potential project and deliver over time instead of the high risk way of a big project?

Guy started off by talking about data literacy and how the analogy of literacy - it's not only the ability to read but also write - carries over to data well. Data literacy or data fluency, it's not just can someone consume data but can they also produce data, can they share information in a way that can be 'read' by others? After all, we aren't trying to share data, we are trying to share information but via data.

When Guy embeds people from his data team into domains it "is with the express purpose of doing education, making sure that we are having the conversations around what things mean, what our expectations of those things are." Instead of embedding people into domains to do most of the work, they are focused on helping other people get to a level they can handle far more of the necessary data work. Which is quite often not the deep data work but bridging the communication gaps and getting on the same page. That is especially important for expectations - mismatched expectations is one of the most prevalent and damaging challenges to data work. So Guy is asking data team members to spend a lot of time making sure the producers know how to manage those conversations and drive to what is actually of value instead of what was initially requested.

In his experience, there is tendency for data people to try to jump to the tooling to solve issues according to Guy. Going back to expectations, if you try to solve without the expectations setting and leveling conversation, you will likely not deliver what consumers expect. You may see it as solved but they sure don't. That's where you get the dreaded "the data is bad" feedback because there aren't clear metrics and expectations. If you align - and as Ghada Richani mentioned in her episode (#206) stay aligned through collaborative prioritization - then there is a much better chance of delivering value and making all parties happy.

A comment Guy made was that there is an over tendency towards action in tech and especially data. People see a problem and they want to jump to trying to fix it instead of getting the necessary information first. And it may be no action is the best answer too. Just because there is pain, that doesn't mean action is necessary immediately.

Right now, Guy sees the industry conversations around data contracts and data sharing agreements as slightly naïve: people seem to be thinking this is about data integration between systems instead of data sharing between two parties. And that producers should declare every aspect of what they are producing instead of consumers being part of the conversation. Consumers need to share what they are trying to achieve, how they will use the data, etc. so producers understand the value and what would disrupt that value creation. There needs to be accountability and responsibility falling on consumers too. The contract portion can serve as the technology interface but that doesn't replace the need for conversation.

Ethics in data is always going to be an interesting but challenging problem in Guy's book. A good place to start is the social contract aspect: how would this be viewed by society? As an organization, start down the ethics path by creating and agreeing to a set of principles. Create good ways for people to seek and receive useful feedback regarding ethics. And honestly, your company ethics will change and it's important to reevaluate your ethical choices, especially as you learn more - your organization will have made mistakes and that's typically not something to lose sleep over, fix it now and know you’re better. Basically look to "do the right thing."

While it can feel good to 'make progress', Guy believes in the Deep Work by Cal Newport type philosophy. People have the greatest impact when they have the time to really think and process. Yet, in today's work world, that is a rarity for anyone. If we are asking teams to really take on data ownership, we have to work to prioritize the time to learn - and that includes processing time. Yes, people learn by doing but not only doing :)

Guy talked about trying to clear the space for teams to learn something new, including the impact to the cognitive load capacity of teams, especially when it comes to data ownership on the domains. When people know there are expectations of them and their work but those expectations aren't explicit or clear, that's unnecessary cognitive load - domains need to have crisp and clear expectations - and if the expectations of them by consumers and the data team aren't super clear yet, communicate that. But try to get to more detail to make the implicit very explicit.

Another common friction point Guy pointed to is the lack of understanding of your impact on others. He believes again that most people want to "do the right thing" but they don't always know there is even a problem to address. How are your actions impacting downstream data consumers? Again, there is a responsibility on those data consumers to generate the conversation! Sharing that context allows people to do the right thing because they are aware.

Currently, most teams in most organizations seem to be overloaded with work and cognitively overloaded in Guy's view. It would be lovely to wave a magic wand and fix that but it's not possible. So, we have to work to pull out the complexity and give our teams the ability to do their best work but high value work has interconnected complexity so you can't take a machete to it and expect good results. Look to prioritize what really matters when you can and break things down into manageable chunks.

In talking again about data ownership, Guy believes that producing teams should not have to own too much of the downstream consumption. They should own the transformation and sharing of data after it's been transformed but the consumer should own the insight or metric - they asked for the data so they need to have some responsibilities and accountability too. Scott note: I don't entirely agree it should be that for every use case but I do like a very crisp line of ownership if it works.

Guy uses the Marie Kondo approach when looking at orphaned systems or processes - evaluate it and is this "sparking joy", is it creating value. If it is, great, let's get it into a good shape and put it into the right hands ownership wise. Not shove something to someone while it is still in data disrepair but get it functioning well and hand it over. But if something isn't creating value, shut it down. For too long in data, there has been a hesitancy to shut things down because at some point they might create value. Don't fall into that trap.

It's important to get to an experimentation - a test, learn, and then iterate - approach in Guy's view; he is the Director of Experimentation after all! A good way to get people to see the value of experimentation is how it provides far better incremental value delivery. Instead of huge projects with big budgets that take years and rarely deliver the value expected, what if instead you took the overall goals and broke it into manageable pieces and delivered value over time as you get closer and closer to the project vision. You'll be more nimble and get a return on investment far quicker.

A few tidbits from the end of the conversation:

Skunkworks can be a great approach to trying things out and seeing if there is value. Don't try to move the skunkworks directly to production but you can do some fun and useful innovation that way.

Good leaders set their teams up to innovate. They prioritize the time to try new things and let their people explore, let them go off the "paved road".

Data Mesh Radio is hosted by Scott Hirleman. If you want to connect with Scott, reach out to him on LinkedIn: https://www.linkedin.com/in/scotthirleman/

If you want to learn more and/or join the Data Mesh Learning Community, see here: https://datameshlearning.com/community/

If you want to be a guest or give feedback (suggestions for topics, comments, etc.), please see here

All music used this episode was found on PixaBay and was created by (including slight edits by Scott Hirleman): Lesfm, MondayHopes, SergeQuadrado, ItsWatR, Lexin_Music, and/or nevesf