Latest / The Pragmatic Engineer / Twisting the rules of building software: Bending Spoons (the team behind Evernote)

Transcript

Twisting the rules of building software: Bending Spoons (the team behind Evernote) · The Pragmatic Engineer

• 0:00
  SPEAKER_0: Just to confirm for the products that you operate.
• 0:02
  SPEAKER_0: This is kind of like a core principle.
• 0:04
  SPEAKER_0: On-call should not be heavy or you should not worry when you're going on-call that you're going to be flooded with notifications and alerts.
• 0:10
  SPEAKER_1: We actually try not to have an on-call scheme at all on many of our products and technologies.
• 0:15
  SPEAKER_1: However, knowing that you don't have that fallback as a software engineer, as an infrastructure engineer really breeds that, have I thought about the corner cases?
• 0:24
  SPEAKER_1: Have I really looked at this and made sure it's really robust, it's really sharply engineered?
• 0:29
  SPEAKER_1: If you know that the on-call is there, it's not the same.
• 0:32
  SPEAKER_1: Raising capital in Italy was borderline possible.
• 0:35
  SPEAKER_1: Our model is so unusual no VC would be interested in investing and I believe that gave us an edge over some of the competitors.
• 0:43
  SPEAKER_0: I do not frequently hear loans from traditional banks with startups.
• 0:47
  SPEAKER_0: Evernote and Meetup are two products many people have heard about, but what about the company called Bending Spoons?
• 0:53
  SPEAKER_0: Bending Spoons is an eleven-year-old startup headquartered in Milan, Italy, and they own and operate both Evernote, Meetup and a bunch of other products.
• 1:01
  SPEAKER_0: Bending Spoons is a fascinating company.
• 1:03
  SPEAKER_0: They started out as five developers building small mobile apps and have now grown to about 450 people surpassing $700 million in annual revenue.
• 1:12
  SPEAKER_0: What surprised me to learn about this company is that they've been profitable every single year and how they spent more than $1 billion in acquisitions.
• 1:21
  SPEAKER_0: It's rare to hear about a European company buying Silicon Valley companies, and I was excited to learn more straight from the source.
• 1:27
  SPEAKER_0: In today's episode we do a deep dive on how the Evernote acquisition happened and why the complete backend needed to be rewritten.
• 1:33
  SPEAKER_0: We look into how Bending Spoons typically operates and how it organizes product and platform teams.
• 1:38
  SPEAKER_0: But we'll start with the elephant in the room addressing a pretty controversial perception on how Bending Spoons acquires companies.
• 1:44
  SPEAKER_0: But then let's go a good chunk of the staff when they take over products, we'll see that the reality is a lot more gray rather than black and white in this case.
• 1:52
  SPEAKER_0: So, let's jump in.
• 1:52
  SPEAKER_0: Hello everyone.
• 1:53
  SPEAKER_0: Today I'm happy to have the Bending Spoons team here with me.
• 1:56
  SPEAKER_0: We have Luca, Francesco and Federico.
• 1:59
  SPEAKER_0: Luca is the co-founder and CEO of the company, Francesco is the CTO and Federico is a product lead at Bending Spoons.
• 2:05
  SPEAKER_0: Welcome to the podcast.
• 2:07
  SPEAKER_1: Thank you.
• 2:07
  SPEAKER_2: Thank you.
• 2:08
  SPEAKER_1: Thank you very much, it's nice being here.
• 2:10
  SPEAKER_0: So, I have to admit, even a few months ago, I had not heard of Bending Spoons.
• 2:15
  SPEAKER_0: At the same time, things that I have heard about and used are Evernote, Meetup.com, which I knew were Silicon Valley companies, and I also heard they got acquired by a different company and this turned out to be Bending Spoons.
• 2:30
  SPEAKER_0: It was actually Evernote acquisition that I first connected the two together.
• 2:37
  SPEAKER_0: But the interesting thing is that Bending Spoons is probably the most single sought after company and the tech company in Italy.
• 2:44
  SPEAKER_0: When I first tweeted about Bending Spoons and how I discovered the interesting things that you're doing, I had Italian developers ping me and telling me, oh, I actually applied to Bending Spoons.
• 2:54
  SPEAKER_0: They're the hottest place to be in Italy.
• 2:57
  SPEAKER_0: And I asked them, when did you apply?
• 2:58
  SPEAKER_0: And they told me, oh, it was like four or five years ago.
• 3:01
  SPEAKER_0: So, they already knew that something really different and exciting was happening at the company.
• 3:08
  SPEAKER_0: The first time you came up was when you acquired Evernote, but you operate other apps and products.
• 3:14
  SPEAKER_0: Which ones are you known for?
• 3:15
  SPEAKER_1: You correctly mentioned Evernote as one of the most well-known businesses we acquired.
• 3:21
  SPEAKER_1: Meetup too.
• 3:22
  SPEAKER_1: We have acquired Mosaic, which is a collection of mobile products from Interactive Corporation, and we've acquired Hopin and StreamYard, possibly the most popular recording and live-streaming suite of features of product in the world.
• 3:44
  SPEAKER_1: More recently Issuu for digital publishing and WeTransfer for digital file storage and transfer.
• 3:51
  SPEAKER_1: We also own and operate Remini, which is an AI based photo enhancer and generator, one of the top two or three most used generative AI products in the world with over a hundred million a month active users.
• 4:03
  SPEAKER_1: But we have been doing this for a decade and we have acquired dozens of businesses.
• 4:07
  SPEAKER_1: These are just the most well-known ones.
• 4:11
  SPEAKER_0: This episode is brought to you by the Enterprise Ready Conference, one day event NSF bringing together product and engineering leader shaping the future of Enterprise SaaS.
• 4:20
  SPEAKER_0: The event features a curated list of speakers with direct experience building for the enterprise.
• 4:24
  SPEAKER_0: Speakers include people from OpenAI, Vanta, Checker, Dropbox, and Canva.
• 4:30
  SPEAKER_0: Topics include advanced identity management, compliance, encryption, and logging.
• 4:34
  SPEAKER_0: Essentially a complex features that most enterprise customers require.
• 4:38
  SPEAKER_0: If you're a founder, exec, PM or engineer tasked with the enterprise roadmap, this conference is for you.
• 4:44
  SPEAKER_0: You'll get details, insights from industry leaders that have years of experience navigating the same challenges you face today.
• 4:50
  SPEAKER_0: And best of all, it's completely free since it's hosted by WorkOS.
• 4:54
  SPEAKER_0: Spots are filling up quickly.
• 4:56
  SPEAKER_0: Make sure to request an invite at enterpriseready.com.
• 4:59
  SPEAKER_0: That is enterpriseready.com.
• 5:03
  SPEAKER_0: This episode is brought to you by DX, a platform that helps organizations measure and improve developer productivity.
• 5:10
  SPEAKER_0: The DX team includes notable researchers behind the frameworks like DevEx and Space.
• 5:15
  SPEAKER_0: So, they're constantly asked by leaders, what metrics should we use to measure developer productivity?
• 5:20
  SPEAKER_0: To help simplify the landscape DX just recently published a DX Core 4, a unified framework for measuring developer productivity that encapsulates Dora, Space and DevEx.
• 5:31
  SPEAKER_0: The DX Core 4 includes four dimensions including speed, effectiveness and quality that provide a focus set of metrics that help track productivity at all levels of the organization.
• 5:41
  SPEAKER_0: You can learn more about the DX Core 4 and how it's being used in companies like Dropbox, Etsy, Versa, and Pfizer at getdx.com/corefour.
• 5:50
  SPEAKER_0: Again, that's getdx.com/corefour.
• 5:56
  SPEAKER_0: I'd like to address an elephant in the room in terms of the perception of a Bending Spoons.
• 6:02
  SPEAKER_0: So, you've already touched on this, but I just really want to double click on it, because from the outside when you search for Bending Spoons, often things in the press will come up.
• 6:12
  SPEAKER_0: Oh, they acquired Evernote and then they reduced the original team.
• 6:16
  SPEAKER_0: Oh, they acquired Meetup and then they reduced the original team.
• 6:19
  SPEAKER_0: Oh, they acquired this other company and they did that.
• 6:22
  SPEAKER_0: So, there's this real perception of like, oh, Bending Spoons buys a company that is struggling or that wants to be sold and they just reduce the team and then they take it from there.
• 6:32
  SPEAKER_0: And this is just one side of the story, obviously this is the external, I guess the hard numbers or the things that make the rounds and make people pay attention and form opinions.
• 6:44
  SPEAKER_0: How do acquisitions really look like from the inside?
• 6:47
  SPEAKER_0: What is your approach?
• 6:48
  SPEAKER_0: Because I'm going to just assume that it's likely not like we're going to cross off ... that doesn't make sense to acquire a company when it sounds you want to make more of this, how do you approach it?
• 7:02
  SPEAKER_1: Yeah, definitely.
• 7:03
  SPEAKER_1: I think given that they require companies to own and operate them forever, and given that we do so with our own money, we're not a fund.
• 7:14
  SPEAKER_1: We're not raising capital from investors to buy companies.
• 7:16
  SPEAKER_1: We're using our own money.
• 7:19
  SPEAKER_1: Pretty much all of my worth is in Bending Spoons, and so is the case for most people here, including Francesco and Federico.
• 7:27
  SPEAKER_1: We would want to do the best we can with every single acquisition with a long-term view, which is what we do.
• 7:33
  SPEAKER_1: The way we approach it, I described earlier a little bit, we will first of all go through a phase of learning.
• 7:40
  SPEAKER_1: When you are on the outside of an acquisition of a company, you don't get to see a lot of stuff you need to be inside.
