Sentra’s Ron Reiter – The Importance of Usefulness

Liran Haimovitch: Welcome to the production-first mindset, a podcast where we discuss the world of building code, from the lab all the way to production.

We explore the tactics, methodologies, and metrics used to drive real customer value by engineering leaders actually doing it. I’m your host, Liran Haimovitch, CTO and co-founder of Rookout.

Liran Haimovitch: We’re joined today by a great friend of mine, Ron Reiter, one of the co-founders of Crosswise, which was acquired by Oracle a while back. He’s now the CTO of Sentra, an incredible new data security company that raised over $20 million. Thank you for joining us and welcome to the show.

Ron Reiter: Thank you for having me.

Liran Haimovitch: So Ron, can you tell us a little bit about yourself?

Ron Reiter: My name is Ron Reiter. I’m a coder. I started coding at the age of 9. At the age of 18, I was recruited to the military intelligence unit 8200. I did cybersecurity there for four, about four and a half years. Then after my service, I went to work at a couple of startups. In 2013, I founded a company called Crosswise. I was the co-founder and VP of R&D. Crosswise built technology to bridge devices that belong to the same person. Basically we used a lot of data and machine learning to guess that your phone and your desktop belong to the same person. We would sell that to people who would know what to do with the data. Usually it’s the ad tech industry. It was mostly the ad tech industry, and we sold the company to Oracle in 2016 for a bit less than $50 million. It was a very interesting experience. I learned a lot from it.

I then joined Oracle as a senior director of engineering. I managed four teams, and then last year, I quit. I started a new company about a month ago, raised money. We started with three other co-founders. Our mission is to help organizations secure and regain control over their data, which is a very big problem today, because your data is basically everywhere. SAAS services, the cloud, IS, pass endpoints, organizations really lost control over their data and they don’t know where it is, how safe it is to store, etc. Basically, that’s our mission and we’re building the product right now. It’s been an interesting experience, as well.

Liran Haimovitch: You’ve moved from a small startup to a huge enterprise and then back to a small startup. How is it like managing engineering those different types of organizations? How is it different?

Ron Reiter: It’s been very interesting because I started – in Crosswise, I was never managing more than one team then, but I kind of grew into it. I was relatively young. That was seven or eight years ago, and the team grew and grew and grew. I don’t really feel the transition to managing a bigger team. Basically what I felt was just me being away from coding more and more, and making more architecture decisions and dealing more with the HR aspect of managing people: what team people should be at, what is the right skill set for the task? What is the right person for that task? Who works well together, who doesn’t? That’s kind of where most of my decisions were focused at when I grew to be the director.

Another experience was Oracle. It’s a very American company. Very big, it’s very organized. You have to do things that you sometimes don’t want, but sometimes you also learn how to do things at scale. Quarterly planning at scale is a very interesting task. It requires a different skill set and methodology and tools. I’ve learned a lot. I’ve also learned how to work inside organizations, in the political aspect. It’s also very interesting. I really learned a lot. I really enjoyed my time in Oracle. I was quite a while there. It was an experience.

In general, if you ask me what I prefer, of course I would prefer to manage a small team at a startup, because you can make all the decisions and especially with a startup as yours. It’s more fun. You don’t get to deal with bureaucracy or wait for other people to make decisions or just not be able to do things because other people don’t know or want to or have time for you.

Liran Haimovitch: And now you’ve got the opportunity again to start your own startup, literally from scratch. You just raised funds a few weeks ago. So how do you go about that? What do you start with your building, your engineering team, your product from scratch?

Ron Reiter: We’re basically planning the MVP right now. We’re very very goal-oriented, so basically we’re looking at understanding what’s the fastest way to get there? I’m focusing less on infrastructure and less on understanding what is the right architecture and more about how to build a product that will appear as if it gives the value, even if it doesn’t give the full value and the potential of the tool. What’s important for us in the MVP is mostly to give something that works and to see the response of the customer. And if he likes it, then we will continue building it in a way that’s more scalable and better and more complete and stuff. That is really our focus.

