The Philosophy Of Product Led-Growth with Or Weis, CEO & Co-founder of Permit.io

(Joel Beasley at 00:00:03) Hello, my friends. Today we're talking to Orr, CEO and co-founder of Permit.io. And we discuss how both empathy for your customers and frustration with a problem leads to great products, the philosophy of product-led growth, and keeping your head above the trenches as a leader. All of this right here, right now on the Modern CTO podcast.

(Joel Beasley at 00:00:32) Here we go. This is the Modern CTO podcast.

(Orr Weis at 00:00:42) And it's essentially also what I try to do. So I'm a developer at heart. I love software, and so I want to cater to other people like myself, to other developers. And that's why I've been creating dev tools for quite a while now.

(Joel Beasley at 00:00:56) Nice. Yeah. How did you get into that initially?

(Orr Weis at 00:01:00) So I started pretty early. I got lucky. I started writing software or code to some degree at the age of five. My sister kind of—we're talking early nineties. My sister kind of convinced my parents to buy this very basic computer. Now looking in retrospect, it was still able to run games. So I was, as such a kid, I was just like—she showed me how I can from a DOS command, how I can start different games. And that kind of just got me started both with English and with running commands on a machine. And from there, it was kind of a deep rabbit hole that I still haven't really emerged at the other side of it. But I think that what really was the biggest leap in my work in tech was my military service.

(Orr Weis at 00:01:50) I served in a unit called 8200, which is part of the Intelligence Corps in the IDF. It's equivalent to the NSA or GCHQ. Also got to work a bit with those folks, which is kind of cool. And there, I really worked on—so I was an engineer and I worked with software before, but in that scenario you work on things that have immediate impact on life and death situations. And that really forces you to deeply understand your software and all its minute aspects. And I think that really took me multiple levels upward in my capabilities and also in my passion for software.

(Joel Beasley at 00:02:31) So what kind of software tools are you building in the intelligence—I don't know, industry's the wrong word.

(Orr Weis at 00:02:37) Intelligence Corps. Intelligence Corps. Intelligence community, if you want to refer to it in a wider sense. So first of all, I can't really tell you—or I can tell you, but then I'll have to kill you. So I'm not sure that's the right way to go with this podcast. But without saying too much and just using some common sense, in the end of the day, intelligence solutions or intelligence organizations are responsible for collecting intelligence to protect the interests of their countries and their people. So in the end of the day, you're building things that help collect data, organize it, find the actual interesting bits of information within it, and similar things like that in multiple areas. There's SIGINT, which is signals intelligence. There's cyber, which everyone knows by now. And there's things like VISINT, like the ability to analyze visual information.

(Orr Weis at 00:03:35) So maybe that's the most easy thing. You have a satellite. It can take pictures from outer space or from orbit, and then you need to actually analyze those maybe fuzzy images and understand where's the ground troop layout of the enemy or where a new nuclear silo is being built or whatever. These are not actual examples, but things that are easy to imagine.

(Joel Beasley at 00:03:59) Right. Cool. Well, so to avoid digging deeper into the—

(Orr Weis at 00:04:04) The topic. Risking your life.

(Joel Beasley at 00:04:06) And risking my life. So what did you start doing professionally after you got out of the service? What was kind of your first civilian jobs?

(Orr Weis at 00:04:17) So I worked in a startup called Integra, and we basically did containers before containers were a thing, but with a really bad go-to-market. We built really amazing, super complex technology there, but I think really missed on actually building it in a way that people would find it easy to adopt. And in the end of the day, something a lot simpler like Docker rose to fame and kind of consumed most of that market. They ended up kind of spoiling their own go-to-market, but that's a different kind of story.

(Joel Beasley at 00:04:51) Cool. Well, what inspired you to create your current company? And did you have a co-founder? How'd you meet them?

(Orr Weis at 00:04:59) So maybe I can just continue the story from that point in time chronologically. So after Integra, where I was one of the first engineers, I then worked in a couple of other startups. I was a VP of R&D in a cybersecurity company. And then in late 2016, I co-founded and ran as CEO of a company called Rookout, which is another dev tools solution.

(Joel Beasley at 00:05:20) Wait. We had Rookout's CTO, Leron.