• 7:46
  SPEAKER_1: So, once you're inside, you get to see enough that you can decide whether you want to acquire it or not and at what price, but you don't know enough to be able to decide how to operate it well.
• 7:56
  SPEAKER_1: And so we go through a learning phase and we really look at the details.
• 8:01
  SPEAKER_1: We go hands-on very deep across the board.
• 8:05
  SPEAKER_1: And the more we do this, the better we become at recognizing patterns.
• 8:09
  SPEAKER_1: And so we get faster, more accurate, but after generally a few weeks, maybe a couple of months depending on the complexity, we find we form a pretty clear opinion and develop a pretty clear vision as to what we want to do with the product, the technology, the monetization, the organization and so on and so forth.
• 8:25
  SPEAKER_1: And then as I said, we try to close that gap between the status quo and that vision as quickly as we can.
• 8:31
  SPEAKER_1: Often there is a gap in how we want the organization to be structured.
• 8:35
  SPEAKER_1: Often we want it to be a much smaller organization where people have a much more autonomy and ownership of projects where we do not pursue projects that are not really likely to move the needle in a major way.
• 8:48
  SPEAKER_1: So, massive focus, massive leanness and autonomy.
• 8:52
  SPEAKER_1: Making that change, and I'm talking again, particularly the organization such as a layoff sucks.
• 8:59
  SPEAKER_1: It sucks primarily for the people who are let go, of course.
• 9:04
  SPEAKER_1: It's also not enjoyable for those of us who implement it and naturally we have empathy for those people.
• 9:13
  SPEAKER_1: We try to do it in a way that's as supportive financially, logistically, emotionally as we can.
• 9:21
  SPEAKER_1: But it still sucks.
• 9:22
  SPEAKER_1: There's no way around it.
• 9:24
  SPEAKER_1: However, I will say if we believe that on the other side of that painful transition, the company is much better positioned to kick ass for five or 10 years down the line, if getting there requires making unpopular or painful decisions, we will make them.
• 9:42
  SPEAKER_1: And we understand we'll take flack for that in the press and it's fine.
• 9:48
  SPEAKER_1: I mean there's a reason for it and it's okay, but it's certainly nowhere near representative of the much bigger effort and the much bigger vision we have for all of these businesses and a project like Evernote I think represents our trajectory well.
• 10:05
  SPEAKER_0: My first reaction was like, oh, this is terrible.
• 10:07
  SPEAKER_0: A company buys another company and then lets a bunch of people go, how terrible, let's say with the Evernote.
• 10:14
  SPEAKER_0: But then I was kind of thinking a little bit further and thought like, hold on.
• 10:17
  SPEAKER_0: I've read all these articles about Evernote, how again, this might not represent, but what I understood, how they struggled to make a profit, how they struggled to operate, how they were burning money, how they tried this, how they tried that.
• 10:29
  SPEAKER_0: In this case, this was clearly a struggling company and to take that company to a successful company, clearly if it would've been easy, it would've clearly been done.
• 10:38
  SPEAKER_0: And when I look through a lot of your acquisitions, some of them, they are companies that are not necessarily doing well or they want to sell for some reason.
• 10:45
  SPEAKER_0: I mean, if they would've been doing amazing, they probably would've not sell.
• 10:48
  SPEAKER_0: I don't know, dude, it sounds like Bending Spoons does not want to sell right now.
• 10:53
  SPEAKER_0: So, if you're successful-
• 10:55
  SPEAKER_1: We didn't steal any companies.
• 10:57
  SPEAKER_0: Exactly.
• 10:59
  SPEAKER_1: We didn't steal them.
• 10:59
  SPEAKER_1: I promise.
• 11:00
  SPEAKER_0: These are companies that are actively looking for a buyer for some reason, either because they're struggling or not.
• 11:06
  SPEAKER_0: And it sounds like they've been through what are easy solutions and what I thought about this, well, I mean in my view, a company that goes through a painful transition and then becomes successful in the long term or a product is probably better than one that slowly dies.
• 11:21
  SPEAKER_0: And we've seen recently a lot of startups that just shut down and after they couldn't find anything.
• 11:26
  SPEAKER_0: So, that's just ... it's not all black and white, right?
• 11:33
  SPEAKER_1: No, and I think we have been dealing with this criticism for a while now, and I think I understand it better than I did a couple years ago.
• 11:40
  SPEAKER_1: I will say this, to simplify, the world seems to be divided into two camps.
• 11:47
  SPEAKER_1: Some people think ultimately that as long as a business can survive, it should not be made more thriving, more successful if doing so means going through a painful decision such as a layoff.
• 12:02
  SPEAKER_1: And these people think that bringing the business from a six out of 10 to a nine out of 10, if it means going through a painful decision such as a layoff, it's evil.
• 12:14
  SPEAKER_1: And then there are people who think that as long as you act empathetically and supportively, you should try to run a business in the most effective, efficient way you can.
• 12:23
  SPEAKER_1: And that if doing so means going through hard decision like a layoff, you should do it, again, trying to be super supportive financially and logistically and emotionally, but still do it.
• 12:33
  SPEAKER_1: Of course, the latter view is more free market view.
• 12:37
  SPEAKER_1: The former, you can give it a name.
• 12:41
  SPEAKER_1: We belong in the latter camp, but if you belong in the former camp, there is nothing I can say to convince you.
• 12:47
  SPEAKER_1: You will believe we're evil and call evil.
• 12:50
  SPEAKER_1: There is a difference in the underlying deep assumptions of what one should strive to do.
• 12:55
  SPEAKER_1: But within the latter camp, we try to do things the right way to build the best products we can to build the best organizations we can to treat anybody in the way out as well as we can, to monetize a product as efficiently as we can and be rational and scientific about it.
• 13:13
  SPEAKER_1: So, that's who we are.
• 13:15
  SPEAKER_1: And if someone sees things more in this way, then I think they'll have an incredible experience working with us, partnering with us in any capacity.
• 13:23
  SPEAKER_1: If someone sees the world in the former way, we fully respect that.
• 13:26
  SPEAKER_1: It's almost call it a political view in a way, and it's totally fine way of looking at the world, but then they will never like us.
• 13:33
  SPEAKER_1: There's nothing we can say to change their minds.
• 13:35
  SPEAKER_0: Yeah, I respect that.
• 13:36
  SPEAKER_0: I think as long as you're open with what your values are, what you're doing, and I think for example, Netflix is a very good example.
• 13:42
  SPEAKER_0: They also are known to a very harsh culture.
• 13:45
  SPEAKER_0: They have the keeper tests regularly challenging people, but they publish this.
• 13:50
  SPEAKER_0: And again, it's like they have this culture, there's pros, there's cons, and I think it's nice when you're clear about what you stand for and explain because again, every company will be different.
• 14:00
  SPEAKER_0: It's just some companies are a bit harder to figure out because they don't talk about this.
• 14:04
  SPEAKER_0: So, again, the fact that you're actually talking here, this is actually helpful.
• 14:09
  SPEAKER_1: We are very transparent about it.
• 14:11
  SPEAKER_1: We share a lot of stuff on our website including policies and whatnot.
• 14:15
  SPEAKER_1: When we extend an offer to an applicant, we send a document called Controversial Principles where we include seven or eight values or principles we implement at the company that some people may consider controversial.
• 14:32
  SPEAKER_1: One being that we are uncompromising on excellence, which means that we want each position staffed with a performer that's at least in the vicinity of the best possible performer we could hire.
• 14:43
  SPEAKER_1: So, we see the company in the same way as you would see an ambitious basketball team or football team.
• 14:51
  SPEAKER_1: We really want to make sure each position is staffed with an outstanding performer and if it means demoting someone or letting someone go, we will do so.
• 15:01
  SPEAKER_1: We tell you upfront, we're super honest about it.
• 15:04
  SPEAKER_1: And again, someone who's seeking a place where everybody's trying to be absolutely great professionally will have a blast because talent density is sky-high.
• 15:17
  SPEAKER_1: Someone who's not seeking that sort of one foot outside of your comfort zone all the time place will not like it.
• 15:25
  SPEAKER_1: And I think both views are absolutely respectable and understandable.
• 15:29
  SPEAKER_1: You just need to be honest about who you are and then it can be a match made in heaven.
• 15:35
  SPEAKER_1: By the way, it's good, working at Bending Spoons, we must be doing something right, because we have a level of unwanted team member churn that's to my knowledge, unheard of in the industry.
• 15:45
  SPEAKER_1: About 1% per year.
• 15:46
  SPEAKER_0: 1% per year churn.
• 15:48
  SPEAKER_1: Yeah, unwanted churn.
• 15:49
  SPEAKER_1: And if you look at our Glassdoor reviews-
• 15:52
  SPEAKER_0: I think we called it unregulated attrition, the official ... but yeah, people who ... yeah.
• 15:57
  SPEAKER_0: Wow.
• 15:58
  SPEAKER_1: If you look at our Glassdoor reviews, I am not aware of many companies with such high support, but yeah, it's not for everybody.
• 16:10
  SPEAKER_1: It's really not for everybody.
• 16:12
  SPEAKER_0: Yeah, that is very, very low indeed.
• 16:15
  SPEAKER_0: Yeah, so surprising because I did a newsletter issue on this.
• 16:23
  SPEAKER_0: I think the industry average was around seven to 10%, and then it can be higher as well depending on the stage of the company.
• 16:30
  SPEAKER_0: So, 1% is truly impressive.
• 16:34
  SPEAKER_1: Literally a handful of people out of 450 per year, like 3, 1, 5, something like that [inaudible 00:16:41]-
