The 98th episode of Datacast is my conversation with DeVaris Brown—the CEO and co-founder of Meroxa.

Our wide-ranging conversation touches on his childhood growing up in Chicago and hustling early while at UIUC; his wide-ranging experience doing product work at Microsoft, Zendesk, VSCO, Heroku, and Twitter; his stint working at startups in the gaming, music, and branding space; his current journey with Meroxa to build the industry-leading platform for creating real-time data applications; tactics on hiring for cultural diversity, finding design partners, and fundraising; advice on building technical communities, evaluating startup opportunities, and angel investing; resources for minorities in tech; and much more.

Please enjoy my conversation with DeVaris!

Listen to the show on (1) Spotify, (2) Google Podcasts, (3) Apple Podcasts, (4) Stitcher, (5) RadioPublic, (6) iHeartRadio, and (7) TuneIn

Key Takeaways

Here are the highlights from my conversation with DeVaris:

On Going to UIUC

My mother worked at a software consultancy during the first dot com boom. While I was there, I saw all these college-aged kids driving fancy cars and doing things that I could only imagine. I would ask them: “Hey, how did you get to this point?” And they always told me that they learned how to code and dropped out of school to make six figures. As a 14-year-old, 6-figure in the 90s was like $1 million. So my mom would give me $50 every month to buy books and teach myself how to code. Eventually, I learned how to develop in C++, ASP, etc., and worked on some cool stuff.

From there, it was off to the races. The field of software development just so enthralled me because it was constantly changing. I’ve done stuff from being the IT guy to a system engineer to a database engineer. College for me was a great stepping stone because of these world-class research opportunities. At UIUC, I was fortunate to work on these great projects because I had practical experience. I got to work on the LOVM, the Human Genome Project, one of the world’s fastest superclusters at the time, and other things for operating systems, distributed systems, security, etc. It was an intellectual thought exercise for me since I loved being around super smart people who were thinking about the future of computing.

On the other hand, I made websites for every student organization. I built my own CMS first and then charged people to get on my CMS. That is how I was paying my bills. I was always hustling to figure out a way that scratched my intellectual curiosity.

On Hustling Early

I was a huge book person. Back then, there were computer conventions. I would go there and buy my own servers and computer parts. I have been putting together computers since probably 1996 or 1997. I was the first person on my block with the Internet. I was the first person on my block with a CD burner. Once I got to school, I was wiring my own Ethernet cable. When other kids were going out and buying Jordans or clothes, I went out to buy new processors and put them into my machine.

I remember that at one point, we ended up getting DSL at my house. That changed my entire life. AT&T brought a line to our house because my mom needed it for her job. I was getting all the benefits from her doing all that stuff. Looking back at that, I was super fortunate to have somebody in the house working at a tech company. My mom did QA stuff and did not know how to code. However, I had access to a bunch of people around her that could teach me whenever I got into a spot where I did not know things.

On Interning at Intel and Cisco Systems

At Cisco, I learned that:

1. There are two approaches to software development: one is innovation, and the other is acquiring innovation by acquisition. Cisco is the latter. At a certain point, you just cannot build more products. You actually have to acquire something. As a founder-CEO now, I had one of those nuggets in my pocket.

2. Culture is extremely important. When you acquire new companies, it takes a long time to assimilate them into the acquirer’s culture. That was apparent to me because there would be all types of in-fighting and battles.

3. Not all companies that are making billions are sexy. If you ask any college graduates about the companies they would love to work for, I am pretty sure that Cisco is not at the top. But Cisco just finds a way. They hire 1,000–1,500 interns a year. That consistency of messages and the power of building a distribution channel were valuable lessons for me.

At Intel, I learned that:

1. I worked on the server side of Intel’s chip production process. We were building brand new factories all the time. That gave me the skillset to understand the supply chain on a global scale.