(Orr Weis at 00:05:25) Leron. Yeah. Yeah. So Leron was my co-founder in Rookout. And during my time in Rookout, we ended up rebuilding our access control to the product itself five times when the company wasn't even three years old. And I was like, well, that's stupid. I don't want to do it once, let alone five times. And kind of taking a step back and thinking about it, I realized that I've been building permissions for my different products throughout my career thousands of times. And again, at no point did I want to.

(Orr Weis at 00:05:58) It's a stupid necessity. I got together with Asaf, who's a good friend and now my co-founder, and he worked at Facebook at the time. And through that, we kind of saw that Facebook, for example, invested a team of 30 people for half a decade to build the level of access control that they have, and they're still continuing to build it onwards. So that kind of painted the picture of both how annoying and complex it is for developers today, especially with the move to the cloud, especially with microservices, especially with multi-tenancy. But more importantly, the problem is only getting worse.

(Orr Weis at 00:06:34) It's only going to get more complex as the software itself is getting more complex and the players interacting with it are getting more complex. So up till now, it was mostly human users using your software. But more and more, it's becoming other software, other automated agents, on behalf of other automated agents, on behalf of other automated agents, on behalf of humans somewhere down the line that actually use the software you've built. And the speed and the complexity and the amount of connectivity that exists is just mind-blowing. Just thinking about all those levels of permissions and the way you need to shape your software for them, that can be a bit overwhelming even just to think about it. So that really kind of brought us to understand that this is an important problem to work on, both for now and also for the upcoming future.

(Joel Beasley at 00:07:26) That reminds me of—we have an episode coming up with a company called Flatfile, and their founder describes what you're talking about. They have tools for importing data and cleaning that data on import so that it's more useful. And he had to build those tools over and over again, and he calls it rage design because he's just so mad that he has to build it. So he sat down and made it an off-the-shelf solution.

(Orr Weis at 00:07:55) Yeah. I think those are the things that are the best source materials for creating companies. Things that you are actually passionate about. Pain that you're actually feeling yourself. That makes sure that at least one thing happens: you have empathy for your customers. You actually understand what they want, and you're not guessing. Or a lot of times, especially with more technological folks like ourselves, usually you get excited by this tech idea, and you're like, oh, let's see if we can find things that we can do of this. And sometimes that works, but most often you miss the mark because you're not actually caring for what your customers, what the people actually want.

(Joel Beasley at 00:08:33) Yeah. I mean, people talk a lot about how important it is to be close to the customer. But if it's pain that you are personally experiencing, you are the customer. So it seems like a good scenario. So how long have you been working on Permit for?

(Orr Weis at 00:08:51) About—well, it depends on how you count it, but I'd say a year and a half, getting close to two years now.

(Joel Beasley at 00:08:57) Very cool. So what stage of growth is the company at, and what kind of problems are you solving on a day-to-day basis today?

(Orr Weis at 00:09:05) So we started with—we almost bootstrapped for a year, focusing initially mostly on an open-source offering, a project called OPAL, which we built on top of another open-source project called OPA, Open Policy Agent, which is pretty well known. OPAL itself is also becoming very, very popular these days, already running in production in companies like Tesla, Zapier, Accenture, and dozens of others. So we took those, and we built Permit as a service on top of that, adding more capabilities, mainly the experiences that you need to build access control into your product. So a lot of products out there try to give you the infrastructure, like a policy engine, APIs that you can play with, but we're kind of coming from empathy. We really understand that that's not what developers want.

(Orr Weis at 00:10:02) Developers want to get this problem off their table. No one is excited about building access control. No one is going, yay, I really want to get that access control ticket. I really want to add another role to the system. No. That doesn't happen. People are like, a developer getting these tickets? Just how can I get rid of this as quickly as possible and make sure that this ticket doesn't come back in another way or form? And the main problem with access control is—I like to call it—it's the gift that keeps on giving.

(Orr Weis at 00:10:29) There's always another requirement from another user, from another stakeholder in the company, the product manager, security, compliance, partners. There's always something. And in the end of the day, none of these things are unique. So I'll just list a few experiences that usually you need to build into an application, and you'll see as I list them that you've seen all of them a billion times. But the sad thing is every time you saw them, some poor schlep of a developer had to create them from scratch.

(Orr Weis at 00:10:59) So user management with the ability to assign roles, API key management, secrets management, audit logs—AKA the ability to see who did what within the system. As a developer, you want to see what all the tenants did, and you want each tenant to be able to see on their own what they did within the system. Multi-tenancy, obviously. If you're with microservices, you want to have multi-tenancy. Approval flows, the ability to ask permissions from another user. Invites, emergency access, and the list really goes on and on and on.

