This is identity at the center. If it has anything to do with IAM, this is the go to podcast now your hosts Jim McDonald and Jeff Stedman. Welcome to the Identity at the Center podcast. I'm Jeff and that's Jim. Hey, Jim. Hey, Jeff, how are you? Not so bad yourself. Doing great. Really excited about the episode today. Salto dot IO or Salto as the company is called. I first got introduced to them at the Octane 2023 conference.
They had a booth near where I was sitting and I thought, you know, I've got all these identity at the center stickers. Obviously I can trade them. They're like currency. Go around. You can trade them for whatever booth giveaways they had. And they had these killer socks. And so I still wear these socks, right? But I I just had to find out what do they do. And they solved a problem that became apparent to me, you know, many years ago in one of my first Okta projects.
And as I was going through this project, my question was, OK, well, how do we take the configurations from a lower environment and move them into production? And the answer was, well, basically just redo them in production. And it was a blank stare and a moment of silence because it was like, seriously, that's the answer. And so I just for years and
years that was the answer. And these folks at the booth explained to me like that's the problem we solved and they showed it to me. I'm like, Oh my goodness, so much better than the socks. And these were good socks. But that was like it was like an eye opening experience. So really kept these guys in mind, and I talked to many clients about that over the years, and today we're gonna have an episode about it. Yeah, why don't we go ahead and
talk about that episode? So today definitely is a fully sponsored episode sponsor Spotlight as we call it. We have collaborated with our friends over at Salto to create this special discussion that we'll talk about get to learn more about Salto. I'm not super familiar with it, Jimmy. You're more familiar than I am with it. But I think this is also maybe the first time you've heard the term stare and compare. Is that right? You've not heard that?
Before exactly. That's the origin of that. And I've I've stolen that. Actually, people didn't know that that wasn't mine, so now they know. Well, to be fair, I've heard that one for years, at least 10 years ago, so I was a little bit shocked. But hey, we always learned that they knew, right? So today's sponsored episode is by Salto. They specialize in DevOps for business apps. You can find them on the web at salto dot IO.
We have a special web page salto dot IO slash idac and that's where you can find out more information. I'm excited to welcome Gil Hoffer. He's the Co founder and CTO at Salto. Welcome to the show, Gil. Thank you, Jeff, and thank you, Jim. Thank you for having me. Yeah. Thanks for taking the time. And obviously Jim is has got a little more I think insight into what you guys work on. But I always like to start with the person, tell me a little bit about your identity origin
story. How did you get into the world of identity? Is it something that you chose or did it choose you? Great question. So well obviously Identity is part of everyone, right, but in the in the context of computers and and software. So I think the first time that I started dealing with Identity was in my previous company when we had to start building some
SSO solutions etcetera. So that's the first time that I started learning about it. And then in salto our customers all the time talks with us. Well, we understand what you're doing, but can we do it with Octa? Can we do it with Azure ID or Entra etcetera. So they they pulled us back in. I thought I was out of the Identity game, but they pulled us back in. That's how the identity space works, right? Just when you think you've escaped orbit.
Nope. There's some gravitational pull that that brings you back in. Jim mentioned what he sees Salto is doing. But I want to give you the opportunity, right? You're the expert. Tell us more about Salto. What do you do? Of course so at Salto we're a DevOps platform for managing the configurations of business and IT applications. So as you all know, typically a modern company is using a few 10s if not hundreds of those applications SAS applications.
Typically to run their business, you would need to configure or customize them in order to in order for them to fit your business processes. Typically this is being done very manually using UI, no low code kind of ways.
And at SALTO, we enable our customers to bring all of those best practices and processes that are typically being used for development and DevOps and rely on the fact that we're not using AUI to do all of those, whether we have code and we enable our customers to to use these kind of IDs when managing
those configurations. So instead of just clicking and steering and comparing and having endless spreadsheets with everything that we've done, we can use git, we can automate changes, we can implement once in a sandbox and then deploy those changes to production etcetera. Everything becomes much more process oriented, automated, repeatable, just like the way that we typically work with DevOps and and code, but applied to the different business and IT
applications that we support. So what was the genesis for this idea of Salto? How did this thing get started? What was the the idea that I was like, oh, we need to do something about this? Yeah. So, well, for that, I need to go back to our previous company, so before Salto with a company called Ravello, Ravello Systems and a very different domain. And we were actually an infrastructure virtualization company.
We're a virtual cloud provider. We develop our own hypervisor and virtual networking, virtual storage etcetera. And for the SAS company, I started around 2011 and as any other company those days we're using all kind of different SAS applications run our business, right. So Salesforce and NetSuite and Zendesk and Girai and Mercado etcetera. And frankly speaking, the way we're managing those business applications, it was probably the least professional thing that we did in that company.
It was like that host potato that we kept on bouncing between departments and all kind of consultants helping us. And really no one knew what's going on with those applications. And luckily the business with Ravel picked up very nicely and the company grew quite a lot. And then at one point in time, I remember I was running engineering back then we had a project to redo our pricing scheme and I was sizing the project. I said well, yeah, it will take us about two months to implement
this. And then I remember it as if it was yesterday. I remember our VP of Product Management coming into my room and asking me, well Gil, I understand that you say that it will take two months in the product, but what about the implication on on Salesforce and and the NetSuite? And I was looking at him and I told him, well, I don't know anything about those systems.
Let's let's look and obviously there were all kinds of implications and we started pulling the responsibility over those systems in house into engineering, started shifting resources etcetera. Things got slightly better. Then it was early 2016, we got acquired by Oracle. Now one might imagine that Oracle great respectful company knows how to manage these kind of systems, right.
So after we got acquired, everything became so much more complicated in the way that we manage all of those systems including identity by the way, where the interesting project about integrating the different identity systems. And we realized that things that typically when we manage in in code, in a system the way that we're used to would take us a few days, takes us many, many months to actually achieve and
implement. That's when we started looking very deeply into the way that companies manage their business and IT applications. And we realized that the way that those systems are typically being managed, it feels very similar to the way that IT infrastructure was managed about 20 years ago. About 20 years. I was managing a large team that dealt a lot with data centers.
And a typical guy on my team would start his day with a box in his hand, go down to the data center, put that server into a rack, pull out one of those nifty foldable keyboards, and start typing commands all day long. Right. Installing stuff, obviously not scalable, very error prone. And back then, well, the IT organizations dealt with it like they know with red tape and bureaucracy and you got an SLA of two months for a new server, etcetera. Who remembers those days.
And the way that the industry dealt with that was by importing best practices from the way that we used to manage software and applied into the way that we manage infrastructure. So all of a sudden it wasn't an IT person going into the data centre. It was automation with, if you remember Chef and Puppet and these kind of projects back then and today, it's all about infrastructure is code. So you Terraform for example, so you can manage everything in a
source control repository. But at the core of it is that we enabled the industry, as an industry to manage infrastructure the same way that we manage code. Everything became very repeatable, well defined etcetera. By the way that we manage the configuration of our business and IT applications.
It still looks like 20 years ago, everything so manual done directly in production or if you would like to do it in a in a in a staging environment or development environment before you would typically document it meticulously and then repeat those changes again as Jim mentioned before. So that was a realization that, well, we understand the problem. It was already solved in a different domain, All right. That feels like a good idea, good business to start.
And let's bring all those goodies to the way that organizations manage their business and IT applications. So that was around five years ago when we started a company. And today it's really exciting because we have so many customers using us to manage those critical systems. And I just took it a few days ago. So five different continents across all kind of different applications, a different domain.
So that's a lot of fun that. Sounds pretty exciting and I wanna we wanna ask definitely some questions about how this works right and use cases and things like that. But I think I am always interested to hear about company names. How did you come up with the name Salto? Why call it that? Yeah well it's not the it's not the best story but so as I mentioned before Salto with a company called Rovello Rovello Systems and in Salto of two two Co founders and before Revelo
they had two other companies. One of the the one before Revelo was called Kumarnet with AQ and the one before Kumarnet would was called Pentagon with AP. So you might imagine it was PQR. We needed something that starts with an S and then we needed it to be short and the domain to be available. And just as we're about to start, Salto Rami, my partner and CEO, he was earning Italian, he he was earning Italian. He went to Rome for a few months in order to brush his Italian,
and he suggested a saltare. A saltare in in Italian means to jump to leap. And I told him, well Rami, it's it's too long, no one will be able to actually pronounce it correctly. And Salto, both in Italian and in Spanish it means to leap. It's basically the the noun of Philippe like somersault and and we thought that it is also a nice metaphor because we're basically enabling the industry to leap forward and take all of those IDs that I mentioned
before and apply them here. So connect all those. The fact that it starts with an S that it is metaphorically relevant to what we're doing and the domain was available that's the company name and there are by the way there are endless pans that we're using on Salto. We'll get to it as we talked about the the technology. Yeah, having the domain available is is very key, you know, right.
I thought of and realized that as I was doing that introduction earlier and talking about my early experience with Okta may have come off as like, Oh no, he's kind of criticizing the Okta's approaches. But the reality of it is, is they've opened the API to make it available for Salto to even exist. If it wasn't for the API, there's no way you could have the Salto product be able to do what it does. Is that correct? Yeah, it's 100% correct. And without API wouldn't be able
to do that. And the problems that we're dealing with in SALTO, they're not specific to Octa. So it's actually quite common. For example, support Zendesk and Dura and Salesforce and NetSuite and and multiple different applications. It is quite common that there is no way to actually deploy changes from a lower environment
to a higher environment. And come to think of it, there is a lot of investment that those vendors need to make in order to to make it available to very easily have sandboxes that are synced from production to be to make it easy to deploy those changes and to understand what are the difference between different environments etcetera. It's not surprising that those features are missing in many cases, because for every vendor to build them it's it's costly. No, it's good.
So it's kind of a tip of the cap to them. One of the things that one of the things that I want to make sure that we don't do is, you know leave anyone in the dust in terms of explaining what Salto does. So I was wondering if you could, thinking of it from the perspective of an Oct administrator, what would they use Salto for and how would they go about doing that? Yeah, of course. Great question, Jim. So typically an Octa administrator let's try and
portray a day in his life. OK, so let's say there's a requirement to go and implement a certain change to the to the configuration of Octa, let's say to some authentication policy. So the first step for the for the admin to do is first of all to analyze what would be the impact of that change. So what are all the other configuration elements or parts of the implementation that will be impacted by that change.
Then that admin would go and implement the change in a development environment that should be very similar to the production environment. And after testing, you should eventually also be able to deploy those changes to production while also being able to roll back if needed. So that's what the admin needs to do. Now let's describe how it does that with Salto.
So with Salto, the admin will have all of his environments, all of his different tenants connected to Salto, and Salto automatically reads the configuration of all of those tenants on the background. We use those APIs. We read all of the data all the time and we use a format which we call NaCl Knuckle which stands for not in our configuration language and just happens to be the chemical sign
formula of salt. So we read all of that configuration into Salto and the first thing that we enabled that admin is visibility. So you can very easily understand what is that you have implemented. You can very easily understand all of different dependencies. So for example, looking at that specific policy, what is it dependent on and what depends on it? So we'll be able to know what we might break when we make that
change. Then that admin would go into the lower environment that should be synced from production. We can help with that as well. Implement the relevant change in Octa using the UI doesn't need to change the way that he works in his day-to-day. And then Salter would automatically detect what was changed in that environment, show it to the user, enable it, enable him or her to also push those changes into Git.
So we'll have proper paper trail for everything that was changed and deploy those changes to the higher environment. So in alternative universe, what you should have done is develop those changes in that in that lower environment in Octa test, right, Typically and we see it with customers having like very long spreadsheets which document everything that they changed and then they would need to go and reimplement those changes in
production. And this is extremely risky because there might be all kind of differences between a different environment that he is not aware of. And then the fact that it tested something on the lower environment is almost meaningless because it typically would have tested it on a different environment. He's unaware of the differences between those different changes. And then when deploying to production only production is the environment which is representative in this case.
So that would be the alternative. Obviously for a smaller Octa setup it might be OK because the configuration might be in a scope that one can understand on his own sound for customers. We're talking about teams of 10/15/20 Octa, administrators in a single organization, in a single tenant, managing 100,150 thousand users. That configuration is insane in most cases.
And going and implementing a change directly in production, for example, or a massive change in a in a preview tenant and then reimplementing it in production, that's a very risky move. By the way, you didn't lose me on that NaCl sodium chloride, which I mean, when you figured that out or that came up, you must have just like that must have been quite the moment. Yeah, I remember.
Yeah, I don't want to blame for the for that name because we're sitting in a room and we're saying, well, we need to have a name for our language. What are we going to call it? And then I was just playing with with all kind of letters so well and it's still that's that's clever. Very clever, very clever. So I think he got into why it's problematic or risky to do things manually. Is that what most organizations are doing that don't use salto?
Are they doing it manually or are they kind of rolling their own solution? So typically we're seeing one of three alternatives. The organizations are really unaware of the risk and they just go and make changes directly in production and they don't care.
In many cases, the bulk of the organizations that we're seeing, they're very much aware of the risk and then they would typically deal with it in a process kind of solution, meaning that they will have lots of documentation would go and implement those changes typically three times. Typically it will be in a development environment, then in testing environment or UAT, then in production environment. And the way that those changes would work would be manual with.
Very careful documentation in spreadsheets, in tickets, etcetera for these for these organizations, we both reduce risk but also reduce a lot of manual work. Meaning we have, we've seen, we see with sound for customers processes that used to take them many days if not weeks are reduced to minutes because there's no need to create a
documentation. That documentation is basically the state of the system that we look at and you don't need to reimplement those changes because just click a button and deploy etcetera. The third type of organizations are the ones who these are the most advanced. These are companies that typically adopt for example Terraform as a way to manage their Octa tenants and that it deals with the bulk of the issues that I mentioned.
But it creates other challenges because for those of you are familiar with Terraform, Terraform is a very popular open source project and infrastructure for managing typically infrastructure like AWS tenants etcetera. The main challenge there is that they would need to go and create HCL files or Terraform files that describe the configuration
that they would like to deploy. So typically Octa admins are experts in Octa, meaning they really know the way around Octa and the Octa UI and creating policies and they're experts in identity and access management, etcetera. Creating those directly in Terra forms HCL can be very challenging and time consuming. So yeah, yeah, just staring.
And compare, I mean I I think that's the most common, right, especially for Octa organizations that are organizations that are smaller kind of have a limited budget, limited scope of Okta. That's what they're doing to me. It's extremely dangerous because you can miss type A
configuration. Other words you brought it over but you left out a letter or you know how many times do we misspell things in our day-to-day lives where you know fortunately we have spell check there to to save us, right. We we think there's only 1L in in in a word and there's really two that that kind of thing and it can take you hours to find out. So not only do you have to stare and compare it correctly, but if you do your push and it's not working now you've got to unroll it.
Well, what makes you think you are going to unroll it correctly if you didn't roll it correctly. So I think it's extremely dangerous, extremely risky, especially for major deployments
that are customer facing. It's just and seems like you know from my experience in in managing web applications like it's just you don't even have to be at that high of the level of maturity to be driving automation like you wouldn't, you know when you roll a jar file to a Java server, right, you just drop the jar file in and if you have to unroll it, you take it out and put the other one in or the old one in,
right? You don't, you know, go through line by line of code and try and figure out the problem or try to roll things that way. And to me it's kind of like that that's this alternative way, the manual way, or writing your own. The problem with that is like usually when you write code, it's fit for purpose, but your purpose may change over time.
So, you know, you might have a creep away from the standard baseline and it's not picking up certain configurations that Okta added and you've been using in your sandbox environment, for example. So those are some of the risks that really jump out to me. But I also think just for organizations that aren't already doing kind of a DevOps approach and a CICD approach, that's the future, right? And this is just another part of doing that. Yeah, I I. Agree.
That's the future. And that's the future by the way, not just for Okta, but for all of the different IT and business applications that run your your companies. And I'll give you an example for something that our customers typically love is the ability to create a share responsibility within a team. Because share responsibility is a concept which is very much known when you develop code,
right. You would like the entire team to be able to collaborate on the same on the stuff that we're building and the common language that they have for that is code.
So for example one of the things that SALTO enables just by the fact that we translate everything into a textual representation into that NaCl file files is that you can review other team members changes and you can approve them and you can exact understand exactly what changes Jeff did two weeks ago and what changes Jim did a week ago and you can go and in Git we call the blame or praise.
We can either blame or praise Jeff for the changes that that he did back then and creating that kind of visibility. It's mind blowing that it's not it's it's nonexistent in those type of applications. The fact that I can't that you can't open, typically it's called a pull request, right? A change request to the config and someone else can approve it and only then it can be deployed.
Sounds like basic table stakes in critical systems under high compliance requirements and there's these things do not exist now. Moreover, as I mentioned, because your companies are using so many different solutions, it makes no sense to build a different solution for managing each and every one of those systems. Typically you would see an IM team, it's managing multiple different systems, right. It's not, it's not just Octa.
In many cases you will also deal with Cell Point or with Entra or with Splunk or with many Jams or with many other relevant systems or with a or HR system or to push users etcetera.
And having streamlined consistent processes for understanding that configuration, collaborating on it, deploying on it is it's not even the future, it's the present and CICD and DevOps in order to enable that, well these are the principles that enable the software development world in the last 20 years to support that kind of innovation that we're seeing in the world today, right. So these are like battle tested, proven ways of doing things.
So I think that we're going to see that every company is going to start using these IDs when managing their business and IT applications and that's why Salto is there, right. So what is it that sets? Salto, apart from others, I guess, in this space, right? I think one of the things that a lot of IT people probably suffer from, and myself included, as we get jaded, right? There's a lot of options out there, I guess. Tell us why Salto is unique in this field. Yeah, of course.
So the unique part in Salto is that first of all we're we're a platform, meaning that we cater for many different applications. It's not just Octa, it's not just Salesforce, it's not just Zendesk, not just JIRA, it's all of them and many others. We're adding support for a very large number of applications this year and that we put the user experience off the admin in the center, meaning that in some cases you would find solutions that are relatively very technical.
They might be a good fit for a developer or for a very sophisticated IT person, but eventually an admin that for example with Octa lives and breathes. I am an Octa, not necessarily code. I think that we're basically the only solution that enables that both a very admin friendly way of things while not compromising at all all the important traits of source control and automation and CICD et cetera. We make it accessible to them as well as cross across many different applications.
We're not aware of anyone else's who's doing it today. Well, that definitely. Puts the unique into it, don't also doing it. How about can you share any customer stories over examples because they think that's another way that people can kind of start to understand how they might leverage this and maybe some other ideas that others can get from this. Any customer use cases or things and feel free to share names or not, that's fine. But maybe you can walk us through that.
Yeah, of course. I can share a few a few different use cases and I I think that I I can share also a few names. The first one is a very large retailer with 10s of production tenants in the 30s and they used to manage everything manually with spreadsheets. So think about it, you have a production tenant, you have your sandbox or preview that is tied to it in a 1:00 to 1:00. They also had like a gold tenant where the that should have been
the gold standard. Now obviously over time all of those 60 something different tenants that I just mentioned, they drifted away, drifted apart. So the actual relation between the configuration in any of those environments became almost random. So for them both rolling changes from that, let's say they would like to roll a change from that golden image to all different instances as well as adding a new tenant.
It was all huge projects and that's when they started working with us and they reduced a configuration change that would typically take them about a week to less than an hour by automating everything with Salto and creating that kind of visibility. Another interesting that's a a public at a company, a Udemy I we we can share their name.
So Udemy, they strip when they got to us, the CIO, which is very forward thinking and was thinking about their OPS all the time and he came to us with a problem of how can he eliminate the silos that he has across his org because Salesforce was being managed in a certain way and that's what was being managed in a different way. And then this was being managed
in a different way. And it each one of those suffer from the same challenges and same problems but found different solutions or no solutions at all. So over there it was how can they get to a way that all of the different business and IT applications are basically being managed in the same way and that's how they're using US and they're very happy customer in that sense.
And the large example, which might might sound a little bit silly, but a European retailer, a very big European retailer. They made a. Mistake and deleted very large parts of their production configuration by mistake like fat finger kind of mistake and it happened once. Then they realized well they have to take care of proper processes for managing their configurations both.
So first of all they will develop on a development instance and development tenant and not directly in production, so reduce that risk of a fat finger. But also when things go South. So they could very easily roll back very selectively those changes. So that's when they onboarded the salto. Oddly enough, they made the same mistake again after they onboarded Salto, but then that fall back was immediate and they
undo. Now we need to remember that it's a retailer with north of 100,000 employees, so the implication of a bad change can be huge from a financial perspective. Think about all of those salaries that you pay to your employees who cannot log in into your network or if you're serving customers and this is somehow customer facing, that's a huge risk and that's a huge impact. And for them it's it's a no brainer. I saw three different examples I think of what customers are using us for.
I think those are really. Helpful. And you know, I'm browsing the website and kind of following along here as you're kind of explaining this. But I guess from a use case perspective, I think mostly we've been talking about configuration backup. Is that the right way to phrase it or is it CICD DevOps is a little bit of both. Are there other use cases maybe that we haven't talked about that you guys can help with?
No, so, so. Typically the main use case that most of our customers come to us is around configuration management and deployment of changes. We view backup as like a private case of it, because eventually when you when you backup, when you restore, you deploy from a previous version, you can be as selective as you'd like about it. And because we automatically fetch the configuration every hour or every day, you get back up as as part of the solution. Two other interesting use cases.
One of them is around compliance and showing traceability for every change that you make. Because when you think about it, once you move everything to a stream and process which is backed by git and source control etcetera, you can very easily now connect those changes to let's say a ticketing ServiceNow or in Jira and show the approval and show everything that you need to show to your auditor in case those systems are under
scope. And another one is around monitoring of configuration changes. Because there are many companies who came to us tell us, well these are some very sensitive areas of our configuration. We need to get alerted whenever anyone changes them. Think for example about, I know security settings in the NetSuite, you wouldn't like anyone to play with your financial systems security settings. So we can also automatically alert on those these types of
changes. All of these use cases, eventually they boil down to the fact that we have visibility to the entire configuration of those systems and we actually understand that configuration in a way that enables us to understand what changes over time to deploy changes to understand dependencies. So what will break if we change something and to roll back to restore etcetera. It all boils down to death to the fact that we we can understand all of that config it seems to.
Me, like salto wouldn't be that hard to start using. In other words, you should if you're doing manual stair and compare something like that, you should be able to start using salto and once you build up the confidence level, start using it right away. Am I missing something obvious? What does the typical implementation look like? No, no, you're. Not missing anything Jim, we're
actually, we have a free trial. You can just go to our website and connect Salto to your systems and start using it. And we saw cases where during that first month of a free trial where the prospects already running 10s if not hundreds of deployments during that month using SALTO. Obviously if you'd like to go to like automation and CICD etcetera, then you need to build some of this also in your own
systems, in your own processes. But just to get started, you just connect it using very standard way to your systems and you start it's that easy. What about the pricing? Is expensive. We don't. Think so. But the way that salt is priced is according to the complexity of your configuration, meaning that we connect to different systems, for example, to Octa,
to JIRA. And with Octa, we look at the number of applications, number of groups, number of policies that we manage and there's a price table accordingly. And the reason that we do that is because we believe this is very tightly tied to the value that we provide to our customers because if that configuration is very complicated, very complex, you get a lot of value by using salto if it is very simple, less volume. So you said they?
Can go to the the salto dot IO slash IDAC and you know, get a copy, play with it. Then if they say OK, there's something I want, can they figure out their own price or how do they contact somebody on the on the sales side of Salto and they contact them back and figure that out, how does that work they? Can do either. They can either reach out or we will reach out.
In many cases also and because especially with larger companies might need to walk out some some legal or whatever, we need to walk out with them. But we also have a self-serve and you can just wipe your credit card and then go from there if that's something that you're interested at. OK, that sounds. Pretty easy. So one question that we want to ask is if you're the customer and you are using salto, how do you measure your success?
Great question. So I think it is very similar to like Dora metrics, if you're familiar with the way that dev OPS and metrics typically work. But most of our customers, they would like to have more deployment to production and the scope of those deployments should be smaller. So that's like typically the way that you would like to to measure it. We also measure the success rate of those deployments, meaning if they were successful or if you
needed to roll back. So the theory in dev OPS typically is that you would like to have very rapid deployments, meaning as many deployments as possible per day and to reduce to with a minimal error rate. So that's typically what our customers would see and we have customers that we're talking about hundreds of deployments to a single system in a month because the rate of changes is that high.
And that really that's what enables them to to become agile, which is that's really what everyone is looking to do, right, in order for to provide value to the business faster that eventually all goes to their right. All of us work in a business when the business to be successful. For that we need to deliver value as fast as we can and DevOps and tools like Salto is what enables you us to do that. I have one more question for
you. And I want to know what is next for Salto. We've talked about Okta a lot. I'm hoping there are more identity platforms in the near future, but what's next for Salto? Yeah. So in Salto we're adding many different applications all of the time and there are a few on the identity domain that we're planning to add later this year, nothing which is like final in terms of date etcetera.
But I think that you might you might see support from Salto for example the Microsoft ecosystem in the Google ecosystem as well as maybe products like sale point etcetera. So because we've seen such an. Overwhelming demand from the Octa community that we believe that those problems that we're solving are extremely important in the identity ecosystem and that's why we're trying to prioritize identity solutions as some of the applications that we're adding later this year I
want to make. One statement. So if there are people who are listening, who are product managers or in an influential role, and they build identity systems, make the APIs available for configuration management, please. Period. No exclamation. Point I'd like to 2nd that, yeah, that's well said, Jim. That's what it comes down to. Right. Yeah. I I. I. Agree. I agree. Those days of closed systems are should be over.
So we were. Talking before we hit record here and just kind of get into each other a little bit and this has been a fascinating conversation. So I hope people will go out and visit salto dot IO slash idac but I want to ask a non a non identity question. Jim, do you have anything else you want to get to before I do that or are you good to go? No. No, we can't. We can take it out. This is a fantastic conversation. I really enjoyed it. Thank you.
Yeah. We were talking about basketball and you mentioned that you like to play and coach and I have a couple of questions, 'cause I used to play no longer anymore. I'm, I'm old and short and round like a basketball at this point, but I used to play when I was younger. So two questions for you. First is a player's question, What's your go to scoring move, gotta score, games on the line, how you get in that bucket? So. As a player, I was playing until the end of high school.
I was always very aggressive and that's also what I typically teach my kids. So I would grind my way into the basket and like typically power moves because especially at younger ages and if you're also non professional players tend to be a little bit soft. So use your shoulder and you'll get that bucket shoulders and. Butt, right? Yeah. Jim, what's your go to scoring move? I don't have one. Don't. I do not. I don't know. I'm terrible at basketball.
I I go up and I do layups and they, well, they used to be automatic for me. Used to be able to hit 9 out of 10 layups for sure. Now it'd be like if it got one out of 10, you're too. Small. You can't. You can't lift the basketball up correctly. All that weightlifting, maybe? It's just I think I'm going to be able to jump and get to a certain height and I can only jump like 6 inches and that's the problem, OK. I've got some good. Basketball stories though. All right.
I got a good basketball story. So this is my grandfather who is was shorter than me by an inch. So he is 6/1. I'm 62. He's 6/1. He went to South Catholic High School in Philadelphia. It's now called Bishop Newman and he was the center. Get this 61. So this was you know in like the early 1940s because as a 18 year old, he's over in Germany in 1943, so early 40s. And the man was the Center for
his high school team at six one. And he is in that high school's sports Hall of Fame. He was a Letterman in baseball, basketball and swimming, and he was just a superstar basketball player. I think he was in the All Star team for the city in 1942 or whatever. It's pretty cool. So you. Guys are tall. I'm not. I'm 5-6 now and you know, when I was younger I was probably a good solid 5, two or five, three. But I I I mean, I used to play basketball all day long.
I mean, it was not uncommon for me to be playing games of 21 down on the playground or my backyard. We actually had two hoops on my backyard. So I was like legit playing all the time. And so my scoring, I had two moves. I mean, I could drive the lane and do those acrobatic, you know, lay UPS, reverse lay UPS, all that good stuff. Or the fadeaway jumper, 'cause I grew up in the era of Michael Jordan and you know, we're talking mid 90s, early, early to
mid to late 90s. And that was just the move, right? Unstoppable, unblockable. Didn't matter how tall you were. I was shooting over you and that that was my go to move was the was was really the the the the fadeaway turn around jumper. That was my jam right there. All right. Second question for you and revolves around coaching. You coach Youths today, what's a brilliant coaching move that you've made recently, maybe in a game or a match or tournament or something like that, that you're
like, Oh yeah, that. I'm glad I did that. Yeah. So and unfair advantage in many cases with young kids is turning on and off full cold press and because kids can get confused when you press them or also when you don't press them. So in one of the games last season, we basically turn it on and off all the time because if you press all the time they get it and then etcetera. And then the other team got so confused and we just kept on stealing and lots of easy lay UPS.
So that's one thing that works well in young ages and another thing is that we woke up on this a lot in practices we try not to dribble at all. So just moving the ball all the time even if it doesn't feel like there is a great purpose because there there's no shot clock right when with kids. So the difference because it needs to move all the time then it creates opportunities. So just teach the kids to move
the ball all the time. So just dribbling, that's what we're walking on. That's a that's a great. Drill and I totally agree with the full court press because I gotta tell you, as AI played in I guess would have been middle school which would have been grades like 6-7, eight I think if I remember. And full court press is a lot of fun if you are the one doing the full court press. It is not fun at that age when you are being full court press
and you're totally right. Like there's confusion and it's, it seems like such a, you know an easy way to play defense. Here's a brilliant move that my coach, coach Byrd, I think was his name. I was probably in fourth or fifth grade and if you think I'm short now, why was I short then? And we're playing and I won the Mr. Hustle award for our team. I just basically was like a gnat on these giants around me and annoying and you know just in between their legs and just a a
real nuisance. We were not very good, I'll tell you that right now we sucked. I don't think we won a game all year. We were playing another team and they put me in at center. So here I am giving up probably a an easy 2 feet to the mother Center. But we were so well trained on the basics and This is why I mentioned the butt before boxing out, boxing out, boxing out, boxing out. And so I could do that really
well. And I kept getting over the back fouls, called on whoever was whoever is boxing out their center fouls out, their backup center falls out, power forward falls out. We end up in the third quarter they had fouled out so many people that they only had three players on the court for the last three minutes of the game. And yes, we still lost. So that's how bad we were.
But I always, I always think back as like and I didn't really kind of get at the times too young to kind of figure that out. But what a brilliant move. Take your shortest person, good fundamentals and just box them out you you know. Use that button. I'll use that. Well, there you go, See. We're helping each other here. I think that's a good way to probably end this episode, this conversation.
I want to thank you again for being part of this and kind of sharing your wisdom around this, Gil. We'll have links in our show notes that we can have people go out and visit and you know, if they've got questions, they can certainly reach out and connect with you on LinkedIn. We'll have, you know, your LinkedIn profile as well in our show notes. So visit salto dot IO slash
IDAC. They'll learn more. Jim and I, we're on the web, idacpodcast.com and you can always connect with us on Litter on on LinkedIn, if I could talk correctly. And with that, we'll go ahead and leave it for this week. Thank you again, Gil. Thank you, Jim. And we'll talk with everyone in the next one you've been. Listening to Identity at the Center. We hope you've enjoyed the show. Make sure to like, rate and review and we'll be back soon.
But in the meantime, hit the website at identity@thecenter.com and find us on Twitter at IDAC Podcast. See you next time on Identity at the Center.