2. I also saw the importance of understanding local rules and regulations. We built factory plants in places like the Philippines and Costa Rica. As a young kid, I was able to visit these places and talk to people to understand the impact of these plants on them. It made me understand that whenever you go to somebody’s house, you just do not kick your feet up and relax. You ask for permission.

3. Intel also taught me the power of process. You can have the perfect process in the world, but you cannot really control the outcome. That taught me patience — optimizing the process and not worrying about the outcome.

On His Proudest Accomplishments at Microsoft

One of my proudest things at Microsoft was automating a ton of infrastructure when I was on their Global Foundation Services team. You can think of us as a centralized compute platform with separate data centers. In my first month there, there was an underwater earthquake going from the US over to Asia, and the cable suffered. Literally, all of Microsoft’s online services (Hotmail, Windows Live, etc.) were not available in Asia. We were brought in to figure out how to build a geo-distributed and replicated platform for everybody at Microsoft. That is where well-known Microsoft products like Bing and Windows Azure came from. As a system engineer building the next generation of data centers, I helped create an automation framework to automate their operations. As a result, Microsoft no longer needed hundreds of thousands of machines worldwide and the people who managed them.

After that, I felt burned out, so I took an academic evangelist job closer to Chicago. This job was dope because I had done a ton of research already. I went to different universities and taught them how to use Microsoft technologies in their research and projects. During the night, I hosted pizza parties and hackathons and gave away Xboxes. During the day, I would work with some of the best world-class researchers on all types of crazy stuff. There are two things that I was super proud of:

1. I worked with historically black colleges and universities to get them to up-level their offerings for students. I created intentional programs that trained students to get internships. Even to this day, many people in those initial cohorts are currently working in the Bay Area. They always tell me that those resources and attention back then literally changed the course of their lives.

2. I spoke at the first SXSW conference. I was working with Ohio State University at the time. Microsoft had just released the gaming framework XNA and put it on the web, the Zune phone, and the Xbox. Now people are talking about universal apps, which I was doing in 2008. Many things I had done back then became industry standard.

On Working in the Gaming and Music Space

Marmalade was right at the advent of mobile gaming. The holy grail was a gaming platform that allowed folks to write code in a single language and deploy it to multiple targets. This pulled back to my early experience writing code once and deploying to many things. I took all the learnings from Microsoft and built a developer community from scratch for Marmalade. I traveled to places like London, Japan, South Korea, Dubai, and East Africa, where mobile penetration was extremely hot. It was crazy to be at the forefront of those things because I had never done anything around the globe. I learned how to be an evangelist without the Microsoft marketing machine. By and large, Marmalade was quite successful and acquired by a Japanese telecom company. At the end of the day, learning how to do business globally was the best thing I learned from Marmalade.

Things were a bit different at Klick Push — an advertising platform for music. I am a DJ and have been in the music industry for years. Streaming was killing artists, so we were figuring out how to get more revenue for artists. Klick Push was a company I co-founded with two other folks. Our mandate was: How do we get people to listen to music for free and give artists another revenue stream without having to worry about the economics of streaming? And yeah, we figured it out.

• One of the insights I had was: Every time an artist releases an album, they essentially give you one or two promo songs you might hear on the radio. They also have a different loyalty structure with a back catalog. Instead of paying for a big giant catalog, we asked the artist to give us access to that catalog and the promotional singles. Then we targeted games. A lot of the time, it is not the new single that make great music for games. It is the back catalog stuff.

• We worked with the Mafia game. Old-school music like Frank Sinatra, Dean Martin, and Perry Como worked better for that mafia game than the newfangled stuff (Future, Kendrick Lamar, etc.). I remember getting a letter from the Dean Martin Society saying that their royalties went up a ton, just based on Klick Push taking back catalog music and marinating them into the Mafia game.

The thread of my career has been helping developers get more revenue and be more productive by on-ramping them into platforms. It has always been about helping the people who are making the thing rather than just consuming the thing.