The second thing which I focus on right now is to delegate as much as I can to external tools and services around DevOps. I want to do the least amount of DevOps I can. For example, Amazon just released their Google Cloud Run competitor, AWS App Runner. So that’s kind of the things that I’m interested in and excited about, because any tool that makes me do less DevOps is great, right? Because we really need to focus on building a good MVP, seeing the response of the customer, and be basically sales-driven and MVP research-driven and not thinking about how to build the tool in the right way right now.

Liran Haimovitch: Isn’t that odd? I mean, you’re a very senior, very talented engineer. You are hiring an awesome engineering team. So why not take advantage of all the coolest new features? Kubernetes is all the most advanced, powerful mechanisms. Why go for something idiot-proof such as AWS App Runner?

Ron Reiter: Great question. The answer is I’m just holding myself back, right? Because right now, if you go into that rabbit hole, you really invest a lot of time in it and what you want to do is to wait for about a year until you get a very, very firm OK from your product manager that tells you this and this is the the product that we’re building. You can go ahead, make it scalable, make it robust, make it flawless. And that is when probably in about a year when the big gun’s used.

Liran Haimovitch: Right now from your perspective, at your stage, it’s all about figuring out the functional requirements instead of focusing on the non-functional requirements. So being production-first is about figuring out how to bring the most value to your customers right now.

Ron Reiter: Yes, correct. We’re basically focusing all of our efforts on the production side and not the dev side. Anything we can to get the tool up faster and make it work in every situation and every use case that the demo needs to work at is our focus.

Liran Haimovitch: Everybody right now is talking about how hard it is to hire engineers. So what’s your perspective on that and how does it compare with the tools you’re working on? I mean, what do you try to work on with tools, what do you try to outsource? What do you have to do internally and how do you go about hiring those people?

Ron Reiter: Really great question. I think I have a lot to say on that topic. First of all, it goes directly to my theory that I want to delegate as much as I can right now. My assumption is I want 0 DevOps right now. I have no capacity, capability to find such people and to hire people like that. Also, I prefer them to focus on the product itself. So basically, my mindset really is about outsourcing everything I can in terms of services, in terms of the product that I get. If I can have Auth0 do my authentication, I will do that. If I will have, as I said, App Runner or Cloud Run and such tools take care of the infrastructure of the ware applications, the microservices, CI/CD – anything that I can use a service for I will use it. That’s a very important mindset that we have right now. I don’t mind paying any price. Any price for these tools.

Liran Haimovitch: It’s incredibly expensive.

Ron Reiter: I agree. Datadog and such, they’re extremely expensive tools. But you know what’s more expensive? Time. And time is even more expensive than the price of developers right now in Israel, which is very high. That is the number-one goal right now. And in general, in terms of how to deal with that problem, which is a problem, there’s two aspects. The first aspect is who are your first 20 developers, and how to hire them. And the second aspect is scaling your organization.

In the first 20 employees, it’s a very different mentality. I think it’s more about aligning them with your adventure and showing them how a growing organization looks. Showing how to start a company. That’s more of the reasons that the founding team comes and works for you, because they really want to be part of the beginning. That also means that you look for other people. First of all, you look for other types of talent, you look for the versatile people, the people that can do anything. But you’re also looking for the people who don’t mind going and doing things that they’re not familiar with or they want to or they have to just be with you in the battle. They have to be beside you. That’s the type of people you recruit, and because of that, they’re not interested in the salary. They’re interested more in equity. They’re interested in learning and to be with you and be part of your team. That’s what they’re looking for. That is actually quite easy to find when you’re a second-timer, especially when your partners manage 10,000 people and 1,000 people and they’re very great leaders. That’s luckily an easier task.

The second task, which is how to scale the organization, this is going to be the first time that I’m going to scale about 40 people. Hopefully. That requires culture. So you have to build a strong culture, you have to build an environment, you have to build a sense of belonging-ness. Something that’s unique to you that people look for when they look for a job. They obviously have to pay high salaries nowadays, and I think our investors understand that, and that is also why it was critical for us to raise a significant amount of money. Because without that amount of money we just couldn’t have done that. So they understand that. I’m not there yet, but that is my strategy.

