From Tiny Romanian Startup to Global AI Automation Leader | Daniel Dines, CEO of UIPath

Yeah, Matt, thank you for having me. It's always a pleasure to tell the story because I've said it multiple times, but every time I remember something, which is kind of fun. It didn't start in my apartment, but it started in a very small rented apartment, which is, I think, the equivalent of a garage—the Romanian version of a garage.

Yeah, I worked five years at Microsoft, and I had the craziest idea to start a company, and even crazier, to go back to Romania to start a company. So obviously, I had no idea how to build a company. I was a software engineer, and like most engineers, I thought that just building a good product, even without customer input or anything, would be enough and people would jump on it.

Yeah, exactly.

Well, we had some experiments on the product side, but they were mostly in the consumer part, so we tried consumer. I thought it's way easier than to just go into big enterprise. I had no idea how to enter. So we built a really small tool initially that was like a dictionary, something providing quick access to online resources from your desktop computer. So, like, if you long-clicked on any word on your computer, we would understand what you were doing, extract the word behind the mouse cursor, and then offer a pop-up to search, to translate, to do some stuff.

It's actually way more difficult than you imagine to understand the context of every application and how they draw text and everything that's there. So we built a pretty sophisticated—it was systems programming—to intercept all the Windows APIs that an application is using. And we were rendering the text in memory and figuring it out. So it was pretty, pretty interesting. This is what we were doing in the first place. First, we started with this idea: let's intercept API calls and then let's build a product around it.

Yeah. And the product was not successful in a real sense. We had like maybe a few, maybe even 100,000 users at peak, which was not bad. But what was interesting, that led us to our first real customer.

And it was a small software company based in the U.S. And they were doing some kind of integration software for credit unions. So what they actually were doing was to read the screens of these cash machines that tellers were using back in the day—we're speaking 2005, 2006—and read the number of bills and coins on the screen and then align it with their banking software. They didn't communicate. So it was a very early form of RPA, actually.

And the funny story is, we monetized that product that we launched, the consumer product. Maybe in one year we got maybe $100, $200. And this guy wrote to me and said, look, I'm not interested in the product itself, but I'm interested in the engine that reads the text of the screen. Would you license it? And I said, yeah, why not? Because we actually built a product in a good engineering fashion with layers of software. So it was very easy for me to give him a component.

Just decoupled to give the software to him. And he asked me, how much do you want for a license? And I thought, look, I had no idea. So on a hunch, I said, like, $10,000. And the next day, basically, he wired the money without any negotiation, nothing. So I said to myself, well, this is an avenue actually that we can go on. And from that tiny library, we started to extend it to add, besides text capability, the ability to understand also what's on the screen, like all the controls, how they are related to each other.

And then we added the ability to interact with the screen, to click and type on the screens. And initially, you had to be a developer to use our library. So for a few years, until like 2013, we were basically an OEM SDK business. Not very lucrative. I think at most we made like $200K per year, which was kind of enough. It was like five people in the company, five developers.

Basically, in Romania, you could make a living out of it. And we were living, in a way, the dream. I was independent, people were buying my software, and it was a completely bootstrapped business. But at the same time, it was kind of an endgame for my career. I stopped being a developer and I did all sorts of things—product support, marketing, legal, advertising, everything. Even paying the salaries was really in my hands. So I remember that we had a meeting at some point and we said to ourselves, we need to put a deadline on ourselves.

We cannot just do this thing because we ruin our careers.

And so it was like 2011 when we had, like, a death sentence on us. And then we said, let's do it two more years and let's build something more interesting on top of our little product. And that was the moment when we entered into low-code, no-code automation development.

Not really for business people, but a tool for—

Easier to use by, I would say, technical business users. I think that might be a more accurate term. This is one of the pillars of our success. We tapped into a rather large population of people that are not necessarily pro devs, but they have basic programming knowledge and they can easily be trained in our technology and they can deliver automations. Because automation is a species of application development, but it's way simpler than delivering a full-blown application. You don't have to understand so many concepts about reusability and security and all this—the whistles and the bells of true engineering.

And it's enough to have maybe a few software architects, RPA software architects, and then you have many people that can really deliver the body of the work. So tapping into this population was essential because it's pretty large and it's not that expensive. So it made the entire proposition of delivering automation feasible.

Yeah. So we started that no-code journey in 2011. It took us, like, two years to finish the product. And to our—

