Summary
This episode features an insightful conversation with Petr Janda, the CEO and founder of Synq. Petr shares his journey from being an engineer to founding Synq, emphasizing the importance of treating data systems with the same rigor as engineering systems. He discusses the challenges and solutions in data reliability, including the need for transparency and ownership in data systems. Synq's platform helps data teams manage incidents, understand data dependencies, and ensure data quality by providing insights and automation capabilities. Petr emphasizes the need for a holistic approach to data reliability, integrating data systems into broader business processes. He highlights the role of data teams in modern organizations and how Synq is empowering them to achieve this.
Announcements
Hello and welcome to the Data Engineering Podcast, the show about modern data management
Data lakes are notoriously complex. For data engineers who battle to build and scale high quality data workflows on the data lake, Starburst is an end-to-end data lakehouse platform built on Trino, the query engine Apache Iceberg was designed for, with complete support for all table formats including Apache Iceberg, Hive, and Delta Lake. Trusted by teams of all sizes, including Comcast and Doordash. Want to see Starburst in action? Go to dataengineeringpodcast.com/starburst (https://www.dataengineeringpodcast.com/starburst) and get $500 in credits to try Starburst Galaxy today, the easiest and fastest way to get started using Trino.
Your host is Tobias Macey and today I'm interviewing Petr Janda about Synq, a data reliability platform focused on leveling up data teams by supporting a culture of engineering rigor
Interview
Introduction
How did you get involved in the area of data management?
Can you describe what Synq is and the story behind it?
Data observability/reliability is a category that grew rapidly over the past ~5 years and has several vendors focused on different elements of the problem. What are the capabilities that you saw as lacking in the ecosystem which you are looking to address?
Operational/infrastructure engineers have spent the past decade honing their approach to incident management and uptime commitments. How do those concepts map to the responsibilities and workflows of data teams?
Tooling only plays a small part in SLAs and incident management. How does Synq help to support the cultural transformation that is necessary?
What does an on-call rotation for a data engineer/data platform engineer look like as compared with an application-focused team?
How does the focus on data assets/data products shift your approach to observability as compared to a table/pipeline centric approach?
With the focus on sharing ownership beyond the boundaries on the data team there is a strong correlation with data governance principles. How do you see organizations incorporating Synq into their approach to data governance/compliance?
Can you describe how Synq is designed/implemented?
How have the scope and goals of the product changed since you first started working on it?
For a team who is onboarding onto Synq, what are the steps required to get it integrated into their technology stack and workflows?
What are the types of incidents/errors that you are able to identify and alert on?
What does a typical incident/error resolution process look like with Synq?
What are the most interesting, innovative, or unexpected ways that you have seen Synq used?
What are the most interesting, unexpected, or challenging lessons that you have learned while working on Synq?
When is Synq the wrong choice?
What do you have planned for the future of Synq?
Contact Info
LinkedIn (https://www.linkedin.com/in/petr-janda/?originalSubdomain=dk)
Substack (https://substack.com/@petrjanda)
Parting Question
From your perspective, what is the biggest gap in the tooling or technology for data management today?
Closing Announcements
Thank you for listening! Don't forget to check out o