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

Episode Date: October 23, 2024

Brought to you by:• The Enterprise Ready Conference on October 30th — For B2B leaders building enterprise SaaS.• DX — DX is an engineering intelligence platform designed by leading researchers. • ByteByteGo — Ace your next system design interview.—You may not be familiar with Bending Spoons, but I guarantee you’ve encountered some of their well-known products, like Evernote and Meetup. In today’s episode of The Pragmatic Engineer, we sit down with three key figures from the Italy-based startup: cofounder and CEO Luca Ferrari, CTO Francesco Mancone, and Evernote product lead Federico Simionato. Bending Spoons has been profitable from day one, and there's plenty we can learn from their unique culture, organizational structure, engineering processes, and hiring practices. In today’s conversation, we cover the following topics:• The controversial acquisitions approach of Bending Spoons• How Bending Spoons spent more than $1 billion in buying tech companies• How the Evernote acquisition happened• How Bending Spoons operates and how it organizes product and platform teams• Why engineering processes are different across different products• How ‘radical simplicity’ is baked into everything from engineering processes to pay structure.• And much more!—The Pragmatic Engineer deepdives relevant for this episode:• Good attrition, bad attrition for software engineers: https://newsletter.pragmaticengineer.com/p/attrition • Healthy oncall practices: https://newsletter.pragmaticengineer.com/p/healthy-oncall-practices • Shipping to production: https://newsletter.pragmaticengineer.com/p/shipping-to-production• QA across the tech industry: https://newsletter.pragmaticengineer.com/p/qa-across-tech—In this episode, we cover:(2:09) Welcome, Luca, Francesco, and Federico from Bending Spoons(03:15) An overview of the well-known apps and products owned by Bending Spoons(06:38) The elephant in the room: how Bending Spoons really acquires companies(09:46) Layoffs: Bending Spoons’ philosophy on this(14:10) Controversial principles(17:16) Revenue, team size, and products(19:35) How Bending Spoons runs AI products and allocates GPUs(23:05) History of the company(27:04) The Evernote acquisition(29:50) Modernizing Evernote’s infrastructure(32:44) “Radical simplicity” and why they try for zero on calls(36:13) More on changes made to the Evernote systems(41:13) How Bending Spoons prioritizes and ships fast (49:40) What’s new and what’s coming for Bending Spoons(51:08) Organizational structure at the company(54:07) Engineering practices(57:03) Testing approaches(58:53) Platform teams(1:01:52) Bending Spoons tech stack and popular frameworks(1:05:55) Why Bending Spoons hires new grads and less experienced engineers(1:08:09) The structure of careers and titles at Bending Spoons(1:09:50) Traits they look for when hiring (1:12:50) Why there aren’t many companies doing what Bending Spoons does —Where to find Luca Ferrari:• X: https://x.com/luke10ferrari• LinkedIn: https://www.linkedin.com/in/luca-ferrari-12418318Where to find  Francesco Mancone:• LinkedIn: https://www.linkedin.com/in/francesco-manconeWhere to find Federico Simionato:• X: https://x.com/fedesimio• LinkedIn: https://www.linkedin.com/in/federicosimionatoWhere to find Gergely:• Newsletter: https://www.pragmaticengineer.com/• YouTube: https://www.youtube.com/c/mrgergelyorosz• LinkedIn: https://www.linkedin.com/in/gergelyorosz/• X: https://x.com/GergelyOrosz—References and Transcripts:See the transcript and other references from the episode at https://newsletter.pragmaticengineer.com/podcast—Production and marketing by https://penname.co/. For inquiries about sponsoring the podcast, email [e-mail]. Get full access to The Pragmatic Engineer at newsletter.pragmaticengineer.com/subscribe

Just to confirm, like, for the products that you operate, this is kind of like a core principle of 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. We actually try not to have an on-call scheme at all on many of our products and technologies. 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, 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, it's not the same. Raising capital in Italy was borderline impossible. Our model is so unusual. No VC would be interested in investing. And I believe that it gives us an edge over some of the competitors.

I do not frequently hear loans from traditional banks with startups. Evernaud and Meetup are two products many people have heard about. But what about the company called Bending Spoons? Bending Spoons is an 11-year-old startup, headquartered in Milan, Italy, and they own and operate both Evernote, Meetup, and a bunch of other products. Bending Spoons is a fascinating company. They started out as five developers building small mobile apps and have now grown to about 450 people,

surpassing $700 million in annual revenue. 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 on acquisitions. It's rare to hear about a European company buying Silicon Valley companies and I was excited to learn more straight from the source. In today's episode, we do a deep dive on how the ever-known acquisition happened and why the complete backend needed to be rewritten.

We look into how Bending Spoons typically operates and how it organizes product and platform teams. But we'll start with the elephant in the room. Addressing a pretty controversial perception on how Bending spoons acquires companies, 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. So let's jump in. Hello, everyone.

Today I'm happy to have the bending spoons team here with me. We have Luca, Francesco, and Frederico. Luca is the co-founder and CEO of the CEO. Francesco is a product lead at Bending Spoons. Welcome to the podcast. Thank you. Thank you very much for my as being here. So I have to admit, even a few months ago, I had not heard of vending spoons.

