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 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.

Alex's LinkedIn: https://www.linkedin.com/in/alex-bross-33853837/

In this episode, Scott interviewed Alex Bross, VP of Data Engineering at Fifth Third Bank. To be clear, Alex was only representing his own views on the episode.

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

1. Start from empathy. Being able to empathize with someone will give you a far better chance of understanding their context. And analytics is really about understanding what the data shows with the applicable context.
2. There are 3 main barriers to change: logic, credibility, and emotion. Don't skip any of them.
3. Microservices can teach us a LOT about how to distribute data, especially from the people angle. When moving from the monolith with single branch development to API-driven microservices, how did people feel? How did we get them to the right place mentally and capability-wise? We should learn from that and leverage it for data mesh.
4. Don't try to do all your disruption at once. And data mesh is a disruption to the status quo. The business has a cadence, look to fit to that as best as possible.
5. When looking where to begin with something like data mesh, look at need and/or desire. Is there a team that is really struggling and needs change? Or is there a team very willing to try it out?
6. It's very difficult to have positive change with a team that is already struggling. If you are going to work with them now, make sure to be there to help instead of demand change.
7. Catalysts lower the amount of energy needed in a chemical equation. Be a catalyst for change - make it less difficult to change. Focus on that and many - most? - domains will welcome you with open arms.
8. Business users are, by and large, much more digital and data literate than historically. With a moderate amount of upskilling, they're able to leverage low code / no code platforms for scalable/repeatable data consumption.
9. If your data consumers can see the value data literacy can unlock for themselves - their careers - and their domains, they will likely be very hungry for training.
10. Failure doesn't have to mean disaster in data any more. With fast feedback loops, you can quickly adjust. Make sure people understand that - perfect is the enemy of good/done.
11. If you do a bootcamp, look for practical applications over theoretical - how can someone take this and apply it to their job, to their domain today? Actually doing something now - while training - makes it more tangible and likely to stick.
12. That practical work can have a positive impact now. Set milestones for trainees around real contributions to real use cases as they learn and gain the skills and confidence to contribute back.
13. From Allen Holub's Death of Agile: Training a team for 2 weeks slows them down for 2 weeks. Not training a team slows them down forever.
14. Starting change discussions around handing over data ownership is a big potential friction point. If you can give people the capability to own their data and the desire to learn and use their new capabilities, the ownership conversation becomes far easier.
15. It's easy to fall into the trap of trying to level up data literacy by hiring. If you want to upskill your people instead, look to the incentives of who might approve a data literacy program and align as best as you can.
16. If you want to get a data bootcamp approved, write a business case for it. People invest in what makes business sense. Make your data bootcamp make more business sense.

Alex started the conversation with an important message that often gets lost in data related discussions - let's start from empathy. Almost all people want to help each other and work together. Most will want share their context with each other so it's important to start from that. Being able to understand someone's context is crucial to sharing your own context with them.

So when thinking about data mesh, Alex thinks it makes sense to look at microservices and how people felt and behaved and learned during that transition. How did we upskill people for DevOps? What were effective patterns and what were the not-so-effective ones? And as Zhamak has discussed with her approach to data mesh, we need to decontextualize those approaches and learnings from software development and DevOps and then recontextualize them for data. Easier said than done - and not that easily said - but still, we have a lot of good and well documented history to learn from.

A focus on quarterly results is another aspect Alex feels is important to recognize - there is a real sense of urgency. But there is also a desire to not rock the boat too much - we can't do data mesh in a quarter. Combining those two aspects, we need to break data mesh work into more manageable and understandable pieces - those nice milestones. You can't do all the disruption at once as it will create chaos.

When looking for a place to get started with data mesh, Alex recommends looking for domains that either are having real business pain and pretty urgently need to change or domains that are very willing to take on change. If a team is having lots of issues, you can quickly add value and alleviate pain. If they are very willing, it obviously makes things easier. And then of course take the stories of successful change and use them to entice other teams :)

But, according to Alex, if a team is having issues with change, you should look to what's blocking them. It's easy to try to throw additional change at them but that's just more burden when they are already struggling, already underwater. Go in with empathy to help them, that will win them over. Anchor to the idea of being a catalyst for change, something that lowers the effort needed to achieve change. And look to manage feelings because it's scary to think that what you are doing as part of your role won't be relevant. Watch out for that and work with them to see it as the less valuable pieces going away, not their importance.