Yes, because from an SDK, basically, to going to a product, to a finished product—like, we call it Studio—but it's a finished product that one can use and build an automation and run it. Initially, it was something that you can run on the same machine. It's like Visual Studio or Eclipse or something. It was an IDE, basically, dedicated to build automations. So it took us some time to build it, but it was, I think, a pretty refined one and really good, state-of-the-art for low-code, no-code tech.

Even today, most of the way our product works is based a lot on the ideas that we incubated during these two years.

Kind of. I would say the acceleration started a bit in 2014. We launched that product in 2013, but our base of developers couldn't care less about this one because it was not for them, actually. But the word got out a little bit, and I think good timing is essential, especially in the beginning of a category when nobody really knows who the players are. And I said this story multiple times, but it was really a phone call from a guy sitting in Chennai, India, that basically accelerated our journey into the RPA category.

At that point, I didn't know what RPA was. And the term was coined like a year before. But interestingly enough, this guy was searching on the internet for a low-code automation platform because he was annoyed by his current provider not being flexible enough. So he was looking for something that was visually appealing, that looked like low-code, no-code to build automations. And we were the only nice game in town, really. So he called us, and it's kind of funny because he used a Yahoo address.

And I was in charge of support, so I was reading the tickets that we were getting, and he said he needed a demo of the product. And my first inclination was to just ignore it because it didn't look like a business.

But then I had, again, this hunch: maybe it's something. So I asked a developer, because we were all developers, to take this guy through a demo. One hour later, the developer came to me and told me, "Daniel, this is actually something very interesting. He works for a big company. Apparently, you have to talk to him." And I talked to him right away. So we were on Skype at that time, and the first thing he asked me was, "What do you feel about this?"

How do you compare with this company that they were using? I said, "Man, I have no idea who they are. Let me search."

So I was searching as I was talking, and there came this kind of boring corporate page with investors, careers, and I don't even know. It looked like a big company. We were just a tiny startup. I didn't think we could compare. But anyway, it was good because it was authentic. So he kind of liked it, and we continued the discussion. And in the end, his company offered us a paid POC to build competitive automations that they were building in parallel with the other company.

And then I sent most of my company, three people, to Chennai. They worked for like three months to build the automation. And that was the big aha moment when we understood this is actually quite a big market. This is the pain that we were looking for. We built a product in search of a market, actually. But unexpectedly, we found the market, which is not—I would not recommend that anyone do this. But that happened. We were developers. We built something that we really enjoyed.

It was nice. We knew, even before we had discussions, that we needed a little bit of luck. We knew that we built something that was remarkable.

They were, yeah, exactly. I didn't know the term until recently.

Yeah. So they were our first design partners. But then, from then, they were like a BPO company, but with a lot of technology. After them, we became known within the BPO circles. Capgemini and Cognizant were the next design partners, and they were even more important than the initial company—bigger companies. They knew in that moment that this was going to be instrumental for the automation of manual work. Because BPOs are structured in very long-term contracts, but every year they have to deliver a certain percentage of savings.

So they initially start with some kind of business process engineering, which is pure—it's working on the flowchart and understanding how you can remove unnecessary trips in the process. But after that, automation is the only game in town.

And this one, emulating how people work, worked brilliantly for BPOs. Because, interestingly, many times they don't have access to the systems, to the customer systems directly. They use something like remote access, like Citrix.

So they had to automate applications and processes strictly from a user point of view. And that was the thing that we mastered really well at that time, this computer vision approach. So it was really a nice integration between low-code and computer vision. So basically, on a screen, on a remote screen that comes from Citrix, it's pure image-based. And you can really record what we are doing with an understanding of the objects and pictures on the screen. So it was—I remember a moment when I also realized something.

It's dramatically better than anyone from the competition standpoint. I showed this to some people. They were actually experts in our competition at that point. And they were totally speechless because what I showed them working in front of them with the recorder, everyone could have done it. It was like, I don't know, three minutes or something. Press run, and it works. It would have taken days in other software using a very cumbersome process.

It's days.

We were AI from the beginning. It's true. In the beginning, we were using some AI libraries, but it was the emergence of one of the first good libraries, this OpenCV from Intel. And we used that one heavily. But the key was to pack it with low-code, no-code, with automations, with all this that we have in the OCR, that we have our own stuff. But the integration was so nicely done, it was really way ahead of anyone else.