At the same time, things that I have heard about and used are EvernoteMeetup.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. It was actually the Evernote acquisition that I first, you know, like connected the two together. But the interesting thing is that bending spoons is probably the most single sought after company in the tech company in Italy.

When I first tweeted about bending spoons and how I discovered the interesting things that you're doing, I had Italian developers paying me and telling me, oh, I actually applied to bending spoons. They're the hottest place to be in Italy. And I asked them, when did you apply? And they told me, oh, it was like four or five years ago. So they already knew that something really different and exciting was happening at the company. The first time you came up was when you acquired Evernote, but you operate other apps and products.

Which ones are you known for? You correctly mentioned Evernote as one of the most. most well-known businesses we have acquired. Meetup 2. We have acquired Mosaic, which is a collection of mobile products from interactive corporation. And we've acquired Hoping and Streamyard, possibly the most popular recording and live-streaming suite of features a product in the world. More recently, issue for digital publishing and we transfer for.

digital file storage and transfer. 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 100 million amount of users. But we have been doing this for a decade, and we have acquired dozens of businesses. These are just the most well-known ones. This episode was brought to by the Enterprise Ready Conference. One Day Event in SF, bringing together product and injuring leaders shaping the future of

SaaS. The event features a curated list of speakers with direct experience building for the enterprise. Speakers include people from OpenAI, Vanta, Checker, Dropbox, and Canva. Topics include advanced identity management, compliance, encryption, and logging, essentially yet complex features that most enterprise customers require. If you're a founder, exec, PM, and engineering tasks with the enterprise roadmap, this conference is for you. You'll get details insights from industry leaders that have years of experience navigating the same challenges you face today. And best of all, it's completely free since it's hosted by WorkOS. Spots are filling up quickly. Make sure to request an invite at EnterpriseReady.com. That is EnterpriseReady.com.

This episode was brought to by DX, a platform that helps organizations measure and improve developer productivity. The DX team includes notable researchers behind the frameworks like DevEx and space, so they're constantly asked by leaders, what metrics should we use to measure developer productivity? To help simplify the landscape, DX just recently published the DX core 4, a unified framework for measuring developer productivity that encapsulates Dora, space, and DVEX. The DX score 4 includes four dimensions, including speed, effectiveness, and quality that provide a focused set of metrics that help track productivity at all levels of the organization. You can learn more about the DXCore 4 and how it's being using

companies like Dropbox, Etsy, Versal, and Pfizer at getdX.com slash core 4. Again, that's getdX.com slash core 4. I'd like to address an elephant in the room in terms of the perception of a bending spoon.

So, you've already touched on this, but I just really want to like double click on it. Because from the outside, when you search for bending spoons, often things in the press will come. up, oh, they acquired Evernote and then they reduced the original team. Oh, they acquired meetup and then they reduced the original team. Oh, they acquired this other company and they did that. 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. But how do, and this is just one side of a story. Obviously, this is the external, I guess, the hard numbers or the things that make the rounds and make people pay attention and and you know, form opinions. How do acquisitions really look like from the inside? Like, what is your approach? Because I'm, I'm going to just assume that it's likely not like we're going to cross off. Like, that doesn't make sense to acquire a company when, you know, like, it sounds you want to make more of this. How do you approach it? Yeah, definitely. I think, given that we, they require companies to to own and operate them forever. And given that we do so, our own money, we're not a fund, we're not raising capital from investors to buy companies,

we're using our own money. Pretty much all of my worth is in many spoons, and so is the case for most people here, including Francisco and Federico, we would want to do the best we can with every single acquisition with a long-term view, which is what we do. The way we approach it, I described earlier a little bit, we will first of all go through a phase of learning. 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. 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. And so we go through a learning phase and we really look at the details. We go hands-on, very deep across the board. And the more we do this, the better we become recognizing patterns and so we get faster are 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. And then, as I said, we try to close that gap between the status quo and that vision as quickly as we can. Often, there is a gap in how we want the organization to be structured. Often, we want it to be a much smaller organization where people have 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, so massive focus, massive leanness and autonomy. Making that change, and I'm talking again, particularly the organization, such as a layoff, sucks. It sucks primarily for the people or let go, of course. It's also not enjoyable for for those of us who implement it.

And naturally, we have empathy for those people. We try to do it in a way that as supportive, financially, logistically, emotionally, emotionally as we can. But it still sucks. You know, there's no way around it. 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.

And, you know, we understand we'll take flag for that in the press and it's fine. 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 these businesses and a project like Evernote, I think, represents our trajectory well. reaction was like, oh, this is terrible. A company buys another company and then let's a bunch of people go, how terrible, let's say with Evernote. But then I was kind of thinking a little bit further and thought, like, hold on, 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. This was, I mean, in this case, this was a struggling company. And to take that company to a successful company, If it would have been easy, it would have clearly been done. 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. I mean, if they would have been doing amazing, they probably would have not sell. Like, I don't know, it sounds like bending spoons does not want to sell right now, right? So if you're successful.