On Being a Platform PM at Zendesk

The CTO of Zendesk heard me speak at a conference and asked me to be the person who could help them with building a developer platform. They had a Rails-based API that was undocumented at the time, but people were already hacking around the Zendesk app. The usage got big enough and caused a denial of service at some points. When I got there, we dumped all the API logs into Hadoop and ran aggregation queries to determine what endpoints to offer. That was basically data-driven development and taught me the power of what data can do for an organization.

Once we put up the API documentation, it took off like wildfire and turned Zendesk from a customer service product to a customer service platform. I was working with the golden startups in our generation, such as Uber, Twitter, Twilio, Airbnb, Groupon, etc., and helping them build customer service applications on top of our newly developed API. It was crazy to see different use cases and learn the value of customer service — being proactive about answering tickets, participating in community forums, and doing outreach to customers to learn how they were leveraging our platform. Most crucially, Zendesk taught me how to build community and leverage the power of a community to find people who are emotionally invested in our success.

Two other little things that I learned from Zendesk:

1. The power of self-serve: At the time, in order to sign up for an enterprise product, you have to talk to a salesperson and wait a couple of weeks or months to get anything done. Zendesk pioneered self-service where you could sign up with an email address/credit card and be off to the race.

2. Design as a differentiator: Zendesk pushed for a design-first culture and positioning so that people can be immediately productive. Zendesk really embraced the consumerization of IT, which are commonplace now. If you looked at the Zendesk dashboard in juxtaposition with other enterprise software at the time, it was night and day.

On Building a Technical Community

The biggest challenge of building a community is figuring out how to provide immediate utility and cut through the noise. What are you offering as a community that will be different from everybody else?

Today, every community is so cookie-cutter: a Discord or Slack channel plus maybe a user conference. You have to start diving into the ethos of your community, as to why and how somebody can engage in it. Since you are competing for mindshare amongst everybody else, you must be self-aware and dive deep into the success metric/criteria you are trying to tease out from the community. From there, you want to be very intentional about creating programs and entry points for participation that people can have. I always say: It is easy to throw a party or advertise a party, but you have to get people to come and stick around. Understanding the value that you can provide is paramount to the community.

Additionally, you want to provide a safe space for contributions at different levels. Not everybody will be the super power user that understands everything about your product, so you have to figure out how to engage people (as to where they are at) and have offerings for them (such as a sub-community). That self-awareness is always the challenge because everybody thinks if I build it, they will come. But you have to be proactive about engaging the community and figuring out why they want to engage with you versus the myriad other communities they can interact with.

On Building Creative Tools at VSCO

I went to VSCO because I wanted to figure out if I could be a consumer PM. I am also a huge VSCO user as a photographer, so the opportunity to marry my passion with my day job was extremely attractive. When I got there, we were in the midst of trying to figure out what the new version of VSCO would be. I helped install a product-driven culture there and learned how to do growth PM.

1. First of all, I had to build a data platform because VSCO did not have one. The first version of VSCO used Localytics. The analytics part was dope, but the marketing automation part was terrible. I ended up coming and replacing that product. The lesson I learned is not to be solution-driven as a product manager. My job is not to come up with all the answers. My job is to ask the right questions. I did not ask the right questions, so that project failed, to be honest.

2. Once we got the data platform in a decent direction, it was my job to figure out growth. I started to see all these people using VSCO globally, so I started building communities of photographers based on that data. I looked at the data to determine where all the top users were from a language perspective and built a graph of the top 10 places/languages of VSCO users. Then I simplified/localized the app into those top 10 different languages and released specific VSCO versions in those languages.

Once again, I learned the power of data and what it can do to unlock growth and deeper connections with customers. But I also realized I do not want to be a growth PM. I do not want to look at charts/graphs all day and figure out points of optimization. While I am decent and good at it, it just does not bring me joy at the end of the day.

On Building Software for Brand Ambassadors and Children's Shoes

