Make the impact visible
Following on from yesterdays post, perhaps the key point is to make the impact of data issues visible.
Following on from yesterdays post, perhaps the key point is to make the impact of data issues visible.
Yesterday I wrote about Conway’s law and the challenges it causes in organisations where data teams are placed in a separate part of the organisation to where the data is generated.
Conway’s law asserts that the designs of systems are influenced by an organisation’s communication structure, suggesting that how teams are organised and communicate will reflect in the final product.
More than anything else, your success is determined by your communication.
That includes:
You could have the best platform, but without communication your adoption of data contracts, or any transformation, will not be a success.
The bystander effect is a social phenomenon where individuals are less likely to offer help to a victim when other people are present.
Think of the processes you have in place. Which ones are reliant on a single person?
We’re very lucky these days that it’s so easy to connect with people around the world to collaborate and share ideas. It’s this that allows us to move and improve more quickly than ever before.
After mentioning the title of my talk for apidays in Paris was “Data Contracts: The API for Data”, I had a couple of responses saying that data contracts are not APIs, and that they’re for communication and facilitating an agreement between the generators and consumers of data (or something along those lines).
Want great, practical advice on implementing data mesh, data products and data contracts?
In my weekly newsletter I share with you an original post and links to what's new and cool in the world of data mesh, data products, and data contracts.
I also include a little pun, because why not? 😅
(Don’t worry—I hate spam, too, and I’ll NEVER share your email address with anyone!)