We didn't steal any companies. Exactly. We didn't steal them, I promise. So these are companies are actively looking for a buyer for some reason, either because they're strongly or not. And I mean, it sounds like, you know, they've been through the, the what are easy solutions. And what I thought about this well, I mean, in my view, a company that goes through painful, is transition and then becomes successful in the long term or a product is probably better than one that slowly dies.

And we've seen recently a lot of startups that just shut down and after they couldn't find anything. So that's just, you know, I was, it's not all black and white, right? No. And I think, you know, 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. I will say this. To simplify, the world seems to be divided into two camps. 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. Some people think that,

And these people think that bringing the business from a six out of ten to a nine out of ten, if it means going through a painful decision such as a layoff, it's evil. And then there are people who think that as long as you act empathetically, supportively, you should try to run a business in the most effective, efficient way you can. And that if doing so means going through a hard decision like a layoff, you should do it. Again, trying to be super supportive financially and logistically and emotionally, but still do it. We, of course, the latter view is more kind of free market view, the former, you can give its name.

We belong in the latter camp, but if you belong in the former camp, there is nothing I can say to convince you. You will believe we're evil and call us evil. There is a different in the underlying deep assumptions of what one should strive to do. 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 their way out as well as we can, to monetize a product as efficiently as we can, and be rational and scientific about it. So that's what we are.

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. If someone sees the world in the former way, we fully respect that. It's almost a political view in a way. And it's a totally fine way of looking at the world, but then they will never. like us. There's nothing we can say to change your mind. Yeah, and I respect that, right? I think as long as you're open with what your values are, what you're doing, and I think, you know, for example, Netflix is a very good example. They also

are known to have a very harsh culture. They have the keeper tests regularly challenging people, but they publish this. 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. It's just some companies are a bit harder to figure. out because they don't talk about this. So again, the fact that we're actually talking here, this is actually helpful. We are very transparent about it. We share a lot of stuff on our website, including policies and whatnot. 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 implemented

the company that some people may consider controversial, 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. So we see the company in the same way as you would see, you know, an ambitious basketball team or football team. 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. So we tell you up front, we're super.

honest about it. And again, someone who's seeking a place where everybody is trying to be absolutely great professionally will have a blast because talent density is sky high. Someone who's not seeking that sort of one foot outside of your comfort zone all the time place will not like it. And I think both views are absolutely respectable and understandable. You just need to be honest about who you are. And that. And then it can be a match made in heaven. Yeah. And by the way, it's good.

Working at Bennings Pools, 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, about 1% per year. 1% per year churn. Yeah. Unwanted churn. And if you look at our glass or reviews. I think we called unregard attrition, the official.

But yeah, people who, yeah. Yeah. Wow. If you look at our glass or reviews, I'm not aware of many companies. with, you know, such high, high support. So, but, but, but yeah, it's not for everybody. It's really not for everybody. Yeah, that, that is very, very low.

Indeed. Yeah, so surprising because, uh, I, we did a, I did a newsletter issue on this. 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. So one, one percent is, is, it's truly impressive. Yeah, literally like a handful of people out of 450 per year, like 3, 1, 5, something like that. Well, you must be doing something right. And when you do have this type of information to look on, that's actually quite helpful.

I feel more companies could look at this data because it is quite telling. And I'm assuming you have ex-ed interviews with people who leave as well, right? We should probably put this in our website somewhere. I think people should know about it more. Yeah. 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, you know, queries per second, revenue, the things that can help place how large and high, low, bending spoons is? So we're currently at around $700 million in revenues. We've been profitable every year since we funded the company 11 years ago.

we serve well over 200 million man elective users across a few dozen products and in terms of team size excluding the most recent acquisition of we transfer we are a little over 400 right now I think 450 give or take and if you include we transfer over 800 people work at vanish points we run multiple products I think it's north of 100 digital products at the moment 100s are new products wow that's yeah I mean it's keep growing but it's already like a I mean I think it's an important number we we don't only take care of the developing the core features of this product 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. Just thinking about all the services that we provide from the platform, we're talking about more than 100,000 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 like 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. Can we talk about your AI products and specifically the AI load there? Because I know Remini, it's a very popular AI application, But how does it transform into like GPUs?

At the moment, I believe on average daily, we do more than 2,000 inferences per second. 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 440. thousand GPUs that we need to sort of allocate dynamically, because as you can imagine, they're very pricey and we need to be to run the infrastructure at the maximum efficiency. Not everybody may appreciate how here there's a double problem to be solved. On the one hand, you want to deallocate GPUs you're not using so as to save in terms of

financial costs. 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. There are different ways you can do that depending on the platform, but that also has a cost. 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. 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. And do I understand correctly that, you know, 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 will just, they'll just, you know, 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. But it sounds like you have another constraint here. right? Yeah, definitely. We have run the company profitably every year initially because, you know, 2013, 2014 raising capital in Italy, because that's where we're headquartered. We have people all over the world, particularly Europe, but we started off in Italy. So that's where we had, you know, the financing questions early on. And raising capital, equity capital, a decent terms in Italy in 2014, was, I would say, borderline impossible.

