Name: 5 Most Common Mistakes When Building In-House IT
Uploaded: 2026-01-14T21:16:04.645Z
Duration: 58 min
Description: 5 Most Common Mistakes When Building In-House IT

Transcript for "5 Most Common Mistakes When Building In-House IT": Alright. Well, hey, folks. Thank you so much for joining us today. I'm Carter. I'm a IT community manager here with Ripling. I've been with Ripling for a few years, but my background is deep IT administration. I'm really happy to have a conversation with James, who's with Rippling today, as well as Paul Strauss, CIO from Parallel. And we're gonna go through, like, what are some of the most common mistakes that folks make when building in house IT from scratch. What happens, you know, as you start to scale, even with small teams or in Paul's, you know, experience being kind of the only guy out there making it all happen. Like, what are the kind of catch catchalls and and things to consider while going through all this for the very first time? So, James and Paul, you wanna you wanna say hi to everybody? Well, hello, everybody. Yep. Like you said, I'm James. I'm here from Ripley IT, and I'm ready to use my tech background to help shape your future. Let's do this. Hi. I'm Paul Krause. I'm CIO from Carrolol. Been working with our company for about eight years now. We're a startup in the area of, caregiving services to make individual caregivers' lives easier and better. And we are subject to a lot of complexities for a business of our size in terms of security and compliance, dealing with very high end, health plans, insurance plans, financial institutions, our customers. So, we have some unique challenges as at our size, trying to meet all of those obligations without a big IT footprint. Yeah, right on. And you're kind of at that exact influx size of when things start to get a little bit more complicated. I'm excited to kind of talk through this. Maybe before we jump into the mistakes, let's, level set just a little bit. What, what's your, what's Carrolo's IT environment like? I mean, what, what pushed you to think about IT infrastructure when you did, Paul? So Carrolo's infrastructure is, we're kind of a mostly cloud based infrastructure. So, our end users are typically interacting with applications that have been, they're either third party hosted software as a service applications like Zendesk or Google Workspace, and then our own proprietary in house applications that we've integrated with those platforms. So we're, and we started out as a fully remote business. So we're a little unique in that area in that we did not, we went through the COVID era era already remote. So we didn't have to go through that transition. But we also had to go to the, this, this process of how do we manage a secure system that's distributed this way. So we have centrally hosted infrastructure and applications, but we have all these endpoint devices all over the country. So we have people in a bunch of different states. We're running, both Mac and Windows endpoint devices primarily, UI components and, other things that we, are BYOD type situations. But in terms of the the devices we're managing, it's all Mac OS and Windows. And so we're and then our applications are all hosted at AWS. So we have, you know, user access management we have to deal with for accessing those applications, both from an administrative perspective, as well as a, you know, just a general day to day utilization. Yeah. So lots of different kinds of endpoints, lots of different kinds of identity things going on there. Is there any like specific problem you were trying to avoid as you kind of built this up? So, well, certainly the the problems we wanted to solve early on were ensuring that we had some sort of remote management capability of devices. That was critical because we're dealing with geographically distributed users, but we're also dealing with a high compliance environment. We need to be able to shut people's accounts down the minute they're terminated. We need to be able to remote wipe devices, all these sort of things. So that was critical to us early on. We were also trying to avoid all the pitfalls that small businesses have of things like account sharing and, you know, inconsistent password rules and and things like that where users are just off on their own administering their own boxes, and then we're trying to sort of back into fixing that. So those were things that we knew going into this. When we started as a company before our first couple of customers, we were allowing people to like BYOD, their laptops, things like that, just to get us up and running as a business. And very quickly, like within a year, we just said, we have to move to we're managing it all. It's our hardware. It's our infrastructure. When you're in that first step of startup, there's a tendency to do that. And it was okay for like marketing folks. But for anybody who's dealing with end user data, PHI, PI, that kind of information that's so critical, we couldn't go that direction. Yeah. For sure. So those are things that we're really concerned about early on is getting in a situation where we could wrangle this remotely. Yeah. Lots of things to consider, especially in your industry. I mean, the the idea of a single source of truth in that moment tends to be something that people gravitate towards as as a solution. Is there any kinda consideration there? Yeah. I mean, so so when we started out, we we wanted to be at that point, but it wasn't easy to glue all the pieces together. You know, we started out, we knew we were gonna use Google Workspace for managing user accounts, and we knew we were gonna push the business in that direction for document management and that sort of stuff. But we didn't have a clear answer for, okay, but how are we gonna combine that with device management and, and remote management and antivirus and all those things? And we started out down one path. You know, we, we actually started out with junk cloud a few years back. Ran into some pitfalls there. Probably the biggest one was not being able to handle any sort of the the physical asset management, which was really critical for to us as we grew. Now for the first year or two of our business, we were managing 10 laptops, keeping track of where they are, who has them, what condition they're in, all that was pretty easy to do. Now that we've got, you know, 45 endpoint devices out there and that just keeps growing every year. It's it's not manageable. So it's it's that was one of the big reasons we moved to Rippling was in order to combine that IAM, the the the management of the accounts with the management of the actual device inventory. Yeah. Changes a lot. James, what do you what do you got there from your experience dealing with a whole bunch of different shops of various sizes? Any kinda takeaways that ring ring similar in your experience there? I mean, yeah, a lot of companies I've dealt dealt with have the same kind of issues you stated, the whole starting smaller and getting larger, the whole startup approach where you have very smart people that have jobs to do. But then because you're building the company, they're doing this job also. And their goal is to make the problem in front of them go away, not to solve the problem that's coming up next. Right? So what you get is configuration drift and, like, tech debt that just piles and piles and piles. And you end up having situations where essentially shadow IT becomes the only way things get done. And you have these stacks upon stacks. You've you've probably seen the pictures online, the little thing holding the whole thing up. And one person leaves, and then you don't really know what's supporting what anymore. So, yeah, I think I've definitely seen the situations here where you have these smart people making good decisions in the moment, but not good ones for the long success of the IT infrastructure for an environment because there's so many disjointed systems. I think what Paul said is pretty interesting, you know, specifically with a largely distributed remote workforce and having to, you know, handle inventory in different places or however that looks for different shops. Any ways you you think James that like, you know, common ways companies mess up specifically that, like device purchasing or inventory, you know, happenings? Oh, for sure. It's it's it's like almost the exact same thing. I mean, you Bob needs a laptop. You run the Best Buy. You stop at the Apple Store. Our machine's there. Great. Until it isn't. So you have no control over that device. If it gets lost, you don't know if it's locked. You don't know if it's secured. You don't know what the Uber, you know, driver has access to. And then you can't do anything with it when you have give it to another employee besides get it back and physically touch these things or have to guess what's there. Yeah. Not having control of your inventory from the purchasing stage to the employee's hands is, like, a big security risk, but it's also really an inconvenience for IT and the end user. Yeah. I mean, I I found myself running to the UPS store, dropping things off and getting laptops shipped back to me and and just a bunch of little every day, every week, things that add up and take up, you know, a couple hours a week of handling those shipments and handling, you know, oh, there's a device missing a power cord. All of those sort of little annoyances add up over the course of the year. Like, yeah, it's a death by a thousand cuts and helpful people get. I had never been to FedEx more than the first few months of COVID. Like I was in my house all the time except for FedEx. I saw them, and I saw my bubble, and that was it. Because I was constantly making sure people were getting their devices. And, again, it's that curse of being helpful where you wanna do all this work, but it it adds up. Like, you said, it was a lot of time. I worked somewhere where FedEx was actually at the Ground Floor of the building, and it still wasn't convenient. You know, it's like still sucked up so much of my time that like, my next gig was actually just a few blocks from there. And all of a sudden it's like, Oh, this just went from like being an hour or two a week to being like, had to walk there and that would take so much longer. It's like, I didn't, you know, I didn't anticipate the time suck of that and how good I had it when it was downstairs because it was such a crappy position then, you know? When I was, before I just moved back to Chicago area this year, I was living in rural Oklahoma for three years. It was a forty five minute drive to the closest UPS. No. So that was every time I had to go ship something, it was an hour and a half out of my day to go deal with that and come back. So that was not very convenient at all. So what does that actually look like now that you've got things in Rippling? Like you, you It's, it's super smooth because all I do, first off, I boxed up all the stuff that was sitting in inventory here, shipped it to the Rippling warehouse. They clean it up, tag it, make sure, you know, it's working, give it a grade of what condition it's in. So, so for those initial devices that are in inventory, it's super easy. I get a new employee. I say, assign a device, pick the device that I want to go to them. It automatically pulls their address from the employee file and ships it off in whatever method I want to ship it, whether I want it, you know, urgent because they need it tomorrow because it's always urgent. Because of when our background checks come back, like literally the day that somebody started. So things like that, that have you shipping in a rush. And then retrieving the devices is easy too, because you just go in when you terminate an employee or you need to fetch a device back because you know, you've swapped the device out or something like that. You just go into the system. You say, you know, unassign this device, asks whether you want it back. And then Rippling sends a box out with a shipping label and it goes back to Rippling and goes back into the cycle. So that's all really simple. And then when you wanna buy new devices, there's an integration with, with a a shop. So you can go and say, okay, my standard build for, you know, these users is this MacBook Air. My standard build for these users is this Dell, laptop. And then you can just reorder those and have them direct ship. It takes a little bit longer on a brand new machine than something that's already in inventory. You know, closer to a week, I think, in most cases. But, that's it's really nice to have that all integrated in one place. Yeah. It's kinda like, it's hard for people who haven't had to do it before, who see each one of those things you described as being like an issue when really it's more like the device life cycle is the issue. Like it it's it's from the moment you buy it until the time it's it's gone. You want to be able to track that. You want to be able to know where it is all the way across the board through that. And otherwise you're manually popping stuff in somewhere maybe, or hopping from tool to tool. So, yeah. Yeah. Think the one area that we're still trying to come up with the best solution for as we scale is the actual device support. So this process solves a big part of new device provisioning, getting devices back when somebody's terminated. But once a device is in the field and then somebody's like, oh, my laptop started freezing. It got slow. These sort of things. Beyond the warranty stuff where we can, get a device shipped back to Lenovo or Dell or someone like that. We're still struggling because of our size and our, at this point of inflection in our organization of not having a big IT team. How do we best support that going forward? I welcome any ideas that you guys have for a business of our size. Yeah. It's a desk, desktop support engineers are Yeah. It's a tough one. Cool. Well, well in that vein then, I mean, what does your daily management of those devices look like? Like maybe not when they're broken, but like when things are functioning correctly, like what, what does your, your business look like as far as managing those devices, be it the ones that are fully managed or you said you have some BYOD considerations as well? Yeah. So, so the BYOD is just, you know, handful of, of mobile devices and kinda not the main focus of what we're working with on a daily basis. For all of the devices that are fully managed through through Rippling, we're typically, you know, we're onboarding new users, obviously. We're granting them access to applications. The system automatically provisions applications to the devices. So there's like a big library of stuff. Plus we can upload our own custom applications. Send those down to the device when they're first onboarded. And then on a regular basis, the only real IT management that we have to do is making sure that, you know, antivirus is monitored, you know, if there are any compliance issues, devices need to be kept up to date with the latest version of operating systems. Fortunately, the MDM capabilities and, and remote software management capabilities and Rippling let us automate a lot of that. So, you know, making sure everybody's on the latest version of Windows 11, but not the bleeding edge stuff, but the stuff that's fully compliant and, you know, golden release, things like that. So, so we're able to automate that and we're not going out and having to wrangle every individual system and make sure it's up to date, but also keeping track of when somebody is out of compliance. Right? So knowing, okay, there's a device that's been sitting out there for two weeks and nobody's logged into it. So it didn't get the updates. So, so that's part of the IT cycle as well. It's just monitoring those things and then following up with the users. Beyond that, you know, application provisioning. So we've got both applications that go onto the devices that we have sort of preset set of things that every parallel laptop ends up with. And then we have SSO, implementation for granting access. And we're just kind of in the beginning days of migrating most of our SSO into Rippling. We had previously done most of our SSO through Google Workspace, but we're trying to centralize as much as we can. Yeah. So it's like one account for everything and, you know, both from a user convenience perspective, but also from a compliance perspective, because something that's really important to us is we have to do account reviews regularly, you know, who has access to what? Do they have access to what they're supposed to have access to? Did we audit it? Cause we have to track all that for, for our SOC two compliance reporting. Right. We have to have evidence that we actually did that. We terminated accounts and people quit and all those sorts of things. Yeah. Specifically for off boarding. So when you off board your devices are locking or wiping based on what you choose during an off boarding. Do you have, do you have you hooked up like the Google off boarding features yet? We've done it for Google Workspace and we've done it for a couple other applications, but we're trying to get to the point where as many of those things that can be automatically access removed by rippling SSO, we're gonna try and do that. And and also where possible, where those integrations exist, where it can auto provision new accounts. I know there's some limitations, some SSO platform is SSO doesn't support automatic provisioning. So you have to go and create the account in that other system first, but then you can grant access to it. So there's, you're always gonna run into those kind of wrinkles because not every, every system supports those standard, but Much less of a problem than it used to be. Feel like that gotten a lot better. Shrinking. James, what about you got anything to say to that in the context of like folks not having MDM who, like, don't realize exactly how powerful that is during an onboarding, offboarding, for example? I mean, yeah. I I I've come to think of MDM as, a baseline requirement for doing, you know, any kind of business IT support. Like, not knowing what out there what's out there is, like, a really a problem. So for onboarding, offboarding specifically, with without MDM, you have you've taken the burden of onboarding from essentially robots and the machines, make the things pretty for how you want it to the end user sitting through these sessions or your tech walking them through or someone in office going through a whole checklist when things are going in. And that's not actually all that bad. It's a lot of work, and it's annoying, and no one likes doing it. But what's worse is on the off boarding side because you can't control that as much because people leave for different reasons, happy ones, sad ones. Things just get lost. Things happen. Right? And on the way out, you don't really get to do the checklist because there's not always people involved. So if you want MDM, you don't have control over the device. So essentially turning, like, a checklist into a checkbox that the device is expecting to see kind of takes people out of the loop except for in the planning phase. So, yes, you have to integrate your systems and make sure they work. You have to choose the right policies. But once things are just running, they just run. So, yeah, without MDM, you can't do any of this stuff. That's Mac, Windows, whatever. In that thought, let's talk about maybe like identity and come back to the SSO part of the conversation too. Like, what, what does that look like at Carrolol? You know, you said you're, you're rolling out SSO. Were there any challenges there with your user base maybe? Like, or was that easier for them as you started to roll that So, so we'll talk a little bit first about where, where our biggest challenges have been around account management. You know, when you start up, you start tracking things in spreadsheets, right? It's like, here's a list of users. Here's what they have access to. Here's when they got terminated. Here's when we took access away. And it's a whole sort of management nightmare trying to track all that in all these different systems. So the first goal of this is to like get to the point where that's, none of that is managed that way. Yeah. And that you can go into a place and say, okay, this user's in this group and people in this group get these, these roles and this, these tools. And then when they're terminated or they change roles, that all happens. So, so that's really what we were trying to get done throughout this process. And I would say we're not all the way there yet because we're still in this process of getting everything moved into SSO and rippling. But, but we were getting close to that point in, in Google Workspace where most of our accounts are, you know, you log into your Google Workspace email account, and then you have access to everything else. Managing it in that system is not very user friendly. And the group management and all that, just not the best. So that's another reason we're trying to get everything moved over to Rippling for SSO. But, but at the end of the day, the most important part of that whole IAM for us is making sure, again, coming back to compliance, we have very explicit things in our, in our controls and in so our contracts even that say, you know, this whole like, principle of least privilege, who has access to what they, people should not have access to anything they don't need to perform their specific tasks. And so being able to use role based access control and being able to group people into specific user roles, that's really important. And it's something that we've been getting better and better at as, especially as our company's gotten bigger, where people wear more sort of defined hats. Whereas when we first started, everyone wore 12 different hats. And so it was really hard to define roles. It was like, okay, well, this guy needs these eight apps. And this guy needs these nine apps and this guy needs these three apps. And now it's like, okay, well, all the care advocates get this and all the business development and marketing people get this. And so with growth, I think that's one of the things that's really important is that you do a good job of planning those and, and defining with business stakeholders. What do people really need to perform their job and make sure that they have that and make sure that that, that access is granted through, through our systems. Otherwise, we end up back in shadow IT labs. People are going off and installing things they shouldn't have. That's obviously one of the things that's very important to us too, is nobody had other than a couple of IT slash, development folks in this, in the, in our company, Nobody else has admin privileges on their their systems. Yeah. We don't want people installing applications we don't know about that haven't been vetted. We're especially sensitive these days around AI applications. We don't want people training, you know, the worst scenario would be somebody goes and trains, an LLM with somebody's PHI. So you really try and restrict those things. James, any comments there with regards to identity sprawl or, like, ownership issues that you you're familiar with? Oh, for sure. So I'm is one of those things. Like I said, MDM was the baseline need, and I'm is becoming more and more, like, required in, like, every circumstance. Some things that I see happen when people don't have this or why people do these things when they don't have this, especially start off smaller ones that are starting out and growing, they don't they're they're not lazy. They're busy. Right? So they just wanna make sure it's easy to do their job. So they just have shared access or whatever way they're sharing their passwords. People have shared accounts. We have people trying to save money early on, so they don't wanna have multiple accounts in the same system. And that becomes really great when you're three people and you're all friends. But then when you're three becomes 30, becomes 60, it doesn't work anymore. And then people obviously leave. You wanna control that access. But that's all for starting out and granting access initially. I think where it gets much more complicated, and you really start seeing the beautiful benefits of I'm and other integrated tools is when people change roles because and, you know, companies move fast, and a rep link moves fast. You know, your startup grew to, like, as fast as it did to where you are. I'm sure people changed roles. With And the changing of roles comes different responsibilities, who's managing what. And as those hats change and get more defined, you wanna be able to scoop that in the tools. And without I'm you don't really know what you changed all the time. You have to go figure it out. The number of times I've figured out what someone has access to at at or because I've worked to manage that was when they left. And figuring that out, it's like like, you don't wanna pay your your electric bill when lights turn off. You know? You wanna know what's going to happen. I can't I'm not speaking from experience on that one, but, you know, my wife's particular playing the bills. I'm not very good at those things. But I really like, one of the one of the newest things that Ripley rolled out for identity is, like, the the shadow drift, the idea of like access drift changes popping up. Like I spun up a new service. I gave James access early because he's an IT admin maybe, but then later he got real access given because he was in like the IT group. Right? So like, it highlights now whether you gave access to somebody via two different things and can let you easily take away that like, oh, you gave him like individual access, like that looks gross in a report. It kind of just like makes you not know exactly why someone has access. Like that. I like that feature because I would have used that at previous jobs like all the time for sure. Yeah. Well, identity is key then. Maybe moving on to just general treating security, how you treat security as something other than an afterthought. Maybe James, we'll start with you. What what do you feel about companies that say, I will save that for later or something like that? Right? Oh, famous last words. So alright. You don't wanna deal with a breach after it happens. That's obviously terrible. But let's in a less extreme model, yeah, security gets annoying. People are doing it themselves. Right? You don't wanna deal with the impact of it or the user impact. But there are a couple of benefits to starting it early. First, there's some soft impacts. Having the correct security stuff in place because you know you need it makes it easier to hit those check boxes for those reports that are coming in. But also for your employees, they get used to playing within those lines from early on. And you're not the bad guy for adding it on later when you should have done it before, which is basic just easier to, like, people working your environment. People forget about those soft parts of it because it really is like this balance between usability and security. And if it's just there, it becomes a baseline. And then there's just, you know, people wanna start adding tools later, the MFA and other things. And it gets complicated when the tools they chose weren't vetted to work the way they wanted it to. Earlier, Paul, you were saying some of the tools didn't have the right SAML or skin components to work with modern IAM stuff. Yeah. That's true. Because it but they weren't vetted to do that when they were added because they didn't need to. Right? But now you need it. So when you deal with the security stuff as part of the conversation for adding your tools together, you know what's going to work or not with your with your current stack when you start. Right? So, that's my take on it. You wanna plan so it's less painful for you and your team. Paul, what about like, do you have any non NBM, non IAM security things that you feel like you did early on that like made a big difference? Sure. Sure. For, for us, because we're not just running an IT infrastructure, but we're developing our own applications. Security at every layer of what we do is so critical. So software to scan your application code, both when a developer and early, as early in the process as possible before code gets checked in and deployed. You're doing security scans. You're doing, intrusion detection in your production environments. You're doing penetration testing of your environment, both manual penetration testing and some sort of automated tools. All of those have been critical to sort of our application infrastructure. And then layered on top of that, you have to make sure your endpoint devices have, you know, a good, at least antivirus, anti malware, ideally a full EDR solution running on we've gotten to a point, especially with all of the bad actors out there, you know, when it was largely manual or people write script kiddies and that sort of thing, the, the, the attack surface wasn't so bad and it's getting worse and worse because of AI. And so you have to be prepared for anything. So having all your devices managed remotely, being able to see, you know, did somebody, you know, somebody's machine stepped onto some website that tried to install some malicious software that could ripple into your whole business. I mean, you could get hit with, an attack that comes in through once somebody has elevated privileges on one laptop, they could get in and, and, you know, shut down your whole business. Ransomware attacks, things like that have gotten very, sophisticated. Probably one of the biggest things that we did, and we did it early because of compliance requirements in our industry, but it was so valuable to us. And we say, everybody needs to do this. As much as people hate training, like online training and watching videos and all this stuff and fast forward you through so you can get to the, to the quiz at the end. We do regular IT training, both at Hire and on an annual basis. We cover a whole lot of topics. We're using a platform called InfoSec IQ for that. There are a bunch of them out there in the market. But that's been really helpful for us in terms of making sure that people are are understand the risks of the things they do and issues with social engineering and those sort of behaviors, impacting security as well. So it's not we look at security as this whole big thing that if we attack it on 20 different fronts, every one of those places that we, we cover makes it less likely that we'll have a vulnerability or less likely that a breach would expand and extend in a, in a meaningful way. Yeah. So, you know, we've had our vendors, we've checked their SOC two reports, all that good stuff. And, and so that helps a lot as well. So it's not just like what software you're running, but what are the processes you have in place to make sure that, you know, even if you don't go get a SOC two, even if you're not HITRUST certified or any of that, go look up the controls that are recommended for those things and work on ins- you know, instilling those into your behavior. Yeah. It really helps in terms of making sure that you run not just from a, from an infrastructure and software perspective, but from a process perspective in secure and compliant ways. And I think you probably as a CIO have, you know, real good optics into what prevents, you know, what doesn't slow your crews down, what doesn't slow your engineers down from developing as you've got to do this quickly and securely, but you know, you've got to keep everybody secure, but you don't want to slow them down by, you know, putting something that's either hard to use or obtuse or, you know, things of that nature. Cool. So kind of like an automated and invisible component of security for sure. Yeah. I mean, for instance, we use, we use an, a tool called sneak in our development process. And what sneak does is whenever code is checked in, from the, from Visual Studio code, it'll take that and it'll run it through all of its tests around, you know, best practices around security, known vulnerabilities, any dependencies that might have vulnerabilities. And it gives the developer feedback immediately. Cool. Before it gets into higher environments. The developer can fix those things early on. And it just becomes part of the organa- organic process of development. And then we also run that whole scan again, right before we deploy. So we run it against the full code base and say, oh, are there any issues? And if they were, we kick the whole thing back until those can be remediated. So that's any place that you can build in that automation. And you can also build in systems that prevent things from moving forward. Yeah. If they don't pass those checks and balances is important. One of the things that has we see it on security questionnaires all the time about, you know, when you have an emergency, is your, your process different? If you have to do an emergency deployment, is your process different? And our answer is always, no, it's not. We do it faster. Yeah. We do it, but we do all the steps you can't skip the steps because that's when mistakes happen. And that's when bad things happen to your environment. And also bad actors use those emergencies as like fake Reese's trying to get in. But your fast feedback loop you have is really important. You get that information early in the cycle. It's way cheaper to fix it early. And it's just better for your, your coders to know what best practices to type next time. Yeah. Cause they learn, they learn things that they didn't do well and then they improve by learning those things early on as well. Right on. Well, in that thought of kind of automation preventing security risks to, know, automation and good practices, role based access controls for me, you know, are one of the very first things that I drill into whenever I've like fallen into any kind of IT role is like, wanna know exactly why role based, you know, controls are there. What do they look like? Why are they in place? How are they automated if at all? Paul, how do you how do you handle those things happening? I mean, we talked a little bit about it earlier, but like the changes that happen for people going into new roles, is that granting them new access at all or giving them new insights into tools or things? Yeah. I mean, I think it's, for us, it's a combination of things. And typically when somebody's moving between roles, they may need access to completely new applications they weren't using before. They may need different levels of access to tools they were already using. So, so all of those rules have to be part of those configurations in each of those different applications. Yeah. And so there may be a set of roles and rules within like Domo, for instance, such as our, our unified platform for reporting and, data warehousing. And so we have to be very careful about who has access to what tools there, what reports, what data sets, and those. Yeah. Reports, in particular are kind of cool in the rippling world because you can like keep it shared out. If someone suddenly, you know, falls into this new security team that needs to have access to all these reports, it's it's not a matter of like tracking down all these different like CSVs you've got just like all over Google Drive or anything like that necessarily. Yeah. I mean, the, the, the, the wonderful thing about role based access control is being able to centrally manage everything about a particular user and their, their role within the business. The downside is to it is that it can be very powerful and you can, you're not paying attention. Yeah. And you can accidentally grant privileges people shouldn't have. Yeah. So it's, it's a balancing act. It's still much better than doing, you know, individual role or granting of privileges to applications. So, so I'm all for it, but it's, I think it's really important, an important exercise to do to line up business need with roles. Yeah. So a lot of time we'll find ourselves in situations where a particular system only has a couple of roles available in it. It's got like admin, super godlike user, and then everyone else. And then we're like, but we don't want, you know, somebody wants to be able to generate a particular report for instance. And we don't want them to have access to all those other features in the tool or be able to delete users or other stuff. Sometimes that's enough to get us to switch platforms or not purchase that product at all in the first place. So, so I think that's a pitfall you should also be looking for when you're looking at software early on in a business is, will it give you that granularity of control that you're gonna need later? Because at, at first, when it's like just me with godlike access to change everything in the system, that's great. But when you hire that next person, you don't want to be blindly deleting data or removing users. You wanna be able to be much more granular about that. Yeah. I think we've all dealt with, you know, school tools where there'd be like 45 different check boxes on a new user creation screen. And it's like, what are you checking? You just check-in some like template that someone some old IT admin gave you and said, we hire someone into marketing, this is what checkboxes they get. And it's like, oh, man, I don't know, James, that sounds like burn that sounds like burnout on a plate to me. Right? Sounds like process fatigue, like for users and that, that you just don't wanna do the same thing over and over again, because you don't really know what you're doing anymore. You need to make sure you do it. But, like, at a certain point, just checking the boxes. You don't always check all the boxes that are really happening, you know? Yeah. Yeah. It's not very satisfying. What about, in you in your current role, Paul, I mean, a one person IT myth busting as a conversation, I mean, is, is, if you were starting today with like just you or just one other person and it was a totally fresh environment, is there any kind of lesson, big lessons learned that we haven't talked about yet from that perspective? Well, think, I think a couple of big lessons that, that I learned in my business specifically were around understanding as much as you can about the landscape of the, the scope of the universe of your business and not just the IT aspect of it, but like what are the typical requirements and needs within the space that you're going to be selling within or the space in which you're going to serve customers? Because they're all very different. And there are things that you might decide differently early on if you, even if you're not worried about them on day one in a year, you're to worry about them. Yeah. I'll give you a great example. When you first started up, we have, you know, some software where applications are managed by third parties that are offshore. And as you get deeper and deeper into Medicare and the government and all this fun stuff, there are a lot of restrictions about what you can, what can happen outside of The US. Yeah. So you need to plan those things upfront and think about them when you're, when you're doing your application selection. Are they HIPAA compliant? Are they gonna be able to provide you with onshore resources to support your environment? All those sorts of things. So that's a very specific to our use case, but just in general, if you're coming into an IT role, especially if you're coming into a startup and maybe you were in a different role, different business, anything like that, it's important to get that landscape of where it could go early on. You know, we're talking about the single sign on and, and being able to promote provision. Those are the sort of things like if you identify those as requirements early in the process, even if you're not gonna use them day one, it's really good to sort of have that runway. Yep. Sometimes you have to make trade offs though. As a small company, sometimes you have to cheap choose the cheapest product, right? Sometimes you have to choose the one that doesn't do all that. And then you may have to have a game plan of how I'm gonna migrate from this when we can afford to do it when we're bigger, when the tool set, you know, is mature enough, that sort of thing. So those, those are some of the big pitfalls. And then I would also say as early as you can, you get your MDM up and running, get your, remote account management I'm set up as early as you can in your business. Even if you're just a couple of people, if you can do it, if you can find a cost effective way to do it, start that as early as you can. It's gonna give you something to build on and grow into through configuration instead of like, now it's time to go do a swap out of three different disparate platforms. Yeah, totally. You definitely have an advantage when you're coming into it. Like you said, from the beginning, really having stock of your environment and knowing exactly what possible pitfalls could happen. But like James, in your in your experience, seeing seeing a lot of different shops as well. I mean, I feel like the need for a ton of boots on the ground. People has definitely shifted when rolling out MDM, rolling out IAM, something that used to really take, you know, a manager and like a sysadmin and like a boots on the ground person might not take that depending on the size of your your shop and kinda like the maturity of your shop. You you got any comments kinda talking through that? Yeah. I think part of what you were just touching on about when the process you add these things, the earlier on the process you can, the less work will always be. Right? But even now, like, migrating from one method to another has gotten so much less painful that I used to be scared for anyone saying words like migration or changing things in the field. But now it's like, you know, you just do it. So, like, when was the best time to plant the tree? Well, obviously, twenty years ago, but also today. Like, just plant that tree. Get that fruit. I like it. Alright. Well, I think we're hitting our little lightning round area. So these are like quick responses to, to to just kinda like general general questions that maybe either y'all both of y'all wanna take a stab at, but, what's the biggest it mistake, the single biggest it mistake that a company might make in the first ninety days? 92. Can I take this one? Yeah. Of course. So not having separate tests and production environments. But people do that? Do it all the time. I've seen it over and over again in small businesses where they just start building in production and there's not a place to And shit things it doesn't happen that often in really big companies, although I have seen it happen, especially with like Skunk Works projects and things like that. Or in companies like I worked for a media company at one point and security and compliance were not top of mind. But yeah, having, having those multiple environments is critical. Yeah. And I'd say, oh, shadow IT stuff's gonna happen, but not by putting some kind of stoppage for any group of our systems. Anything where people work together and allow that to happen early on causes so many rippling out problems. Like, for example, we might use Slack or you might choose Teams or River or Discord or whatever. But once people are in those systems sharing information and data, and you're and they like it, it's, like, really hard to make changes in a way that is, like, malleable to everybody. So they're like, oh, what's the big deal? We're using Discord to use it at home. I can't, but it doesn't work with any of our our tools. It wasn't made for this. You know? Keep using it there. So, yeah, not not stopping people from making those easy decisions. Yeah. When you've got a when you've got an org that has a mass to 10,000 emoticon Slack library, you know, it's always tough to kinda get them on teams. Oh, god. Sorry. Here's another one. What's the first thing? What's the first thing you would automate? What's the first thing an IT team automates? Oh, user creation. Right? So not just the individual user, but the process around what happens when they are created. So anything, you know, your configuration of what a user is in your organization because that ring fence is no longer your network, no longer the computer, it's the person. So figuring out how they get deployed and what they get access to would be the first thing I would wanna be. Paul? Well, you kinda stole my answer there. Sorry, Paul. It's a good one. It's a good one. I said it fast. I think the other thing that I would want to automate is the process of, account creation. So, so there's not just the user, but there's everything around accounts and access and that area of the world. Yeah. Monday, having Monday mornings not be a total pain in the butt and having your Friday afternoons not stolen from you for off boardings. That's my answer. I know I'm not supposed to answer, but that's my answer on and offs for sure. Ons and offs. All right. I think we're hitting the last one. What's a sign your IT foundation? What's a sign that your IT foundation won't scale? What's like a red flag if you've got something going on, you're like, that actually turns out to not work in the long run. I'm going to go back to my multiple people sharing accounts. Yes. Yes. Oh, You know, like you see it and you see it in startups, you see, oh, I just created this account and I emailed them the password so they can get in there and use this tool. And, and related to that, because we saw that we actually have a, I have a very specific example. I will not name the product, but there was a product that we've selected four years, five years ago, that we use for some very, you know, some form of creation. I'll say that. I'll give you a category. And it's great. It does everything we want. It's HIPAA compliant, all this stuff. They have a version for small businesses that's a single user version. Anything more than one user is a 100 times more expensive as their enterprise and so, and we're, we're kind of stuck because we're using it. We've got end users going to these companies all over one user account or go from something that's a $200 a month expense to a $10,000 a month expense. Do you at least handle that with a password manager? I mean, is that something that like you've at least got secured in that sense? You can, but we've decided our approach is only one person can actually access the account. We, we share the data through other mechanisms. So we have access to APIs and we can pull the data out into our data warehouse and have access around that. But the actual administration of the system and logging into the system and creating new forms and that sort of stuff, one person. One person. Just because we, we absolutely forbid that sharing of credentials. I, I hear hear. I I I I approve of that. James? Right. That was a good one. I'm gonna say your onboarding and by and also offboarding of users. If that takes a long time, if it's a very large process, if it you see people have access after they leave. If your onboarding, offboarding is not tightened up and an easy enough process that's not wasting time and not actually working, that's the thing. You scale about onboarding and offboarding. You might never you may never add an employee or lose an employee. Right? But if you couldn't do that quickly and easily and securely, then your tools aren't configured in a way that will scale. And it impacts so much more than IT. Right? I mean, it's like, it's sure where the people having to, like, instantly deal with it, but, like, the managers of that person who just left or who just came on are also feeling pain in that situation too. So I feel that. I agree. Yeah. Good answers. Awesome. Well, any, any closing thoughts? I think we're kinda, we're kind of at our time gentlemen. I think my, my only other closing thought is, and I think this is a general sentiment for a lot of it and engineering folks is automate, automate, automate. Wherever you can identify opportunities to take processes that require human intervention that you can figure out. What are the steps? I replicate these steps? Can I document these steps? Then figure out how to make that something that's automatically replicable. It'll make your life easier. It'll make your business scale faster. And, it in general will make you more secure as well. I had a former, I had a former manager whose sysadmin roles that he would open, the job description would always be you are going to automate everything. I always appreciated that. I like the way you put it also. It isn't like start with automation. It's first you make sure the process is correct and automatable. So the person's involved there. And once you've, you know, vetted it, then you can automate it. Then you know your vetting process, that good work you done happens every single time. And it doesn't, like, replace anyone else's work. It really just makes everyone's work better. I really do appreciate that. Yeah. Very good. Awesome. Well, great conversation. It was it was awesome to to hang out with y'all for a little bit today. I hope everybody on the call learned something. Check out Carolelle, and stay tuned for some future 2026 webinars from James and I. We'll be around for sure. So keep everything automated. Thanks, guys. See you guys later. See you soon. Paul. Cheers, y'all. Bye, Paul. Bye. There we are. Okay. A little bit of a delay there, but hello. Thank you everyone for sticking around. I do wanna wait. Welcome, James, but perhaps welcome back to take a little bit of q and a here. So we will cover that in just a second. Thanks again for for sticking around. If you do have any more questions, please pop those in now. Still got plenty of time to cover a couple things. Before we do that, I'm just quickly gonna run through a couple upcoming events we have. You may have seen them in the docs panel. But just in case, for anyone here who's in the the Philly area or, you Tri State, New York in general, you can take the train. We've got a Mac admins meet up on next not next Thursday. That's tomorrow, isn't it? Yes. So we will be there tomorrow. We, being James, will be there tomorrow with the whole crew. So that's from six to nine at Queen and Brooke Game Cafe, which I trust is as quaint and fun as it appears in this photo. After that, Paul mentioned this in the chat while we were talking today. Bay Area, EUA's drop off day. Super cool event. I was really glad we were able to pull this together, but it is what it sounds like. You can get all the details in the doc side panel. But if you have old stuff flying around in your office and our house like that. Great example, James. You can swing by Park Paddle Paddle? Paddle? I I actually never quite landed on how you're supposed to pronounce that. But next Saturday, we will be we will be there in San Francisco. Highly encourage you to come out. Entry's free. We'll have coffee, you know, matcha, all the things. If you're a true San Franciscan, you'll have. the matcha. Alright. And after that, if you are local to neither of those areas but just wanna hang out with us a little more, and might wanna ask some questions about device buyback, which is also related to our u based drop off day, a really exciting new feature launch that we have. James did promise you have props he's delivering. That is a virtual event. That is, boy, two Thursdays from now. Yes. The twenty ninth, and that's at our a little later than our usual webinar clock because, you know, for our whiskey tasting, it seemed appropriate to try and go at least after work hours for this half of the country. So apologies to our West Coast brethren. You'll just have to be a little buzzed for the end of your Thursday. But while since we are somewhat short on time, I will quickly, like, run through this. I think you guys probably have some impression of what Rippling IT is and does. But just to reiterate some points that were touched on in that conversation, the three main areas that we operate are in identity and access, which we talked about quite a bit in this past conversation, as well as the other two. We also touched average device management and inventory management. And those three put together. The reason that we are so confident that those that tooling is really powerful as a as you as you unified set of capabilities is because they're all built around the same concept, which is the employee as the source of truth, the thing that drives the work of IT teams. Like, a really helpful analogy that one of our product leads used recently was to say that, like, engineering MacBooks are really MacBooks for engineers. And while that sounds like just a simple, like, change of turn of phrase, and it is, I think it is a limited of something that's really important about our philosophy and how we approach IT here. It is that the person, the employee is what informs every decision that gets made about their access, the devices they have, the apps they have access to. So, like, that is that is how we think about things here, and we build really powerful automation engine off of that premise. So that is what we do. You may see a survey popping up to take a demo and get a closer look at this, which I highly encourage you to do. Our SCs, our solutions consultants here are amazing. They're super helpful. They will walk you through any questions you have. Since we do have a couple questions to get to today, I will now launch the side of the giant q and a on it. So, James, we had one question here that was, I think, probably intended for Paul, but, I'm gonna pose it to you in a somewhat, less parallel specific manner. Being is asking how big are your IT teams and your employee size? And I think one way we can approach this without Paul here is to talk about the sorts of companies that Rippling IT typically tends to work with. Yeah. Meeting with a lot of our teams and people and contacts from the IT teams and our clients. A typical size, from my experience, been in the one to five range, People actually doing the IT. It does get a bit fuzzier because often people are wearing those separate hats using multiple roles. We have founding engineers, and we've got, like, developers that are, like, chipping in to do IT work. So sometimes the numbers get a little bit fuzzy. Yeah. No. Totally appreciate that. And I hope that's helpful. And I apologize if I mispronounce your name. Leanneet? Leanneet? Not sure. But a another question. Again, this one probably intended for Paul, but, hopefully, we can speak to this as more of a a parallel agnostic perspective is a mixture of three six five and Google Workspace, or does everyone use a single platform? So, of course, like, that's asking about parallel. But could you just kind of speak briefly on how Rippling IT interacts with both of those environments? Sure. A bit. And, obviously, you can go a lot further in the demo, but I'll just do from, like, my experience here. Most orgs for the email side or identity side are using one or the other, Google or 365. We do see people using both when they're using, like, the apps, the the word, the Excel, along with their Google email. They'll have a three sixty five account for that. And people who are doing, like, you know, their the Windows, like, device management, like, there'll be some Microsoft component there to manage those devices if you have a a dual platform environment. Awesome. Hopefully, that answers it. No. I mean, you know, we're we're we're doing our. best under the under these circumstances. So I hope hope that was helpful. Obviously, any other questions you have, feel very free to reach out to any of us. Our our contact info is all over this this golden s page, and you can you will find somebody if you go to rippling.com/it and reach out there. Last thing, whenever we do webinars, we tend to do a fun little raffle as suggested by the slides. So view winner this week. Hopefully, you are still in the audience. It's a little hard to tell in this view, but, this is gonna go to Bill Story, who's the IT director at Samaritan House. So congrats to you, Bill. We will be in touch as to how you can redeem that. So look out for an email from from our team, and, we will get you set up with that. But, let me just thank everybody one more time for coming out today. I realized taking an hour out of your day is no small thing, so we really appreciate, having you guys having you guys here to listen in and hope you, had as much fun listening to this as we did talking about it. So cheers, and take care, and we'll see you next time. Thank you all. It was great spending time with you.