(Orr Weis at 00:11:31) And none of these things are unique, but building them from scratch every time is a pain in the ass. So instead of just giving you an API and telling you, go ahead, build all these awesome things yourself, we actually provide those out of the box. But we provide them with low-code, no-code interfaces that generate code. So for example, our policy editor that allows you to create new roles, new permissions—it creates code in a language called Rego and soon in other languages that you can run on Open Policy Agent.

(Orr Weis at 00:12:04) So you can maintain policy as code but still have the product manager—let's say the product manager comes in and says this new customer needs another two roles that are specific to their use in the system. So instead of opening a ticket and having an R&D sprint on adding those capabilities, you can visually tell them, dude, it's like, go click on Add Role, check a few checkboxes, and you're done. You don't need me for this. Just go. I have better things to do. I have an actual product with actually unique features that I want to build. So this is kind of empowering for everyone, the developers themselves, which are the people we focus on. But through them, the entire organization gets empowered. And what we're focusing on now, getting back to the actual question that you asked with this additional background—so what we're working on now is really taking it to the next level.

(Orr Weis at 00:12:55) So up till now, we provided role-based access control. Maybe I should recap that too. So when you're building an application, everyone starts with the most basic policy model, which is admin and non-admin. Right. So I'm the admin. I can do whatever I want. I have all the permissions, and everyone else is not an admin. But then you get a requirement that some other people should have some more permissions, and then you move to admin, non-admin, and super admin. And then you move to access control list and then to role-based access control and then role-based access control plus something, plus ownership, plus time, plus geolocation, plus some kind of attribute. And then you move to attribute-based access control as you pile on more attributes on the RBAC.

(Orr Weis at 00:13:38) And then you sometimes move to relationship-based access control and other stuff like that. And demands are constantly, as I said before, are constantly coming. And the idea with what we try to do is that you don't actually have to understand all these models, and you can run between them with ease. But we started by supporting RBAC, role-based access control, which is probably the most familiar one. But it's not the most powerful one. It doesn't cover all the cases. So now what we're bringing to the table and by taking it to the next level is with attribute-based access control, allowing you to create all those complex policies, all those complex conditions without having to write code, without having to understand all the models in depth, without having to know Rego, that policy language, but still have everything generated as code and maintained into a Git repository in a way that everyone can play with. And so that's what we are really focusing on now, making it fulfilling the promise end to end—not just enabling this, but enabling this end to end. So everyone at the party, all the other stakeholders, the product managers, security, compliance, can all enjoy the full power of policy as code.

(Joel Beasley at 00:14:51) That is crazy to me that you have to build from scratch at every company just the ability to have the most basic level of admin and non-admin permissions within your company. I hadn't thought about that before, and that totally makes sense why you're running a company off of solving that problem.

(Orr Weis at 00:15:15) It's kind of silly. I think it was annoying for a while now. I think the problem has been silly in the way it affects so many people for at least a decade now. But with the move to microservices and the incoming scale, it's moving from being stupid to being ridiculous. And we could probably have started this company slightly earlier, but I think now it's not a moment too soon.

(Joel Beasley at 00:15:43) Yeah. Well, it sounds like Permit has to be pretty deeply embedded in the stack of whatever company you're working with. What's the timeframe from when you initially start working with another company to when you're fully up and running and people are able to just click the button to assign roles?

(Orr Weis at 00:16:06) Yeah. That's a terrific question. Because truly, authorization or permissions, as opposed to authentication, is a far more deeply ingrained problem than authentication. It's for every basic request that is handled by the application, you need to test for permissions. As opposed to authentication, which just happens at the gateway—you just log in, and then you continue with that verified identity throughout your application.

(Orr Weis at 00:16:32) With authorization, again, with every action you do, you need to apply some enforcement, some checks, and some enforcement. And that is definitely part of the challenge, but we are leveraging a lot of our advantage from coming from the Intelligence Corps, cybersecurity background, and knowing how to create solutions that are easily embedded into software without hindering that software. And a lot of the architecture that we've created both for Permit itself and for OPAL, the open-source project that we have, really speed up that process, really make it easier and less painful for you as someone adopting it. And I can elaborate on the architecture, but I'll take a step back first and just tell you how it usually looks. And the bottom line is one developer with a couple of weeks can take a mid-size company to use Permit on their own single-handedly, moving from their existing homebrew solution to using Permit end to end in production.