And then I think today things are much, much better. I'd like to believe also thanks to Ben Spoon's having been a success case and such attracted international capital, but at a time, you know, we didn't have access to it. And also our model is so unusual that we felt no VC would be interested in investing. So we had to develop that profitability muscle from early on. I think in hindsight it's been a good thing. 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 forces to be extremely efficient and thoughtful about their allocation of resources, more autonomous and independent. And I believe that scarcity of resources has bred resourcefulness and 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. Yeah, so I do not frequently hear we took loans from traditional banks with startups.

In fact, you're the first one when I hear that. But let's talk about this history because today you're you said you're more than 400 people, you're headquartered in Milan, Italy. But you started this company 11 years ago. 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. Can you talk about that?

Right. So I graduated in Copenhagen, Denmark, studied engineering. and with two friends at the time, we started a company called Evertail, and the vision was to create a self-rising diary of a user's life using AI, so you 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. I think AI in 2010, this is 2010. I believe you only heard about it in academia. I don't think people were talking about it much in the mainstream media. So we built this app. It actually worked reasonably well, but it was a commercial failure.

And then on the ashes of that project, we were left with about $40,000 of VC money. In that case, we had raised $1 million or about that in VC money. And 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. for $1 because they didn't want to go through the pretty cumbersome liquidation process. The $40,000 would have been theirs. They had liquidation preferences. But again, for simplicity, they sold us the shares.

That amount of money, which was very substantial to us, was peanuts to them, pretty large fund. And so we ended up taking out these $40,000 from that failure. And that was the seed money for Bendings Spoons, which started in Copenhagen. in 2013 with that $40,000. The same three people who started Evertail plus two people who had been hired at Evertail and turned out to be particularly capable. And so we asked them to co-found Benin Spoons.

So we started with that amount of money, invested in the first acquisition soon after, I think, 2014. So at around the same time, we moved the company back to Italy. Again, at the time, it was just the co-founders. And, you know, we invested in the first acquisition $10,000. What was this first acquisition? So that one was a, an app, an iOS app to personalize your keyboard, very simple. I believe we bought it from a one-man show developer from somewhere in the world.

I don't remember, frankly, where. And we tried to improve it, ultimately turning that $10,000 investment. went 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. And so you fast forward around 10 years later, we're now acquiring companies in hundreds of millions of dollars in price. We've invested more than a billion dollars in acquisitions and hundreds of millions of

dollars in research and development. But yeah, it's been a pretty steady-paced journey since then. And what was like a bigger milestone? Like I imagine clearly ever know it 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? 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. 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. can you tell us about how this acquisition happened from your point of view? The short of it is we came to know that Evernote could potentially be acquired around late

2022. 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. and you always have to go through antitrust clearance periods and so on and so forth. 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 Bendings Springs, 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. They talk to almost everybody, look into almost every line of code or module, read many documents around 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 of 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 is 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 embats 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 state of school and that vision across the board as quickly and as fully as we can.

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 and opportunity to look at a pretty established product and see, you know, like, what are the bottlenecks and how can we improve it? So the first thing we noticed when we acquired Evernote, I think, that's what was a, 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. And that migration was, of course, supported by, the cloud provider. It was made in a 101 fashion, meaning that it wasn't really happening. Evernote didn't, let's say, reshaped the infrastructure or the architecture, making it cloud-native. And as a result of this, we found herself with a monolith, a huge one, It was a Java 11 monolith And he was running on Virtual machines on Google Cloud

But they were sort of manually provisioned There were 750 machines Rural machines All of them were manually provisioned And Ouch Users data were sharded Among all of these machines

That sharding was not even After Toro analysis It doesn't even have us prune to be even, meaning that certain machines have heavier, louder than others, significantly heavier. And sometimes that caused it also a lot of interventions, a lot of maintenance. We had to realize that own calls were actually very needed. You know, we have, 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 objective 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 that... So just to confirm, like, for the products that you operate, like, this is kind of like a core principle of, like, 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. Not even that. I think it's even more than that, Gargaly, we actually try not to have an uncalled scheme at all on many of our products and technologies.

So the goal is, yeah, but I think, yes, however, knowing that you don't have that fullback, 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 were 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. I love the different thinking because I think in the industry is kind of a given, like, look, we generate a lot of revenue. We can afford to do on-call.

And we'll pay engineers a bit of extra. 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 do it differently. Let's take from this principle. 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.

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. Additionally, we encourage people not just not to add, complexity, but to look for ways they could remove complexity. So we constantly question whether are any system, really. And it's not just technological systems.

It's also policies could be made simpler. And we've plenty of examples of systems that I think were reasonably simple to start with and made radically simple because of this approach. One being pay at Benisphus originally years ago we had bonuses and stuff. Now for many, many years, we've had fixed pay for. for everybody. 100% fixed. There's only a salary and people can choose to receive a percentage of their salary in equity

if they so wish. And you put it on your website, right? I saw that. Yeah, I think so. I think so. Yeah, we tried to be quite transparent about that stuff. So, you know, there was a theory early on that bonuses would somehow drive superior performance. We documented ourselves on the topic in the literature.