Liran Haimovitch: And just a couple of years ago, you were hiring for Oracle. How is it different?

Ron Reiter: First of all, it was much harder to be honest, because you don’t have – so there is a transition. We felt the transition from Crosswise to Oracle. What you feel is that first of all, you can’t get the same type of people. You can’t get the ones that want to see how a startup grows, and they have this startup all-can-do mentality. So you hire different people. People who don’t look for wild adventures, who just want to wake up, do what they like, and go home to be with their family. And it’s perfectly fine. And they love coding and they love managing, but that’s it. That’s what they want to do. That’s their goal in life, and it’s fine. So you look for other people and you do it in other ways, and you make the case for hiring them and try your best and do your best.

The good thing about Oracle is that they allowed us to keep our culture and we decided on which offices we want to have and we have our own IT and we have our own everything, basically. Because of the fact that we managed to create our own culture in Israel, which was very accustomed for the Israeli engineer that we actually managed to hire very good talent.

Another thing which is very good about Oracle is that they give a lot of trust to the managers. So they don’t – unlike Facebook and Google and Microsoft, they’re not developer-first in their mindset. They’re more sales-first, so they don’t know how to build a cross-org culture that fits the modern developers, the needs of the modern developers. Facebook is a great example; being a Facebook engineer, you come to the office, you have this huge desk, you have a lot of space, you have the best type of gadgets and everything’s Mac and everything’s just easy. You want a new charger, you just go and get one. So very thoughtful towards the developers. In Oracle, they don’t have that mindset. But on the other hand, they give you full and complete autonomy to buy whatever you want, do whatever you want, as long as it aligns with the goals of the business. That was interesting because we really hired people who really built the culture for us and it was nice. It worked. That’s how we do it.

Liran Haimovitch: That’s awesome. Now, working at Oracle, you were an engineering manager, and you were running a SAAS product. And Oracle at the time wasn’t a very SAAS-oriented company. What was it like running a production service within such a huge company?

Ron Reiter: I think – we were lucky to be acquired into a group which was 100% SAAS-driven. It was five startups or six startups now, and all of the six startups were united into one organization called Oracle Data Cloud. From the ground up, we always had the SAAS mindset. The trouble that we had from an organizational perspective was not in the engineering side. It was in the sales side. It was destructive there, I have to admit. It was very destructive, and a lot of salespeople quit, a lot of customers were lost. They really didn’t know how to handle that. But I wasn’t really feeling it from a developer’s perspective.

Liran Haimovitch: So essentially the acquisition by Oracle let engineering flourish but the business teams, the sales teams kind of lost their way within the organization.

Ron Reiter: Unfortunately, that is quite correct.

Liran Haimovitch: That happens quite often in acquisitions.

Ron Reiter: Yeah, I think Oracle today is very SAAS mindset oriented. They made a lot of good acquisitions, NetSuite, for example. So I think they do understand SAAS now. Having salespeople sell SAAS is also very challenging.

Liran Haimovitch: It’s very different from what they used to do.

Today you’re back on the hand, you’re back running your own business. You’re scaling from the ground up, you’re building your SAAS MVP. You mentioned the importance of tools. You mentioned the importance of tools as something that will allow you to scale faster, scale easier, and not worry so much about hiring more and more people for everything single-task. How do you go about that? How do you go about identifying which tools you need, what’s the best tool for the job?

Ron Reiter: I’m a coder from a young age. I’m an enthusiast. I love development. I mean, one of my favorite hobbies, unfortunately, is coding. What I go to in terms of news is Hacker News, basically. I read Hacker News before I read the news. I am always up to date. That is why I also chose to be the CTO because it is my passion. Technology is my passion. I investigate a lot of tools all the time. One of the more exciting emails I read is the AWS product release notes.

Liran Haimovitch: The digest! [laughs]