Slyce.io is like Dropbox for creators and brands. Inside a brand, there are multiple personas and customer profiles you need to target. The biggest challenge we encountered was that not everybody experiences the same thing in the value chain. Let’s say I am Budweiser and want to get an influencer to post on my thing. Well, the influencer might have an agent, a manager, homies or handlers, all that type of stuff. These people have different levels of technical sophistication. For us, building a product that would address that is tough, to be honest. The thing I learned there was to differentiate who your customers and your users are and then figure out how to get people to buy your thing.

Super Heroic had a physical product — which was a shoe for kids’ playtime and an app that went along with it. We needed to figure out a way to size kids’ feet without actually shipping them a branded device. So I built an app called Kids Feet, where you can take a picture of a foot in various positions, which would be sent to our AI platform to provide a recommendation for the size of that foot. The funny story was that we got the training dataset by posting an ad on Craiglist: “Hey, we need to get pictures of feet in all different shapes, sizes, and colors.” But the pictures we got back were not of very high quality. The challenge there was learning how to blend digital and physical experiences seamlessly.

On Evaluating Startup Opportunities For Early-Career Technologists

Unless you have had entrepreneurial exposure before, I honestly suggest you work at a big company first. The reason is that you have never been exposed to the process of how a big company became big. It boggles my mind that people think unicorn startups should be revered. When I was at Microsoft, we had ten business units with over a billion dollars in revenue. I was in charge of recruiting and hiring — activities that helped me be a great founder because I had the room to try and fail at Microsoft. We recently hired a VP of Sales at Meroxa, and he told me that our recruiting and onboarding process was the best one out of all the big and small companies that he had worked at. I would love to take credit for that, but honestly, I learned that at Microsoft — which gave me a great foundation to understand how well run a company should be.

When you are young and thinking about joining or doing a startup, you do not have the context to understand aspects like customer service, recruiting/hiring, retaining/growing people, etc. Those things help the product to be more successful. I would not have learned that if I had just worked at a startup because, many times, startup founders do not even think about these things. I would recommend getting the experience at a big company first to understand how things are done at scale, and then going to work at a smaller startup where you can build the product yourself technically. At a big startup, you do not really get an opportunity to do things end-to-end. At a small startup, you must build the skills to do everything end-to-end while keeping an eye out for what this thing looks like at scale. Scale is the hammer you cannot teach people. You cannot read it in a book. You just have to experience it. That is why I think learning from a big company first is extremely important.

On Building Tools for Developers at Heroku

Building developers has always been difficult because you have to navigate their egos. Every developer with time and ability feels like they can build anything. The lesson I learned there was not about building the thing but maintaining and operating the thing. Every developer wants a Platform-as-a-Service, but they have to be the ones building it. That is why I think Kubernetes is so popular because it makes developers feel like they have control over what they are using and building. But at the end of the day, you cannot really compete with git push heroku master.

At Heroku, we prided ourselves on being intentional about the developer experience by building features like pipelines and review apps. As the lead PM for Heroku’s developer experience, I observed that many components in our product experience have now been taken out. Whole companies are being built around review apps, orchestration, chatbots, etc. — things that are now commonplace within the developer stack.

The biggest challenge that we had was getting over your developer’s ego. Do you want to build your own dev infrastructure and hire a bunch of folks to maintain and operate it? Are you a platform-as-a-service company or a FinTech company? Do you want to focus on providing the best FinTech experience or take six months/one year to build your own internal platform? Those are the topics that I continuously fought with developers while at Heroku.

On Being a Platform Engineering PM at Twitter

During my interview at Twitter, they told me that it took them six months for an engineer to be productive because of various silo things such as acquisitions and legacy tech. Twitter, at the time, processed 12 billion events per minute. They could not go to Datadog for observability or LaunchDarkly for feature flags. They had to build in-house to handle that type of scale. They were also growing 77% month over month in terms of user traffic.

