All the articles I saw by ______ on Data Contracts were quite long and not enjoyable to read. I won't say their name, but I do like their content and read it. This was a relatively quick read and got the point across well. I think the natural topic missing here is what data contracts look for small med and large teams. These flows can really slow down velocity, but without them, the alternative is way more costly!
Just another example how company culture and communication standards are pretty fundamental to making a business work!
Appreciate the note Hal! The problem with most of the content around Data Contracts, like most other topics in data, is that most content creators want to be an authority and prescribe what is correct and what isn't. As a result, the content is presented in a manner that is complex, opinionated, and hard to follow. My goal is to do the exact opposite here.
In terms of what data contracts look like, it's a topic that I do think about a lot and at some point, I hope to offer more. However, like I mentioned in the guide, a data contract is a "workflow" that can be designed in many different ways depending on how teams are structured and what tools they're comfortable with. One can easily create something using a project management tool like ClickUp or similar and integrating it with the tools used by Engineering to release updates.
Me reading this realizing "a data contract is a workflow" not a singular document 🤯 Even though I wouldn't consider myself a data specialist, I love reading these posts because I always come out with a better understanding of something I thought I was too technical for me to grasp.
You don't need to be a data specialist of any sort and you certainly don't need crazy technical chops to understand these concepts. My motivation to cover these topics is to demystify them for everyone rather than let a few gatekeep them.
All the articles I saw by ______ on Data Contracts were quite long and not enjoyable to read. I won't say their name, but I do like their content and read it. This was a relatively quick read and got the point across well. I think the natural topic missing here is what data contracts look for small med and large teams. These flows can really slow down velocity, but without them, the alternative is way more costly!
Just another example how company culture and communication standards are pretty fundamental to making a business work!
Appreciate the note Hal! The problem with most of the content around Data Contracts, like most other topics in data, is that most content creators want to be an authority and prescribe what is correct and what isn't. As a result, the content is presented in a manner that is complex, opinionated, and hard to follow. My goal is to do the exact opposite here.
In terms of what data contracts look like, it's a topic that I do think about a lot and at some point, I hope to offer more. However, like I mentioned in the guide, a data contract is a "workflow" that can be designed in many different ways depending on how teams are structured and what tools they're comfortable with. One can easily create something using a project management tool like ClickUp or similar and integrating it with the tools used by Engineering to release updates.
Me reading this realizing "a data contract is a workflow" not a singular document 🤯 Even though I wouldn't consider myself a data specialist, I love reading these posts because I always come out with a better understanding of something I thought I was too technical for me to grasp.
You don't need to be a data specialist of any sort and you certainly don't need crazy technical chops to understand these concepts. My motivation to cover these topics is to demystify them for everyone rather than let a few gatekeep them.