DeVaris Brown is the CEO and co-founder of Meroxa, a VC-backed company enabling teams of any size and level of expertise to build real-time data pipelines in minutes, not months. Prior to founding Meroxa, DeVaris was a product leader at Twitter, Heroku, VSCO, and Zendesk. When he’s not sitting in front of a computer, you can find DeVaris behind a camera capturing moments in time, at the stove whipping up the finest delicacies, or behind a set of turntables, moving a sea of people through music.
My conversation with DeVaris was recorded back in April 2022. Since then, many things have happened at Meroxa. I’d recommend checking out:
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:
If you’re new, see the podcast homepage for the most recent episodes to listen to, or browse the full guest list.
Here are the highlights from my conversation with DeVaris:
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.
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.
At Cisco, I learned that:
At Intel, I learned that:
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:
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.
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.
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:
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.
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.
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.
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.
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.
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.
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.
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.
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.
The reason why we open source Conduit was two-fold:
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.
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.
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.
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.
The way I found investors is structured.
Being targeted helped me get to yes faster and not spread myself too thin.
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.
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.
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.