We had discussions. We ultimately said there is very. is very weak evidence that they do. There is certainty that there are a big pain in the ass to manage. Of course, you know, set targets, discuss, you know, I deserve it. I don't deserve it. It's not nice for anyone involved. And so we figure, let us have just fixed pay.

We trust everybody working here that they want to do the best job they can. And, you know, if they don't, it's a different type of problem. We shouldn't need a bonus to drive performance. And we haven't looked back. I mean, we don't even dream of adding bonuses back to the economy. question. Awesome. And going back to Evernote, so you said, okay, here was a technology, Java 11 virtual machines, some of the manually provisioned. What did you decide to move it on? What is Evernote on these days in terms of the technology stack architecture, how did you make it more cloud native?

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 that was one of the biggest weak point in our opinion. So the first thing we did was migrating all the data from the shards from the virtual machines to a managed database structure that allowed us then to move freely with the application logic in the best possible way. 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. 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. So we had to actually come out, to come up with a plan that was, let's say, taking into account how to move all that core logic about nodes that without, without disrupting the user flows. 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 back end. Substantially before the clients were polling continuously,

bombarding the classic 2010s. Exactly, you know how I went, I can go. It was very heavy to manage and also the clients 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. As you can imagine, Evernote is also about synchronizing events that can happen from the client to the backend. Sometimes some mutations happen on the client. they need to be propagated to the back end 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. So what we had to do, was to move from this polling mechanism to an event-driven communication. We were 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 NSYN, which was basically a downstream event-driven mechanism that allowed, that allowed the clients to just receive all the events from the backend real time.

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 while before wasn't the client. And making that change, though, we made sure that a lot of data synchronization synchronization issues just disappeared because on the back end 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 if it's a software engineer you want to take your system design interview preparation to the next level, check out Bytebygo.com. BiteBytego provides a proven force of framework, detailed case studies, and access to their exclusive Discord community. 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 bitebitego.com to sign up and try it out for yourself.

That is bite-bytego.com. So how did you get to this really fast shooting cadence? Frederico, you were telling me that you, you, you were telling me that you, you, you you committed in 24 to ship 100 updates. And I saw your blog on how you shipped 20 improvements in, I think, April, 30 more in July. It's a really big step-up pace from before. How did you structure yourself or like how did you just speed things up so much?

Yeah. So we approach these things in a variety of ways. So we do have some bigger tracks that take longer to develop. And so like big projects like the ones Francesco was mentioning, of course, like take months and we cannot ship them out every week or two. 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 like easy to build in a sense. And so given that we try to give a lot of autonomy to product teams, as Blueca 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. And so we kind of try to rank the list by both metrics in a sense. And we just started shipping stuff very quickly. A few examples are like, for instance, collapsible sections inside the note editor. Evernaut was missing this feature and we were able to build it in a couple weeks. Other examples are like slash comments

through which you can hit slash and select an item to add it to a node. There are other examples, but basically the point is, while there are projects that are longer and that need to go through like some migrations or stuff like that, in other cases,

it's much more, the value that we build is much more related to the UX or simpler features. And so we try to prioritize those because that way we can build stuff more quickly. And did you prioritize this to get an impression of, like to, you know, get the team motivated to ship things, to show it to people? Or were there other reasons? Because it actually sounds really smart to, you know, mix the easy and visual things and then do the hard and long thing kind of on the side together. Sounds like that's what you're doing, right? We're doing both. Showing both externally and internally what we're building is easy when you're shipping a product feature.

It's kind of harder to communicate when you are changing the way metadata synchronization works, for instance. 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. Performance increased a lot of variability too. So we do try to communicate that. organization actions now take a fraction of the time they used to literally one-tenth or one-twentth of the time they used to. And that's the kind of stuff you love of a product without knowing you love it. Like you just assume it's fast and so it's fine. If it's slow,

you complain, but if it's fast, just assume it should be fast. So it's quite difficult from a point of view of your relationship with users and customers, colleague marketing to highlight that stuff as you're working on it, whereas it's a lot easier to empathize or relate to a particular clear feature you're developing. So yeah, we do try to do both to make everybody happy, although of course not everybody's happy. 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 CICD pipeline. I think it's worth saying that we made huge advancement in that regard.

It was also a lot of work, but before most of the releases of the clients and the backends were required a lot of manual steps, some of the pipelines, most of them were on self-hosted Jenkins. just to give you a sense and we moved to Circle Sciai with our the herbs that we built in the years that we polished a lot, we know what to expect

or what to not that definitely helped the team also ship faster, I'd say on top of that switching to the next exciting challenges for the platform of EvanNote technologically speaking, I believe we're closer than ever now to the complete dismissal of the monolith,

the infamous monolith, you know, like the engineers in the team now, they refer to it as an entity from the, yes, it's a villain, something to be afraid of, really, to fear. we worked a lot to piece by piece remove all the dependencies that didn't allow us to sunset it. We're closer than ever now. We just completed the rent effort to move everything on the event-based interactions