(Orr Weis at 00:17:30) And the best thing is that they can do so without having to talk to anyone. We're available if someone wants to. It's really easy to reach out to us. There's a Calendly link on our home page. If you click on it, pick a date, I show up on Zoom like magic. Maybe you regret it because then you're talking to me, but still, that's what happens.

(Orr Weis at 00:17:52) So you have that option, but you don't have to. We've been doing self-service from day one, and the solution is really built so you can adopt it on your own and very quickly get started. I think within a couple of minutes, fifteen minutes, thirty minutes, you can take a small application and have it run with Permit. And within, as I said, a couple of days, couple of weeks, you can take your entire production and migrate it. We also have guidelines how to do it safely, gradually.

(Orr Weis at 00:18:20) You can go gung-ho, but we also encourage you to run it side by side with your existing solution for at least one point so that you have confidence in how you're rolling with it as you're going into production. But yeah, that's kind of the bottom line. While it is complex, we really handle most of that complexity for you.

(Joel Beasley at 00:18:40) Nice. That's amazing. And I like how you mentioned the difference between authentication and permission access management, because that reminds me of we talked to the CTO of Zscaler on the podcast a while ago. They're a large security firm. And he talked about thinking of security as two different models.

(Joel Beasley at 00:19:03) The old way of thinking, he calls it the coconut security model, while the new way is the avocado security model, where the coconut is there's just a hard outer shell, but once you're inside, it's all just liquid sloshing around, and you can go anywhere you want once you've penetrated the outer shell. But then with the avocado security model, you have an outer shell, and then there's some resistance inside. It's not just liquid. And then there's another core on the inside that you can't get into after you've broken through the outer shell. And the analogy there is that the second model is using permission-based access management, not just get your password and you're in and you access everything.

(Orr Weis at 00:19:49) Yeah. You don't want to have a single point of failure or have a weakest link element. So a weakest link element is something that is unavoidable. It's really at the core of building security. And I think in the end of the day, moving to microservices and moving to more kind of granular architectures can give you that zero-trust capability for every small element.

(Orr Weis at 00:20:15) The challenge is that now the duty is you need to manage it for each of those small elements. So you naturally have the option or the advantage of building more granular security and more layers of defense, but it's still left up to you to actually manage it. So that's what we're trying to make easier, giving you and the other stakeholders you're working with the interfaces to make it easier to do while baking in all of those zero-trust components right into what you're using. And I think these things nowadays are mandatory. You have to recognize the weakest link principle.

(Orr Weis at 00:20:54) You have to recognize that you have a very large, complex space that you need to defend. And you have to recognize that there's so much to understand that it's basically nonsensical to expect that you can do all of this on your own. It's much better to adopt best practices and, ideally, even tools that can bring this for you to the table. This is why when I'm talking to fellow engineers or fellow security practitioners, what I really try to tell them is it's okay to build these things on your own, but you better stick to the well-trimmed path. You better stick to at least the best practices.

(Orr Weis at 00:21:34) And if you can, the open source projects that have those best practices kind of baked in. And, ideally, if you have the capacity for it, services that can take you end to end so you can actually focus on the things that you know best as opposed to cryptography, as opposed to the differences between all the policy models, as opposed to managing the different languages and how you manage and how you write in them the right policies that are both performant and secure, just as examples.

(Joel Beasley at 00:22:03) Yeah. Well, so I want to talk a little bit about leadership. Is that cool?

(Orr Weis at 00:22:08) Yeah, awesome.

(Joel Beasley at 00:22:08) So I know that you're a big proponent of product-led growth model at a company. Can you give me an overview of what that means at Permit?

(Orr Weis at 00:22:19) Yeah. For sure. First of all, product-led growth is a go-to-market strategy. It's a way that you think about how your product, your company is going to meet up with the market. And product-led growth in essence means putting the product itself upfront and removing as much friction as possible so people can enjoy the product itself.

(Orr Weis at 00:22:41) And if you hear it just on a baseline, it just sounds, yeah, that makes total sense. But we need to remember, especially the younger folks, we need to remember that up till now, that's not how products went to market. Products went to market through a large bow-tied or otherwise sleek salespeople, sales operation going in, knocking on doors, and convincing people to try out this new amazing product from this and that. Nowadays, and still most of the biggest companies are still selling to market with this kind of layout, but it's becoming apparent that this doesn't fit the consumer culture anymore.

