Sentra's Ron Reiter - The Importance of Usefulness

SPEAKERS
Ron Reiter, Liran Haimovitch

Liran Haimovitch  00:02
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 the engineering leaders actually doing it. I'm your host, Liran Haimovitch, CTO and Co-Founder of Rookout. We're joined today by a great friend of mine, Ron Reiter. Ron was the Co-Founder at Crosswise, which was acquired by Oracle a while back. He is now at the city 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  00:46
Thank you for having me.

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

Ron Reiter  00:50
Sure. So, my name is Ron Reiter. I am a coder, I started coding at the age of nine, at the age of 18, I was recruited to the military intelligence unit at 8200. Did cybersecurity there for about four and a half years. Then after my service, I went to work at a couple of startups and 20-- and 2013, I founded a company called Crosswise. I was the Co-founder and VP r&d Crosswise built technology to bridge devices that belong to the same person. Basically, we use a lot of big data and machine learning to guess that your phone and your desktop belongs to the same person. We would sell that to people who would know what to do with the data. Usually, it's the AdTech industry, it was mostly the AdTech 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, and 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. SAS services, cloud, IS... endpoints, you really-- kind of in organizations where you 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 an interesting experience as well.

Liran Haimovitch  02:29
You've been moving a lot from a small startup or you've moved from a small startup to a huge enterprise and then back to a small startup. How is it like managing engineering at those different types of organizations? How is it different?

Ron Reiter  02:44
It's been very interesting, because, you know, I started in Crosswise. I was never managing more than one team, but I kind of grew into it. Right? I was relatively young. That was, what, seven or eight years ago. And you know, the team grew and grew and grew. And 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 we're making more architecture decisions and dealing more with the HR aspects of managing people, you know, what team people should be at? What is the right skill set for the task? Who is the right person for that task? You know, who works well together? Who doesn't? That's kind of where most of my decisions were focused when I grew to be the director. And another experience was, you know, Oracle, right? It's a very, very American company, right? Very big, it's very organized, you have to do things that you sometimes don't want. But sometimes you also learn how to make, do things at scale, you know, planning-- quarterly planning at scale is a very interesting task. You know, it requires a different skillset and methodology and tools, it's-- you know, I've learned a lot. I've also learned how to work inside organizations, you know, in the political aspect, also very interesting. I really learned a lot, I really enjoyed my time in Oracle, I was quite a while there. It was, well, an experience. In general, you know, if you asked me what I prefer, of course, I would prefer to manage a small team in a startup, because you can make all the decisions and you know, especially when the startup is 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, basically because other people don't know or want to, or, you know, have time for you.

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

Ron Reiter  04:51
We're basically planning the MVP right now. We are very, very goal-oriented. So basically, we're looking at understanding what's the fastest way to get there, right? So, I'm focusing less on infrastructure, and less on understanding what is you know, 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 all 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 such. But that is really our focus. The second thing, which I focus on right now is to delegate as much as I can to external tourism services around DevOps. I want to do the least amount of DevOps I can. So, 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, you know, any tool that makes me do less DevOps is great, right? Because we really need to focus on building an MVP, seeing the response of the customer, and being basically sales driven, and MVP research-driven, and not thinking about how to build the tool in the right way right now.

Liran Haimovitch  06:19
Isn't that odd? I mean, you're a very senior, very talented engineer, you're hiring an awesome engineering team. So why not take advantage of all the coolest new features? I know, Kubernetes is all the most advanced, powerful mechanisms for running code by go something, idiot-proof such as AWS Abrar?

Ron Reiter  06:38
So 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, okay, from your product manager that tells you listen, this is 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 guns used.

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

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

Liran Haimovitch  07:45
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 maybe outsource? What do you have to do internally? And how do you go about hiring those people?