Ron Reiter: Yeah. I tend to be proud of the fact that I know almost all services in AWS. I play around with all the new technologies. I somehow find a way to play around with new technologies all the time. And I look for technologies – let’s go back even to AWS App Runner and Google Cloud Run, which I mentioned. I was a very early adopter of Google App Engine in 2008, which was an amazing PaaS service for compute. I think Heroku came right after. I’m not sure if it’s after or before, it was kind of at the same time. But they got it.

And then a while passed and I think containers kind of – everything transitioned into containers. But something was lost on the way and I think I was looking for these things and constantly understand the pain points of developers and DevOps and I just look for them. When I find them, I’m very excited. So I just gave one example, but I can give 100 more, including Rookout, which I’m very close to, and a good friend and investor even. But it’s very – developer tools are really close to my heart and I just love reading all the time on the internet about the new tools.

Liran Haimovitch: You’ve actually been a part of the Rookout success story from the very beginning. What made you take the leap? What made you invest? What made you take a part?

Ron Reiter: It’s the team, obviously. I just really believed in the vision. For me, it’s trivial that once you launch something to production, you completely lose control of it, and you want to understand what’s going on there. And you just can’t do it. For me, it’s just part of the vision. Another piece of the puzzle of code.

Liran Haimovitch: Besides Rookout, how do you go about ensuring you maintain control in production?

Ron Reiter: The higher level of the tools you use, the less control you have. So you have to find the balance. For example, I’m not a fan of functions. Functions as a service. It’s something I think is a good example of a tool that makes you lose control over your production, for many reasons. But if you look at containers, I think containers are really the perfect abstraction of code in production. The relationships between code and production. I think mastering containers is the way to be able to take over production correctly. So for example, if you know how to create a container, run a container, debug the container, test a container, send a container, build a container in any environment – locally, in your cloud, anything. If you are very versatile with containers and you’re able to, you know, most importantly debug a container everywhere, then you can get things under your control. First of all, before you go to production, I always make sure that you know how to do all these things. I always assume the worst, that things will leak memory and break and we will have to upgrade things fast and have to move fast and deploy a lot. You have to make sure that you can test things. So basically, you have to guarantee that before you go to production that you can do all these things. I think the container building-block is what you need to master.

Liran Haimovitch: What do you like most about containers?

Ron Reiter: That’s a good question. I had never thought about that answer. It’s so trivial to me. I’ll say what I said before. I think what I really love about containers is that they’re the perfect abstraction – you know what Occam’s razor is?

Liran Haimovitch: Mm-hm.

Ron Reiter: Yeah, so Occam’s razor really talks about that something needs to be as complex as it should be. Or it’s the same exact thing. It should be as simple as it should be and as complex as it should be. Not more, not less. And I think containers is really on point. Because from one perspective, you have full control over your code, including what you need from the operating system, like full control. At least in user mode. But on the other side, you can make it completely serverless. There’s nothing in containers that ties you to a concept that is called an instance. I think that is why it’s perfect.

Liran Haimovitch: At Rookout, the team and I have written a lot about containers on our blog, and I’m kind of wondering, from your perspective, what’s missing. What would you like added? What’s the biggest feature that’s missing from containers?

Ron Reiter: I think containers, they still lack a lot of tools. And I think mostly around production, right? You can’t go into a running container environment and change what you want. That’s partly by design, which is great. I’m not saying containers should stay immutable. But still, you need that, right? What do you do? What is your approach? You have to have an approach for that. Maybe a new layer. Production, maybe. I don’t know. But you have to – that is something that should be solved inherently in containers.

Liran Haimovitch: Yeah, really deploying an entire container or entire set of containers just to add the logline –

Ron Reiter: Exactly

Liran Haimovitch: – is extremely excessive.

Ron Reiter: Exactly, it doesn’t make sense.

Liran Haimovitch: I know you’ve mentioned you’re a very passionate about technology, about programming. And I know you’re also very passionate about teaching and education of technology and programming. What can you share about that?