But we were waiting for that opportunity for, like, eight years.

Yeah, we raised money in July 2015.

But I have to say, my first round was the longest by far. So I met our first investors in March 2014, and it took such a long time. First, it's very risky, I think, to invest in a nobody startup in Romania. So we got to know each other. Then they gave—

Earlybird, yeah.

Digital East, I think it's called. Digital East.

Yeah. It was kind of like a franchise of Earlybird. They gave us a term sheet in August 2014, but it was so onerous, the standard kind of terms, that I couldn't even myself take it. So we started a long negotiation process. Well, not to belabor the thing, but I'm sure they don't regret that they signed it. But they ended up signing common shares in the end. So we started to see such a nice acceleration, even through '14 and '15.

So I started talking with big clients. And can you imagine, companies like Kaiser Permanente left voice messages to us: guys, please contact us. So at some point, with all the negotiation, I ended up telling them, guys, if you invest, you have to decide now, and you invest in common shares. And this guy said, yeah, but the only provision is that we'll get the same terms as the next round. And it was smart. It was good.

Accel was for the Series A. There were a few funds that passed on us, and it was interesting. Not valuation, but they couldn't accept to leave me in control of the company. And I was pretty adamant that, guys, that gives me the freedom to act. The moment we'll start having an independent board, I will take my political animal out of me. And this is not how you build a company.

To us, it worked because even today I have a controlling stake in UiPath. And why it worked? Because I realized very early on that the people on our board are actually better than most of the people we can hire, actually better than all of them, especially in the initial stages. So this is why I opened completely the company to the board. I told them, guys, you don't have to ask my permission to talk. Everyone can talk to everyone, and at all levels in the company, because I was never afraid there would be any kind of politics behind my back or anything.

So it gives a lot of flexibility and freedom when you have this type of— because it's—

Yeah.

Yeah, they will go and be controlling. And also, I've seen with the people that I hired later, more seasoned executives, the board acts a little bit like—they are fearful of the board. And a lot of what they do is for them to look good in front of the board. I never had this. And I always told my boards, guys, we are here to discuss open things on the table. I don't care so much to praise ourselves, but I need your help to help me fix the dirty things in the company.

Yes, we ran boards mostly really about the issues. Of course, it was typical strategic things, numbers, product, but putting upfront what is not working was always part of my strategy to talk with the board.

We were never truly a European company. So starting out of Romania has the advantage that Romania has no market. So we had to think globally and remotely. I didn't really have money to travel to meet customers. This is actually funny. Our first enterprise customer that we signed, I think it was fall of 2015. First, it was like a $100K deal. It was a Swiss company called Swiss Re. It's a pretty significant company. And they told me—we were talking about negotiation, the agreement—but so I really expected them to sign.

So they told me, "Daniel, before we sign, we'd like to meet you in person." And I was surprised. I said, "Why?" So then I realized they wanted to see if this is the real person behind. So I think this is when I had one of my first few business trips at that time. So I flew to Zurich and I met them, and they signed after seeing the person. But it was unusual for me.

So we were dealing worldwide. GE was one of the first American customers. We signed GE in March 2016. Good deal at that time, like $200K, all remote. I didn't go to America for that one. And so we were prepared to do global business. I moved to New York. So I debated for a while between London and New York, but then I realized that you have to be in your largest market. And it's better to be close to the next investors.

And it's better to put your leadership team in a talent-pool geography, which there is no one compared to the US, really, in terms of talent pool.

So it was a good decision.

San Francisco was too far away, I think, for our global business. Time zone doesn't help you when you do global business. It's not really so well connected globally, I think, from a flying perspective. And we were not so big in tech at that point. Our interest was much more in the financial services industry. So I think New York and the East Coast was a good choice. And why New York? I think New York, it's a great city to be here.

It's a lot of—it's intense. It's fun to be. I don't regret my choice to be a little bit unusual, especially in 2017.

There's been a few companies, Datadog, that started to be relevant at that time.

MongoDB.

But at the same time, we didn't establish in New York and then try to do only US. What was unique to us is, despite our small size and even not raising a Series A, so we were a very small company, we went globally. Japan in 2017 was a country that brought us more revenue than the US.

And we were lucky to expand into Japan.