Alex is quite excited about some of the new data technology on the data consumption side - it's starting to feel like the tech is finally catching up to the software side in terms of tooling. Data consumers are much more digital and data literate than historically and with low code and no code offerings, with a bit of training, business users are able to actually get to and leverage data for generating insights. Note: Zhamak has said she is skeptical of low code/no code tooling but that has typically been on the data production side.

When Alex and team looked at where they were having the biggest challenges around data, it was consumability. Data consumers weren't comfortable trusting the data, couldn't really understand the data, couldn't always find the data, etc. And the data changes were centralized with the data team itself. While that is a common situation - the data team owning changes when they don't have the context of the use case or the context of the source systems - it wasn't scaling well for them.

Because of the data issues, data consumers were the hungriest for change and Alex and team decided to set up a bootcamp to level up data consumers. With more knowledge / higher data literacy, data consumers were excited to be able understand the data more, make changes on their own - thus not relying on the centralized data team -, trust the data more, etc.

Pushing the idea of finding your failures fast - and being okay with issues/failures - in data is something Alex is pushing. Perfect is the enemy of good so putting something out and then stress testing it is far better than theoretically sound but untested work. With a fast feedback loop, they were able to quickly adjust their data bootcamp when they heard learning SAS before SQL made it very difficult to understand for instance.

Alex shared some interesting learnings from the bootcamps they are doing thus far. 1) Focus on practical application and let people get their hands dirty now rather than teaching only theory. Time shouldn't only be spent in the classroom. 2) Look for those fast feedback loops. 3) Work to ensure people can take the time off necessary to actually focus on learning. It's easy to add more things onto a schedule, not put things off. 4) People really do want to learn to use data, they just aren't sure how without some structure. 5) Similar to #3, cognitive load is a very dangerous thing for bootcamps - don't overburden people. 6) Let people know they don't have to retain the exact specifics versus the knowledge on how to leverage data. You won't remember every function by heart and you shouldn't have to.

According to Alex, steering the conversation away from ownership towards getting someone excited about learning a new skill has worked well. Instead of 'I need you to do X. I guess I will train you,' instead they are starting from training new skills to unlock additional capabilities and people are far more willing to take on using those new skills. People are so excited to go unlock more value and do cool things with their new skills. And they'll layer in responsibility and ownership as those people learn more and apply their skills.

Getting to viable, valuable use cases is not hard according to Alex. He recommends just asking people what's frustrating them and then synthesize those into use cases that you can potentially address. That's actually what they are doing in the bootcamp - having people find use cases before coming into the training and then spending half their time during the bootcamp working on tackling those use cases. Getting them some real world situations to try to apply their new skills to. And if something already does exist around that use case, then they contribute by augmenting it or writing documentation or something similar. Create real-world impact milestones.

It's pretty easy to feel like you might be left behind if your team isn't framing data work the right way according to Alex. Instead of pointing out exactly where to fix or that things are changing or they need to upskill, he looks to create the environment for them to realize things aren't great instead and have the realization that they want to go fix it themselves, regardless of the issue.

Alex believes there are 3 main barriers to change: logic, credibility, and emotion. Most people try to appeal at most to two of the three and in data we often forget to manage emotion. And it's really important. And there is a heck of a lot of change involved in people's roles and work when it comes to data mesh in the long-run. As stated, it doesn't all change at once but you need to work with people to work through the change. Don't look to skimp on hitting all three.

To get a big data literacy program approved like Alex did, look to whose incentives align with it and work with them. Always start from how is this beneficial to the person who gives the green light. You can give them the choice of do we try to hire our way to data literacy or do we train and upskill our current people. It might feel faster to try to hire but it probably isn't. And it's probably way more expensive. For Alex specifically though, the team was pretty bought in so he didn't have to go to a heroic effort.

Other tidbits:

If you want to get a data bootcamp approved, write a business case for it.

Currently, Alex is encouraging a building block approach to everything. It's easy to fall into trying to scale too early but you do have to prepare for scaling if you're successful.

"Training a team for 2 weeks slows them down for 2 weeks. Not training a team slows them down forever."

Basic blocking and tackling questions, those FAQs, are probably the biggest stumbling blocks for most people in data mesh. How to get access to X or Y system. Look for patterns in those questions and try to address them through automation.

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