Ron Reiter: So if you search “learn Python,” and a few other languages, learn C, learn PHP, learn Java, the first result in Google will be my website, so LearnPython.org, for example. Of course, excluding ats. I don’t know how I managed to do it, but I started this idea in 2010. I was really frustrated. At the time, Code Academy didn’t exist. I was really frustrated by the fact that people who – like, okay, Python is very easy, right? It’s a very easy language. The problem with coding is a lot of times, the setup cost. It’s expensive and it’s hard, even if you have Python installed in your Mac, it doesn’t mean anything. You have to create a file. what is a file? What is a text file? What is an editor? What is an indentation? What are these things? You have no idea how to actually do the technicalities and let’s call them the DevOps of coding.

So I understood or, okay, I thought I understood, right? It’s all theoretical. but I thought I understood that this was the barrier. So I assume that if you could code in your browser, and you could see the solution and play around with it and just start by clicking on Run and then move on from there, then people would be more open to try coding and learning how to code. Google says I’m right, I guess. So I have a free interactive Python tutorial. It will always stay free, it’s on GitHub. It’s interactive. It’s my vision, right, to teach as many people as I can coding. And hopefully someday soon, I can apply that vision to the Israeli ecosystem, as well. But that’s a different story.

Liran Haimovitch: How much effort did you put into making those websites a reality?

Ron Reiter: At the beginning, it was just a few days. It was literally three or four days. Remember my story about Google App Engine? One of their amazing feats were that you can run code in the Cloud without worrying about the security of it. So in the beginning, that’s how I did it. Later on, I started moving to APIs. And today, you can even do it on the browser. At some point, I’ll also use the browser eventually to run the interpreter and such, but the beginning was very easy. And then I think in 2014, another revelation came to me, which was I used some sort of Wiki to manage the tutorials, and then I kind of fell in love with Markdown.

At the time, that was what I was very interested in. It made a lot of sense. I was looking for something like that. Again, mentioning what I mentioned before. I found Markdown and then I thought, “wow, it would be interesting to build a CMS based on Markdown,” so I did that. It’s actually very easy, right? Building a CMS on top of Markdown. You take a markdown renderer and you iterate over directories and you build the HTML out of Markdown and just display it in your template. I just built it on my own. And then I put everything on GitHub. It’s all open, and now you can send me pull requests. And when that started, people started to contribute a lot of code and a lot of languages. So it kind of got a life of its own. I run the infrastructure, I get some ad revenue, and it’s profitable, so it’s nice. It’s fun. Every now and then, I get an offer to acquire my assets. But I will probably keep it. It’s part of who I am.

Liran Haimovitch: You mentioned your first in Google search. That’s crazy. People spend so much time and effort and money to rank high in Google SEO and you’ve kind of – how do you get there? How did it happen?

Ron Reiter: I think that is – my answer will be completely irreproducible because if it was reproducible, everybody will be number one. So obviously, it’s just a theoretical, but I tend to believe that Google ranks usefulness from websites. Because usefulness is something you can measure. Okay, you go into a website. If you go out of it and go to another one, then the first website you’ve been to is less useful. If you stay on the website a long time and you don’t continue on to the next website, then it’s more useful. My assumption, if I were Google, that is what I would do: rank usefulness. I really tried to focus on being useful. And being useful comes back to the discussion I said. Another thing, very important as well, is to not try to compete on categories, which you can deliver the best and the most useful category, right?

Liran Haimovitch: I think you’ve mentioned throughout this interview quite often the importance of usefulness, the importance of being focused on the value and bringing the most value, whether it’s about education or whether it’s about building a new startup or everything you’re doing. And I’m wondering as you’re educating people as you’re giving them the tools of the craft, as you’re teaching them to code, how do you go about ensuring they’re focused on usefulness, about delivering value out of the code they’re building?