My job was to come in and build an internal Heroku for Twitter. We got people down from 6 months to a few weeks and turned the product into a machine. Interestingly enough, while I was there, I got asked to build a data platform for Twitter. While at Heroku, Ali and I already had the idea of building a data platform for the future. So when I got asked by Twitter to build a data platform that allows people to build data products fast, I realized that this was the sign to start a company.

On The Founding Story of Meroxa

Ali and I were at Heroku together. He was the lead engineer on Heroku’s Kafka offerings, and I was on the Developer Experience team. We would frequently get placed on customer success journeys — basically going to a customer, hearing them complain for a couple of hours, eating lunch, and having them complain again to us. That was dope because, without that customer feedback, we would not know what people cared about. But literally, for every single conversation, we kept hearing about a better Heroku for data.

We tried to put something together and pitch it internally at Heroku, but they did not want to do that. So we started talking to potential customers (data engineers, data scientists, and data analysts) to determine whether this was a problem. Most of the folks in our target customer audience spent 80–90% of their day getting data into a format that could be used. If we can help them do that faster, they can provide business value without worrying about the actual setup. Ali and I went to a WeWork and drew what the architecture would be. That is honestly what we built today.

On Meroxa’s Architecture

Meroxa is Debezium plugged into Kafka Connect with a schema registry. What differentiates us from other products is that you do not have to worry about any infrastructure. We maintain an automated infrastructure and scale it for you. We have built a UX layer for an engineer to connect the data source to a destination easily. Then Meroxa handles the orchestration of events and data in between. If the performance of your pipeline gets degraded, we automate the scaling to ensure your pipeline still performs. If we see any destructive changes, Meroxa will automatically halt your current pipeline version and give you the ability to make some changes and replay the events again. These things are not trivial to do, so we boil them down to a CLI command. These are things I learned from Heroku and other places I have worked at. Meroxa’s big thing is making sure that people are immediately productive.

Ideally, we want standards in place to build connectors, but everybody’s APIs are different. We basically use Kafka as a speed bump and our intermediate layer to do the transformation. So once you connect to a data source, we pull out the schema and embed the DDL into the Kafka topic — which is denormalized into an intermediate format. When you do the connector on the other side of the destination, we normalize it to the format of the destination. That is something we do underneath the scene to increase developer productivity by reducing the amount of work you need to do in order to consume and leverage your data.

Another thing I realized is that a lot of products have just one source to one destination. Meroxa allows people to build very complex data constellations that have your data done in real-time in the way you need. The architectural design we have thought about is all in the service of making developers’ life easier.

On Open-Sourcing Conduit

The reason why we open source Conduit was two-fold:

1. We need to scratch our own itch. If you ask anybody that’s built anything with Kafka Connect, they are not very happy. Operating it was terrible. Getting connectors was terrible. Confluence is the only game in town for high-quality connectors. One of the things we realized from a platform perspective is that if you run anything on the JVM (which Kafka Connect runs on), you will have a world of hurt trying to maintain and monitor that. Connectors are giga-byte, so your platform might not have consistent throughput. Additionally, creating connectors was painful. The developer experience of Confluent is not very great — docs are incorrect, testing connectors is terrible, and the process of spinning up a separate cluster with Kafka Connect and Zookeeper is complex. We built the Kafka Connect alternative called Conduit, which is written in Golang — where single-binary connectors can be written in Go and transforms can be written in JavaScript.

2. If you look at the data replication and integration space, there are 1,700+ commercial and open-source products that are moving data from one place to the next. Literally, these companies do automated copy-paste, to be honest. We were getting lost in that conversation. If all people want to do is move data, let’s give them a high-quality free tool to do that. They do not need to adopt all these crazy platforms. Just use Conduit, which does not require a ton of resources and works similarly to things that run on your local machine.

