20-Minute Leaders“What we're doing at Swimm is downloading information that’s in the head of the developers and creating a strong knowledge base that will grow.”
20-Minute Leaders
“What we're doing at Swimm is downloading information that’s in the head of the developers and creating a strong knowledge base that will grow.”
Developers don’t document information about their code because it is a pain to write, it is quickly out of date, and it’s hard for others to find, says Oren Toledano, co-founder and CEO of Swimm.
Developers don’t document information about their code because it is a pain to write, it is quickly out of date, and it’s hard for others to find, says Oren Toledano, co-founder and CEO of Swimm. So when new employees join and need to add to or change the existing code, they need to have the other developers explain the legacy code and logic first. Swimm is changing this process with a documentation product that integrates with developers’ workflow. It keeps the documents in the developer environment and either flags items that need to be updated or automatically updates them so everyone can access the knowledge base and it can grow with the code. Toledano explains that it is important for him to balance client needs and technical possibilities. He says there is great opportunity for Swimm to expand as the company gathers more knowledge about code.
Share with me a little bit about yourself.
I was born in France and grew up there until the age of 17. I moved to Israel, learned Hebrew, studied political science and economics at the Hebrew University of Jerusalem, and was selected for 8200. That's where I got my knowledge with technology, product, and connecting between the needs or pain and the engineering part. As CEO, the ability to balance between the needs of the client and the technological specs is something that is important.
After the army, I was three years in France. I was the head of the Jewish Agency there. I came back and founded Israel Tech Challenge. I was the CEO for seven years. Training, technology, coding, Zionism, connection with Israel: that's my background.
Do you know how many engineers you've brought into the ecosystem?
There are two numbers that I like to hold for myself. One is hundreds of engineers, almost more than 1,000 right now, after all these years with ITC. Another number is from a period at the Jewish Agency: 6,000 Jews came to Israel during this time.
What is your understanding of the problem space as you're thinking through Swimm?
It came from Israel Tech Challenge because we were training so many people to become developers and then we understood that it was a big pain for them to onboard in their new jobs. My co-founders and I tried to understand where the pain exists. The essence of this problem is understanding the code base at the company. That's how it started, from the onboarding problem of developers.
If somebody who's not necessarily an engineer thinks through this problem, they are thinking, "Let's equate a repository to a Google Drive folder. You have a bunch of files, and you print them out and just start reading them.” But it's a little different than that.
Yeah. Code is very complex. Usually when you join a company that is more than 10 developers, code has already been written by many developers in different ways and usually with the complex logic behind it. It's not self-explanatory. Some parts of the code are, but you can't understand the complex logic behind it, the different flows and how things were exactly built. When you have to contribute code, it's kind of complicated. The way it's done right now is that you ask your fellow developers in the companies, and some of them have already left. There is what we call "legacy code." There are areas in the code base that nobody really understands and try to avoid because of the complexity.
Is it simply that coding is complex, that engineering is complex? Or is it the habits that we formed that make it complex?
I think it's a mix. It's the fact that code is a complex creation. As it becomes more and more advanced, it becomes more and more complex. Another part of that is that we didn't have the tools or the good habits to create a knowledge base around the code-base itself. Every time they write a line of code, they can't document this code and can't explain it. The result of that is every time someone needs to understand the code, they need the developers themselves to explain it. The knowledge is very scattered in different places, in the head of the developers. What we're trying to solve at Swimm is a way to easily download this knowledge that is in the head of the developers and create a strong knowledge base around the code that will actually grow as the code is growing.
Tell me about the product.
When we started learning about what is documentation, it's something that developers hate. They have three main pains that we discovered: it's hard to write documentation; it's hard to maintain documentation because the code is changing all the time; it's very hard to find documentation when you need it. If I know that it's going to be very quickly obsolete and nobody will find it, I don't want to write it.
What we're trying to rebuild here is this relationship between developers and documentation. Make it easy to write, easy to maintain, and easy to find. The way to do it is, in our opinion, to connect it very deeply with the CI/CD, with the workflow of the developers. In some cases, we will help them with automated documentation that we will create based on patterns in the code. We will connect the docs that we're creating with Swimm with the code itself, and we'll be actively following after the changes in the code. We'll be able to say, "This doc is outdated. We will update it automatically. Or we will flag it and you will update it." Because of this connection with the code itself, while you are in the developer environment, we will tell you exactly where the relevant doc is when you're working. We try to avoid a context switch, which is a big problem for developers.
I'm curious about how you get engineers to contribute to this. When you said that that was a part of the CI/CD, is that an enforcement mechanism that before they deploy, they have to contribute to the documentation?
Enforcement is a word that we don't really like, but building a culture of documentation. So once you couple the code with the docs, you want to ensure that the work you've done as a developer is not going to go out of sync. If it's part of the build, it's part of the CI/CD, and you decide as a team to block a PR every time it goes out of sync, it becomes this habit. In more than 90% of the cases, Swimm will automatically update the docs.
How do you cope with logic changes?
It's part of our secret sauce and the patent that Swimm has: by adding snippets of codes in the doc themselves. By looking at these snippets and the contextual change and the syntax change, we're able to decide whether the changes were important or just changes that happen all the time. We can decide whether to update the doc automatically or tell the developer, "You need to take a look at that."
Tell me about go-to-market and how you actually get this to scale.
With developers, it needs to have a part of it that is PLG, product-led growth. Developers want to test the product themselves; they want to make sure they like it. It's really like almost a B2C approach when you need to know the approval of the other developers. There is another motion that we call "top-down," and it's more like a B2B sales practice that you need to have with bigger organizations. We sometimes need some security process and an IT process and they need some approval. So you need to have the two motions going on.
What are the KPIs that you measure?
When you're a SaaS or in PLG, you need to measure all parts of the funnel, and then you need to measure adoption. How fast is it to write a first doc? How fast do people invite additional people from the team? How many docs are being written, read, and maintained? All these, we measure.
I think that something that's really fascinating about this strategy is that, given that you succeed in becoming a part of the CI/CD process, the opportunities are pretty limitless.
We met with one of the important investors in New York. They told me, "The thing I heard from your presentation about Swimm is that actually you're building a better and smarter Atlassian." We didn't think about that. When you own this knowledge on the code itself and you know what are the best practices, you can go in many, many different directions. It's really something that we're looking forward to.
Michael Matias, Forbes 30 Under 30, is the author of Age is Only an Int: Lessons I Learned as a Young Entrepreneur. He studies Artificial Intelligence at Stanford University, is a Venture Partner at J-Ventures and was an engineer at Hippo Insurance. Matias previously served as an officer in the 8200 unit. 20MinuteLeaders is a tech entrepreneurship interview series featuring one-on-one interviews with fascinating founders, innovators and thought leaders sharing their journeys and experiences.
Contributing editors: Michael Matias, Megan Ryan