We went through a partner in Japan initially, but I was lucky to meet a Japanese guy that became, a bit later, the one running our business in Japan. And he was instrumental to put us in front of large customers. And to tell you also an anecdote that I don't think I ever said before: so I was in Tokyo for the first time, and I was meeting that guy from SMBC. His name is Yamamoto-san. We've built really a good partnership and friendship later on.

But when I met him the first time, I didn't have cards. So going to Japan, I had to print business cards. So at that time, I had only my Romanian phone number. So I thought it's not a problem to put. It turned out that this kind of scared him. How can I do—I'm one of the mega banks in Japan—how can I do business with a company based out of Romania? And then what I did the next day, I went to Skype and I bought a UK number to put on my business cards.

But anyway, we started to gain his trust with our product and then with our dedication. And we hired people in Japan and started to really offer them a lot of free support. Always our policy was really complete customer-centricity. And it's very easy to say this, but it's not so easy to practice it. So how does that manifest?

It's a question of the product roadmap, and not even the product roadmap, but it was a question of fixing the bugs in the product. Developers, especially when you run so fast, developers are attached to building the next shiny thing. And many times companies have the temptation to bring a feature but not finish it, go to the next experiment. So you end up with an ugly mess, especially in an enterprise when you have a long list of features, not in consumer. So this Japanese client, actually, by their presence and way of asking, commanded certain respect.

And especially to our developers. So it was the first time when I went to them and I said, "Guys, this time I don't take any bullshit from you. They say something, you go deliver. I don't want to enter into endless debates of what's priority, what's not. These guys are paying us our salary. So let's stop all these futile debates."

Yes, to focus on—they helped to really deliver a strong product.

Our product was always very horizontal. Even today, I don't think we have a line of code built for one customer. Maybe that was lucky, because when you build a—the key to build a horizontal product is to identify common building blocks, but they apply to many industries.

And in our case, the building blocks were so obvious. The way we operate as a person is the same if I am in the healthcare industry or if I am in the banking industry, in the way I'm using computers and I'm using the same paradigms. For us, it was in a way simple to just identify the building blocks of how people use computers, formalize them in software, and then apply it to all the industries.

So first of all, why is discovery of processes important? Because even if it's counterintuitive, in large enterprises, there is no single repository of truth and knowledge about what they are doing. You have to help them to understand even their processes, to discover, in a way, what they are doing. Because there's a lot of oral knowledge there. It's small groups, it's big groups, it's many manual tasks. Maybe only three, four people in the company have an idea of what they are doing.

It's also large processes like hire to retire. It's a very big process spanning almost all the departments.

It could be a series of steps.

Paying an invoice, ordering a product.

A series of steps and also a series of approvals, verifications, validations between different departments.

So process mining is a way to actually look at the systems of record and figure out what transactions happen in the systems of record in a more visual way. So you plug into SAP, for instance, and then you can show all the transactions happening in a very nice process graph that shows all the paths in the process.

No, no, no. In process mining, it doesn't work like this. You basically extract all the information from the logs, from the system logs, and then you transform them into a format that is understood by process mining.

The output is a graph, yeah. The format of process mining is kind of very simple. It has a timestamp of the transaction. It's the user that made the transaction. And it's the business activity of the transaction and some business data. Of course, it's a little more complicated, but this is the essential. And based on this, you understand all the steps and how a transaction flows through the system. And you understand also the timing between different steps.

You understand where the process can take more time than is necessary. You can compare with the ideal version of what you want. So you can do a lot of monitoring, optimization, and you can also understand what are the steps in a big process that are prone to automation.

Yeah, task mining is the ability to install an agent on users' desktops and monitor what they are doing and figure out what the repetitive patterns are in a manual task.

I think we are working right now to actually combine task mining and process mining better. In a way, you start with process mining. You understand that in one particular step, let's say, people are processing invoices, but it takes a long time. So then you can deploy an agent to the user group that processes invoices, and then it monitors them for a few days. And then we have AI that looks there and understands the patterns and figures out what they are doing.

Exactly. So then you can go automate or maybe optimize in a different way, but you combine system data with also manual steps that people are using. So this is how you have, like, a 360 view of what's going on in an enterprise. Communication mining, it's something that is more about understanding emails or messages that flow in an enterprise. And usually most processes will start with an external communication. A lot of times it happens on email or maybe using a ticketing software or some kind of chat version.

