Just to confirm, like for the products that you operate, this is kind of like a core principle. 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 fullback as a software engineer, as an infrastructure engineer, really breeds that, as I thought about the corner cases, I've 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 BC would be interested in investing. And I believe that it was an edge over some of the competitors.
I do not frequently hear loans from traditional banks with startups. Evernote 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 dollars 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 in 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 Evernote acquisition happened and why the complete back and 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 and the root. 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 Franchesco. Luca is the co-founder and CEO of the company. Franchesco is a CTO and Franchesco is a product lead at Bending Spoons. Welcome to the podcast. Thank you. Thank you very much. So I have to admit, even a few months ago, I had not heard of Bending Spoons.
At the same time, things that I have heard about and used are evernotemeatup.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 ever-node acquisition that I first 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 ping 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 well-known businesses we acquired. Meetup 2, we have acquired Mosaic, which is a collection of mobile products from interactive corporation. We have acquired Hopin and StreamyArt, possibly the most popular recording and live streaming suite of features of product in the world.
More recently issue for digital publishing and we transfer for digital file storage and transfer. And we also own an operate Rammini, 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 active 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 you by the Enterprise Ride Conference. One they have entered SF, bringing together product and engineering leaders shaping the future of Enterprise 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 a complex features that most enterprise customers require. If you are a founder, exec, PM or engineering task with the Enterprise roadmap, this conference is for you. You will 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 you by DX, a platform that helps organizations measure and improve developer productivity. The DX seem includes notable researchers behind the frameworks like DEVX 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 a DX Core 4, a unified framework for measuring developer productivity that encapsulates DORA, SPACE and DEVX. 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. You can learn more about the DX Core 4 and how it's being used in companies like Dropbox, Etsy, VersaLandFizer, 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. You've already touched on this, but I just really want to double-click on it. 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. They acquired Meetup and then they reduced the original team. They acquired this other company and they did that.
There's this real perception of 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. This is just one side of the story. This is the external, I guess, the hard numbers or the things that make the rounds and make people pay attention and form opinions. What do acquisitions really look like from the inside? What is your approach? I'm going to assume that it's likely not like we're going to cross off.
It doesn't make sense to acquire a company when it sounds you want to make more of this. How do you approach it? Definitely. Given that we acquire companies to own and operate them forever and given that we do so with 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 maintenance spoons.
There's the case for most people here, including Francesco and Federico, we would want to do the best weekend 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 we need to be inside.
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. You don't know enough to be able to decide how to operate it well. We go through a learning phase and we really look at the details. We go hands-on very deep across the board.
The more we do this, the better we become at recognizing patterns, so we get faster and more accurate. 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 of the organization, and as long as forth.
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 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, 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 who are let go, of course. It's also not enjoyable for those of us who implement it. Naturally, we have empathy for those people. We try to do it in a way that's as supportive, financially, logistically, emotionally as we can.
But it still sucks. 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 keep cast for 5 or 10 years down the line, if getting their requires making a popular or painful decisions, we will make them.
We understand we will take a flag for that in the press and it's fine. 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 Abernold represents our trajectory well. My first reaction was like, oh, this is a terrible company, buys another company and then let's a bunch of people go how terrible, let's say with ever note.
But then I was kind of thinking a little bit further and thought, I called on, I've read all these articles about ever note 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 clearly a struggling company and to take that company to a successful company, clearly, 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, do like, sounds like bending spoons that 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. 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 water easy solutions and what I thought about this well. I mean, in my view, the company that goes through painful 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 stars that just shut down and after they couldn't find anything. So that's just a, 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 they and these people think that bringing the business from my 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. 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 hard decision like a layoff, you should do it again trying to be super supportive financially and logistically and emotionally, but still do it. Of course, the latter view is more kind of free market view, the former, you can give it a 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 assumption, so what one should strive to do. But within the latter camp, we try to do things the right way to 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 efficient lives 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 totally fine way of looking at the world, but then they will never like us.
You know, there's nothing we can say to change our minds. Yeah, I respect that. 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 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 you'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.
And we're going to implement the company that some people may consider controversial. One being that we are uncompromising on excellence, which means that we want each position staff with a performer that's at least in the vicinity of the best possible performer we could we could hire.
And if we're going to do the company in the same way as you would see, you know, an ambitious basketball team or or or football team, we really want to make sure each position is tough with an outstanding performer. And if it means demoting someone or letting someone go, we will do so. So we tell you upfront, we're super honest about it. And again, someone who's seeking a place where everybody's trying to be absolutely great professionally.
And that's not the last because the talent density is sky high. Someone who's not seeking that sort of one food outside of your comfort zone all the time plays will not like it. And I think both user absolutely respectable and understandable. You just need to be honest about who you are. And that can be a match made in heaven.
Working at Venice, we must be doing something right because we have a level of unwanted team member churn that's to my knowledge on herd of in the industry about 1% per year. 1% per year churn. Yeah, unwanted churn. And if you look at our. Yeah, like we called undergarter attrition, the official but yeah, people who yeah. If you look at our glass reviews, I'm not aware of many companies with you know, such high high support. So. But yeah, it's not for everybody. It's really not for everybody.
Yeah, that is very low. Indeed. Yeah, so surprising because I we did a. I did a newsletter issue on this. I think the industry average was around 7 to 10% and then it can be higher as well depending on the stage of the company. So 1% is truly impressive. So now literally like a handful of people out of 450 per year, like 315 something like that. Well, you must be doing something right. And when you do have this type of information to look on that 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 exit interviews with people who leave as well, right? We should probably put this in our website somewhere. I think I think we should know about it more.
Yeah, to put things in perspective, could you share some some hard numbers, especially engineering numbers, to get a sense of where you are in terms of, you know, queries per second revenue that the things that can help place how large and you know, high load bending spoons is. So we're currently at around 700 million dollars in revenues. We've been profitable every year since we founded the company 11 years ago.
We serve well over 200 million man's like the 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 bench points. We run multiple products, I think it's north of 100 digital products at the moment. 100 digital products. Wow. Yeah, I mean, it's keep growing, but it's already like I think it's an important number.
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 build 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, which does in the years to build complex architecture able to scale accordingly? Can we talk about your AI products and specifically the AI load there?
Yes, because I know Remini is a very popular AI application, but how does it transform into like GPUs? At the moment, I believe on an average daily, we do more than 2000 inferences per second. We can reach peaks of 8,000 per second. That turns into, if you look at the GPU demand that we need to satisfy in order to fulfill these inferences, what's talking about around 4000 GPUs that we need to allocate dynamically.
As you can imagine, there's very pricey and we need 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 allocate 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. So we build algorithms that help us predict whether I'm booking 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.
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 starters will just take their funding VC funded AI startups. They will allocate however many GPUs and their number one thing will be let's get it out of users, but sounds like you have another constraint here.
Yeah, definitely we have run the company profitably every year initially because in 2013, 2014 raising capital in Italy, because that's where we are headquartered. We have people over the world, particularly Europe, but we started off in Italy. So that's where we had the financing questions early on and raising capital equity capital, decent terms in Italy in 2014 was, I would say borderline impossible.
And then I think today, you think are much, much better. I'd like to believe also thanks to Benispun's having been a success case and such attracted international capital, but at the time, you know, we didn't have access to it. And also our model is so unusual that we felt no VC would 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 forced us to be extremely efficient and thoughtful about the
allocation of resources, more autonomous and independent. And I believe that scarcity of resources as bread, resourcefulness and an engine weathe, 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 floated with financing. Yeah, so I do not frequently hear we took that loans from traditional banks with startups. In fact, you're the first one I hear that.
But let's talk about this, this history because you today you're you said you're more than 400 people, your 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 so I kind of 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 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.
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 BC money.
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 at the liquidation preferences, but again for simplicity, they sold us the shares that that amount of money, which was very substantial to us was not was was peanuts to them pretty large fund.
And so we ended up taking out this $40,000 from from that failure and that was the seed money for for Benin's proves 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's proves 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 the first acquisition $10,000. What was this first acquisition?
So that one was a an app and I us 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 into say 20,000 and then 20,000 gets you a slightly bigger more promising acquisition and if you're good eternity to 40 then the compounding is a pretty powerful force over time exponentially.
And so you fast forward around 10 years later where now acquiring companies hundreds of millions of dollars in price we invested more than a billion dollars in acquisition some hundreds of millions of dollars in research and development. But yeah it's been a pretty steady paste.
And what was like a bigger milestone like I imagine clearly ever known as is one very well known from externally but from internally like you said it started off small you started growing but where 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 supplies a mobile VD 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 ever know ever note 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 we came to know that ever note 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 then you always have to go through antitrust clearance periods and so on so forth.
So the position actually closed very early January 23 and we jumped into the organization and the way we operate is we spend the first several weeks some times couple of months in fully fledged learning mode where some some of the team members at Bennings proves particularly the most experienced ones.
So we're enjoying at all levels management individual contributor in different teams and just try to absorb as much information as they can to talk to almost everybody looking to 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 a vision spans the gamut organization technology user experience when it's a
vision marketing everything we come up with a vision of the best version of that business we we can come up with with a long to review something. There's a misconception about sometimes we acquired these companies to own and operate them forever so we think with the longest time for we can.
And so that vision embeds that sort of long term thinking in it and then the second phrase 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 ever note like what kind of tech stack was it running on and and while for some tech changes that you decided to make and why did you what why did you do it I mean I assume it's always an exciting and opportunity to look at a pretty
salvage product and see you know like what are the bottlenecks and how can we prove it. So the first thing we noticed when we acquired ever note I think that's what was the main cause of all the other issues that we identified after all the things we could improve was that of course it was a very old code base with many years of tech that accumulated but one
peculiarity was that it was migrated at the certain point from the more traditional data let's say Burmeteil servers to the cloud space and that migration was of course supported by the cloud provider and was made in a one-on-one fashion meaning that it wasn't really happening ever note didn't let's say reshaped the infrastructure or the architecture architecture making it cloud native and as a result of this we found
herself 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 it they were 750 machines with all machines all of them were manually provisioned and user users data were shared it among all of these machines that
sharding was not even after our analysis doesn't even have us pruned 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 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 own 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 own call an exception
on ever note we found no awesome so it was just a confirm like for the products that you you operate like this is kind of like a core principle of like on call should not be let's say heavy or 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 garrickly we actually try not to have an on call 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 full back as a software engineer as an infrastructure engineer really breeds that you know
ever thought about the corner cases I've 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 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 code base as yet I love the different thinking because I think in the industry it's kind of a given like look we have we generate a lot of revenue we can afford to do on call and you know we'll pay engineers a bit of extra like we'll give them either bonus for the week and a lot of company's operate like this so I really like how you actually just said okay let's do it differently let's 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 this views on on the on call programs is called 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 true the burden of proof is always on those who want to do so as a
post to on those who want to retain the simpler status additionally we encourage people not just not not just not to add complexity but to look for ways they could remove complexity so we constantly question whether or any system really and it's not just technological systems it's also policies could be a simpler and we've plenty of examples of systems that I think we're reasonably simple to start with and made
radically simple because of this approach one being pay at Benis Fools originally years ago we had you know bonuses and stuff now for for many many years we've had fixed pay 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 didn't put on your website right I saw that yeah I think so I think so yeah we try to be quite transparent about that stuff so you know there was a theory early on that bonuses would
bonuses would somehow drive superior performance we documented ourselves on the topic in in the in the literature we had discussions we ultimately said there is very weak evidence that they do there is certainty that there are big pain in the
customer of course you know set targets discuss you know I deserve it I don't deserve like 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 if they don't it's a different type of problem we shouldn't need a bonus to to drive performance and we haven't looked back I mean we we don't even dream of adding bonuses back to the equation awesome and going back to to ever
know 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 ever known on these days in terms of the the technology stack architecture the 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
opinions the first thing we did was migrating all the data from the charts 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 they were already some services that the previous team of
evernote was already building let's say following a microservices architecture principle but they were very very for all let's say they were not yeah 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 notes that without
diswrapting the user flows one of the core projects also that we needed to take care of to do that such a move as changing the interaction mechanism between the clients and the backend substantially before the clients were pulling continuously both the tools classic 2000s exactly you know how I went I can go it's it was very heavy to manage and also quite
well yeah the clients also had to let's say embed 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 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 backend to be sure that they become permanent and that let's say
mutation must be acknowledged accordingly to to make sure that on the on the client also nothing strange happens otherwise you incur in what we what we called in the past in data missing issues let's say 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 that were managed by the by the client
from the polling system to what we called and sync which was basically a downstream event driven mechanism 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 was in the client and making 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 declines.
If it's a software engineer you want to take your system design interview preparation to the next level check out bite by go calm. Bite by go provides a proven force of framework detailed case studies and access to the exclusive discord community. They cover everything software engineers need to consistent and do well on system design interviews and this increased chances to land those high level software engineering roles.
Head over to bite bite go calm to sign up and try it out for yourself that is bite bite go calm so how did you get to this really fast shipping caveman's Frederico you are telling me that you committed in in 24 to ship 100 updates and I saw your blog on how you ship 20 improvements and I think April 30 more in July it's it's really big step up pace from from 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 from just what 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 try to prioritize those things that people wanted but we're also like easy to build in a sense and so given that we try to give a lot of autonomy to to project teams as look I was mentioning.
We built this backlog of initiatives and features that the users needed and we basically try to assess them both from a standpoint of how important they were for 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 ever not 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 like hit slash and select an item to add to a note there are other examples but basically the point is while there are projects that 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 will be this much more related to the UX or simpler features and so we try to prioritize those because that way we can do stuff more quickly.
Did you prioritize this to get an impression of like to get the team motivated to ship things to show to people or were there other reasons 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 sounds like that's what you're doing right.
We're doing both showing 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 for customers in a good way like performance and create a lot of variability too. We do try to communicate that. We do try to communicate that.
We do try to communicate that. We do try to communicate that. I sometimes get a little bit of a fraction of the time they used to literally one tenth or one tenth of the time they used to. And that's the kind of stuff you do a lot 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 can play in but if it's fast just assume it should be fast.
So it's quite difficult for me point of view of your relationship with users and customers quality marketing to to highlight that stuff as you're working on it. Whereas it's a lot easier to empathize with the or relate to a particular clear feature your developing so yeah we do try to do both to 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 CIC department. 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 a sickle scii with our arms the arms that we built in the years that we polished a lot we know what to expect what not. And we definitely helped the team also sheep faster let's say on top of that switching to the next exciting challenges for the platform of ever note.
And I think that the logical 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 a as an entity from the yes it's a it's a villain something to be afraid of really to fear.
We weren't 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 on the event based interactions that 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 ever note engineering thing because at that point will 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 a in our opinion many more microservices that actually needed.
The was the trade off with microservices you you need them of course but sometimes can get out of ends it can be hundreds sometimes like the only the boilerplate of shipping a microservices to just microservice 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.
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 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 you want to do for what's going to be the next architecture of the ever note system.
We just need to finally sunset the monolith we're very close to it we committed herself to completely sunset it by the end of the year we're doing our best 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 Ubran it's so hard to tell externally I mean I mean assuming you know your 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 we've sunset the most because for them literally like a good model of something is nothing changes right.
Absolutely although we try we try to explain importance of it but yeah I understand that we 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 my opinion to the management team to the product team internally rather than to the users outside.
So I believe we're we're very lucky here to be able to voice engineering needs and you know full time at the center of the road map for the product. And then 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 note 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 like I was honestly surprised myself by how accurate this and one thing that is coming soon is that we are trying to build this into a standalone tool so outside of ever note which is kind of unusual I guess but but we are so proud of it that we want to use it as a tool to show people that ever note is cutting 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 ever note how you acquired it how how you how you balance 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 ever note 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 a rum book or like here 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 ever note being one and and these business units have dedicated management teams and and resources you know such a software engineers data analyst scientist product designers for depending on the on the needs specific of that product and business and we encourage them to.
To operate largely autonomously and then we have a shared platform including several platform teams and and what the platform does is it supports and serves at a different business units with tools services that are relevant generally speaking to most of them some of this is as basic as you know counting finance on his fourth. And some of it is as advanced and technically exciting as all sorts of data storage and processing tools and layers.
A machine learning models to forecast a particular user cohort behavior and value a be testing systems automations for marketing we spend. Tense of millions of dollars in marketing each year and it's almost entirely run by machines. So within these framework the principle we try to follow is to create small teams of exceptional talent density and give them a very vast mandate and in what to do so we trust people to set intelligent objectives and try to.
And try to achieve them and this really is not limited to engineering it's it's a cultural trade at the company. And so it it works at every scale you look at for example if you look at every note as a unit as a business unit the whole team knows they don't have to follow any mandate direction they can make their own decisions on their mistakes on their failures.
But also we never know that this more squads taking care of the various missions or objectives also have a broad mandate on how to pursue them will not impose any particular technological stack on them 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 all is available to coach help support ultimately we trust people to take full responsibility for for their actions.
And in terms of engineering approaches which ones do is 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 look 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 are across the different teams.
Tools are tools they're meant to achieve a certain 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 at say for for QA for instance we try to give that responsibility to share to share that responsibility.
The responsibility among all the different software engineers and also of course QA testers but in many spoons 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 QA 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 in terms more productive and also happy about what's up and next because
it's that's it's more rare to ship bugs into production if you if you built the right developer experience and also gave shared responsibility to everyone about testing their code base. And how big are you an automated testing in terms of like unit integration and to end some of these things you didn't mention manual system which obviously is important but like or is it more more per app or 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 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
let's say the use case word building the right set of tests and that can be generalized enough to be 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 highest coverage but we're also very careful to not trigger false positives 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 you know
we've seen improving a lot the life of engineers after not finding 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 for some of these share things you must have platform teams right
yes and what what kind of platform teams you have what what the does platform platform engineering teams that is we have a team we call it foundations technology it builds all the tools expertise and knowledge to 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 to be done
and if you don't have a wide portfolio products usually you don't you don't find it a good investment or like it's a 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 that scale so we we have the let's say the opportunity to build to make such investments
and to see the results at large so the the foundations technology team builds the tools that allow us to for instance do proper A beta testing to let's say manage infrastructure in an efficient way the data allows to for instance collect and define metrics for different products
we can we can track all the data code 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 the 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 technologies 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 such such to issues with whether you know 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 and certain particular types so all the sort of things it becomes a shared benefit across the whole company and speaking of technologies what type of sound technologies frameworks do you use inside the company or just the most popular ones at least yeah so I'd say the most popular back in language that we use is Python we use fast API for instance to we 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 this particular useful because they can move from clients to back end easily we it's all not just we use Swift and Kotlin to build native iOS and Android apps typically but we also rely on React when it makes sense we use Electron what else I'd say 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 the 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 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 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 a marketing attribution we build our own internally usually most of the player outside rely on mobile measurement partners such as adjust, crush out our flyer at a certain time over let's say 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
it's a peculiar let's say unique time for performance isn't it? exactly yeah we loved it it was clear that it was making everything better much more than the back of language that we used the most which was Python but for that aim it was not the right one and was clear from let's say an engineering perspective just looking at the numbers
so yes we went for Rust and the moment or internal tool for attribution scene we call it it's still a Rust and it's working that's awesome careful it's popular we 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 typically entry level engineers which is refreshing to see how 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 were talking about we always have favored hiring new graduates or inexperienced people and the 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 with over time particularly high quality experience being surrounded by great colleagues working on really challenging project at a high pace talent we cannot teach
and so given that we're 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 of years or all on 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 bandage firms but also the people who we hire
the second reason is our approach or 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 for inexperienced ones
Awesome and when people join banding students 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 careers fits in here from a software engineers perspective
Yeah it's very simple relative to our understanding of what standard out there we don't have any titles so if you're hired as a software engineer you are an always built will be as long as you know that's what you do a 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 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 what
Ben is doing today multi year very long term view and in your 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 you know 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 can we could 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 that's what are traits that you're hiring for and what does an engineer or 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 what makes your culture possible
Yeah that's a good point I think by the way hiring primarily in experienced 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 and I think it's also be helpful for us to not having had and there's there are pros and cons but we haven't had a whole lot of advisors early on because we were
in the ranges of the technological empire as we were building banish films 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 that any better you know so you know as usual pros and cons but 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
who are 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 it's a really high autonomy environment for you know with a good and a bad depending on what you like
and third I would say a trade to a 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 where we trumps I all the time again for better worse I think if those things are true of someone and they really want to
they see the role in an expansive horizontal way they're they're not in in this for just becoming the most expert Python programming the world but they want to be a great 360 degree engineer who understands the piece of the impact of what they do or as a an interesting that I think that such a person will probably do really what I've been is
and love it. Do I understand correctly that like if I fair phrase it you're hiring for things like drive motivation and like getting things on our talent of being able to to get things and learn quickly does that kind of yeah I think drive let's say pro reasoning problem solving learning ability for lack of better term and collaborativeness to I think that's very important.
A collaborativeness yeah awesome thank you so I'll close with this question why do you think no one else is attempted this really unconventional bull strategy of acquiring companies improving their efficient turning into turning it into a better version and looking at 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 you're pretty hard the platform will build the company culture the technology 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 like it's it's really hard to build a culture employer brand and 50 plus technologies like 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 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 the start is going because you are a tech company you're a tech startup you you hire the type of people who want to work at tech start.
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 won 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 you're not going to be able to do that.
So I think it's on you know these things that most companies don't need to focus on you just have 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 sound 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 know you can go even back even earlier than that.
But yeah I think our the particular conditions are failed the startup before what we learned there or we built Benispunse certainly have helped shape this view for sure. You could say probably that seven years ago we were the company everybody's trying to do now in a sense. Now 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 working 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 they if they want to apply there's a jobs page we are available on most social media platforms too. I'm always happy to have a conversation so do reach out and if you want to witness the great ever not 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 very thank you thank you to go founder and see a look a Ferrari. CTO Francesco Mancone and product lead Federico Cmino Nato for sharing all these inside your 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 take away number one even inside a single company you should choose entering process it based on the maturity of the product you're working on. The CTO of bending spoons found it 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 an experimentation.
So more mature products will have more stage of releases and experimentation but products that are just being built will not necessarily invest in this take away 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 workplace or team.
Take away number three you don't need to copy popular approaches in order to become successful as a product or injuring team. 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 here are a few examples their most popular languages 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 team uses rust and they have plenty of no one types of usage. Another example is how they do not have career ladders might 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 can figure out what works 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 subscribe and love to your view. Thanks and see you in the next one.