Ron Reiter  08:04
So 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 zero 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 service is right in terms of the product that I get, if I can have auth, zero, do my authentication, I will do that. If I will have, as I said, the app runner or cloud run and such tools, take care of the infrastructure of the web applications and microservices, CICD, anything that I can use a service for, I will use it right? So, 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  09:02
It's incredibly expensive.

Ron Reiter  09:03
I mean, yeah, I agree, Datadog in such, you know, 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 you know, in general, in terms of how to deal with that problem, which is a problem. There’re two aspects. 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 one the employees, it's a very different mentality. I think it's more about aligning them with your adventure, and showing them, you know, how a growing organization looks like, showing how to start a company, right? 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 type of talents, you look for versatile people, right? 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, right? they have to be kind of aside you. And that's the type of people that you work with. And because of that, they're not interested in the salary, right? They're interested more in equity, they're interested in learning, and to be with you and to be part of your team, that's what they're looking for. And that is actually quite easy to find when you're a second timer, especially when your partners are, you know, manage 10,000 people and what those people are, and they're very great leaders. So 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 above 40 people, okay, hopefully. And that requires culture, right? So you have to build a strong culture, you have to build an environment, you have to build a sense of belongingness, something that's unique to you, that people look for, when you know, 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, right? So, they understand that. So, I'm not there yet but that is my strategy.

Liran Haimovitch  11:37
And just a couple of years ago, you were hiring for Oracle, how was it different?

Ron Reiter  11:42
First of all, it was much harder to be honest, because you don't have-- So there is a transition, right? We felt that 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 adventurers, who just want to, you know, wake up, do what they like, go home, to be with their family, and it's perfectly fine. And they love coding, and they love managing, but that's it, you know, that's what they want to do. That's their goal in life, and it's fine. And so, you look for other people, and you do it in other ways. And you know, make the case for hiring them and try your best and do your best and show that-- we were actually-- the good thing about Oracle is that they allowed us to keep our culture. We decided on which offices we want to have, and we have our own IT, and we have our own everything basically. So, because of the fact that we managed to create our own culture in Israel, which was very accustomed for the Israel engineer that we could have, we actually managed to hire very good talent. Another thing that 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 Salesforce. So, they don't know how to build a cross org culture that fits the modern developers, the needs of the modern developers. You know, Facebook is a great example, being a Facebook engineer. You know you come to the office, you have this huge desk, you have a lot of space, you have, you know, the best type of gadgets, and everything's Mac and everything is just easy. You want a new charger, you just go and get one, right? So very thoughtful towards the developers in Oracle, they don't have that mindset. So, 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's, it aligns with the goals of the business. So that was interesting because we could have, we really hired people who really built the culture for us and it was nice and it worked. That's how it is.

Liran Haimovitch  14:05
Awesome. Now walking at Oracle, your engineering manager, and you're running a SAS product. And Oracle, at the time wasn't a very service-oriented company. What was it like running a production service within such a huge company?

Ron Reiter  14:20
So, great question, I think. So, we were lucky to be acquired into a group, which was 100% SAS driven. Tt was five startups or six startups, no, and all of the six startups were united into one organization called Oracle Data Cloud. So, from the ground up, we were always, we always had that SaaS mindset. And the trouble that we had from an organizational perspective was not on the engineering side. It was in the sales side. It was destructive there. I have to admit, it was very destructive. And you know, a lot of salespeople quit. A lot of customers were lost. They really didn't know how to handle all that, but I wasn't really feeling it from a developer's perspective.

Liran Haimovitch  15:03
So essentially the acquisition by Oracle let engineering flourish. But the business teams dispersed teams kind of lost their way within the organization.

Ron Reiter  15:14
Unfortunately, that's quite correct.

Liran Haimovitch  15:17
That happens quite often in acquisitions.

Ron Reiter  15:19
Yeah, I think Oracle today is very SAS mindset-oriented. You know, they made a lot of good acquisitions. NetSuite, for example. So, I think they're-- they do understand SAS. Now, having salespeople sell SAS is also very challenging.