(Orr Weis at 00:23:25) So most sales operations, for example, are dependent on getting leads. So you could do cold calls and you do conferences and then you chase over people and send them messages on LinkedIn. And I don't know about you, but with me, the first thing that happens if someone calls me is that I get annoyed. Why the hell is someone calling you?

(Orr Weis at 00:23:44) And if I, for some reason, decide to answer that and someone starts pitching and selling me something that I didn't ask for and I don't care about, I'm not only annoyed, I'm furious at that point. So expecting people, if you're building a product and you expect people to, no matter how good your product is, if you expect people to tolerate that, I'd say, rude behavior, I think you have another thing coming. So product-led growth is really being aligned with the modern consumer culture, and it's really being aligned with being a decent human being and not bothering people. And the way to do it, so a lot of people would ask at this point, so how the hell do I get people to actually learn about my product if I don't push it on them? And the answer is simple.

(Orr Weis at 00:24:32) Just tell people, put out the message that the product exists, and then just let them try out the product. Let them try it before they buy it. Create alignment points where they can get a taste of the actual value of the product. And if they're interested, you'll be surprised. They actually raise their hands and go in and want to talk to you instead of you having to chase them.

(Orr Weis at 00:24:51) So, interesting side effect this has for companies is it creates much more efficient sales cycles. It increases the margins. And maybe most importantly, it's better on the soul. You don't feel like you're forcing people's hands. And specifically with developers, developers have a keen eye to anything that is salesy or too markety.

(Orr Weis at 00:25:15) And if you, I advise people to try this in a conference. Go up to a developer and start selling them a pitch. You'll see their eyes glaze over instantly. They'll be there. They'll stand and hear your pitch, but it's essentially going directly to /dev/null.

(Orr Weis at 00:25:31) So what I recommend instead with PLG is, again, create a product that people can use with ease. Remove as much friction as possible so people can start getting understanding of what it is, understanding of what its value is, and actually tasting that value as soon as possible. And that's exactly what we're doing with Permit. So from day one, we offered self-service. From day one, we were completely transparent about our pricing and what's in the open source and what's not in the open source.

(Orr Weis at 00:26:04) We were always available to talk to people, but never forcing our hands on them. So we're just putting ourselves out there. And I spend most of my time every week talking to customers, and all of them are inbound. All of them are coming to me most often after they tried out the product because they could, and it was interesting to them. And that's really why I think PLG just makes a ton of sense.

(Orr Weis at 00:26:32) And I was surprised by investors and other people that kept kind of clamoring or trying to latch back to the old world of enterprise sales. I think it can be relevant for a lot of ventures, a lot of companies. But for most companies and definitely companies selling to developers, I think PLG is possibly the only way to go.

(Joel Beasley at 00:26:55) Yeah. So did you have sales experience before you started Permit?

(Orr Weis at 00:27:00) So in my previous company, so Rookout is a dev tools company, but it's enterprise top-down. So it's the complete opposite go-to-market. And while the company definitely has a lot of customers and it's selling well, I couldn't ignore the amount of friction it takes to engage with a customer. And maybe another point that is relevant there is the direction of the engagement. So if you work with the developer themselves, they are able to adopt things quickly and push them into the organization and also facilitate purchasing very quickly.

(Orr Weis at 00:27:37) They have a lot of clout as people controlling the software itself, which is a lot of time the heart of any software company or software-driven company, which is essentially all companies at this point or almost all companies at this point. But if you go the other way around, if you go top-down, it means that you're selling to their managers, like the team leads or the VP of R&D or CTO or maybe even another executive at the company. And then what happens is that that person goes to their developers and tells them, I think this is the tool you need to use. And you know what effect that has? That has the completely reverse effect to the one you want.

(Orr Weis at 00:28:18) Yep. Because if there's something that developers hate, it's being told what tools to use, especially by people that are not hands-on in the work and don't actually know what is needed. So it's actually a surefire way to create more friction for your sales operation. And I think that's just a shame. It could be a lot easier and creates a lot more alignment if you're aligned with how your customers want to buy the product and not just how you want them to buy the product.

(Joel Beasley at 00:28:46) Yeah. That's a trend I'm seeing talking to lots of tech leaders is selling directly to the developers, or I'm hearing a lot of organizations that used to be top-down, and their whole reason for coming on podcasts and talking to people like me is that they're trying to get out to the world that they're selling directly to developers. They're trying to reach the developers directly. And hearing you talk about it, I love the way you discuss it because I can so hear the passion that you are a developer, and you just want to speak to people the way you would want to be spoken to.