• 16:41
  SPEAKER_0: Well, you must be doing something right, and when you do have this type of information to look on, that's actually quite helpful.
• 16:48
  SPEAKER_0: I feel more companies could look at this data because it's quite telling and I'm assuming you have exit interviews with people who leave as well, right?
• 16:56
  SPEAKER_3: We should probably put this in our website somewhere.
• 16:58
  SPEAKER_3: I think people should know about it more.
• 17:01
  SPEAKER_0: Yeah.
• 17:01
  SPEAKER_0: To put things in perspective, could you share some hard numbers, especially engineering numbers to get a sense of where you are in terms of know queries per second, revenue, the things that can help place how large and high load Bending Spoons is.
• 17:18
  SPEAKER_1: So, we're currently at around $700 million in revenues.
• 17:22
  SPEAKER_1: We've been profitable every year since we founded the company 11 years ago.
• 17:28
  SPEAKER_1: We serve well over 200 million monthly active users across a few dozen products.
• 17:36
  SPEAKER_1: And in terms of team size, excluding the most recent acquisition of WeTransfer, we are a little over 400 right now.
• 17:44
  SPEAKER_1: I think 450 give or take.
• 17:46
  SPEAKER_1: And if you include WeTransfer, over 800 people work at Bending Spoons.
• 17:51
  SPEAKER_2: We run multiple products.
• 17:53
  SPEAKER_2: I think it's north of a hundred digital products at the moment.
• 17:58
  SPEAKER_0: A hundred digital products.
• 17:59
  SPEAKER_0: Wow.
• 18:02
  SPEAKER_2: Yeah, I mean it's keep growing, but it's already, I think it's an important number.
• 18:13
  SPEAKER_2: We don't only take care of the developing the core features of this product.
• 18:18
  SPEAKER_2: I think one uniqueness of Bending Spoons is that we built a platform that can provide services that these products can leverage as is, which is also one of our biggest competitive advantage in my opinion.
• 18:34
  SPEAKER_2: Just thinking about all the services that we provide from the platform, we're talking about more than a hundred thousand requests per second, let's say taking care of everything about authentication, security, monetization, data tracking, all of these utilities that we provide for the units that takes care of digital products is already giving us a lot of traffic that we need to handle that let's say pushed us in the years to build complex architecture able to scale accordingly.
• 19:17
  SPEAKER_0: Can we talk about your AI products and specifically the AI load there?
• 19:22
  SPEAKER_0: Because I know Remini, it's a very popular AI application, but how does it transform into GPUs?
• 19:29
  SPEAKER_2: At the moment, I believe on average daily we do more than 2,000 inferences per second.
• 19:37
  SPEAKER_2: We can reach peaks of 8,000 per second, and that turns into, if you look at the GPU demand that we need to satisfy in order to fulfill these inferences, we're talking about around 4,000 GPUs that we need to sort of allocate dynamically because as you can imagine, they're very pricey and we need to run the infrastructure at the maximum efficiency.
• 20:10
  SPEAKER_1: Not everybody may appreciate how here there's a double problem to be solved.
• 20:17
  SPEAKER_1: On the one hand, you want to deallocate GPUs you're not using so as to save in terms of financial costs.
• 20:25
  SPEAKER_1: On the other hand, the way the cloud providers operate is that the only way to make sure that a GPU is available when you need it is to keep it booked.
• 20:34
  SPEAKER_1: There are different ways you can do that depending on the platform, but that also has a cost.
• 20:39
  SPEAKER_1: And so we've built algorithms that help us predict whether unbooking a particular GPU will result in a comparable GPU not being available or being available.
• 20:50
  SPEAKER_1: So, it's actually a very complicated problem to solve in a way that optimizes for those two contrasting goals of ensuring service and minimizing costs.
• 20:59
  SPEAKER_0: And do I understand correctly that one of the reasons you're doing all of this additional complexity is what you mentioned that you have been profitable and I'm assuming you want to remain profitable because a lot of AI startups, they'll just take their funding, VC funded AI startups, they will allocate however many GPUs and their number one thing will be, let's get enough users.
• 21:20
  SPEAKER_0: But sounds like you have another constraint here, right?
• 21:24
  SPEAKER_1: Yeah, definitely.
• 21:25
  SPEAKER_1: We have run the company profitably every year initially because 2013, 2014, raising capital in Italy ... because where we are headquartered.
• 21:35
  SPEAKER_1: We have people all over the world, particularly Europe, but we started off in Italy, so that's where we had the financing questions early on.
• 21:45
  SPEAKER_1: And raising equity capital at decent terms in Italy in 2014 was I would say borderline impossible.
• 21:54
  SPEAKER_1: And then I think today things are much, much better.
• 21:57
  SPEAKER_1: I'd like to believe also thanks to Bending Spoons having been a success case and such attracted international capital, but at the time we didn't have access to it.
• 22:09
  SPEAKER_1: And also our model is so unusual that we felt no VC would be interested in investing.
• 22:18
  SPEAKER_1: So, we had to develop that profitability muscle from early on.
• 22:21
  SPEAKER_1: I think in hindsight it's been a good thing.
• 22:23
  SPEAKER_1: We could have probably grown a little bit faster with equity financing, but having grown through our own cash flows and a little bit of debt from traditional banks has forced us to be extremely efficient and thoughtful about the allocation of resources, more autonomous and independent.
• 22:46
  SPEAKER_1: And I believe that scarcity of resources has bred resourcefulness and an ingenuity at least I'd like to believe that's been the case, which today give us an edge over at least some of the competitors, particularly those who have been flooded with financing.
• 23:05
  SPEAKER_0: Yeah, so I do not frequently hear, we took loans from traditional banks with startups.
• 23:12
  SPEAKER_0: In fact, you're the first one I hear that.
• 23:15
  SPEAKER_0: But let's talk about this history, because today you said you're more than 400 people, you're headquartered in Milan, Italy, but you started this company 11 years ago.
• 23:25
  SPEAKER_0: Can you tell me about how it started and if I recall correctly, when I read your founding story, it started with some AI application 10 years ago, not even in Italy?
• 23:36
  SPEAKER_0: Can you talk about that?
• 23:37
  SPEAKER_1: Right.
• 23:40
  SPEAKER_1: When I graduated in Copenhagen, Denmark.
• 23:43
  SPEAKER_1: Studied engineering and with two friends at the time, we started a company called Evertale, and the vision was to create a self-writing diary of a user's life using AI.
• 23:54
  SPEAKER_1: So, we would install this app and it would collect data from the phone transparently then through AI, and at the time we weren't even talking machine learning.
• 24:04
  SPEAKER_1: I think AI in 2010, this is 2010, I believe you only heard about it in academia.
• 24:10
  SPEAKER_1: I don't think people were talking about it much in the mainstream media.
• 24:14
  SPEAKER_1: So, we built this app, it actually worked reasonably well, but it was a commercial failure.
• 24:21
  SPEAKER_1: And then on the ashes of that project, we were left with about $40,000 of VC money.
• 24:26
  SPEAKER_1: In that case, we had raised $1 million or about that in VC money when we felt we had exhausted all of our avenues and we wanted to shut down the company, the VC firm told us they sold their shares to us for $1 because they didn't want to go through the pretty cumbersome liquidation process.
• 24:50
  SPEAKER_1: The $40,000 would've been theirs.
• 24:52
  SPEAKER_1: They had liquidation preferences, but again, for simplicity, they sold us the shares that that amount of money, which was very substantial to us was peanuts to them, a pretty large fund.
• 25:04
  SPEAKER_1: And so we ended up taking out these $40,000 from that failure, and that was the seed money for Bending Spoons, which started in Copenhagen in 2013 with that $40,000, the same three people who started Evertale, plus two people who had been hired at Evertale and turned out to be particularly capable.
• 25:26
  SPEAKER_1: And so we asked them to co-fund Bending Spoons.
• 25:29
  SPEAKER_1: So, we started with that amount of money invested in the first acquisition soon after I think 2014.
• 25:34
  SPEAKER_1: So, around the same time we moved the company back to Italy.
• 25:40
  SPEAKER_1: Again, at the time it was just the co-founders and we invested in the first acquisition $10,000.
• 25:48
  SPEAKER_0: What was this first acquisition?
• 25:50
  SPEAKER_1: So, that one was an app, an iOS app to personalize your keyboard.
• 25:58
  SPEAKER_1: Very simple.
• 26:00
  SPEAKER_1: I believe we bought it from a one man show developer from somewhere in the world.
• 26:05
  SPEAKER_1: I don't remember frankly where, and we tried to improve it ultimately turning that $10,000 investment into say 20,000, 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.
• 26:28
  SPEAKER_1: And so you fast-forward around 10 years later, we're now acquiring companies hundreds of millions of dollars in price.
• 26:35
  SPEAKER_1: We've invested more than a billion dollars in acquisition, some hundreds of millions of dollars in research and development.
• 26:41
  SPEAKER_1: But yeah, it's been a pretty steady paced journey since then.
• 26:51
  SPEAKER_0: What was a bigger milestone?
• 26:53
  SPEAKER_0: I imagine clearly Evernote is one very well known from externally, but from internally, you said it started off small, you started growing, but were there any kind of notable milestones where you really stepped up a level?
• 27:07
  SPEAKER_1: I think one that's worth mentioning is when we acquired Splice, a mobile video editor from GoPro.
• 27:14
  SPEAKER_1: 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.
• 27:26
  SPEAKER_0: So, 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 mainstream news.
• 27:38
  SPEAKER_0: Can you tell us about how this acquisition happened from your point of view?