But we bought, two years ago, a company based in London. That was Re:infer.

Re:infer. So they were one of the first startups that built this transformer-based machine learning to understand email messages. Email is a form of short message, not long message, but it's a form of short messages, and also it's threaded. So it's interesting to understand the communication back and forth and to classify and to extract information from emails. And it made a lot of sense because we can combine communication mining that understands the message with document understanding, because a lot of times you will have also some kind of attachments.

Extract, process both messages and documents, extract the information, understand the intent, and then run an automation. And then, using GenAI, you can go and reply back, create a contextual response to the customer. Customer can be internal or external customers for an enterprise.

Essentially, our technology works by taking a process as is and automating as much of that process. Sometimes you emulate people, sometimes you replace maybe some manual things that people are doing with some API calls, or, at large, it's mostly about emulating what people are doing. Because, in communication mining, for instance, many companies will set up some kind of shared email inboxes, and customers will just go there and complain or ask questions. And then you will have people monitoring the emails and putting them in different folders.

And then there will be specialized people per folder taking them and replying and doing certain actions. We'll basically use software to classify and then put them in folders. And then from folders, maybe running automations to extract more information and so on.

Yeah, that was actually really one of the breakthroughs that we understood when we went to India, at that initial customer. Before that, our focus was to deliver one automation that was working well. So, one developer, one product, build an automation running on that machine. We were scheduling on one machine. But we focused so much on making it very reliable. And it was actually a good approach because if you start too big of a system day one, you'll end up with spaghetti and nothing works.

We mastered this piece, and it was world-class, best ever, and it's still the best in the industry to build one automation, run it reliably. What we understood there was that this is not enough. What if you have to build 100 automations and they have to depend one on the other, and they have to run at certain times, and they have to run on different types of machines with different types of software, different types of security permissions? So then we built all this: a product called Orchestrator that is capable of scaling hundreds and thousands of automations, or thousands of runtimes, and making the communication between them via queues.

And you have—it's a pretty sophisticated system.

Yeah.

Generative AI is, in a way, the missing piece in RPA and even broadly in automation. Because first of all, it lets you understand unstructured content way better. So it helps close some pieces in a process that they couldn't automate before. Therefore, that was the first use for us of GenAI in our document understanding piece. And we have a generative extraction technology right now that helps extract information from unstructured documents, can even help to build better models for semi-structured documents.

One of our fastest-growing businesses is this document understanding business. And we combine specialized models with generative models to basically deliver an end product to the customer that improves over time. Because one of the things where GenAI doesn't work well today, in all fairness, is that it doesn't learn. All the fine-tuning, it's more context grounding, large context windows, but it's not learning. You don't go to OpenAI and modify their weights. This is not how it works.

But with a specialized model, that's possible. So what we are doing for our customers, for instance, they want to process invoices. I know it sounds trivial, but some of the invoices are so complicated, even a human user would find it difficult to understand all the relationships and to extract information. So what do we do? We have base models that are pretty good, but then we have to learn from samples. And we pair GenAI to tag samples, help people tag documents better to create training sets that work well.

So we accelerate using GenAI in creating the training sets, and then we use LLM-based dedicated models. So we build something on top of T5, which people will say is a little bit of an older model. But we believe that encoder-decoder models are better when you deal with semi-structured documents than decoder-only models. So we are using T5 as our own LLM, but then we retrain T5. We use a LoRA-based approach to minimize a little bit the training and the runtime performance.

But in the end, we will beat any performance of GPT-4 or whatever, and they would be extremely reliable. And they are not prone to any hallucination or to spitting out customer information.

I don't think so, because I think nature is pretty smart. And if you look at how our brain operates, we have a very good cognitive engine, but we are not using that cognitive engine to do trivial tasks. It's way too expensive. If you want to learn to swim or to play tennis, you start using your cognitive engine. Maybe you go to a coach. You understand the movements, but as you learn, you actually build a dedicated model that will help you do this unconsciously.

You don't think, because sometimes you don't even have time to think. So it has to be extremely fast and less expensive in terms of energy. I don't see any reason why this is not going to be the case in the real world. So it's kind of obvious for me.

Yes, this is what I refer to. They are these T5-based LLMs, but trained with a lot of the data that we got there.

Yes, but it's really a thing for models customized by our customers, but starting from base models that we built. It's not really intended to take anything from Hugging Face and then just run it in AI Center. But it runs with our own models customized for the needs of customers.