(Orr Weis at 00:29:26) It's basically common decency when you think about it. Yeah. The bigger corporations are now latching onto this trend as it's kind of engulfing the market and there's more conversations around it, and they can also see the impact for it. I think one of the most interesting test cases for this is the revolution that happened in the APM world and the monitoring world for software. I had the good fortune of actually being at the sidelines, talking to the people, and seeing it happen.

(Orr Weis at 00:29:55) So if you go back to, say, 2016 and talking to the leaders of the APM world, primarily AppDynamics and New Relic, both founders of two companies came out of Wily. And so they were archenemies of one another, kind of competing on the same market. And, basically, they and Dynatrace, to some degree, kind of dominated the space. And when you talk to them, you ask them, what, where are you headed? What are you working on in terms of the market?

(Orr Weis at 00:30:23) And they're like, we're focused on the enemy, which if you're, it's New Relic, it would be AppDynamics. If you're at AppDynamics, it would be New Relic. And and it was also like Voldemort. You don't mention their name. It's like the enemy.

(Orr Weis at 00:30:34) We have to defeat the enemy. It's us and them to dominate the market. And I was like, yeah, but what about this tiny company, Datadog? They seem to be growing quickly and have unique things to offer. And they're like, Datadog, they sell to only small companies.

(Orr Weis at 00:30:50) They have this mid-market bottom-up approach. That's nonsense. We're selling top-down to the Fortune 500 companies. We don't care about that. Speed forward a couple of years.

(Orr Weis at 00:31:02) Not many, like 2018, 2019. You talk to AppDynamics or New Relic and you ask them, hey, how's it going? Are you fighting with the enemy? What? You mean those guys?

(Orr Weis at 00:31:11) No. No. No. They're not interesting. It's all about Datadog now.

(Orr Weis at 00:31:14) They're eating the market. We have to catch up with them. Right. And you speed up a little further, get to current times, like a year ago, two years ago, and AppDynamics is essentially dead. They were acquired by Cisco and gradually just faded away.

(Orr Weis at 00:31:30) No one from the original company is there anymore, and they're struggling just to maintain their existing clientele, even losing foothold in India, which was their primary example for the market. And New Relic, well, I'll get to New Relic in a sec. Let's look at New Relic and Datadog. So New Relic was the bigger company, right?

(Orr Weis at 00:31:55) And Datadog was like a tiny thing. And if you look at the market cap graph, it's really interesting to see the intersection point and then to see where things are now. And, like, last time I looked, I think New Relic was at $3 billion valuation and Datadog at $33 billion valuation. And so, as I said, AppDynamics is basically fading, and New Relic is still fighting. It's still there.

(Orr Weis at 00:32:25) You want to guess how they are kind of still surviving?

(Joel Beasley at 00:32:29) They adopted the bottom-up approach?

(Orr Weis at 00:32:32) Exactly. They spent a year or more pivoting from top-down sales to product-led growth bottom-up. They're still struggling just to make ends meet, but they are there, and they're changing to meet these newer times. And I think this story really highlights two things. One, in the end of the day, when push comes to shove, the wider market access gives you the advantage.

(Orr Weis at 00:32:57) And two, the incumbent, even if they're bigger, they don't have the advantage unless they're aligned with how the market wants to buy the product. And I think that just appeals to anyone looking at a market with incumbent players or with a future where they want to remain a leading player in that space. And with that, I think in most scenarios, you just can't ignore product-led growth. Definitely not forever.

(Joel Beasley at 00:33:24) Yeah. Absolutely. So I'm curious for you personally as a longtime developer. How did you decide as a cofounder to be CEO of your company rather than CTO or lead engineer?

(Orr Weis at 00:33:41) Yeah. So that's a very good question. So, initially, there was another startup that I worked on that I cofounded, and there was the CTO there, a company called Reactivful, which actually I think by the time this podcast would be released, the acquisition would be announced, which is kind of nice. But there, I'm a tech person. I'm very well connected to the technology.

(Orr Weis at 00:34:04) I'm passionate about it. And that's probably where I should stay, right? But working on that company and also looking at other ventures, I realized that technology and, if you want to make a change in the world, if you want to actually create a product that succeeds, technology is a really small part of it. And in actuality, the marketing of it, the strategy of it, the how you connect this to the people, is in more cases than not, the more critical element.

