The Pragmatic Engineer
00:25:47 · Gergely Orosz, Luca Ferrari
[00:25:47] S0: What was this first acquisition? [00:25:50] S1: So that one was a, an app, an iOS app to personalize your keyboard. Very simple. [00:25:59] S0: I [00:26:00] S1: believe we bought it from a one man show developer from somewhere in the world. Remember frankly, where and we tried to improve it, ultimately turning that $10,000 investment into say 20,000. And, you know, and then 20,000 gets you a slightly bigger, more promising acquisition. And if you're good, you turn it into 40, then the compounding is a pretty powerful force over time exponentially. And so you fast forward around ten years later, we're now acquiring companies, hundreds of millions of dollars in price. We've invested more than $1,000,000,000 in acquisitions, some hundreds in of millions of research and development. But yeah, it's been a pretty steady paced journey since then. [00:26:50] S0: And what was like a bigger milestone? Like I imagine clearly Evernote is one very well known from externally, but from internally, like you said, it started off small, you started growing, but were there any kind of notable milestones where you really kind of like stepped up a level? [00:27:07] S1: I think one that's worth mentioning is when we acquired Splice, a mobile video editor from GoPro. That was the first time we acquired an asset from a large structured seller as opposed to single individual developers or small teams around the world.
00:27:07 · Luca Ferrari, Gergely Orosz
[00:27:07] S1: I think one that's worth mentioning is when we acquired Splice, a mobile video editor from GoPro. That was the first time we acquired an asset from a large structured seller as opposed to single individual developers or small teams around the world. [00:27:27] S0: Jumping over to Evernote, it's one of the well known... Most well known note taking apps. And it's one of the first times that I personally heard about you and you made it into into mainstream news. Can you tell us about how this acquisition happened from your point of view?
00:27:42 · Luca Ferrari
[00:27:42] S1: The short of it is we came to know that Evernote could potentially be acquired around late twenty twenty two. We jumped at the opportunity, the process was pretty fast, I would say probably around a couple of months, and it was basically all done by late twenty twenty two, then you always have to go through antitrust clearance periods and so on and so forth. So the acquisition actually closed very early January twenty twenty three and we jumped into the organization. And the way we operate is we spend the first several weeks, sometimes a couple of months in fully fledged learning mode where some of the team members at Bending Spoons, particularly the most experienced ones, join at all levels management, individual contributor in different teams and just try to absorb as much information as they can. Talk to almost everybody, look into almost every line of code or module, read many documents, run analysis. And at the end of this process we try to come up with a vision. And the vision spans the gamut: organization, technology, user experience, monetization, marketing, everything. We come up with a vision of the best version of that business we can come up with, with a long term view. Something there's a misconception about sometimes, we acquire these companies to own and operate them forever. So we think with the longest time frame we can. And so that vision embeds that sort of long term thinking in it. And then the second phase starts, which is where we try to close the gap between the status quo and that vision across the board as quickly and as fully as we can.
00:29:35 · Gergely Orosz
[00:29:35] S0: When you acquired Evernote, like what kind of tech stack was it running on and what were some tech changes that you decided to make and why did you do it? I mean, I assume it's always an exciting opportunity to look at a pretty established product and then see, you know, like what are the bottlenecks and how can we improve it.
00:29:56 · Francesco Mancone
[00:29:56] S3: So the first thing we noticed when we acquired Evernote, I think that's what was the main cause of all the other issues that we identified after all the things we could improve, was that, of course, it was a very old code base with many years of tech that accumulated. But one peculiarity was that it was migrated at a certain point from the more traditional data, let's say, bare metal servers to the cloud space. And that migration was, of course, supported by the cloud provider. It was made in a one on one fashion, meaning that it wasn't really happening. Evernote didn't, let's say, reshape the infrastructure or the architecture, making it cloud native. And as a result of this, we found ourselves with a monolith, a huge one, with a Java 11 monolith. And it was running on virtual machines on Google Cloud, they were sort of manually provisioned. Were seven fifty machines, virtual machines. All of them were manually provisioned and users' data were sharded among all of these machines. That sharding was not even after thorough analysis, doesn't even have as proven to be even, meaning that certain machines have heavier loader than others, significantly heavier, and sometimes that caused also a lot of interventions, a lot of maintenance. We had to realize that on calls were actually very needed. Know, we run several products. What we do generally, we try to make them reliable enough to not need an on call program. That's one of the first objectives of the engineering team building the technology, is that we want to make it reliable enough to make the on call an exception. On Evernote, we found Awesome.
00:32:09 · Gergely Orosz, Luca Ferrari
[00:32:09] S0: So just to confirm, like, for for the products that you you operate, like, this is kind of like a a core principle of of, like, on calls should not be, let's say, heavy or or you should not worry when you're going on call that you're gonna be flooded with notifications and alerts. [00:32:24] S1: Oh, not even that. I think it's even more than that, Gergely. We actually try not to have an on call scheme at all on many of our products and technologies. So the goal is to Yeah, but I think, yes, however, knowing that you don't have that fallback, as a software engineer, as an infrastructure engineer, really breeds that, you know, have I thought about the corner cases? Have I really looked at this and made sure it's really robust, it's really sharply engineered? If you know that the on call is there, you know, it's not the same. You know that a lack of foresight, there's a safety net. So we try to reserve on call programs only where if an issue occurs, the damage is truly staggering, or if we are not comfortable with the state of the infrastructure and code base as yet. [00:33:18] S0: I love the different thinking because I think in the industry, it's kind of a given like, look, we have... We generate a lot of revenue, we can afford to do on call and, know, we'll pay engineers a bit of extra. Like, we'll we'll give them either a bonus for the week. A lot of companies operate like this. So I really like how you actually just said, okay, let's let's do it differently. Let's let's let's take from this principle.