Ron Reiter: That is more a question of product, to be honest. I think once you have defined a useful product, and that is not the engineering’s responsibility to do so, I think then you can achieve what I mentioned. To do that, first of all, you have to be a good product manager or have a great product manager, and luckily, in my new startup, I have an amazing product manager. That’s the number one thing you need to do. You need to have understanding of the market, of how to be useful in your category, of how to be easy to use and quick to use, focusing on ease of installation, ease of deployment, ease of use, and very short time to value. Right? In the B2B world, it’s called proof of value. In the B2C world, it’s called metrics. You have to look at the metrics and see that you’ve managed to increase the time that your people used your tool or your bounce, reduced your bounce rate and such-and-such. And of course, always collect feedback all the time from people. That is really a product question.

From an engineering perspective, I think moving fast and being versatile is the number-one priority. So being versatile means don’t be attached to your code. If you need to throw it out, throw it out. Write as many – I have an 80/20 approach. Basically, that means 80% of the value comes from 20% of the effort. And 20% of the value comes from the other 80% of the effort, if you want to get to 100%. So just go for 80 and build more. And if you build more, you get to try out more things. And I think it’s an iterative process, where you understand what needs more investment in terms of engineering following product feedback. I think very good alignment between product engineering in that sense and that perspective is very important. If your product manager feels strongly about something, then you need to know about it. So sometimes engineering needs to pull that from product. Make sure that they tell them, what are you more confident about? What do we need to change? What do we need to focus on, where should we invest the infrastructure or the architecture to scale more versus less? And always be prepared to hear a no.

I’m not saying it’s not important to start with very good practices from Day One. Pick the tools as if you’re going to build the largest service – like, be prepared for scale. If you can, be prepared for it. It doesn’t mean throwing our your MySQL for a web-scaled DB or whatever. But definitely not that. I think that in the database world there’s also very good relationship scalable tools as well, today. But I am saying, okay, if you can use something that is completely scalable, I mentioned functions, App Runner, Google Cloud Run and such. Then you know inherently that they have scalability by design. Any serverless tool would have scalability by design, by definition. The analytics world really made a very big shift there, right, from the Vertica, Teradatas of the world to the snowflakes of the world, which started from Google’s BigQuery.

So I think if you pick the right tools at the beginning, you will avoid a lot of growing pains. You don’t need to invest architecture and effort in making sure that what you’re building right now is really, really scalable, because you can always rewrite the things that aren’t scalable over time.

Liran Haimovitch: Speaking of scale, where do you see Sentra going over the next few years?

Ron Reiter: I hope we’ll get to dozens of customers in a few years. I understand that I’m going to have a massive challenge in terms of scale if everything works out right. So I hope I’m right. I hope we’ll have scale issues. But yeah, I’m very much prepared for the scale challenge. Every day, every morning I wake up, I think, “Okay, if I make this decision in two years from now, when we’ll have X customers, will they really be annoyed because we’re not scaling fast enough? Will we not be able to add on customers because we can’t scale fast enough?” That is what I wake up with every morning.

Liran Haimovitch: Good trouble to have.

Ron Reiter: Yeah. I’m in this mindset because I’m just trying to avoid my boss yelling at me. Why isn’t this working good enough? But yeah, if we will have that trouble, then it will definitly be good trouble to have.

Liran Haimovitch: There is one last question I have to ask all of my guests. What bug do you remember the most from your career?

Ron Reiter: Wow. That’s a good question. I remember one bug which I had, I wrote a condition wrong and the condition caused some flow to happen in places that it shouldn’t have been happening. It was in the army, so I can’t really speak about it. But it was an and versus or. It was supposed to be an and but it was an or. And it caused something I can’t talk about, but it caused something extremely bad. And I will never forget that specific bug I had. And you couldn’t see it, because the application just behaved differently. It wasn’t an exception or something. It was just a logical bug. It was hard to trace. Very hard.

Liran Haimovitch: Ron, thank you again for joining us. It was great having you. We had a great episode.

Ron Reiter: Thank you for having me. It was really fun.

Liran Haimovitch: And thanks to everyone who is listening on, and check out Sentra.

So that’s a wrap on another episode of the production-first mindset. Please remember to like, subscribe and share this podcast. Let us know what you think of the show and reach out to me on LinkedIn or Twitter @Productionfirst. Thanks again for joining us.