(Orr Weis at 00:34:38) And in the end of the day, when I think about myself as an engineer, as a developer, it's all about creating. I really view it as an art form. I'm not like, I'm good with maths, but for me, technology and software is really about creating things that empower or connect to kindred spirits. That's my thing. And so I realized that if I want to really drive that impact, I can't just focus exclusively on the technology.

(Orr Weis at 00:35:07) And so I started to learn more about go-to-market at the start. I started to learn more about how you do sales and how you do marketing and how you do partnerships and how you connect to other people. And I started to get passionate about that too because that's also creating, and that's also working with kindred spirits. And I guess I just got swept away in some way.

(Joel Beasley at 00:35:28) That's really cool. Well, on the topic of people, I want to hear a little bit about hiring because that's something I'm always interested in. It's kind of been top of mind for me recently because we had this company called Lemon on the show, which they're a really cool company that provides pre-vetted, experienced remote devs to come to other companies around the world, which is a very interesting value prop because those kinds of people are hard to find. But I'm curious, how do you go about attracting and retaining top talent at Permit?

(Orr Weis at 00:36:05) That's a terrific question. So first of all, we should probably say that it's very different doing hiring for an early-stage young startup and doing it for later stages. Having done both, I can say it's like worlds apart, both in what you're offering people and both the people that you actually need. And I'll focus on what do you actually need.

(Orr Weis at 00:36:28) And I think early on in a startup, because of all the chaos and all of the high velocity and all the intense quick requirements that come from the market, and you don't have—because it's not a big organization, so you don't have a lot of things shielding you—like every little thing, everyone on the boat feels the tremors.

(Joel Beasley at 00:36:46) Yeah.

(Orr Weis at 00:36:47) So what you need, you need, I think at least, you think you need very capable, independent people. You need people that can embrace that chaos, find what they need within it, and charge forward. In general, the mentality that I really like, and it also kind of goes back to my military background in that unit in 8200, it's really about being back-to-back in the trenches, knowing that you can trust the other person next to you, and knowing that everyone's charging at their own goals, at their own targets independently, but they have your back. So that combination between independence and teamwork is, I'd say, the core most critical thing, even more than specific skill set. Obviously, you need a specific skill set for the different things that you need to build.

(Orr Weis at 00:37:40) But if you don't have that commando mentality, I think it makes everything a lot harder. And if you have it and it's a common theme throughout your team, you can really charge forward and lift or tackle far greater than your actual weight.

(Joel Beasley at 00:37:57) I love that, the commando mentality. So when you're—so obviously, the interview process for hiring people, you don't get to know them on a super deep level in the small amount of time you get to spend with them before making the decision. How do you identify people that have the commando mentality in that small amount of time you get before you have to decide whether or not to hire them?

(Orr Weis at 00:38:25) Yeah. So first of all, you don't necessarily need to—they don't need to have it in advance. They need to have the affinity or capability to adopt it. And what I usually do in interviews—so first of all, I just spend some time talking to the person as a person, just kind of like a date, awkwardly, but kind of like a date. Just tell me a little bit about yourself. I want to know what you're passionate about. I want to know what's important to you in life. I want to know what's important for you in this job. I want to know what do you expect to get out of it? Where do you want to be in a few years from now?

(Orr Weis at 00:38:57) What's the trajectory of your evolution, of your improvement? In general, I believe that companies grow if the people in it grow. So if you're—it's really important for me to everyone with Permit and or any other company I work at, that each individual gets out more skillful, better as a person than how they got into the company. Because that makes sure that the entire company as a whole would improve. And aside from that, what I like to do with technical positions is I ask people to tell me about a project that they have built and they're really proud of.

(Orr Weis at 00:39:32) So that does two things. One, it removes a lot of noise. Because if you ask people just, you know, tell—let's do FizzBuzz or let's solve this ridiculous computer science questions or, I don't know, do a binary tree, all those silly things. You don't—you're kind of gambling on what that person should know or not know. And while people have some mutual backgrounds, like basic computer science education, they're not all the same person.

(Orr Weis at 00:40:01) And if they don't know, like, I don't know, like, to in the most optimized sense, how to search a binary tree, that doesn't mean they're not a good engineer. That's like a very specific thing that they can look up. Yeah. So I find those really, really silly. So I prefer to ask something that the person feels and thinks that they're good at.