Liran Haimovitch  15:33
It's very different from what they used to do.

Ron Reiter  15:35
Yep.

Liran Haimovitch  15:35
Today, you're back on the hill, you're back running your own business, you're scaling from the ground up, you're building your SAS MVP and you mentioned the importance of tools. You mentioned the importance of tools is something that will allow you to scale faster, scale easier, and not worry about so much about hiring more and more people for every single test. 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  16:04
Great question. So, 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. When I go to a-- 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 and knowledge is my passion. I investigate a lot of tools all the time and one of the more exciting emails I read is the AWS product release notes. They just-- Yeah. I tend to be proud of the fact that I know almost all services in AWS, and 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 past service for compute. I think Heroku, you know, came right after, you know, I'm not sure if it's after before, it was kind of at the same time, but, you know, they got it. And then, a while past, and I think containers, kind of, everything transitioned into containers but, something was lost in the way, and I think I was looking for these things. And they all constantly understand the pain points of developers and DevOps. I just look for them and when I find them, I'm very excited. So, you know, I just gave one example. But you know, I can give a 100 more, including, you know, Rookout, which I'm very close to, and a good friend and an investor even. But it's very tools of developer tools, or a really close to my heart. And I just love reading all the time on the internet about the neutrals.

Liran Haimovitch  18:01
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?

Ron Reiter  18:10
It's the team, and obviously, but I just really believed in Division. For me, it's kind of trivial that, you know, 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. So, for me, it's just part of the vision, just another piece of the puzzle of code.

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

Ron Reiter  18:39
So, 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 it's 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 obstruction of code in production, you know, the relationship between code and production. And 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 running container, debug a container, test a container, you know, send a container, build a container in any environment, in your own locally in your, you know, 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. So, first of all, before you go into production, I always make sure that you know how to do all these things. And I always assume the worst that things will leak memory and break and we will have to upgrade things fast and enough to move fast. First and deploy a lot, and 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. And I think, you know, the container building block is what you need to master.

Liran Haimovitch  20:16
What do you like most about containers?

Ron Reiter  20:18
That's a good question. I have never thought about that answer. I mean, it's so trivial to me. I think 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? Have you heard of it? Yeah. So, Occam’s razor really talks about that something needs to be complex as it should be, or is the same exact thing, it should be as simple as should be as complex as it should be. Not more, not less. And I think containers is really like, on point, because from one perspective, you have full control over your code, including what you need from the operating system, like full control, and at least have 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, and I think that is why it's perfect.

Liran Haimovitch  21:10
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 to edit? What's the biggest features that are missing from containers?

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

Liran Haimovitch  22:01
Yeah, we're deploying an entire container or entire set of containers, just to add a logline.

Ron Reiter  22:06
Exactly.

Liran Haimovitch  22:06
It's extremely exhausting.

Ron Reiter  22:07
Doesn't make sense. Exactly.

Liran Haimovitch  22:09
I know you've mentioned you're 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  22:20
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, learn python.org, for example, of course, excluding ads, and I don't know how I managed to do it. But you know, I started this idea in 2010, I was really frustrated, 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 on your Mac, it doesn't mean anything like, you have to create a file, what is a file? What is a text file? What is an editor? What is indentation? Like, what are these things? You have no idea, you know how to actually do the technicalities, and let's call them the DevOps of encoding. So, I understand that was okay. I thought I understood, right? It's all theoretical. But I thought I understood that this was the barrier. So, I assumed that if you could code in your browser, and you could, you know, see the solution, and play around with it, and like just, you know, 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. And I mean, Google says, I'm right, I guess. So, I have a free interactive Python tutorial, it will always stay free. It's on GitHub. And you know, 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 on the Israeli ecosystem, as well. But that's a different story.

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