We discovered that many of our customers actually use multiple LLMs, and they want to have some governance and security layer, so like an abstraction layer in front of the LLMs. So maybe they start with GPT-4, but who knows, maybe Claude is better for a particular task or not. So instead of creating, again, a little bit of spaghetti in the application code, you'd rather use this abstraction layer. And then you configure the abstraction layer for different calls. What kind of LLMs are you using?

And we can provide also better services like anonymization of data. We can do smart things. Even if you send an invoice to GPT-4 to extract some information, what we can do, for instance, is digitize the document and replace all the sensitive information with synthetic information, get it back, and then redo the translation when you go to the customer. So it's important to have this in-between layer. It helps with a lot of things.

I think this is going to be maybe the biggest transformation we are seeing in the enterprise space that would be based on LLMs. To me, let me start with my generic thinking about where LLMs are today. They help a lot with increasing the productivity of clerical workers, but they are not transformational. Why do I think they are not transformational? Because it's a user-based technology.

You cannot use an LLM in enterprise production in an autonomous fashion today. It's simply impossible because of the hallucination aspect and the lack of reliability. In a way, I think to get to an incredible transformation, we don't need smarter LLMs. I think the LLMs that are here today are smart enough. We need them to be predictable, reliable. Because think about, even if you put yourself in the shoes of an enterprise and you hire a person, I don't think many people would shy away from hiring a genius that is extremely unpredictable.

They show up to work only one day a month, and they have all the... For most jobs, that doesn't work. You will need smart enough people, but reliable, diligent. I'm not an expert in the field, but I believe that we need another giant leap of innovation to get there.

I'm not sure just throwing compute and increasing the number of GPUs, without some fundamental discovery, is going to create this. So this is why, in my opinion, we will get to autonomous agents, but first we will have to have these digital assistants that work under people's supervision. And this is where—I think many people refer to this field as large action models. My instinct is the first wave of deployment will really be in a user-based mode.

It's an assisted, user-assisted technology. It's like self-driving cars, which is an assisted technology. This is where we focus right now.

We have a dual strategy. We have something called Project Foundation. So we are building internally this dual-modal model that understands both text and images that we want to put at the foundation of many of our task-based automations. So it's aimed to replace document understanding, computer vision, the way we interact with the screens. But we would also like—we are partnering with one of the most interesting startups right now, Adept, the one we are both investing in—to build really these next digital agents that will be capable...

Actually, of combining knowledge of a task or a process, maybe later on, with the capability of acting and replicating what the human user would do to complete that task. So in this way, we will have to learn how an accountant works, how an auditor works. And that, paired with some of our technology that is capable of acting on user interfaces and their ability to plan, to have knowledge of a task and then plan how that task should be completed.

I can create a list of steps, and then carry on these steps using UiPath technology. I think it's an amazing combination.

Basically, we have three centers where our AI teams are located. We started initially in Seattle and Bucharest. The guy that leads our AI is based in Seattle, and they are doing mostly the computer vision part, document understanding. They are also building our Autopilots. This is a copilot-type product that aims to create automation faster, to help developers build based on a prompt, create a skeleton of automations. In London, based on the Reinfer team, we are building this project foundation that is the next generation of multimodal systems that we want to put as the base of everything we are doing.

Partnership was instrumental. We couldn't have entered big enterprises' doors without partners. There was really absolutely no chance back in the day. But what I also realized around 2016 is that partners are not going to fight for your own destiny. They are very opportunistic in the end, and they want to make money. So the same competitor that I talked about in the context of the India phase, they made an early decision to go completely indirect in their go-to-market.

I think that was a huge mistake. So we went indirect via partners, but we built the— and I'm a big believer in a direct sales force that will fight for your own destiny. Partners, in our case, are not so important for us for reselling the technology. Partners are important to open the door and to implement our technology. But to win the deal, it's us. It's rare that the partner can win the deal for us. So this is, I've seen that that's the winning combination: to put your direct salespeople, to put the partners—

working together to win deals.

Yeah, services consulting partners. Technology partnership largely didn't work for us. And I think it's extremely difficult to make a technology partnership work. It has to be such a huge alignment at the leadership level between two companies that it really works. That's my learning. This is why I'm also investing in a few companies, and this is what I tell them. Even recently, I'm talking to one of our portfolio companies that is on the verge of doing a partnership with a much larger company.