(Orr Weis at 00:40:20) So that minimizes a lot of their noise around the things. So we have to at least an agreement. This is something that you should be good at if we were—if you chose to talk about it. And then I just spend some time hearing about the project. So that's an opportunity to see how the person thinks about building things, how they talk about things that they are passionate about, how they explain technology that might be complex, but they have good understanding of.

(Orr Weis at 00:40:47) And then what I like to do is take it another notch up. So it's always easy. No matter what you've built, there's always another feature that can be added. There's always another classic problem with asynchronous or or multithreading or greater scale or another type of database or another type of interface that can be added. And then you can see in real time that person think about a problem that they have a good standing at, but they're tackling something new, and they can have the conversation with you.

(Orr Weis at 00:41:19) And I think that most times, really quickly, separates the chaff from the—I forgot the expression.

(Joel Beasley at 00:41:27) Chaff from the wheat.

(Orr Weis at 00:41:28) Thank you. It really quickly gets you to have in-depth conversation about real things and not just make-believe scenarios. And sometimes I also like to kind of try and take it to the actual problem I'm trying to solve now. And oftentimes, it's not that hard because a lot of complex systems share the same complex problems.

(Joel Beasley at 00:41:48) Well, fantastic answer and advice. I'm definitely going to use it as I'm continue hiring at my company. But I got one more question for you before we wrap up. If you could go back and give yourself one piece of advice the first time you moved from individual contributor to manager, what would you want to know?

(Orr Weis at 00:42:09) I think the best advice I could give myself in that sense would be, one, understand the greater picture. So when you—you got your head kind of deep in the trenches, deep into the material, it's hard to telescope and zoom out and see all the other elements that are part of the challenge. And it's sometimes—it can be surprising to realize that there's a lot more complexity on the macro level than there is on the micro level. For example, with the go-to-market or with how people want to try out the product or with the user experience or with how you actually get to build a business on it or commercialize on it. Those things can be as complex as build—as solving critical driver synchronous solutions in, like, the kernel of, like, the operating system.

(Orr Weis at 00:43:03) And sometimes, unless you actually spend the time to give that attention and realize that that's a complex system too, you can miss out on that. And then as a manager, you miss out on translating and communicating that to the rest of the people. And I think that's the most important—one of the most important things a manager does is creating alignment between the higher level, potentially the entire company, and the individual. Understanding where this individual wants to be, where the company wants to be, and how those areas intersect. And you can only do that if you fully understand both, if you fully understand the person in front of you and you fully understand where the company needs to go.

(Joel Beasley at 00:43:42) Well, Orr, I think that's a great spot to end off on. Before we wrap up for real, is there any extra shout-out you want to make, any call to action you want our listeners to hear?

(Orr Weis at 00:43:55) So I have two. So we talked about product-led growth. One of the other things that I do is I run a group for founders called Upwards. It's—I used to say that it's, like, the biggest product-led growth founders group in Israel. Now it's, like, probably the biggest in the world.

(Orr Weis at 00:44:11) Several hundred founders all working actively in product-led growth. And you can reach out to me and you can join that group. We do monthly fireside chat sessions with market leaders like the CEO of GitHub, founder of Bitnami, people from LaunchDarkly, a lot of awesome people anyway. So I invite everyone to join the group. Everyone's a founder who's actively working on product-led growth is more than welcome.

(Orr Weis at 00:44:35) The other one is, like, just if you want to talk to me, like, if you were working on a venture or if you're building a piece of technology that needs help with DevSecOps or with permissions specifically, obviously, it's really easy to reach out to me. Look at @orweis, O-R-W-E-I-S, on GitHub, on LinkedIn, on Twitter, on Reddit, wherever you want, and just shoot me a message. And I think most people are surprised on how happy I am to engage with people that just want to talk about something, as opposed to trying to sell me something, connecting to what we chatted on before. So, yeah, I really want to encourage people to try this out. And, obviously, if you're working on building permissions and you want to actually focus on building your product, I'd love it if you check Opal and if you check Permit at permit.io.

(Joel Beasley at 00:45:25) Thank you so much for listening. And if you found this episode useful, please share it with a friend or colleague who you think would get value from it. And if you have topics that you'd like to hear discussed on the podcast, either add me on LinkedIn or send me an email, [email protected]. Every time I get an email or LinkedIn message, it absolutely makes my day and inspires me to keep going.