• 27:42
  SPEAKER_1: The short of it is we came to know that Evernote could potentially be acquired around late 2022.
• 27:53
  SPEAKER_1: 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 '22.
• 28:05
  SPEAKER_1: Then you always have to go through antitrust clearance periods and so on and so forth.
• 28:11
  SPEAKER_1: So, the acquisition actually closed very early January '23, 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.
• 28:41
  SPEAKER_1: They 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.
• 28:56
  SPEAKER_1: Organization, technology, user experience, monetization, marketing, everything.
• 29:01
  SPEAKER_1: We come up with a vision of the best version of that business we can come up with a long-term view.
• 29:09
  SPEAKER_1: There's a misconception about sometimes we acquire these companies to own and operate them forever.
• 29:15
  SPEAKER_1: So, we think with the longest timeframe we can.
• 29:20
  SPEAKER_1: And so that vision embeds that sort of long-term thinking in it.
• 29:25
  SPEAKER_1: 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.
• 29:36
  SPEAKER_0: When you acquired Evernote, 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?
• 29:44
  SPEAKER_0: I assume it's always an exciting and opportunity to look at a pretty established product and see what are the bottlenecks and how can we improve it?
• 29:56
  SPEAKER_2: 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 that 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.
• 30:27
  SPEAKER_2: And that migration was of course supported by the cloud provider.
• 30:32
  SPEAKER_2: It was made in a one-on-one fashion, meaning that it wasn't really happening ... Evernote didn't, let's say reshaped the infrastructure or the architecture, making it cloud-native.
• 30:49
  SPEAKER_2: 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, but they were sort of manually provisioned.
• 31:06
  SPEAKER_2: They were 750 machines, virtual machines, all of them were manually provisioned.
• 31:13
  SPEAKER_0: Ouch.
• 31:15
  SPEAKER_2: Users' data were sharded among all of these machines.
• 31:19
  SPEAKER_2: That sharding was not even after thorough analysis, doesn't even have aspiring to be even meaning that certain machines have heavier loader than others, significantly heavier, and sometimes that caused it also, a lot of interventions, a lot of maintenance.
• 31:41
  SPEAKER_2: We had to realize that on-calls were actually very needed.
• 31:47
  SPEAKER_2: We run several products.
• 31:49
  SPEAKER_2: What we do generally, we try to make them reliable enough to not need an on-call program.
• 31:56
  SPEAKER_2: 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.
• 32:07
  SPEAKER_2: On Evernote we found that-
• 32:09
  SPEAKER_0: Awesome.
• 32:09
  SPEAKER_0: So, just to confirm, for the products that you operate, this is kind of a core principle of on-call should not be, let's say heavy or you should not worry when you're going on-call that you're going to be flooded with notifications and alerts.
• 32:24
  SPEAKER_1: Not even that.
• 32:25
  SPEAKER_1: I think it's even more than that, Gergely.
• 32:26
  SPEAKER_1: We actually try not to have an on-call scheme at all on many of our products and technologies.
• 32:33
  SPEAKER_1: So, the goal is-
• 32:34
  SPEAKER_0: [inaudible 00:32:35].
• 32:35
  SPEAKER_1: Yeah, but I think yes, however, knowing you don't have that fallback as a software engineer, as an infrastructure engineer really breeds that, have I thought about the corner cases?
• 32:48
  SPEAKER_1: Have I really looked at this and made sure it's really robust, it's really sharply engineered?
• 32:54
  SPEAKER_1: If you know that the on-call is there, it's not the same.
• 32:59
  SPEAKER_1: You know that a lack of foresight, there's a safety net.
• 33:02
  SPEAKER_1: 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 codebase as yet.
• 33:19
  SPEAKER_0: I love the different thinking.
• 33:20
  SPEAKER_0: I think in the industry it's kind of a given like, look, we generate a lot of revenue we can afford to do on-call and we will pay engineers a bit of extra.
• 33:28
  SPEAKER_0: We will give them either a bonus for the week, and a lot of companies operate like this.
• 33:31
  SPEAKER_0: So, I really like how you actually just said, okay, let's do it differently.
• 33:36
  SPEAKER_0: Let's take from this principle.
• 33:38
  SPEAKER_1: I think a broader higher-level principle we follow religiously at the company and it's probably one of the main drivers for these views on the on-call programs is call it radical simplicity.
• 33:51
  SPEAKER_1: We truly try to make it a core cultural principle and value that everything we do, we should seek out the most radically simple solution and approach and adding complexity, the burden of proof is always on those who want to do so as opposed to on those who want to retain the simpler status.
• 34:17
  SPEAKER_1: Additionally, we encourage people not just not to add complexity, but to look for ways they could remove complexity.
• 34:24
  SPEAKER_1: So, we constantly question whether any system really, and it's not just technological systems, it's also policies could be made simpler, and we have plenty of examples of systems that I think were reasonably simple to start with and made radically simple because of this approach.
• 34:42
  SPEAKER_1: One being pay.
• 34:43
  SPEAKER_1: At Bending Spoons originally years ago we had bonuses and stuff.
• 34:48
  SPEAKER_1: Now for many, many years we've had fixed pay for everybody, a hundred percent fixed.
• 34:52
  SPEAKER_1: There's only a salary and people can choose to receive a percentage of their salary in equity if they so wish.
• 34:58
  SPEAKER_0: And you even put it on your website, right?
• 35:00
  SPEAKER_0: I saw that.
• 35:01
  SPEAKER_1: Yeah, I think so.
• 35:02
  SPEAKER_1: I think so.
• 35:02
  SPEAKER_1: Yeah, we tried to be quite transparent about that stuff.
• 35:04
  SPEAKER_1: So, there was a theory early on that bonuses would somehow drive superior performance.
• 35:13
  SPEAKER_1: We documented ourselves on the topic in the literature.
• 35:17
  SPEAKER_1: We had discussions.
• 35:19
  SPEAKER_1: We ultimately said there is very weak evidence that they do.
• 35:23
  SPEAKER_1: There is certainty that they are a big pain in the ass to manage.
• 35:26
  SPEAKER_1: Of course, set targets, discuss, I deserve it.
• 35:30
  SPEAKER_1: I don't deserve.
• 35:31
  SPEAKER_1: It's not nice for anyone involved.
• 35:33
  SPEAKER_1: And so we figured let us have just fixed pay.
• 35:36
  SPEAKER_1: We trust everybody working here that they want to do the best job they can, and if they don't, it's a different type of a problem.
• 35:43
  SPEAKER_1: You shouldn't need a bonus to drive performance and we haven't looked back.
• 35:47
  SPEAKER_1: I mean, we don't even dream of adding bonuses back to the equation.
• 35:51
  SPEAKER_0: Awesome.
• 35:52
  SPEAKER_0: And going back to Evernote, so you said, okay, here was the technology Java 11 virtual machines, some of them manually provisioned.
• 36:01
  SPEAKER_0: What did you decide to move it on?
• 36:03
  SPEAKER_0: What is Evernote on these days in terms of the technology stack, architecture?
• 36:08
  SPEAKER_0: How did you make it more cloud native?
• 36:10
  SPEAKER_2: Yes, so first of all, we noticed that all the data user, the users had their data stored on the virtual machines, actually the databases, they were all deployed locally on the virtual machines.
• 36:23
  SPEAKER_2: That was one of the biggest weak point in our opinions.
• 36:27
  SPEAKER_2: The first thing we did was migrating all the data from the shards from the virtual machines to a managed database structure.
• 36:36
  SPEAKER_2: That allowed us then to move freely with the application logic in the best possible way.
• 36:42
  SPEAKER_2: At that point, after some analysis, we found out that the best way moving forward was to move from the monolith to a microservices architecture.
• 36:51
  SPEAKER_2: There were already some services that the previous team of Evernote was already building, let's say, following microservices architecture principle, but they were very peripheral, let's say they were not, let's say, handling the core that was about the notes, about everything that the users were using from years.
• 37:21
  SPEAKER_2: So, we had to actually come up with a plan that was, let's say, taking into account how to move all that core logic about notes without disrupting the user flows.
• 37:40
  SPEAKER_2: One of the core projects also that we needed to take care of to do such a move as changing the interaction mechanism between the clients and the backend substantially before the clients were polling continuously bombarding-
• 38:00
  SPEAKER_0: [inaudible 00:38:01] polls.
• 38:00
  SPEAKER_0: The classic 2000 cents.
• 38:04
  SPEAKER_2: Exactly.
• 38:04
  SPEAKER_2: You know it went, how it can go.
• 38:07
  SPEAKER_2: It was very heavy to manage and also-
• 38:13
  SPEAKER_0: Quite wasteful as well.
• 38:14
  SPEAKER_2: Yeah, the clients also had to, let's say, embed a heavy, let's say quite a big layer of logic just to take care of all the pollings and all the combining the mutations that were coming back from the backend.
• 38:31
  SPEAKER_2: As you can imagine, Evernote is also about synchronizing events that can happen from the client to the backend.
• 38:39
  SPEAKER_2: Sometimes some mutations happen on the client.
• 38:41
  SPEAKER_2: They need to be propagated to the backend to be sure that they become permanent and that, let's say, mutation must be acknowledged accordingly to make sure that on the client also nothing strange happens otherwise you incur in what we called in the past in data missing issues, let's say.
• 39:10
  SPEAKER_2: So, what we had to do was to move from this polling mechanism to an event-driven communication.
• 39:19
  SPEAKER_2: We built and we kept moving all the entities of the database, all the ones that were managed by the client from the polling system to what we called EndSync, which was basically a downstream event-driven mechanism that allowed the clients to just receive all the events from the backend real-time.