My advice to him is: build a strong relationship with the leadership team, and especially with the CEO of that company. This is how a piece of paper doesn't make a partnership. Most partnerships are just marketing announcement hype. But if there is no personal connection, if there's no will on both parties to make it happen, it's not going to work.

I have so many thoughts. One of the issues I think a technical founder has is that they will never understand sales to the bare metal. Like, I understand software to the bare metal. I can talk to anyone in UiPath and I can challenge anyone. So I'm a pretty detailed guy in my software reviews, and so I go and I ask questions until I get to the root of the problem or challenge them in very much detail.

And I think this is what you should do in go-to-market as well. What I cannot do to that level, I have an understanding, but it's too high level. So, in a way, I always struggle to hire the best salespeople. What I've seen in UiPath and in some other companies, especially in the sales leadership, there are two types of leaders: operational-oriented leaders and customer-oriented leaders. Ideally, you'll need kind of both, but it depends who is on the top, and the culture will be reflected by the person you hire on the top.

Initially, for a startup, I think operationally it doesn't matter, in my opinion. All that matters is building an extreme customer-centric culture. So you need people that understand that you have to do everything for a customer. Even making quarters, it's not so important. Building customer relationships is all that matters. To us, initially, I think I made the good call to hire not professional sales reps, but rather consultative-type people. My first salespeople were actually, look, for instance, the first guy that was building EMEA for us, and then our leader in Japan.

They were both consultants as their background. So that helped because these people are really trained to do what's best for the customer. Next wave, I realized that we don't treat sales as engineering. We were treating sales more like an art. But that doesn't scale. So next, I hired the guy that had very strong operational rigor. And he put a good foundation for us to structure the sales organization, to assign territories, quotas, comp plans.

So that was when we put— but then we started to lose a little bit of the customer centricity. To me, it's always that struggle in my mind. How can you build a sales org that will preserve extreme customer focus, but will have the discipline of an engineering organization? It's a tension that we have to be very attentive to, that tension, because the leaders will go in one direction or the other. I haven't seen yet someone that is both equally strong operationally or from a customer-facing perspective.

I always had, and I still have, the imposter syndrome. That helped me because I was always coming to the table with the idea: I am not the smartest, but I am the dumbest person at the table. So that helped me with managing my ego, lowering my expectations, always not being even afraid to ask stupid questions. What is this acronym? Some people would not ask because they think it's expected of them to. And to me, life is a learning journey.

When I discovered that in any domain, you will find things to learn that are very entertaining. Look, so I started as a software engineer. I was very proud that I was coding systems, server systems using C and C++. At Microsoft, I was working for SQL Server, which is a really amazing database engine. I met, I think, even today, the best engineers that I met in my life. The smartest people were there. But then, building the company, I had to learn a lot of other things.

I really became a copywriter. I wrote a lot of ads for the company. I learned Google Analytics and spending the dollars well. And then I took Microsoft's Word license agreement, and then I had to copy it and transform it to build our first legal agreement. I couldn't afford to pay a lawyer. But it helps, and I kind of like it. It's nice to learn different things. And then I started to learn sales. And to me, one piece of advice that I give to entrepreneurs is that, especially in enterprise business, sales is as important as the technology.

And it's not enough for them to understand the basics of sales. They need to love it. Because if you don't love it, you are not going to hire really good people. Maybe, to your previous question, the key to hiring great salespeople is to love them so they feel your love and your understanding. And you don't treat them only like it's a coin-operated machine, because it isn't. The better a salesperson is, the better they understand the customer and how to talk, how to explain their business, and how to—it's a very complex dynamic that happens in sales and in a deal that is six to nine months long.

It's really not simple. Look, and then the IPO process was very interesting to me. You learn quite a lot because when you talk to private investors, you have a lot of time to explain the business. When you talk to public investors, you have to be way more crisp. And you should tell the same story to everyone. You cannot deviate and give some people more information or less information.

So it was a great education for me to understand, and it helped me even with the way I'm structuring my ideas.

We had a really good IR person. I worked with her quite a bit initially, and we worked together on how we present the information. It helped me quite a bit. And I always look back in time, and I'm asking myself, have I learned something? Am I being transformed in the last six months?

And if the answer is no, something is completely wrong.