that I were mentioning to you before. And as soon as we get to the finish line, I believe that's going to be one of the most exciting moment for the Avernote engineering team, because at that point we'll be ready to finally reshape the system entirely to make it much more efficient. At the moment, let's say, for instance, just to mention a few, there is, in our opinion, many more microservices that actually needed. You know, what's the trade-off with microservices? You need them, of course, but sometimes, it can get out of ends. It can be hundreds.

Sometimes, like, only the boilerplate of shipping a microservices to just handle a very tiny portion of the application logic can become, you know, too much simply. 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. get rid of the huge legacy. So everyone is looking for that. All the people are, you know, the engineers are, keep thinking about what's going to be

the next, the proposal that they want to do for what's going to be the next architecture of the Evernote system. We just need to finally sunset the monolith. We're very close to it. We committed ourselves to completely sunset it by the end of the year. we're doing our best. I think we're pretty close. And so far, everything is on track.

Yeah, it's awesome because I remember when we sunset at a monolith back at Uber, and it's so hard to tell externally, I mean, assuming, you know, 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, his update, we've sunset the momentous because for them literally like a good monosone, Sunday is. is nothing changes, right? Absolutely. Although we try, we try to explain the importance of it.

But yeah, understandably people care more about, like, their experience, although that influences it greatly. 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, then to the users outside. So I believe we're very lucky here to be able to voice engineering needs and, you know,

put them at the center of the roadmap for the product. And what are some of the products, things that you're looking forward to? Yeah, we recently released what I believe from my tests, at least, is the best AI transcription feature available on any. not taking product. It basically allows you to upload a video, audio or image file and hit the button and like basically one click, transcribe it. So you get a bunch of text as output. It's pretty fast, super accurate. 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, 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 cut in edge again, in a sense. So that's one thing that we're doing. Okay. Thank you. And switching to a different topic, although somewhat related, so we talked about how you built Evernote, how you acquired it, how you how you've balanced architecture and features. But within bending spoons, how do you typically get projects done. And, you know, like, what I'm interested in is how typical is Evernote versus not. 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? Well, I guess it helps to describe how we're organized. So we have different business units, one, you know, Evernote being one. And these business units have dedicated management teams and resources, software engineers, data analysts, scientists, product designers, so on support, depending on the needs specific of that product and business. And we encourage them to operate largely autonomously. And then we have a shared platform, including several platform teams. And what the platform does is it supports and serves at a different business unit with tools, services that are relevant, generally speaking, to most of them. Some of this is as basic as accounting, finance, so and so forth. 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 behavior and value, AB testing systems, automations for marketing, we spend tens of millions of dollars in marketing each year and it's almost entirely run by machines. 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. So we trust people to set intelligent objectives and try their very best to achieve them. And this really is not limited to engineering. It's a cultural trade at the company.

And so it works at every scale you look at. 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. They can make their own decisions, on their mistakes, on their failures. but also in Evernote, the smaller squads taking care of the various missions or objectives also will have a broad mandate on how to pursue them. We will not impose any particular technological stack on them. We will not impose any particular type of process on them.

There are guidelines. There are lessons learned. And people at the platform level are experts at the platform level are always available to coach help support. ultimately we trust people to to take full responsibility for for their actions. Awesome. And in terms of engineering approaches, which ones do you? I mean, we mentioned CICD 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? I'd say following the lines of what Luke already said,

it's important for us to not be prescriptive and the tools and the methods that we want to follow across the different business units or across the different teams. Tools are tools that are meant to help to achieve a certain objective. Processes have the same objective, let's say. Some teams are more used to follow certain processes than other. We give the team the freedom to choose whatever. they believe is the most effective approach.

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. 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. But in Bending Spoon's, I'd say software engineers really care about the product and the end result of it. So doing white boxing QA is something that they take very seriously. They dedicate a lot of time. Of course, it's also about building

the right developer experience. Otherwise, it becomes very cumbersome. we know very well. But on top of that, then of course, Black Box QA instead is done by the QAer testers. We make sure that everything that can be tested by software engineers before is properly tested. 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 terms more productive and also happy about what's up and next because it's let's say it's more rare to ship bags into production if you build the right developer experience and also

gave shared responsibility to everyone about testing their code base and how big are you on automated testing in terms of like unit integration end to end some of these things you didn't mention manual testing which obviously is important but like

or is it more per app per product, whatever makes sense for the maturity of the product? Yeah, that's the point. I think it depends a lot of the maturity on the product and also what's the real estate, for instance, for that product. 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. We try to reach the right level of coverage.

We try also to be pragmatic, meaning understanding what are 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 positive. 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. We have seen multiple times in the past. We improved a lot in time, of course. but that has been some of the things that, you know, we've seen improving a lot the life of engineers after not fighting, let's say, not finding themselves fighting with false

positive all the day. Am I guessing correctly? Because you mentioned you have about 100 products and you mentioned you have internal teams for some of these shared things. You must have platform teams, right? Yes. And what kind of platform teams do you have? what to do this platform engineering teams, that is?

We have a team we call it foundations technology. 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 this utilities can be used by the business units. if they want. Typically, these are tools and technologies that requires a lot of investment to be done. And if you don't have a wide portfolio products, usually you don't find it a good investment or like it's a big investment that you might not experience returns in the right time horizon. In our case, we have this luxury, let's say, that when we build