• 39:48
  SPEAKER_2: That required quite of an effort, because we moved all the logic of combining all the mutations and making sure that the end state is unique and clear to the backend.
• 40:01
  SPEAKER_2: While before it wasn't the client and making that change though, we made sure that lot of data synchronization issues just disappeared because on the backend side, we had much more visibility, we had much more observability on what was going on, and in turn, we were able to make sure that there was a unique state of what was the user's data, and that state was propagated real-time to the clients.
• 40:34
  SPEAKER_0: If as a software engineer, you want to take your system design interview preparation to the next level, check out bytebytego.com.
• 40:40
  SPEAKER_0: ByteByteGo provides a proven force of framework, detailed case studies and access to their exclusive Discord community.
• 40:47
  SPEAKER_0: They cover everything software engineers need to consistently do well on system design interviews and thus increase chances to land those high-level software engineering roles head over to bytebytego.com to sign up and try it out for yourself.
• 41:00
  SPEAKER_0: That is bytebytego.com.
• 41:03
  SPEAKER_0: How did you get to this really fast shipping cadence?
• 41:05
  SPEAKER_0: Federico, you were telling me that you committed in 24 to ship a hundred updates, and I saw your blog on how you shipped 20 improvements in I think April, 30 more in July.
• 41:19
  SPEAKER_0: It's a really big step-up pace from before.
• 41:23
  SPEAKER_0: How did you structure yourself or how did you just speed things up so much?
• 41:30
  SPEAKER_3: Yeah, so we approach these in a variety of ways.
• 41:34
  SPEAKER_3: So, we do have some bigger tracks that take longer to develop, and so big projects like the ones Francesco was mentioning, of course take months and we cannot ship them out every week or two.
• 41:46
  SPEAKER_3: But on the other hand, as we understood better what our customers wanted, we tried to prioritize those things that people wanted, but were also easy to build in a sense.
• 41:58
  SPEAKER_3: And so given that we tried to give a lot of autonomy to product teams, as Luca was mentioning, we built this backlog of initiatives and features that users needed and we basically tried to assess them both from a standpoint of how important they were for our customers, but also on how hard they were to build.
• 42:22
  SPEAKER_3: And so we kind of tried to rank the list by both metrics in a sense, and we just started shipping stuff very quickly.
• 42:32
  SPEAKER_3: A few examples are, for instance, collapsible sections inside the note editor, Evernote was missing this feature and we were able to build it in a couple weeks.
• 42:41
  SPEAKER_3: Other examples are slash commands through which you can hit slash and select an item to add to a note.
• 42:48
  SPEAKER_3: There are other examples, but basically the point is while there are projects that are longer and that need to go through some migrations or stuff like that, in other cases it's much more the value that would build is much more related to the UX or simpler features.
• 43:06
  SPEAKER_3: And so we try to prioritize those because that way we can do stuff more quickly.
• 43:12
  SPEAKER_0: And did you prioritize this to get an impression of, to get the team motivated to ship things, to show it to people, or were there other reasons?
• 43:21
  SPEAKER_0: Because it actually sounds really smart to mix the easy and visual things and then I'll do the hard and long thing kind of on the side together.
• 43:27
  SPEAKER_0: It sounds like that's what you're doing, right?
• 43:29
  SPEAKER_3: We're doing both.
• 43:32
  SPEAKER_3: Showing both externally and internally what we're building is easy when you are shipping a product feature.
• 43:39
  SPEAKER_3: It's kind of harder to communicate when you are changing the way metadata synchronization works, for instance.
• 43:45
  SPEAKER_3: Although we try to communicate this as much as we can because it's a big change, it's a very impactful thing for customers in a good way.
• 43:52
  SPEAKER_3: Like performance increase a lot and readability too.
• 43:55
  SPEAKER_3: So, we do try to communicate-
• 43:57
  SPEAKER_1: Some synchronization actions now take a fraction of the time they used to, literally one-tenth or one-twentieth of the time they used to.
• 44:07
  SPEAKER_1: And that's the kind of stuff you love of a product without knowing you love it, you just assume it's fast, and so it's fine.
• 44:17
  SPEAKER_1: If it's slow, you complain, but if it's fast, just assume it should be fast.
• 44:21
  SPEAKER_1: So, it's quite difficult from a point of view of your relationship with users and customers, call it marketing, to highlight that stuff as you're working on it, whereas it's a lot easier to empathize with or relate to a particular clear feature you're developing.
• 44:42
  SPEAKER_1: So, yeah, we do try to do both to make everybody happy, although of course not everybody's happy.
• 44:50
  SPEAKER_2: Let me also add with respect to what you were saying before that from an engineering perspective, what helped a lot shipping fast was also to completely review the CI/CD pipeline.
• 45:02
  SPEAKER_2: I think it's worth saying that we made huge advancement in that regard.
• 45:07
  SPEAKER_2: It was also a lot of work, but before most of the releases of the clients and the backends required a lot of manual steps.
• 45:18
  SPEAKER_2: Some of the pipelines, most of them were on self-hosted Jenkins, just to give you a sense.
• 45:26
  SPEAKER_2: And we moved to CircleCI with our orbs, the orbs that we built in the years that we polished a lot, we know what to expect and what not.
• 45:37
  SPEAKER_2: That definitely helped the team also ship faster, let's say.
• 45:43
  SPEAKER_2: On top of that, switching to the next exciting challenges for the platform of Evernote, technologically speaking, I believe we're closer than ever now to the complete dismissal of the monolith, the infamous monolith.
• 46:02
  SPEAKER_2: The engineers and the team now, they refer to it as an entity-
• 46:09
  SPEAKER_3: The villain.
• 46:09
  SPEAKER_2: ... from the ... Yes, it's a villain, something to be afraid of really to fear.
• 46:17
  SPEAKER_2: We worked a lot to piece by piece, remove all the dependencies that didn't allow us to sunset it.
• 46:27
  SPEAKER_2: We're closer than ever now.
• 46:29
  SPEAKER_2: We just completed the rent effort to move everything on the event-based interactions that were mentioning to you before.
• 46:42
  SPEAKER_2: And as soon as we get to the finish line, I believe that's going to be one of the most exciting moments for the Evernote engineering team because at that point we'll be ready to finally reshape the system entirely to make it much more efficient.
• 46:58
  SPEAKER_2: At the moment, let's say for instance, just to mention a few, there is, in our opinion, many more microservices that actually needed ... what's the trade-off with microservices, you need them of course, but sometimes can get out of hands, it can be hundreds.
• 47:19
  SPEAKER_2: Sometimes only the boilerplate of shipping a microservice to just handle a very tiny portion of the application logic can become too much, simply.
• 47:35
  SPEAKER_2: We want to consolidate the responsibilities and the numbers of microservices out there in the architecture now, it's just not the right moment because we first need to get rid of the huge legacy.
• 47:48
  SPEAKER_2: So, everyone is looking for that.
• 47:50
  SPEAKER_2: All the people are, the engineers are keep thinking about what's going to be the next proposal that they want to do for what's going to be the next architecture of the Evernote system.
• 48:04
  SPEAKER_2: We just need to finally sunset the monolith.
• 48:08
  SPEAKER_2: We're very close to it.
• 48:09
  SPEAKER_2: We committed ourselves to completely sunset it by the end of the year.
• 48:16
  SPEAKER_2: We're doing our best.
• 48:18
  SPEAKER_2: I think we're pretty close, and so far everything is on track.
• 48:23
  SPEAKER_0: Yeah, it's awesome because I remember when we sunseted a monolith back at Uber, and it's so hard to tell externally.
• 48:29
  SPEAKER_0: I mean assuming your product team or your leadership team has empathy for engineers, they'll understand why it's so important, but it is not something you can really tell the user is like, oh, it's update.
• 48:42
  SPEAKER_0: We've sunset the monolith.
• 48:43
  SPEAKER_0: Because for them, literally a good monolith sunset is nothing changes, right?
• 48:47
  SPEAKER_2: Absolutely.
• 48:49
  SPEAKER_3: Although we try to explain the importance of it, but yeah, understandably people care more about their experience, although that influences it greatly.
• 48:59
  SPEAKER_2: I think Federico is doing an amazing job on that, but I think it's also worth mentioning that probably the toughest part is actually to making it understand usually in my opinion, to the management team, to the product team internally rather than to the users outside.
• 49:17
  SPEAKER_2: So, I believe we're very lucky here to be able to voice engineering needs and put them at the center of the roadmap for the product.
• 49:30
  SPEAKER_0: And what are some of the products things that you're looking forward to?
• 49:35
  SPEAKER_3: Yeah, we recently released what I believe from my tests at least, is the best AI transcription feature available on any note-taking product.
• 49:48
  SPEAKER_3: It basically allows you to upload a video, audio or image file and hit the button and basically one-click, transcribe it so you get a bunch of text as output.
• 50:01
  SPEAKER_3: It's pretty fast, super accurate.
• 50:03
  SPEAKER_3: I was honestly surprised myself by how accurate it is, and one thing that is coming soon is that we are trying to build this into a standalone tool.
• 50:13
  SPEAKER_3: So, outside of Evernote, which is kind of unusual I guess, but we are so proud of it that we want to use it as a tool to show people that Evernote is cutting edge again, in a sense.
• 50:28
  SPEAKER_3: So, that's one thing that we're doing.
• 50:30
  SPEAKER_0: Okay, thank you.
• 50:31
  SPEAKER_0: And switching to a different topic, although somewhat related.
• 50:34
  SPEAKER_0: So, we talked about how you built Evernote, how you acquired it, how you balance architecture and features, but within Bending Spoons, how do you typically get projects done?