Ron Reiter  24:07
For me in the beginning it was just a few days. It was literally like, you know, three, four days, you know, 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, at the beginning, that's how I did it. Later, you know, I started moving through API's. And today, you can even do it on the browser and 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 use some sort of wiki to manage the tutorials and then I kind of fell in love with Markdown. That was my, at the time, that was what I was very interested in, because I thought 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, well, it would be interesting to build, you know, 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 then just display it in your template. So, I just built it on my own. And then they put everything on GitHub, it's all open. And now you can send me pull requests. And when that started, people started to contribute, like, a lot of code in a lot of languages. So it kind of, you know, got a life of its own. So, you know, I run the infrastructure, I get some, you know, 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, you know, I would probably keep it. So, it's part of who I am.

Liran Haimovitch  25:57
But you mentioned your first Google search. I mean, that's crazy. People spend so much time and effort and money to rank high on Google SEO, and you've kind of-- how did you get there? How did it happen?

Ron Reiter  26:09
So, I think that is, my answer would be completely irreproducible. Because if it was reproducible, it's kind of you know, everyone would be number one. So obviously, it's just a theoretical, but you know, I tend to believe that Google ranks usefulness from websites, you know, because usefulness is something you can measure, you know, 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 not less useful, right? If you stay on the website a long time, or if you don't continue on to the next website, then it's more useful, right? My assumption, if I were Google, right, that is what I would do, rank usefulness. So, I really tried to focus on being useful, and being useful, as you know, 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  27:04
Yeah, I think you've mentioned throughout this interview, very quite often the importance of usefulness, the importance of being focused on the value and bringing the most value. And I think it's everywhere, 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 are building?

Ron Reiter  27:37
That is more a question of product, to be honest. I think, once you have defined a useful product, and that's 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 product-- 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 an understanding of the market, of how to be useful in your category, of how to be easy to use, and quick to use, you know, 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, maybe to reduce your bounce rate and such and such. So, that's really-- and of course, always collect feedback all the time from people. So, 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. Like, if you need to throw it out, throw it out, you know, 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, in that perspective is very important. Right? If you feel-- 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 him what are you more confident about? What do we need to change? What do we need to focus on? What do we-- Where should we invest the infrastructure, the architecture, to scale more versus less and always be prepared to hear no. I'm not saying it's not important to start with very good practices from day one, right? 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 out your MySQL for web scale dB, or whatever. But definitely not that right. I think in the database world, it's, you know, 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, you know, I mentioned functions at Brown or Google cloud and cloud run and such, then, you know, inherently they have scalability by design, any serverless tool would have scalability by design, by definition. You know, the analytic world really made a very big shift there, right? From the vertical Teradata of the worlds to the snowflakes of the world, right? Which started from Google's Big Query. So, I think, if you pick the right tools, at the beginning, you will avoid a lot of growing pains. But you don't need to invest architecture and efforts 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  31:09
Speaking of scale, where do you see Sentra going over the next few years?

Ron Reiter  31:13
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, you know, if everything works out right. So, I hope I'm right. I hope we'll have scale issues. But yeah, I'm very much or I think I'm very much prepared for the scale challenge. You know, I kind of think every day, every morning I wake up and 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 in it fast enough? So that is what I wake up with every morning.

Liran Haimovitch  31:58
Good trouble to have.

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

Liran Haimovitch  32:13
Ron, there is one last question. I love to ask all of my guests. What bug do you remember the most from your career?

Ron Reiter  32:19
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 been happening. So, it wasn't in the army, so I can't really speak about it. But it was an end versus or-- It was supposed to be an end, but it was an or. And, you know, it caused something I can't talk about, but it caused something extremely bad. I will never forget that specific bug I had, and you couldn't see it right, because you know, the application just behaved differently. It wasn't an exception or something. Just you know, a logical bug. It was hard to trace, very hard.

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

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

Liran Haimovitch  33:10
And thanks to everyone who was 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 at @productionfirst. Thanks again for joining us.