a platform tool, it can be applied at scale, so we have the, let's say, the opportunity to make such investments and to see the results at large. So the foundations 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 that allow us to, for instance, collect and define metrics, for the different products, we can track all the data among the different products with the same, let's say, formats,

data pipelines and stuff 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 it's a two-way street by the way so if a business unit has a

need that's incremental to whatever shared technology is available they can improve it and 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 we had so it's just such situations with whether you know whether it's knowledge or an actual uh improvement to the software we've had plenty such cases whether it's authentication being made more resilient against abuse whether it's a our payment processing systems handling more extreme loads or corner cases and certain particular type so all the sort of things uh it becomes a shared benefit across the whole company awesome and speaking of

technologies, what type of technologies, frameworks do you use inside the company, or just the most popular ones at least? Yeah. So I'd say, well, the most popular backend language that we use is Python. We use Fast API, for instance, to ship APIs. 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. TypeScript in that regard is particularly useful because they can move from clients to backend easily. We, it's on OJS, we use Swift and Kotling to build native iOS and Android apps typically, but we also rely on React when it makes sense. We use Electron, what else? we actually have a quite wide tool set. 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. So we find ourselves frequently evaluating if there is a different technology that can work better to achieve a certain goal. Of course, if a certain goal can be achieved with different tools, they're equivalent in terms of output, 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. It helps 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.

Can you tell me an interesting technology or like 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. Do you have a like a fun example of that? Let's say. Let's see. We have our tool for attribution for marketing attribution. We built our own internally. Usually most, most, the player outsides rely on mobile measurement partners, you know, such as adjust, Couchave or Apps Flyer. At a certain time over, let's see, of the, when it was the right moment, we decided to build our own internal tool. As you can imagine, that must be able to handle huge loads with very high efficiency. We have seen that,

Rust was the right language. Nice. It's a peculiar, let's say. Rust is good for performance, isn't it? Exactly. Yeah, we loved it. 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.

It was clear from, let's say, an engineering perspective, just looking at the numbers. So, yes, we went for Rust, and at the moment, or internal tool for attribution, Xena, we call it, it's steel and rust and it's working. That's awesome. Be careful. It's popular. It might be spreading inside the company.

Oh, yeah. I mean, I would be happy about it personally. We can talk about it another time. One thing that is really unusual about bending spoons. I went to your career page and most career pages, you know, 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. And I saw junior engineers, I saw internships posted.

Actually, most of, a lot of them were clearly entry-level engineers, which is refreshing to see. How has this always been the case? And what is your philosophy behind this? 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. We always have favored.

hiring new graduates or inexperienced people. And there are two reasons for it. One is when you hire, there's a trade-off between a few things, certainly talent and experience. And so the more you want to optimize for talent, the less experienced people will be on average and vice versa. Experience we can provide a new hire width over time, particularly high quality experience being surrounded by great colleagues, working on really

challenging projects at a high pace, talent we cannot teach. And so given they were so long-term-oriented and we want to maximize our level of competence or success with a 5, 10, 20-year view, we favor hiring individuals who are more talented, even if we have to be patient for a couple years or how long is needed for them to ramp up in terms of experience. That means we need to invest heavily in training, coaching, but we do that eagerly, given the great benefits involved for not just benefits, but also the people we hire. 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. So we do hire experienced people, but we now have a preference for

inexperienced ones. Awesome. And when people join Benning Spoons, what does career go look like? Do you have a concept of levels or titles or because again, you did mention that you, you do optimize, you have this principle of simplicity. I'm curious how career fits in here from a software engineer's perspective. Yeah, it's, it's a, it's a, it's a, it's a, it's a, It's very simple relative to our understanding what standard out there. We don't have any titles. So if you're hired as a software engineer, you are and always will be as long as, you know, that's what you do called software engineer internally.

And you can choose your own title for whatever external reasons you like your CV, LinkedIn. We only ask that you don't do something that would embarrass us, like calling yourself the CTO if you are a new hire, something like that. But if you want to use senior staff, triple. senior, any of that is fine by us internally or just a software engineer. All managers are simply called leads. Super simple. We have a few levels. They're very few. The difference is pretty substantial. And so we don't try to resolve finer deltas in your contribution. And if you need very frequent, very specific adjustments, we're not a company for you. If you're happy to look at working at Benin Spoon with a multi-year, very long-term view and you're looking for big jumps

when you've 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. So I'm hearing a lot of things are just quite different to how most companies operate. And usually I find that a big difference that, you know, we can 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? How would you describe them? Because I think this could help understand

a little bit of, you know, what makes your culture possible. Yeah, that's a good point. I think, by the way, hiring primarily inexperienced individuals helps because they don't come with the baggage of how it's done and they will look at it from a blank slate. And I think it's also be 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 Benin Spoons. 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

simple because they seem to make sense and we didn't know any better. So, you know, as usual, pros and cons. 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. We can learn very quickly. People who have a strong sense of ownership, so they really want to own their objectives, their work. You don't have to check on them. They'll do their very best every single day.