• 50:46
  SPEAKER_0: And what I'm interested in is how typical is Evernote versus not?
• 50:51
  SPEAKER_0: And maybe we could talk about an example of a project that you got done recently inside the company, and do you even have a typical kind of almost like template or run book or like, here's for us what a well executed project looks like?
• 51:04
  SPEAKER_1: Well, I guess it helps to describe how we're organized.
• 51:08
  SPEAKER_1: So, we have different business units, Evernote being one, and these business units have dedicated management teams and resources such as software engineers, data analysts, scientists, product designers, so on and so forth, depending on the needs specific of that product and business.
• 51:32
  SPEAKER_1: And we encourage them to operate largely autonomously.
• 51:38
  SPEAKER_1: And then we have a shared platform, including several platform teams.
• 51:46
  SPEAKER_1: And what the platform does is it supports and serves the different business units with tools, services that are relevant, generally speaking to most of them.
• 51:59
  SPEAKER_1: Some of this is as basic as accounting, finance, so on and so forth.
• 52:03
  SPEAKER_1: And some of it is as advanced and technically exciting as all sorts of data storage and processing tools and layers, machine learning models to forecast a particular user cohort's behavior and value.
• 52:23
  SPEAKER_1: A-B testing systems, automations for marketing.
• 52:29
  SPEAKER_1: We spend tens of millions of dollars in marketing each year and it's almost entirely run by machines.
• 52:39
  SPEAKER_1: So, within this framework, the principle we try to follow is to create small teams of exceptional talent density and give them a very vast mandate in what to do.
• 52:55
  SPEAKER_1: So, we trust people to set intelligent objectives and try their very best to achieve them.
• 53:02
  SPEAKER_1: And this really is not limited to engineering.
• 53:04
  SPEAKER_1: It's a cultural trait at the company.
• 53:08
  SPEAKER_1: And so it works at every scale you look at.
• 53:15
  SPEAKER_1: For example, if you look at Evernote as a unit, as a business unit, the whole team knows they don't have to follow any mandated direction.
• 53:23
  SPEAKER_1: They can make their own decisions, own their mistakes, own their failures, but also in Evernote that the smaller squads taking care of the various missions or objectives also will have a broad mandate on how to pursue them.
• 53:41
  SPEAKER_1: We will not impose any particular technological stack on them.
• 53:45
  SPEAKER_1: We will not impose any particular type of process on them.
• 53:49
  SPEAKER_1: There are guidelines, there are lessons learned, and people at the platform level that are experts at the platform level are always available to coach, help, support.
• 53:57
  SPEAKER_1: Ultimately, we trust people to take full responsibility for their actions.
• 54:04
  SPEAKER_0: Awesome.
• 54:04
  SPEAKER_0: And in terms of engineering approaches, which ones do you use?
• 54:08
  SPEAKER_0: I mean we mentioned CI/CD and we mentioned that you're aiming to not have on-call, but for example, what's your approach to releasing, QA, testing these areas?
• 54:20
  SPEAKER_2: I'd say following the lines of what Luca already said, it's important for us to not be prescriptive in the tools and the methods that we want to follow across the different business units or across the different teams.
• 54:35
  SPEAKER_2: Tools are tools that are meant to achieve a certain help, to achieve a certain objective.
• 54:41
  SPEAKER_2: Processes have the same objective.
• 54:44
  SPEAKER_2: Let's say some teams are more used to follow certain processes than other.
• 54:50
  SPEAKER_2: We give the team the freedom to choose whatever they believe is the most effective approach.
• 54:56
  SPEAKER_2: We give them principles, we help them shape what is the responsibility of the team, and then of course we work together to understand what technology tool or process can be the most suitable one to work effectively.
• 55:15
  SPEAKER_2: Generally speaking, I'd say for QA for instance, we try to give that responsibility to share that responsibility among all the different software engineers and also of course QA testers.
• 55:31
  SPEAKER_2: In Bending Spoons I'd say software engineers really care about the product and the end result of it.
• 55:39
  SPEAKER_2: So, doing white-boxing QA is something that they take very seriously.
• 55:45
  SPEAKER_2: They dedicate a lot of time.
• 55:47
  SPEAKER_2: Of course, it's also about building the right developer experience and otherwise it become very cumbersome.
• 55:53
  SPEAKER_2: We know very well.
• 55:54
  SPEAKER_2: But on top of that, then of course black-box QA instead is done by the QA or testers.
• 56:02
  SPEAKER_2: We make sure that everything that can be tested by software engineers before is properly tested.
• 56:09
  SPEAKER_2: And we found that approach to give a lot of, let's say, to make the engineers more responsible for the end result and in turns more productive and also happy about what's happened next because let's say it's more rare to ship bugs into production if you built the right developer experience and also gave shared responsibility to everyone about testing their codebase.
• 56:41
  SPEAKER_0: And how big are you on automated testing in terms of unit integration, end-to-end?
• 56:46
  SPEAKER_0: Some of these things you mentioned, manual testing, which obviously is important, or is it more per app, per product, whatever makes sense for the maturity of the product?
• 56:56
  SPEAKER_2: Yeah, that's the point.
• 56:58
  SPEAKER_2: I think it depends a lot on the maturity on the product and also what's the real estate, for instance, for that product.
• 57:06
  SPEAKER_2: If the core part is about the UI or if it's about some critical features, I'd say we develop a lot of end-to-end tests for sure.
• 57:17
  SPEAKER_2: We try to reach the right level of coverage.
• 57:20
  SPEAKER_2: We try also to be pragmatic, meaning understanding what are the, let's say the use case worth building the right set of tests that can be generalized enough to be effective more than manual testing, for instance, or to be sure that those tests can be general enough to capture behaviors and not generate false positives.
• 57:48
  SPEAKER_2: I believe also in terms of observability and monitoring, in addition to QA, something that we have spent a lot of effort is to be sure to tailor metrics or what we test and how in such a way that we're sure that we have the highest coverage, but we're also very careful to not trigger false positives.
• 58:13
  SPEAKER_2: We have seen multiple times in the past, we've improved a lot in time of course, but that has been some of the things that we've seen improving a lot the life of engineers after not fighting, let's say, not finding themselves fighting with false positives all the day.
• 58:34
  SPEAKER_0: Am I guessing correctly, because you mentioned you have about over a hundred products and you mentioned you have internal teams for some of these shared things, you must have platform teams, right?
• 58:43
  SPEAKER_2: Yes.
• 58:44
  SPEAKER_0: What kind of platform teams do you have or just platform engineering teams that is?
• 58:48
  SPEAKER_2: We have a team, we call it Foundations Technology.
• 58:52
  SPEAKER_2: It builds all the tools, expertise and knowledge to make sure that we have the right developer experience, that we have analytics tools, monetization, user acquisition tools, and we make sure that these utilities can be used by the business units if they want.
• 59:16
  SPEAKER_2: Typically, these are tools and technologies that requires a of investment to be done.
• 59:23
  SPEAKER_2: And if you don't have a wide portfolio of products, usually you don't find it a good investment or it's a big investment that you might not experience returns in the right time horizon.
• 59:39
  SPEAKER_2: In our case, we have this luxury, let's say that when we build a platform tool, it can be applied at scale.
• 59:47
  SPEAKER_2: So, we have, let's say the opportunity to make such investments and to see the results at large.
• 59:56
  SPEAKER_2: So, the foundation's technology team builds the tools that allow us to, for instance, do proper A-B testing to let's say manage infrastructure in an efficient way.
• 1:00:09
  SPEAKER_2: That allow us to, for instance, collect and define metrics for different products.
• 1:00:20
  SPEAKER_2: We can track all the data code among the different products with the same, let's say, formats, data pipelines and stuff.
• 1:00:28
  SPEAKER_2: That has proved to be extremely, extremely useful because when you have, let's say, when your data warehouse is built in such a way that all the products produce data with the same kind of semantic and format, every tool that you build on top of it is out of the box ready for all the other digital products when you build it for one.
• 1:00:51
  SPEAKER_1: It's a two-way street by the way.
• 1:00:53
  SPEAKER_1: So, if a business unit has a need that's incremental to whatever shared technologies available, they can improve it.
• 1:01:04
  SPEAKER_1: And so they can pass up, let's say toward the platform improvements that they can then be propagated to benefit any other business unit in the future.
• 1:01:13
  SPEAKER_1: We have had such [inaudible 01:01:14] issues with.
• 1:01:15
  SPEAKER_1: Whether it's knowledge or an actual improvement to the software, we've had plenty such cases, whether it's authentication being made more resilient against abuse, whether it's our payment processing systems handling more extreme loads or corner cases in certain particular types.
• 1:01:37
  SPEAKER_1: So, all the sort of things becomes a shared benefit across the whole company.
• 1:01:42
  SPEAKER_0: Awesome.
• 1:01:42
  SPEAKER_0: And speaking of technologies, what type of [inaudible 01:01:46] technologies, frameworks do you use inside the company or just the most popular ones at least?
• 1:01:50
  SPEAKER_2: Yeah, so I'd say the most popular back-end language that we use is Python.
• 1:01:57
  SPEAKER_2: We use FastAPI, for instance, to ship APIs.
• 1:02:01
  SPEAKER_2: We also use TypeScript a lot, especially because we've been investing a lot in making engineers, let's say full stack as much as possible.
• 1:02:12
  SPEAKER_2: TypeScript in that regard is particularly useful, because they can move from clients to backend easily.
• 1:02:20
  SPEAKER_2: And some Node.js.