Open-sourcing Conduit is a strategic move for us to say: data integration is just one part of your Holy Grail. There is so much more value that Meroxa can provide on top of that. Conduit cements us as one of the people with a differentiated voice in the real-time data transport conversation.

On Customer Use Cases

1. We have had people build real-time analytics dashboards that comply with privacy laws. They connected to a bunch of sources and needed to transform their data in ways that comply with the privacy laws around the world. We put the transformed data into a Snowflake/Redshift/PostgreSQL table that has already cleaned the data stream. Now they can point their analytics visualization tool to that table and know that it will be compliant when doing the analysis.

2. We had people migrating petabytes of data from legacy platforms (like on-premise data warehouses) to cloud-native solutions with Meroxa Connect.

3. We had people updating their fraud detection models in real-time to prevent unauthorized transactions more accurately. They had a corpus of data in their databases and used Meroxa to pull that data into a feature store and enable automated MLOps.

4. We had people using us to do real-time search indexing with e-commerce. In real-time, they would pull out inventory data in their transactional databases and use those completed transactions to update a search index on Elastic and Algolia.

5. We had people doing dynamic pricing based on demand and supply for an online grocery. They used Meroxa to incentivize drivers for surge pricing or kick-off marketing automation flows to hire more drivers for the long term.

Those are the things that our customers have been able to do with our platform. Honestly, none of those things took more than a month to implement.

On Hiring

We had to publicize our cultural values because we could not just out-pay everybody. Even though we raised a decent amount of money, we cannot compete with Netflix, Facebook, Roblox, Airbnb, etc., by out-bidding folks. We ain’t got that kind of money.

Foundationally, what are the things people care about? Am I going to be in a psychologically safe environment that allows me to execute and build relationships with customers and coworkers? Am I going to get challenging work that pushes me to learn new things? Those are things everybody wants to have — the agency and ownership of their outcomes.

For us, being intentional and transparent about that helps attract people. People want to come work at Meroxa by saying, “If I go to a big tech company, I will die by 1000 cuts every day. Maybe I can only die by 50 cuts every day at Meroxa.” That transparent view makes us tick, so we get the types of high-quality people who care about those things.

On Finding Design Partners

The data space is crowded. When you start a startup, you are already at a deficit if you just start thinking about customers and employees. I have been basically starting Meroxa for the 25 years I have been in the tech industry. Through my work ethic and reputation, I have built a network of people (which I call “the Homie Network”) of colleagues and friends who are technical and business decision-makers at these companies. I would call them up and say: “Yo man, remember when I took up for you back in the day? I just need you to give me a solid intro for a 30-minute demo to this person.” That is how we brute-force and get the initial set of lighthouse customers.

The quality of your investors can help as well. Everybody says they are value-added investors, but as a startup founder, you must put these folks to task by asking for one or two customer introductions. That is what helped us get a lot of these early design partners and early validation that our platform could solve problems in the near term and at scale.

On Fundraising

The way I found investors is structured.

1. Family, friends, and co-workers come first. Those people will not make a business decision as to if they should invest in you. They will make an emotional one because they like you.

2. The second round of people I talk to have an investor-market fit. My partners at Amplify, Root, and Drive have done many data- and developer-focused deals. I was not talking to them about why Meroxa should exist. The conversations were around differentiation and added value around real-time data.

3. The third thing is affinity stuff such as school alum group, ethnic diversity, geography, etc. I am a black male from Chicago who went to the University of Illinois. There are accelerators and VC firms that deal with those things.

4. If any of the three things above does not work, then that is when you go talk to people who have a boatload of money.

Being targeted helped me get to yes faster and not spread myself too thin.

On Angel Investing

1. Learn how to balance your time because investments take a lot of time, energy, and effort.

2. Before you start investing, understand how you can invest by budgeting properly and knowing what money you have to play with every year.

3. Be introspective and self-aware to understand what value you can bring to an early-stage company. They probably have a ton of people who are trying to give them money at any point in time, so you have to be crisp about your investor superpower. Why should they choose you versus anybody else? I am articulate and clear about that.

