All right. Good morning, everybody. And those attending remotely, I'm John LEIN and this is the unique challenges of identity. I'm an a in high growth organizations. But before I begin, I need to say that the views and opinions expressed in the stock are my own, and not necessarily those of my employer, any former employers or any organizations with which I am presently or have previously been affiliated. And now that our legal incantation is out of the way. Let me tell you about my experiences working in identity. I started in 2005 at a large global private education concern. They had just rolled out their own internal computer access process for Sarbanes, Oxley compliance. They needed warm bodies on the phone. That's how I got my foot in the door. Eventually I made it to their identity and security group. Next, I started off supporting and eventually owning access management and Federation for a very large conglomerate that once upon a time brought good things to life.
After that, I went on to the knowledge company where I helped kind of reinvent their entire identity strategy as part of a security modernization initiative. And presently, I get to maintain my practitioner bono fee days as the director of Okta on Okta at Okta, which means I own their customer workforce and federal identity implementations of their own platform. There's a lot of very soft vow sounds and repetition of the brand name. Every time I introduce myself, which is always a delight, but as fun as my career is, it's not the reason you're here today, though. Those provide the background for the context of this talk. I unintentionally have found myself working at very, very large organizations that are usually much older than a lot of the startups that we see today. And these big organizations have a lot of employee resources behind them and, and kind of diversification of it structures.
And then suddenly I landed at a much smaller organization though, to be fair. Octa itself is not exactly small, but was small and young compared to the orgs I have worked in. And this isn't a bad thing, rather. It is different. So what is also interesting is happening was what happened right? As I joined Okta, namely, that they announced they intended to acquire ha zero. And from my point of view, HAI was just another young and lightweight organization compared to the ones where I had identity M and a experience. So I was interested in how that would go. So O zero is significantly smaller even than Okta and the combined O zero Okta remains much smaller than any organization where I've had experience in before. And why all of this emphasis on the size of the organizations. So setting aside any of the Freudian implications here, let's consider how and why colossal well-established organizations obtain so much process, policy departments, et cetera.
And let's not get started on their, their bureaucracy that said this bureaucracy didn't just pop up in these big organizations, because it's what they wanted. Rather, I think it can be argued that the big bureaucracy inside of companies were developed in response to new institutional. And let's say regulatory challenges that they've encountered over the course of their existence. The longer they've been, the more these they encounter, the more SOPs they create and the bureaucracy grows. And yes, that bureaucracy can and does ossify many large organizations. Ideally we all end up exchanging our youth for the wisdom of experience. So hopefully we all be in the similar state, but in business, there are four general types of mergers and acquisitions. And I'd seen lots under my conglomerate type use case, which is when a, a large organization with multiple facets absorbs another organization to like augment their portfolio of products and services.
So with the Okta of zero merger, this was my first encounter with a horizontal merger, which is when two companies operating in the same space or a similar space targeting similar customers combined. And unlike all of these conglomerates, a smaller organization can move much more quickly, much more with more agility at the early phases when they're more growth-oriented. So that culture doesn't go away. Once they get a toehold in their market, rather everyone continues to be focused on doing everything they can to move the mission forward, regardless of where the requests come from, or where they sit in the business. That is very exciting. However, moving fast and breaking things, doesn't usually include a documenting and codifying an SOP in response to that step. And what's more sticking notes on a Camden board can be a great way to chunk out sprint work. However, it is not great for developing institutional memory and the processes to guide staff on how to best accomplish all sorts of fun organizational tasks.
So eventually these processes, the deeper specialization of teams, standard operating procedures are going to need to be established in order to ruthlessly prioritize what matters and to be able to get the right things done by the right people in the timeframe the business needs. So this brings us to our first identity M and a challenge identity M and a playbooks and high growth orgs are usually underdeveloped to non-existent based on my sample size of two and many procedures are ad hoc established orgs may be rigid with their SOPs, but at least the framework typically exists. So
A lot of beard fuzz, I guess, all so back to the marriage of these two companies, the announcement went out in March, sorry with that better. All right. The announcement went out in March 3rd, 2021, and the deal's closure was slated for May 3rd. We internally refer to that as day zero and immediately I get my first taste of how things are gonna be different inside of this smaller organization. We got the identity requirements for what we needed to do to make day zero successful 21 calendar days before the deal was closed. And I must emphasize that this is not to suggest there is malice or incompetence or anything else going on there rather. And also it wasn't particularly like 21 days. Sure. I've heard anecdotes and stories where people had much shorter times to accomplish much bigger feats. But from my perspective, it was definitely a change of pace compared to what I was used to.
And that brings us to our second challenge, getting a definition of done from the business high growth worries, move more aggressively with a greater likelihood of unanticipated rescuing as they move through their merger. Established orgs are not immune to this mind you, but that bureaucracy is helpful in inoculating them from doing it quite as much. So here is what we were working with. On the zero side, there are, they have an authoritative source, their HR system that feeds into the Google workspace, which is their IDP. They also have another IDP using their own technology for their engineering apps. So we have a distinction between their business apps and their engineering applications. Our at Okta, we had a kind of a comparable architecture, only everything flows through the Okta IDP.
So the good news is this made hitting day zero very easy because everyone was playing with standard protocols in a cloud space. We simply just connected the office zero Google IDP into our Okta IDP set up just in time provisioning. And then we started to populate the user records at sign on time with all those osteo workers. We had to give them access to three applications. When they started, we have the manage authorization with now the combined population inside of our universal directory using application groups. And here's where high growth organizations definitely have the leg up against our well established counterparts. They're typically very cloud-centric conversant Federation APIs. Whereas the big organizations, they often have lots of on-prem and legacy, and perhaps even deprecated software still critical to production, which makes that marriage a lot harder. All right. So back to our timeline, having cleared day zero, we got our next mission, which was facilitate cross-company access across the broad portfolio of applications for both companies and user groups.
We had six weeks to deliver this. And this is where that resourcing question between high growth and established companies kind of came up as a complication established orgs tend to have dedicated teams for various it functions. I kind of took that as granted, the high growth orgs that have umbrella it teams. This may not be shocking to a lot of people who've worked in different scenarios than I, but to me it was a revelation because the business, they were not in a position to accept that typical business as usual operational tasks, like let's say, onboarding, desktop support, et cetera, we're going to stop in favor of having those same resources go heads down on solutioning for identity integration. So fortunately we made it through to that release part.
I'll just leave that at that. Now we had both organizations, authoritative sources populating our IDP. We swung over from the kind of more just in time, Sam based provisioning into using their actual Google workspace directory to populate our own Octa directory. So now we had both populations using a much more durable platform to manage that we would pass through authentications through their osteo core IDP for a handful of their applications, which were engineering sensitive. And through application groups, we controlled their access for both groups and their combined populations. After that release, we finally had some time to breathe because our next major consolidation activity was not directly owned by identity, but it still requires some major architectural changes to support the order of operations struck me as wonky. But the more I thought on it, the more ultimately that didn't really matter. The first thing was consolidating our authoritative sources, particularly Workday.
Those would be combined on January 1st, 2022. And the next thing thereafter was going to be a combination of our Google workspace environments. I always consider Google workspace in every organization I've been in Okta included as just a downstream application from the identity provider for O zero, since it was their own IDP, it was a little bit more delicate. So the beginning is we had a full six months to figure out what we needed to do to make that transition painless. However, in some regards losing that time, pressure introduced a lot of new wrinkles, said our M and a strategy because it gave time for more turnover, more loss of institutional memory and urgency. And the loss of urgency better said the design and test would become the most critical and sensitive part of this integration. So that brings us to our next challenge, institutional memory, and perhaps even more importantly, asset inventory, we had the time, but we did not have a complete picture of O zero's application or architecture space and how they all would work together. And unfortunately, neither did our counterparts at O zero. So again, this is saying things are bad. It's just different in a well-established organization, asset inventory and maintenance of that inventory is always a challenge. However, at least it is a challenge they have embarked on earlier stage high growth companies often are, are still singularly focused on what their core mission is. And they're not really ready to enter kind of like housekeeping phase of keeping their house in order. So additionally
Efforts to discover technical and business owners surfaced additional challenges, which was, you know, kind of different ways of working in corporate culture, osteo used slack for everything. Email was sent to avoid, never to be seen again, Okta used a mixture of email and slack for official communications. So our calls to action were not reliably hitting the interested parties that they needed to. Additionally, kind of how work gets accepted really varied here. These well established organizations, like I was used to have some sort of a formal intake process, perhaps a prioritization criteria, SLAs for turnaround high growth org in my experience seems to be everybody does everything all the time at the request of everybody, which is cool and energetic, but it is really going to sty me them from achieving the kind of growth to become one of those big wellness established organizations. I'm gonna say this is probably the most difficult phase of the integration, just again, because we were getting a feel for each other's culture.
But once again, we got through it. Once our authoritative sources were merged and all the osteo and Octa records came from one place, we can now follow the Okta standard business processes for lifecycle management, any new Okta Ori employee came the front door and they had access to the birthright Okta apps. And we were able to continue to control access through the engineering apps for new employees using the same controls we had before now. The cool thing is we've kind of had a lifeline here for their Google workspace for the applications which had migrated to Okta from if there was an issue we still had the Google IDP though. The business was not impacted by any difficulties experience by the application. Cause there's always that failback. Additionally, we had to recreate some authorization logic that was found exclusively in that Google workspace and little by little, we began migrating it into our Okta tenant.
We had to get cute with some of our provisioning and authentication logic here. We would do transformations on the, the name ID. So that way the application record for the downstream maps would always match the name of the name ID record coming from our Okta IDP. Even if during the initial phase of this integration, they were being provisioned as a name ID ponder the.com domain. So this all worked pretty well, except a handful of very exciting go getters went ahead and got themselves into each other's systems by setting themselves as contractors and kind of setting up their own records by doing that. So again, not good enough that different unexpected, these accounts took a little bit of time and some vendor support to remediate for certain applications. So that brings us to our next challenge, change management and communication. So these high growth organizations prioritize employees, user experience and productivity, but they have less mature communication processes and less mature SOPs.
Those messages don't penetrate into the company quite as well compared to their more mature counterparts. So our well-established org also don't tolerate outbound processes to the extent that high growth ones might when you're big, you're off in public. And if you're public, you have a lot more regulatory concerns to deal with. So back to our timeline. So we're in the home stretch of our final major change to merge all of our identity infrastructure. And this was kind of the, the point of no return. So that's the consolidation of our Google workspaces. Once we lose that, that safety umbilical of the Google IDP on the O zero site, it meant all a zero business processes had to function well using Okta as the IDP, once more, we confronted the challenges of the lack of institutional knowledge and a complete asset inventory of what it is we were trying to ensure continuity for.
We highlighted said risk because at some point you kind of have to make your piece with not knowing what you can't know, and to my surprise, and to a lesser degree minor who the business accepted that risk. So finally the day came, we created a, a kind of a, a fallback or a net for what would happen in case something bad happened. We called it hypercare. We would do daily standups, dedicated slack channels for support on call rotations for emergency break fixed for ahead of the final cutover, I'm sorry, 30 days after the final cutover, at which point we start kind of considering the further migration of a osteo stuff as business, as usual activity. And it worked, we never got called off hours. We had zero P zeros and the last piece of the puzzle. So again, we're still doing like on a business level, we're doing, doing our application portfolio reconciliation.
There's going to be some time until we can fully remove kind of some of the vestiges of the osteo architecture and, and really merge things into what we're calling our target state architecture, where we have a very simple authoritative source, every single, you know, identity transaction, a business process, ultimately looks to the Okta IDP for authentication and authorization and resource access. Of course, tech debt. You know, that's gonna be a challenge here by our organizations, big and small, young and old. So no surprises there, sort of recap. So identity M and a in smaller high growth companies comes with some unique challenges compared to their larger counterparts. But I, I'm not gonna describe the experiences doing M and a inside of a smaller, more agile company as, as harder or more difficult, but I will definitely say it is, it is different and that's it. Do we have any questions.