• 1:02:23
  SPEAKER_2: We use Swift and Kotlin to build native iOS and Android apps typically, but we also rely on React when it makes sense.
• 1:02:37
  SPEAKER_2: We use Electron.
• 1:02:39
  SPEAKER_2: What else?
• 1:02:42
  SPEAKER_2: I'd say we actually have a quite wide tool set.
• 1:02:49
  SPEAKER_2: These are the most useful, the most widespread among the organization, but as I said, we're not prescriptive about the tech, rather let's say the technology that one can use.
• 1:03:02
  SPEAKER_2: So, we found ourselves frequently evaluating if there is a different technology that can work better to achieve a certain goal.
• 1:03:12
  SPEAKER_2: Of course, if a certain goal can be achieved with different tools, they're equivalent in terms of output.
• 1:03:20
  SPEAKER_2: We tend to prefer tools that have been used the most already across the organization, because that allows everyone to contribute to that more effectively.
• 1:03:33
  SPEAKER_2: It help us avoid single point of failures in terms of knowledge, but apart from that case, we tend to prefer the right technology that help us achieve the highest quality of output for a certain goal.
• 1:03:49
  SPEAKER_0: Can you tell me an interesting technology or maybe a one-off technology that one of the teams uses because it's great for their fit, but obviously it's not mainstream across the company.
• 1:03:57
  SPEAKER_0: Do you have a fun example of that?
• 1:04:01
  SPEAKER_2: Let's see.
• 1:04:03
  SPEAKER_2: We have our tool for attribution, for marketing attribution.
• 1:04:09
  SPEAKER_2: We built our own internally.
• 1:04:11
  SPEAKER_2: Usually most of the player outsides rely on the mobile measurement partners such as Adjust, Kochava or AppsFlyer.
• 1:04:20
  SPEAKER_2: At a certain time of our, let's say of the, when it was the right moment, we decided to build our own internal tool.
• 1:04:31
  SPEAKER_2: As you can imagine, that must be able to handle huge loads with a very high efficiency.
• 1:04:40
  SPEAKER_2: We have seen that Rust was the right language.
• 1:04:44
  SPEAKER_0: Nice.
• 1:04:45
  SPEAKER_2: It's a peculiar, let's say unique-
• 1:04:47
  SPEAKER_0: Rust is good for performance, isn't it?
• 1:04:49
  SPEAKER_2: Exactly.
• 1:04:49
  SPEAKER_2: Yeah, we loved it.
• 1:04:51
  SPEAKER_2: It was clear that it was making everything better, much more than the backend language that we used the most, which was Python, but for that aim, it was not the right one.
• 1:05:02
  SPEAKER_2: It was clear from, let's say an engineering perspective, just looking at the numbers.
• 1:05:08
  SPEAKER_2: So, yes, we went for Rust and at the moment our internal tool for attribution, [inaudible 01:05:13] we call it, it's still on Rust and it's working.
• 1:05:17
  SPEAKER_0: That's awesome.
• 1:05:18
  SPEAKER_0: Be careful the popularity might be spreading inside the company.
• 1:05:21
  SPEAKER_2: Oh yeah.
• 1:05:21
  SPEAKER_2: I mean, I would be happy about it personally.
• 1:05:25
  SPEAKER_2: We can talk about it another time.
• 1:05:28
  SPEAKER_0: One thing that is really unusual about Bending, Spoons, I went to your career page and most career pages you're hiring and a lot of companies are hiring and most career pages I would see senior engineer hiring staff engineer or just software engineer.
• 1:05:41
  SPEAKER_0: And I saw junior engineers.
• 1:05:43
  SPEAKER_0: I saw internships posted.
• 1:05:46
  SPEAKER_0: Actually most of a lot of them were clearly entry-level engineers, which is refreshing to see.
• 1:05:52
  SPEAKER_0: Has this always been the case and what is your philosophy behind this?
• 1:05:55
  SPEAKER_0: Because a lot of companies, especially in your position, would be a little bit afraid to hire less experienced engineers given all the complexity and all the revenue that you're talking about.
• 1:06:05
  SPEAKER_1: We always have favored hiring new graduates or inexperienced people.
• 1:06:15
  SPEAKER_1: And there are two reasons for it.
• 1:06:17
  SPEAKER_1: One is when you hire, there's a trade-off between a few things, certainly talent and experience.
• 1:06:25
  SPEAKER_1: And so the more you want to optimize for talent, the less experienced people will be on average and vice versa.
• 1:06:33
  SPEAKER_1: Experience we can provide a new hire with over time, particularly high-quality experience being surrounded by great colleagues, working on really challenging projects at a high pace.
• 1:06:44
  SPEAKER_1: Talent we cannot teach.
• 1:06:46
  SPEAKER_1: And so given that we're so long-term oriented, and we want to maximize our level of competence, our success with a five, 10, twenty-year view, we favor hiring individuals who are more talented, even if we have to be patient for a couple of years or how long is needed for them to ramp up in terms of experience.
• 1:07:08
  SPEAKER_1: That means we need to invest heavily in training coaching.
• 1:07:11
  SPEAKER_1: But we do that eagerly, given the great benefits involved for not just Bending Spoons, but also the people who we hire.
• 1:07:21
  SPEAKER_1: The second reason is our approach, our culture are so unusual and we only learn this over time as we interface more and more with the external world, that it's proven challenging for highly experienced individuals to adjust to them sufficiently quickly.
• 1:07:39
  SPEAKER_1: So, we do hire experienced people, but we now have a preference for inexperienced ones.
• 1:07:46
  SPEAKER_0: Awesome.
• 1:07:47
  SPEAKER_0: And when people join Bending Spoons, what does career growth look like?
• 1:07:51
  SPEAKER_0: Do you have a concept of levels or titles?
• 1:07:55
  SPEAKER_0: Because again, you did mention that you do optimize, you have this principle of simplicity.
• 1:08:00
  SPEAKER_0: I'm curious how careers fits in here from a software engineer's perspective.
• 1:08:06
  SPEAKER_1: Yeah, it's very simple relative to our understanding of what's standard out there.
• 1:08:11
  SPEAKER_1: We don't have any titles.
• 1:08:13
  SPEAKER_1: So, if you're hired as a software engineer, you are and always will be, as long as that's what you do called software engineer internally.
• 1:08:21
  SPEAKER_1: And you can choose your own title for whatever external reasons you like, your CV, LinkedIn.
• 1:08:27
  SPEAKER_1: We only ask that you don't do something that would embarrass us, like calling yourself the CTO if you're a new hire, something like that.
• 1:08:33
  SPEAKER_1: But if you want to use senior staff, triple senior, any of that is fine by us.
• 1:08:40
  SPEAKER_1: Internally you're just a software engineer.
• 1:08:43
  SPEAKER_1: All managers are simply called leads.
• 1:08:45
  SPEAKER_1: Super simple.
• 1:08:47
  SPEAKER_1: We have a few levels.
• 1:08:49
  SPEAKER_1: There are very few.
• 1:08:51
  SPEAKER_1: The difference is pretty substantial.
• 1:08:53
  SPEAKER_1: And so we don't try to resolve finer deltas in your contribution.
• 1:08:59
  SPEAKER_1: And if you need very frequent, very specific adjustments, we're not the company for you.
• 1:09:04
  SPEAKER_1: If you're happy to look at working at Bending Spoons with a multi-year, very long term view, and you're looking for big jumps when you have made big improvements, then that's great, because we don't have to discuss every six months whether you have made a 5% improvement in your ability to contribute.
• 1:09:24
  SPEAKER_0: So, I'm hearing a lot of things are just quite different to how most companies operate.
• 1:09:29
  SPEAKER_0: And usually I find that a big difference that we could talk a lot more about the differences, but what I often find is these differences often come down to the people because you can do certain things with a certain group of people, and I'm wondering what are traits that you're hiring for and what does an engineer, a software engineer who is thriving at the company look like?
• 1:09:51
  SPEAKER_0: How would you describe them?
• 1:09:52
  SPEAKER_0: Because I think this could help understand a little bit of what makes your culture possible.
• 1:09:59
  SPEAKER_1: Yeah, that's a good point.
• 1:10:00
  SPEAKER_1: I think by the way, hiring primarily inexperienced individuals helps because they don't come with a baggage of how it's done, and they will look at it from a blank slate.
• 1:10:13
  SPEAKER_1: And I think it's also been helpful for us to not having had, and there are pros and cons, but we haven't had a whole lot of advisors early on because we were a bit of the fringes of the technological empire as we were building Bending Spoons.
• 1:10:25
  SPEAKER_1: And so we made a ton of mistakes we could have avoided, but also I think we did some things that in hindsight have been so powerful simply because they seem to make sense and we didn't know any better.
• 1:10:35
  SPEAKER_1: So, as usual pros and cons.
• 1:10:39
  SPEAKER_1: But yeah, what we look for in people, I would say it's really simple on the face of it, we look for people who are very strong problem solvers, who can learn very quickly, people who have a strong sense of ownership.
• 1:10:51
  SPEAKER_1: So, they really want to own their objectives, their work.
• 1:10:55
  SPEAKER_1: You don't have to check on them.
• 1:10:57
  SPEAKER_1: They'll do their very best every single day.
• 1:11:00
  SPEAKER_1: In fact, we have essentially zero process, no micromanaging.
• 1:11:05
  SPEAKER_1: It's a really high autonomy environment with the good and the bad, depending on what you like.
• 1:11:11
  SPEAKER_1: And third, I would say a trait we are really big on is team spirit.
• 1:11:17
  SPEAKER_1: We have refrained from hiring or retaining brilliant people who had too high an opinion of themselves when that disrupted collaboration.