4. Know what you do not like. I do not invest in consumer startups. My niche is data and developer tools and platforms, thanks to my experience building developer communities in the past.

Those are the pieces of advice I would give to people about angel investing: be very self-aware, understand your superpower, know your budget, and communicate to founders why they should choose you versus anybody else.

On Issues for Minorities to Get into Tech

There are a lot of institutional and societal issues ranging from the lack of public schools to the lack of expertise in the technical realm for minorities. In many major cities, most folks do not have access to broadband Internet. If they want to learn how to code, how will they do that? We do not have the basic foundational things in place to enable the population to up-level and up-scale themselves.

We have many exposure programs, like learning how to build a website on the weekend. But there is no bridge between that and how to make a career out of it. We need more programs that can take people who are intellectually curious about the thing and give them skills and opportunities to turn that into a career.

Systemic oppression is also an issue. That is why I found a company with over 60% blacks and browns and over 50% women. I have the ability to take a chance on a person with a non-traditional background. If you look at other industries with unions and apprenticeships, you notice that the software industry is still lagging behind. Everybody is trying to figure out how to pay for a senior engineer instead of growing a junior one. That is why we have an apprenticeship program at Meroxa.

The metaphor I tend to use is: everybody wants to be the Yankees who are paying people multi-million dollar contracts, but not everybody wants to build a farm system like the Braves. Every year, the Braves have some rockstar position player or pitcher brought up and trained in-house. We just need to show more examples of these successful things so that the pipeline is always filled with more diverse, qualified talent.

On Photography and DJ

From photography and DJ, I learned how to be egoless. I can think of the most fire mix, the best turntable routine, or the most beautiful picture, but all of that is subjective. It is not about me. It is about the person I am serving. The product is never about you but about what people want. Now, what people want and what you deliver can be two different things. The famous Henry Ford quote is: “If I ask people, they would have asked for a faster horse and not a car.” But you can still serve them as to what they want, and there is license and liberty to be innovative in that.

Taking risks is another learning. There might be a picture that a person is used to getting their photo done in a certain way. Can I try another approach? Or it is 1 AM at a club, and I have a new song. Can I play it and see how it does? Being able to take the risk and using data to help you triangulate that risk also helped me to be a better product manager.

Show Notes

• (01:43) DeVaris reflected on his upbringing on the south side of Chicago and college experience at UIUC, studying Mathematics and Computer Science in the early 2000s.

• (06:46) DeVaris shared his journey of learning how to program, make computers, and dive into the Internet.

• (09:35) DeVaris recalled valuable lessons from interning at Intel and Cisco Systems.

• (15:49) DeVaris shared his proudest accomplishments during his five years at Microsoft — first as a system engineer and then as an academic developer evangelist.

• (22:06) DeVaris recalled his experience working in the gaming and music space as the Chief Developer Evangelist at Marmalade and the Chief Product Officer at Klick Push, respectively.

• (27:49) DeVaris provided his perspective on the startup acquisition process.

• (29:13) DeVaris unpacked his two years as a platform product manager at Zendesk, where he drove the adoption of the Zendesk Developer Platform for developers to create unique customer experiences.

• (35:43) DeVaris revealed the challenges of building a technical community, given his experience at Zendesk.

• (38:25) DeVaris recalled his time working for a year as the Lead Product Manager at VSCO — a startup that builds digital tools for the modern creative.

• (45:12) DeVaris went over the challenges of building software for brand ambassadors and children’s playtime, given his time as the Head of Product Management at Slyce.io and the CTO at Super Heroic.

• (49:39) DeVaris reflected on his desire to scratch his entrepreneurial itch.

• (52:00) DeVaris gave advice for early-career technologists on evaluating startup opportunities.

• (55:51) DeVaris unpacked the product challenges he encountered while building tools for developers as the Director of Product Management at Heroku.

