great article, Ben - but when i saw the reference to Transform, I was hoping to get your thoughts on the acquisition and what it means for dbt -- they were pretty far along with a "semantic layer" so I'm guessing alot of that gets scrapped now to make room for Transform's tech. Is that a good thing? (at least it supports joins!)
So I have no idea what their actual plans are, though I'd imagine they end up replacing most of what they've built with Transform/MetricFlow. It seems hard to imagine how they'd fit Transform's tech into the Jinja version of metrics that they built, so I'd assume they have two options:
- Start rebuilding Metricflow inside of their tech, and the acquisition was mostly about buying talent.
- Replace what they have with Metricflow.
Option 2 seems a lot more likely because I'd assume Metricflow has a much higher ceiling, that it'd be really hard rework theirs to be like Transforms, and that an acquisition would be an expensive way to do option 1. Plus, if the Metricflow paradigm is the better one long term, dbt's semantic layer is still early enough that they could make a big change to it. In two years, that's going to be much harder.
thanks, Benn! Since you are called out in Tristan's announcement post ( https://www.getdbt.com/blog/dbt-acquisition-transform/ ) as being an inspiration, I was looking forward to hearing your thoughts. Although, I disagree that "What neither of these posts explicitly call out is that these ideas were drawing on work being done by the Transform team." You were calling out the Minerva work at AirBnb back then, which looks like the impetus for Transform. (Side question, since you are much more of a start up expert than I, how do folks keep taking such well developed tech out of their companies where they developed it and cashing out on it just a year or so later? When I worked at AT&T, they would have sued my a** into the ground if I commercialized work I did there and sold to dbt for big $$$)
Fair enough - I was thinking about writing something about BI-ish stuff next week, and this might be a good motivation to do it, since that ties in to the whole semantic layer thing pretty tightly.
On the startup-from-developed-tech thing, I think it depends a lot on the "host" company. For things like Transform, Airbnb isn't ever going to go out and build some data tool, and they typically don't care that much if someone commercializes something that won't affect their business. They could probably sue to get some sort of ownership of the startup, but 1) it's probably not worth the legal trouble since most startups end up being busts, 2) that'd probably kill the startup because people wouldn't found it if they got sued, and 3) it's a little bit against the cultural norms in Silicon Valley. And there's some real social cost in hiring, etc if you're that company that's known as the one who sues everyone.
Beyond that, most startups are some form of "inspired by" internal tools, where the legal question is probably a bit murky. Transform probably didn't take any actual code from Airbnb; they instead took the idea about a metric store, and the expertise they learned about how to build one. Does Airbnb own that? It's hard to say, but (I think) CA law is pretty favorable to the startup, especially if there's no patents or anything in place (which internal tools wouldn't have).
Hey, Benn, thanks for the generous amount of time you gave me today - your perspective is very appreciated. That makes total sense and is a great overview of how things like this actually work in the valley (AT&T *is* pretty old school! lol). I did spend some time looking at Minerva and comparing it to Transform's MetricFlow -- it's not an exact copy but given one of the founders was a PM on Minerva it seems, it definitely feels on the "edge."
The valley is a funny place -- if my employer paid me to work on an internal tool, I'm not sure I would feel right about commercializing it without at least giving them some equity (even if alot of the code was new, there is no way that some AirBnb IP didn't slip in, unintentional or not). Remember the "Netflix prize"? I got the meet the team at AT&T that shared the winning entry and they had no bitterness that AT&T took their share of the $1M prize money. His perspective was that AT&T paid him a healthy salary to work on interesting things, and that was reward enough.
Perhaps I've been influenced too much by academia, but I have trouble relating to what the Transform team "won" by getting acquired. Now they have a boss again, and likely will lose control of the product incrementally over time. (anyone remember the FriendFeed story?).
On the other hand, sometimes the team has no choice but to leave. Check out the Trinio story for how FB pretty much forced their hand.
Anyway, I'm a huge fan of dbt so can't wait to hear more of your thoughts on this acquisition. (As a side note, I've always appreciate how pro-SQL Mode has been - hope things are going well there - it's a great product.)
Yeah, I guess the culture here goes a bit of the other way, where so much of the ecosystem is built around people starting companies that everything biases in that direction. And if people handed over a lot of their companies to prior employers, it'd be a pretty big hinderance to that.
As for Transform, I have no idea why they decided to sell, though I know folks who've done it for a variety of reasons. Sometimes the acquisition lets them keep doing what they're doing, with a lot more resources; sometimes people really get excited about the combined product; sometimes the company needs a bailout; sometimes companies just get tired. So, there are definitely downsides about control and things like that, but there are a lot of reasons why it can make sense.
(And appreciate that about Mode. That was one of the places we got lucky - the market really broke towards SQL)
Thought-provoking as always. My first reaction is that “self-authorship is a luxury of the rich.” It could well be that in this stage of the market, the only rational strategy for a venture-backed data startup is to blindly pursue customers and hope for the best. The outcome is likely to be poor, but at least we as an ecosystem keep random-searching the space of customer desire.
At customer capture is still preferable to vendor capture, like we had in the 1990s with Microsoft and Oracle. :-)
Still, I’d like to believe your article is timely, in that NOW is precisely when we should stop desperately raiding garbage cans for food and start fencing in our own farms.
Perhaps 2023 is the year we finally have enough data -- and self-awareness -- to pick the exact right problem to fall in love with, and bet our startup on.
Fair, though I don't think this means don't listen to customers at all. It's more that I think you've got to be really firm on who you want to be, which customers you want to listen to, and who you become if you listen to them. Evolution and iteration is fine (and probably necessary), but unintentional evolution is dangerous.
great article, Ben - but when i saw the reference to Transform, I was hoping to get your thoughts on the acquisition and what it means for dbt -- they were pretty far along with a "semantic layer" so I'm guessing alot of that gets scrapped now to make room for Transform's tech. Is that a good thing? (at least it supports joins!)
So I have no idea what their actual plans are, though I'd imagine they end up replacing most of what they've built with Transform/MetricFlow. It seems hard to imagine how they'd fit Transform's tech into the Jinja version of metrics that they built, so I'd assume they have two options:
- Start rebuilding Metricflow inside of their tech, and the acquisition was mostly about buying talent.
- Replace what they have with Metricflow.
Option 2 seems a lot more likely because I'd assume Metricflow has a much higher ceiling, that it'd be really hard rework theirs to be like Transforms, and that an acquisition would be an expensive way to do option 1. Plus, if the Metricflow paradigm is the better one long term, dbt's semantic layer is still early enough that they could make a big change to it. In two years, that's going to be much harder.
thanks, Benn! Since you are called out in Tristan's announcement post ( https://www.getdbt.com/blog/dbt-acquisition-transform/ ) as being an inspiration, I was looking forward to hearing your thoughts. Although, I disagree that "What neither of these posts explicitly call out is that these ideas were drawing on work being done by the Transform team." You were calling out the Minerva work at AirBnb back then, which looks like the impetus for Transform. (Side question, since you are much more of a start up expert than I, how do folks keep taking such well developed tech out of their companies where they developed it and cashing out on it just a year or so later? When I worked at AT&T, they would have sued my a** into the ground if I commercialized work I did there and sold to dbt for big $$$)
Fair enough - I was thinking about writing something about BI-ish stuff next week, and this might be a good motivation to do it, since that ties in to the whole semantic layer thing pretty tightly.
On the startup-from-developed-tech thing, I think it depends a lot on the "host" company. For things like Transform, Airbnb isn't ever going to go out and build some data tool, and they typically don't care that much if someone commercializes something that won't affect their business. They could probably sue to get some sort of ownership of the startup, but 1) it's probably not worth the legal trouble since most startups end up being busts, 2) that'd probably kill the startup because people wouldn't found it if they got sued, and 3) it's a little bit against the cultural norms in Silicon Valley. And there's some real social cost in hiring, etc if you're that company that's known as the one who sues everyone.
Beyond that, most startups are some form of "inspired by" internal tools, where the legal question is probably a bit murky. Transform probably didn't take any actual code from Airbnb; they instead took the idea about a metric store, and the expertise they learned about how to build one. Does Airbnb own that? It's hard to say, but (I think) CA law is pretty favorable to the startup, especially if there's no patents or anything in place (which internal tools wouldn't have).
Hey, Benn, thanks for the generous amount of time you gave me today - your perspective is very appreciated. That makes total sense and is a great overview of how things like this actually work in the valley (AT&T *is* pretty old school! lol). I did spend some time looking at Minerva and comparing it to Transform's MetricFlow -- it's not an exact copy but given one of the founders was a PM on Minerva it seems, it definitely feels on the "edge."
The valley is a funny place -- if my employer paid me to work on an internal tool, I'm not sure I would feel right about commercializing it without at least giving them some equity (even if alot of the code was new, there is no way that some AirBnb IP didn't slip in, unintentional or not). Remember the "Netflix prize"? I got the meet the team at AT&T that shared the winning entry and they had no bitterness that AT&T took their share of the $1M prize money. His perspective was that AT&T paid him a healthy salary to work on interesting things, and that was reward enough.
Perhaps I've been influenced too much by academia, but I have trouble relating to what the Transform team "won" by getting acquired. Now they have a boss again, and likely will lose control of the product incrementally over time. (anyone remember the FriendFeed story?).
On the other hand, sometimes the team has no choice but to leave. Check out the Trinio story for how FB pretty much forced their hand.
Anyway, I'm a huge fan of dbt so can't wait to hear more of your thoughts on this acquisition. (As a side note, I've always appreciate how pro-SQL Mode has been - hope things are going well there - it's a great product.)
Yeah, I guess the culture here goes a bit of the other way, where so much of the ecosystem is built around people starting companies that everything biases in that direction. And if people handed over a lot of their companies to prior employers, it'd be a pretty big hinderance to that.
As for Transform, I have no idea why they decided to sell, though I know folks who've done it for a variety of reasons. Sometimes the acquisition lets them keep doing what they're doing, with a lot more resources; sometimes people really get excited about the combined product; sometimes the company needs a bailout; sometimes companies just get tired. So, there are definitely downsides about control and things like that, but there are a lot of reasons why it can make sense.
(And appreciate that about Mode. That was one of the places we got lucky - the market really broke towards SQL)
Thought-provoking as always. My first reaction is that “self-authorship is a luxury of the rich.” It could well be that in this stage of the market, the only rational strategy for a venture-backed data startup is to blindly pursue customers and hope for the best. The outcome is likely to be poor, but at least we as an ecosystem keep random-searching the space of customer desire.
At customer capture is still preferable to vendor capture, like we had in the 1990s with Microsoft and Oracle. :-)
Still, I’d like to believe your article is timely, in that NOW is precisely when we should stop desperately raiding garbage cans for food and start fencing in our own farms.
Perhaps 2023 is the year we finally have enough data -- and self-awareness -- to pick the exact right problem to fall in love with, and bet our startup on.
Maybe even mine. Thanks.
Fair, though I don't think this means don't listen to customers at all. It's more that I think you've got to be really firm on who you want to be, which customers you want to listen to, and who you become if you listen to them. Evolution and iteration is fine (and probably necessary), but unintentional evolution is dangerous.