in fact we have essentially zero process no micromanaging it's a really high autonomy environment for you know with the good and the bad depending on what you like and and third i would say a trade we are really big on is team spirit we have refrained from hiring or retaining brilliant people who had to hire an opinion of themselves when that disrupted collaboration we we are a company were we Trump's eye all the time, again, for better or worse. I think if those things are true of someone and they really want to, they see their role in an expansive, horizontal way, they're not in this for just becoming the most expert Python programming in the world, but they want to be a great 360 degree engineer or understands the business impact of what they

do or has an interest in that. I think that, some of the, such a person will probably do really well at Benin Spoons and love it. Do I understand correctly that, like, if I paraphrase it, you're hiring for things like drive, motivation and like getting things that are like talent of being able to get things and learn quickly. Does that kind of? Yeah, I think drive, let's say, reasoning, problem solving, learning ability for lack of better term and collaborativeness too.

I think that's very important. Collaborativeness, yeah. Awesome. Thank you. So I'll close with this question. Why do you think no one else has attempted this really unconventional bold strategy of acquiring companies, improving their efficiency, turning it into a better version and looking at the long term? Do you have an idea that someone try it that you're aware of or not really? We're not aware of any company doing what we do. well I think it's first of all it's pretty difficult we've been working at this for 11 years

so pretty hard the platform we built the company culture the technologies to know how it's it's taken just a ridiculous amount of investment so it's not like something someone would just set out to do and oh I did it nice you know even today sometimes I wonder if I had to redo it from scratch. I think even with infinite capital, it would take me maybe not 11 years, but maybe six years. It's really hard to build a culture,

an employer brand, and 50 plus technologies. It takes forever. And it's not at all just about the money. So that part is just a big barrier to entry. I think it's probably the main reason. Other than that, I don't know.

But really the barrier to do it, it's hard. It's a lot of work. It takes a long time. And it's interesting because what I'm putting together is, you know, you had a bit of an unconventional start as far as a startup. Because you are a tech company. You're a tech startup. You 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. They didn't have to worry about being profitable. And they want, in fact, they probably were not even profitable. much later on. So I wonder if you mentioned how difficult it was to raise in Italy, I wonder if this might have contributed to putting you in this unique position of struggling for a long time and building up this culture where you focus on, you know, these things that most companies don't need to focus on it. You just had this need. And then now that the world is actually turning into a lot more efficient place and everyone's looking for efficiency, you've been, sounds like

you've been doing this for quite a while, no? Yeah, I guess there's always a lot of process and path dependency. You can go back even earlier than that. But yeah, I think the particular conditions are failed to start up before what we learned there where we built Benin Spoons certainly have helped shape this view for sure. You could say probably that seven years ago we were at the company, everybody's trying to do now in a sense. Oh, interesting.

So now you've evolved since then. Exactly. So thank you very much for sharing all these details with me and with all the listeners. Where can folks find you and reach out and learn more? They can send us an email. There's an email address they can find on the website. If they want to apply, there's a jobs page. We are available on most social media platforms too.

always happy to have a conversation. So do reach out. And if we want to witness the great Evernote reboot, you can subscribe to our YouTube channel. Awesome. It's also linked in the show notes below, so be sure to check it out. Well, thank you very much. Thank you very much, Gary. Thank you.

Thank you to co-founder and CEO Luca Ferrari, CTO Francesco Mancone, and product lead Federico Similato for sharing all these insider details with us. You can find all of them on LinkedIn and other social media channels, as linked in the show notes below. Here are my three biggest takeaways from this conversation. Takeaway number one. Even inside a single company, you should choose engineering processes based on the maturity of the product you're working on. The CTO of Bending Spoons founded completely normal that each team decides on their approach, for example, on testing. More mature products have more automated tests like unit or integration or UI tests, and new products or less mature ones will have less.

Same goes for releasing and experimentation, 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. Takeaway number two, the concept of radical simplicity. Now, this is something that could be applicable far beyond bending spoons. Bending spoons believes, as a principle, that they should seek out the most radical simple solution and approach. When adding complexity, the person or team approaching should build proof why this complexity, is beneficial. Those who retain the simpler status 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.

All of this sounds pretty common sense, so it could be worth trying it out at your workplaces team. Takeaway number three. You don't need to copy popular approaches in order to become successful as a product or engineering team. Bending smooth seems to have come up with how it makes sense for them to operate and didn't copy common approaches from other companies. Here are a few examples. Their most popular language is Python. It's pretty rare for most companies, but not for bending spoons. At the same time, teams can choose what they use, so, for example, a team uses rust, and they have plenty of no entire-script usage. Another example is how they do not have career ladders, like most companies their size would do, at least for now. They do have some concept of levels, but for example, they have no bonuses because they figure it doesn't work as efficiently for them.

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. Still, they figured out on their own what is it that works for them. Now, if a small company in Italy with five developers could do this and they could figure out what worked for them even as they grew, what is stopping you and your team from doing the same? Figuring out what works for you and not just copying approaches that you see that work for others. Thanks for listening and watching.

If you enjoyed the episode, I'd appreciate if you subscribed and loved your review. Thanks and see you in the next one.