• (58:57) DeVaris touched on his one year as the first platform engineering PM hire at Twitter.

• (01:02:18) DeVaris shared the founding story of Meroxa.

• (01:04:28) DeVaris dissected how Meroxa’s platform architecture is designed at a high level — including a change data capture service, schema registry, event streaming service, API proxy, and incident automation framework.

• (01:06:06) DeVaris explained the technical challenges associated with creating connections between data sources and destinations in real time.

• (01:08:37) DeVaris zoomed into Conduit — Meroxa’s open-source, single-binary data integration tool written in Golang that provides developer-friendly streaming data orchestration.

• (01:12:32) DeVaris highlighted a few customer use cases of Meroxa.

• (01:16:16) DeVaris shared valuable hiring lessons to attract the right people who are excited about Meroxa’s mission and fit with Meroxa’s cultural values.

• (01:18:37) DeVaris shared challenges to finding the early design partners & lighthouse customers for Meroxa.

• (01:20:24) DeVaris gave advice to founders seeking the right investors for their startups.

• (01:22:58) DeVaris gave advice to smart, driven operators looking to explore angel investing.

• (01:25:17) DeVaris discussed the remaining barriers that prevent minorities from pursuing a technology career.

• (01:30:42) DeVaris imparted lessons from photography and DJ that benefited his career in product.

• (01:32:26) Closing segment.

DeVaris’ Contact Info

• LinkedIn

• Twitter

• Website

• GitHub

Meroxa’s Resources

• Website | LinkedIn | Twitter | YouTube

• Careers | Medium Blog

• Documentation

• Conduit (GitHub | Discord | Twitter | Docs)

Mentioned Content

Articles

• “Hello World, Meroxa Style” (April 2021)

• “Streaming Your Database Changes with Change Data Capture” (Part 1 + Part 2)

• “Conduit: Streaming Data Integration for Developers” (Jan 2022)

• “Why Conduit? An Evolutionary Leap Forward for Real-Time Data Integration” (Feb 2022)

• “Hello Meroxa 2.0” (April 2022)

Resources for minorities

• Kura Labs (A free training and job placement academy for Infrastructure Computing, DevOps, and SRE for students from underserved communities)

• Free Code Camp (Learn to code — for free)

Books

1. Zero To One (by Peter Thiel)

2. The Hard Thing About Hard Things (by Ben Horowitz)

People

1. Tristan Handy (Co-Founder and CEO of dbt Labs)

2. Arjun Narayan (Co-Founder and CEO of Materialize)

3. Benn Stancil (Chief Analytics Officer at Mode Analytics)

4. Chad Sanderson (Head of Data Platform at Convoy)

Notes

My conversation with DeVaris was recorded back in April 2022. Since then, many things have happened at Meroxa. I’d recommend checking out:

1. The introduction of Meroxa 2.0 and Turbine.

2. This interview on data-driven work culture.

3. New CDC Connectors built into Conduit.

4. Meroxa is a recipient of DoD funding to help the US Space Force monitor aircraft health in real-time.

About the show

Datacast features long-form, in-depth conversations with practitioners and researchers in the data community to walk through their professional journeys and unpack the lessons learned along the way. I invite guests coming from a wide range of career paths — from scientists and analysts to founders and investors — to analyze the case for using data in the real world and extract their mental models (“the WHY and the HOW”) behind their pursuits. Hopefully, these conversations can serve as valuable tools for early-stage data professionals as they navigate their own careers in the exciting data universe.

Datacast is produced and edited by James Le. Get in touch with feedback or guest suggestions by emailing khanhle.1013@gmail.com.

Subscribe by searching for Datacast wherever you get podcasts or click one of the links below:

• Listen on Spotify

• Listen on Apple Podcasts

• Listen on Google Podcasts

If you’re new, see the podcast homepage for the most recent episodes to listen to, or browse the full guest list.