• 1:11:28
  SPEAKER_1: We are a company where we trumps I all the time.
• 1:11:32
  SPEAKER_1: Again, for better or worse.
• 1:11:34
  SPEAKER_1: I think if those things are true of someone and they really want to ... they see their role in an expansive, horizontal way that they're not in this for just becoming the most expert Python programmer in the world, but they want to be a great 360 degree engineer who understands the business impact of what they do, who has an interest in that.
• 1:11:58
  SPEAKER_1: I think that such a person will probably do really well at Bending Spoons and love it.
• 1:12:03
  SPEAKER_0: Awesome.
• 1:12:04
  SPEAKER_0: Do I understand correctly that if I paraphrase it, you're hiring for things like drive, motivation and getting things done are talent of being able to get things and learn quickly?
• 1:12:15
  SPEAKER_0: Does that kind of-
• 1:12:16
  SPEAKER_1: Yeah, I think drive, let's say reasoning, problem solving, learning ability for lack of better term and collaborativeness too.
• 1:12:24
  SPEAKER_1: I think that's very important.
• 1:12:28
  SPEAKER_0: And collaborativeness.
• 1:12:28
  SPEAKER_0: Yeah.
• 1:12:28
  SPEAKER_0: Awesome.
• 1:12:28
  SPEAKER_0: Thank you.
• 1:12:30
  SPEAKER_0: So, I'll close with this question.
• 1:12:33
  SPEAKER_0: Why do you think no one else has attempted this really unconventional bull strategy of acquiring companies, improving their efficiency, turning it into a better version and looking at the long term?
• 1:12:47
  SPEAKER_0: Do you have any idea?
• 1:12:48
  SPEAKER_0: Did someone try it that you're aware of or not really?
• 1:12:53
  SPEAKER_1: We're not aware of any company doing what we do.
• 1:12:58
  SPEAKER_1: Well, I think first of all, it's pretty difficult.
• 1:13:01
  SPEAKER_1: We've been working at this for 11 years, so pretty hard.
• 1:13:05
  SPEAKER_1: The platform we built, the company culture, the technologies, the know how, it's taken just a ridiculous amount of investment.
• 1:13:18
  SPEAKER_1: So, it's not like something someone would just set out to do and oh, I did it, nice.
• 1:13:26
  SPEAKER_1: Even today, sometimes I wonder if I had to redo it from scratch.
• 1:13:29
  SPEAKER_1: I think even with infinite capital, it would take me maybe not 11 years, but maybe six years.
• 1:13:34
  SPEAKER_1: It's really hard to build a culture, an employer brand, and 50 plus technologies.
• 1:13:41
  SPEAKER_1: It takes forever and it's not at all just about the money.
• 1:13:44
  SPEAKER_1: So, that part is just a big barrier to entry.
• 1:13:50
  SPEAKER_1: I think it's probably the main reason.
• 1:13:55
  SPEAKER_1: Other than that, I don't know, but really the barrier to do it's hard.
• 1:14:00
  SPEAKER_1: It's a lot of work.
• 1:14:00
  SPEAKER_1: It takes a long time.
• 1:14:02
  SPEAKER_0: It's interesting because what I'm putting together is you had a bit of an unconventional start as far as a startup, because you are a tech company, you're a tech startup, hire the type of people who want to work at tech startups, but most of these companies just contrasting it, they raise a lot of venture capital early on, they got the momentum.
• 1:14:22
  SPEAKER_0: They didn't have to worry about being profitable on day one, in fact, they probably were not even profitable much later on.
• 1:14:27
  SPEAKER_0: So, I wonder if you mentioned how difficult it was to raise in Italy.
• 1:14:32
  SPEAKER_0: I wonder if this might've contributed to putting you in this unique position of struggling for a long time and building up this culture where you focus on these things that most companies don't need to focus on.
• 1:14:46
  SPEAKER_0: You just had this need.
• 1:14:47
  SPEAKER_0: And then now that the world is actually turning into a lot more efficient place and everyone's looking for efficiency.
• 1:14:53
  SPEAKER_0: Sounds like you've been doing this for quite a while.
• 1:14:55
  SPEAKER_0: No?
• 1:14:56
  SPEAKER_1: Yeah, I guess there's always a lot of process and path dependency.
• 1:15:02
  SPEAKER_1: You can go back even earlier than that.
• 1:15:06
  SPEAKER_1: But yeah, I think the particular conditions, our failed startup before, what we learned there, where we built Bending Spoons certainly have helped shape his view for sure.
• 1:15:20
  SPEAKER_3: You could say probably that seven years ago we were the company everybody's trying to build now in a sentence.
• 1:15:28
  SPEAKER_0: Oh, interesting.
• 1:15:29
  SPEAKER_0: So, now you've evolved since then.
• 1:15:31
  SPEAKER_3: Exactly.
• 1:15:32
  SPEAKER_0: So, thank you very much for sharing all these details with me and with all the listeners.
• 1:15:36
  SPEAKER_0: Where can folks find you and reach out and learn more?
• 1:15:40
  SPEAKER_1: They can send us an email.
• 1:15:42
  SPEAKER_1: There's an email address they can find on the website.
• 1:15:46
  SPEAKER_1: If they want to apply there's a jobs page.
• 1:15:48
  SPEAKER_1: We are available on most social media platforms too.
• 1:15:53
  SPEAKER_1: Always happy to have a conversation.
• 1:15:55
  SPEAKER_1: So, do reach out.
• 1:15:58
  SPEAKER_3: And if you want to witness the great Evernote reboot, you can subscribe to our YouTube channel.
• 1:16:05
  SPEAKER_0: Awesome.
• 1:16:06
  SPEAKER_0: Well, it's also linked in the show notes below, so be sure to check it out.
• 1:16:09
  SPEAKER_0: Well, thank you very much.
• 1:16:10
  SPEAKER_3: Thank you very much, Gergely.
• 1:16:11
  SPEAKER_1: Thank you.
• 1:16:11
  SPEAKER_1: Pleasure.
• 1:16:12
  SPEAKER_2: Thank you.
• 1:16:13
  SPEAKER_0: Thank you to Co-founder and CEO, Luca Ferrari, CTO, Francesco Mancone and product lead, Federico Simionato for sharing all these insider details with us.
• 1:16:23
  SPEAKER_0: You can find all of them on LinkedIn and on their social media channels as linked in the show notes below.
• 1:16:28
  SPEAKER_0: Here are my three biggest takeaways from this conversation.
• 1:16:32
  SPEAKER_0: Takeaway number one, even inside a single company, you should choose entering processes based on the maturity of the product you're working on.
• 1:16:39
  SPEAKER_0: The CTO of Bending Spoons found it completely normal that each team decides on their approach for example, on testing.
• 1:16:45
  SPEAKER_0: More mature products have more automated tests like unit integration or UI tests and new products or less mature ones will have less.
• 1:16:52
  SPEAKER_0: Same goes for releasing and experimentation.
• 1:16:54
  SPEAKER_0: So, more mature products will have more stages of releases and experimentation, but products that are just being built will not necessarily invest in this.
• 1:17:02
  SPEAKER_0: Takeaway number two, the concept of radical simplicity.
• 1:17:06
  SPEAKER_0: Now, this is something that could be applicable far beyond Bending Spoons.
• 1:17:11
  SPEAKER_0: Bending Spoons believes as a principle that they should seek out the most radical simple solution and approach.
• 1:17:17
  SPEAKER_0: When adding complexity, the person or team approaching should build proof why this complexity is beneficial.
• 1:17:23
  SPEAKER_0: Those who retain the simpler data should not have to defend this unless there's evidence and data that adding more complexity truly helps with whatever you're trying to do.
• 1:17:31
  SPEAKER_0: All of this sounds pretty common sense, so it could be worth trying it out at your workplace or team.
• 1:17:36
  SPEAKER_0: Takeaway number three, you don't need to copy popular approaches in order to become successful as a product or engineering team.
• 1:17:42
  SPEAKER_0: Bending Spoons seem to have come up with how it makes sense for them to operate and didn't copy common approaches from other companies.
• 1:17:49
  SPEAKER_0: Here are a few examples.
• 1:17:50
  SPEAKER_0: Their most popular language is Python.
• 1:17:52
  SPEAKER_0: It's pretty rare for most companies, but not for Bending Spoons.
• 1:17:55
  SPEAKER_0: At the same time, teams can choose what they use.
• 1:17:57
  SPEAKER_0: So, for example, team uses Rust and they have plenty of known TypeScript usage.
• 1:18:02
  SPEAKER_0: Another example is how they do not have career ladders like most companies their size would do, at least for now.
• 1:18:08
  SPEAKER_0: They do have some concept of levels, but for example, they have no bonuses because they figured it doesn't work as efficiently for them.
• 1:18:15
  SPEAKER_0: In some ways, Bending Spoons didn't follow any particular approach because they didn't really get too much advice in the early years, they struggled to even attract investors.
• 1:18:23
  SPEAKER_0: Still, they figure it out on their own what is it that works for them.
• 1:18:26
  SPEAKER_0: Now, if a small company in Italy with five developers could do this and they kept figuring out what works for them even as they grew, what is stopping you and your team from doing the same?
• 1:18:36
  SPEAKER_0: Figuring out what works for you and not just copying approaches that you see that work for others.
• 1:18:42
  SPEAKER_0: Thanks for listening and watching.
• 1:18:44
  SPEAKER_0: If you enjoyed the episode, I'd appreciate if you subscribed and left a review.
• 1:18:47
  SPEAKER_0: Thanks, and see you in the next one.