How to Find and Educate Your IAM Team

Go team! All right, so we're going to start today with a pop quiz because I'm evil like that. How many of you are jet lagged?

All right, good. So both speakers and a couple people in the room, this is awesome. How many of you are in here because you needed a place to sit while you were working on your slides for the rest of the week?

Thanks, Andy. Love your support. Fortunately, they're all sitting in the back.

Well, thank you. My name is Heather Flanagan. I'm the Executive Director and Principal Editor for IDPro, and with me is Elizabeth Garber. I'm Elizabeth Garber, and I have quite a few hats, but I've been delighted to work with Heather at IDPro working on the body of knowledge and this job specification work over the last year. So the job specification work has been a lot of, give me the clicker. You can have it. I want the clicker.

I'm sorry, Heather. Give me the toy. You're the boss. Thank you. All right. The obligatory agenda slide. So this project started a while back, mostly because we were listening to people offer some very legitimate concerns amongst themselves. They're like, hey, are you trying to hire someone? What do you ask for?

I mean, how do we actually get the people that we want? And in most large companies, you come up with some vague idea of what you want, then you give it to HR, and then who knows what the heck they do with it. But it doesn't always come out the other side in anything that you find usable. And so we're like, well, this feels like something we should be able to help with. We have a lot of experience, a lot of identity people.

So, surely, we can make this better. And that's part of what IDPro is about, is helping the entire industry and helping the practitioners have a better community and just a better industry to work in. So we're going to talk about that. We're going to talk about some of the challenges that we've seen leaders face in this world. We're going to go through the job description library. And then we're going to talk about some of the other ways that people can be learning about the industry, especially if you're hiring juniors. How many of you hire juniors? You're the best. Okay.

But first, we must get through the obligatory. So what is IDPro? How many of you know what IDPro is? I love this. You guys are really good with raising your hands. Okay. So IDPro is a nonprofit organization that came about in the end of 2017. So we've been around for a while. And we've got somewhere between 1,200 and 1,500 members of the organization. We exist to support identity practitioners and to basically turn our beloved industry into something that's actually a little bit more formally recognized.

If you tell someone that you are a cybersecurity expert, they're like, oh, yeah, I know what that means. They don't, generally.

But, you know, they think they do. And that's close enough. If you say someone, I'm an identity practitioner, not so much. So we're trying to foster that, the ethics, the excellent, what happens in our industry and how to make sure it is recognized for what it does. Okay. So there's a lot of challenges that our industry has. For one thing, it's kind of ubiquitous, if you think about it.

I mean, think of, if you have, if your company has an online presence, you probably have an identity problem. In fact, you are an identity company. I don't care what you're selling. I don't care what you're doing. I don't care if you're selling kittens.

Actually, personally, I do care if you're selling kittens, because I might want one. But you're worried about who can access that website? Who's buying things from that website? How do you authenticate people? How do you manage the back end? Who can manage the back end? What's the access control look like? All of these questions come in. And suddenly you're talking about the field of identity. So that's great. You all have experience with this. You all know kind of what it looks like from the inside. But our field is a little bit icky right now, because we have a lot of interesting challenges.

We have an inordinate amount of technical debt. And I observe this, because one of the things I'm personally interested in is the issue of delegation. And I'm sure there's going to be talks about that this week. Delegation is a really, really difficult challenge. And let's say, for argument's sake, that tomorrow, or at least later this year, or sometime soon, the standards community comes up with the perfect standard that says, yes, this is how delegation is going to happen. This is how delegation chaining is going to happen.

You know, we have all of the protocols, everything that we possibly could need for it. How do you implement that? None of the tools will be ready to do that.

You know, they're all essentially turned into legacy right then and there that you still have to maintain that the best standard in the world isn't going to help you, because you've got this technical debt. You have the challenge of, okay, so where does identity sit in your organization? It probably kind of depends. I come out of a research and education background, and I used to work for Stanford University. Before that, I worked for Duke University.

And identity, well, there were the identity people that worked in the admin IT that supported the HR systems, that supported the student systems and whatnot. But then there were the identity people that supported the LDAP directory, and supported the Kerberos environment, and supported the IDP. And then there were the identity people that worked within different departments, right? And there was no cohesion to that. The organizational alignment around identity kind of didn't exist. And I would like to say that that's a completely unique use case. That doesn't happen anywhere else.

What she said. Okay.

So, essentially, what it boils down to is our industry, as ubiquitous as it is, is a little on the immature side. It's kind of a preteen. It's a preteen that thinks it ought to be 30 years old. We've experienced those before. And as much as we love them, and they're very cute, there's still a lot of growing up to do. And that starts to bleed into, well, how do you get there from here? Because you have to get there from here. A lot of identity has been, in many cases, kind of best effort. Except for certain verticals, like finance. In most other cases, it's been a no, no. We have best practices.

Yes, you should do those. But you may not actually need to go through any ISO certifications. You may not need, you don't have any compliance issues. Because there's nothing you have to comply with. That was then. This is now. Where suddenly, if you are based in the EU, you have more than enough regulation you have to comply with. The general data protection, GDPR, certainly touches on that. But so does NIST too. So does EIDAS. You've got more regulation than you kind of know what to do with here. And suddenly, everything has to comply with it.

On top of being kind of an immature industry that hasn't pulled itself together yet, on top of companies that don't actually have cohesive IAM roles and departments, on top of the fact that you've already got all of this technical debt that doesn't know how to respond to the world of these compliance needs. But wait, there's more. Okay. So we want to fix this. Of course we want to fix this. And what a lot of companies do is like, okay, when they actually have the opportunity to hire someone, they start saying, but we don't know where to find the qualified candidates. Where are they?

What do they even look like? And we know we have a position, but we're not actually allowed to hire for it. That's one that just gets me every single time. The number of times that when I worked for a traditional day job, and they're like, yes, you have an open position. You can post it.

No, you can't hire. It's just out there looking pretty. Why do I have it posted?

But again, that's not an uncommon situation. And for those brave few that are willing to actually hire less experienced people into roles, it's like, okay, well, where do you even get these people trained? All of these things feed into an industry that could use a little bit of help. Leading us straight to, all right, well, how do you describe what help you need? And that's where the job spec library comes in. It is. Let's move on to the next slide.

So we are building or have built, it's currently in beta and it is available on the IDPro website, and we'll share a link with you at the end, a job specification library that helps hiring managers find candidates for open roles. So it gives a sort of a baseline set of expectations for different types of roles in the industry. And it helps candidates or developing professionals really look at what kinds of identity jobs are out there and build their own development strategy. So that's the goal that we set out with. Moving on to the next slide, please.

Now, there are, there were a lot of challenges in building out the library that exists on the website today. So for example, we have a wide variety of naming conventions around the industry when you start to actually read job specifications, you might find something that looks like an analyst over here looks really different.

Over here, same job title, really different role. Same goes for whether you're talking about policy jobs or technical jobs, data science jobs, what have you. Those can be really different. There's also structural differences that pop up. So sometimes you've got IM jobs showing up in cybersecurity. Sometimes they're showing up in IT. Sometimes they really live in product or all over the organization, more likely. There's a lot of jargon in identity job descriptions. And that jargon is changing all the time because we keep making new jargon. I don't know if you've noticed that, Heather.

Oh, just a bit. Because we're trying to, on the one hand, sell these cool products. And so we have to differentiate these products. So we'll call it something shiny. That's not helping. Yes. We need a new name for this.

And then, of course, one of the things that I worried about when we were pulling this together was that we were going to put out their job spec baselines that were actually counter to the objective of increasing the diversity of people who are applying. Because if you put out there that in a job spec, this level of qualification is essential in one, you might accidentally permeate that across the industry when actually some folks are very happy to bring people up to level on one particular component. So I was pretty thoughtful about that.

And when we pulled this together, there's a big headline at the top of each job description that says, you know, you need to vary this according to your needs. And we've tried to limit the extent to which we've said things are absolutely essential or you need five years of experience or what have you. So it's really an adaptable framework. Go ahead. So how did we approach this? Gathering lots of job specs. So I kept an eye on all of the specifications that were coming up on the jobs board that were showing up on Google. Gathering them up, reading them. So then organize them into archetypes.

I did go back and forth. Me and AI, we developed our relationship over this period of time. Tried to pump things that I was finding in there. Get various different AI feedback on how to structure things.

And, you know, it's kind of tough. It's kind of tough. Didn't agree a lot with the output. And it definitely needed a human overlay. So that went around and around in spirals for a little bit. And then now we have an initial library of a few different functions with baseline job specifications. Now we're really in putting it out there phase and gathering feedback. And we'll be looking to, you know, as we learn more about the industry, we might add more job specs. We might edit them. The ones that exist today. So the ones that we have now can be grouped into kind of these themes.

We've got business and product strategy roles. Architectural roles. Like engineering development roles. And IT operations style roles. And they're broken up into measurable outcomes, KPIs. The skills to do the job, which I used to say, key skills. And then someone said, no, people think you're going to mean key management. So the word key should not appear in these. And then we've got responsibilities and the knowledge and qualifications. So each job spec has those components to them. And these are the ones that we have to date.

We've got a program manager role, which is business and product strategy. We have a specific role for customer identity and access management. A specific role for privileged access management. Two architect roles. One senior architecture role and another one that is the same role plus standards architecture. We've got a senior developer role in IAM. IAM operations. An administrator role. And we've also added a more junior analyst role, too, since I made that list. Did you want to go into learning paths now and then jump into looking at the job specs? Yeah. I'll give this back. Yes.

Because then we don't have to bounce back and forth between things. Sounds good. I'm going to give you, I hate QR codes with a passion. But I did put one in the slides at the end so that you can get to the specs a little bit more easily. Because I see some of you taking photos. Okay.

So, before we get to that, I wanted to do a brief digression into, all right, how are people supposed to learn more about the industry? And one solid way, of course, is the IDPro body of knowledge. This is a Creative Commons licensed body of material written by and for identity management practitioners. At this point, we've got about, what is it? We have about 45 articles on there. A lot of it is just core material. It doesn't need to change because it gives you the foundations of what identity is about.

Like, okay, if you think about it, identity at admin time versus runtime being different concepts in there. Things about tokens and what are they and how long should they last? And different ways to look at IAM architecture.

I mean, there's a lot in there. It's pretty darn useful.

We've had, since the first articles were published in March of 2020, I want to say, 51,000 downloads, which is pretty cool. There are, you can look at it online via HTML or you can download PDFs. If you want to download the whole thing in one fell swoop, no, you can't do that yet. I have to keep putting together the PDFs to do that and that's hard. These are just some samples of some of the articles that we do have on account recovery, on MFA, on non-human management.

I mean, there's a lot of really solid material in here. The way it works is someone says, I want to write, and I say, brilliant, what do you want to write about? And they send me a title, they send me an abstract, and we iterate on that a little bit. Eventually, they will either find someone to write with, because I do strongly encourage people to co-author with someone, and when they're ready to submit it, they submit it to a system that was designed for open access journals, and I find two peer reviewers.

The peer reviewers go through, this isn't a blind review, because often there ends up being these long conversations to work on terminology or document structure or whatnot. But the peer reviewers do their job, and they come back and they give me one of four things that I'm supposed to do. I'm supposed to just accept it as the best thing that was ever written, and don't change it. I don't think that's ever happened.

It's good, but it needs some minor modifications. It's good, but it needs some major modifications, or good God, don't publish this thing, which has also happened. All of these things have happened, except the first one. Once that has iterated a little bit, then I have two more groups that I have to check with. I have to check with the Body of Knowledge Committee, and I have to check with the IDPRO board, but they only get to answer two questions, one each. The Body of Knowledge Committee is supposed to answer, okay, does this fit in what we're trying to do in the Body of Knowledge?

And sometimes they say, it's a great article, but it should be a blog post, which is fine. We have a blog. We can do that. And other times they say, it's really speculative, and we don't, the Body of Knowledge actually isn't meant to be bleeding edge. It's meant to give you core material that's well understood and well known. So those are things to consider.

The board, they have, they're supposed to be mindful of IDPRO's reputation. Are we publishing anything that would make us look stupid?

Now, they have yet to tell me, no, excuse me, they have told me at one point in time, no, this one shouldn't be published because we're not qualified, which was fine. That was an article on ethics. But that's their role. And then after all of that, I publish batches of articles three to four times a year. And we have since published some articles on ethics related to digital identity, but just not that one.

No, not that one. That one. That was one of the very early ones. And we had a board member who is like a tenured faculty member in the subject of ethics. And so she had really high standards. I wasn't going to argue with her. That was for sure. Okay. So that's like a source of material that people can go through and read or feed it to the notebook LM and have it read it to them, whatever they prefer. But we also have a certification that, again, identity practitioners put together by and for people who have two years of experience in the field. Only two. Only two.

There's 150 multiple choice questions. Occasionally we will allow this in person at a conference like Identiverse, but mostly it's online. There's nothing for, you should be familiar with what's in the body of knowledge. You should know what NIST 863 is, though you don't have to actually have the whole thing memorized in the same way that you should know what OAuth is, but I do not expect you to read 50 specs to understand the whole world of OAuth. That would be a little bit unreasonable for a two-year-old. The hardest part of the exam. Can anyone guess what the hardest part of the exam is?

SAML is a good guess, but it's wrong. Regulations is another good answer, but also not correct. Put your own name at the top.

Now, there's someone who passed kindergarten, but also no. Is it logging in? Did you turn it off and on again? No. It's the proctoring, because we don't proctor the exams, but they are proctored by a company that does this for a living.

Oh, my gosh, they are so strict. I don't know about you, but if I'm thinking, I might look up and just gaze, empty it.

No, you can't do that. No gazing at the ceiling. No extra devices around you. No water. And they want you to be able to move the camera around so they can inspect your space.

I mean, literally the hardest part of the exam has been the proctoring for most of the people who take it. Be warned. Unfortunately, all proctored exams are like that. It's not this one company. They're all extraordinarily challenging to do online. But there we go. We take this pretty seriously. Okay. So what are the objectives of a CID Pro exam? We don't call it the CID Pro, just so you know, because that's the name of a medication. And folks might get confused.

So there's really five things that we're after to just evaluate as to whether someone has the knowledge and experience to be able to talk about these things sensibly. One is just the basic elements of what does it mean to have an identity solution? What are the parts of an identity? What overall big picture, what does an architecture look like? Next one is, okay, how many of you know the difference between an identity and an identifier?

Yeah, that one's tricky, but you better know. We have questions to make sure you understand the concept of security. Do you know what a threat model is? Could you start one? That would be in there. Are you familiar with rules and standards in this space?

Like, can you actually spell SAML? Very important. Can you spell HIPAA? We actually just had a really good article published on HIPAA, too. That was one that came out April 23rd of this year. And then there's operational considerations, things that you would have to think about when you're just trying to run this stuff. Some of this is a little bit more suited to people who are business analysts. They're more comfortable with that. Some of it is a little more suited to DevOps. But the IAM industry spans all of it. And therefore, all of it is in here.

You do not have to pass with every question correct. You just have to get enough. And I'm not going to tell you how enough is, how many enough is. Okay. There's a couple other things, you know, as you're putting together training programs for the people that you're about to hire, and we'll get back to the job descriptions in a moment.

So, one is a lot of the companies that join IDPro as members, they actually form study groups within their companies, which is really cool. There's one that just started up with us earlier this year. And they're using it almost like a team building exercise, where they've got five people across their IAM department, which is not small, who have come together and said, okay, I'm going to learn this section. You're going to learn that section. You're going to learn the other section. And then we're going to quiz each other and learn together.

And then collectively they will, well, not in the same room because proctoring, but, you know, they will take the exam at about the same time and see how it goes. So, that's one solid way to do it. They're on the website for people who want to go down that path. There's the CIDPro Global Exam Candidate Support page that includes things like, okay, what is the high level blueprint of what you're trying to learn? There's a lot of information on the website. If you're an IDPro member, how many IDPro members do I have? It should have been everybody in the room, but okay.

We have a members only Slack instance. And, man, that is the best resource I have ever encountered.

So, Sebastian, do you have a comment? But you're going to need a microphone for it. Okay.

So, I didn't pay him to say that. And for people who are looking at the recording later, basically he said this Slack channel is awesome, amazing, and something he uses every day for his business. It is something I use every day as well because I can ask questions. There's about 120 different channel options, right? It's not like everything goes in general and you get spammed to death. But if you're interested in IGA, there's an IGA channel. Hang out there. If you're interested in authorization specifically, there's an authorization channel.

If you're, you know, you need a distraction and you need cat photos, there's Identipets. We have that as a channel too. But it's great. If any questions you can think of, any help you want to get, that's the resources just. There's also the EIC channel where you can have a running commentary with friends. Yes. And there's only a little bit of snark, really. Only a little. Okay. Hopefully Martin isn't listening.

So, there's all that. But if you want to actually outsource this, we recently signed a memorandum of understanding with a company called Identitrain, which is forming up to actually help people learn about the identity space. And they're doing it with an eye towards can we help people actually learn enough to pass the CID Pro? That's like their bar, which will be pretty cool.

But wait, there's more. And since we're at EIC, right, we literally on Friday signed an MOU with Cuppany or Kohl such that there's sort of mutual discounts to each other.

So, if you are a Cuppany or Kohl member where you're getting some of their materials and whatnot, that's a great place to learn from what they have, from the consultants they have. As an ID Pro member, you'll get a discount to that. And the reverse is also true. If you are a member there, you can get a discount for your first year of ID Pro membership also.

So, there's lots of different ways to level up on skills. And with that, I want to say thank you. All right. You ready? Everybody got their cameras? That's where the job specs are currently. Anyone can reach them. They're not password protected in any way. I do want to emphasize, and Elizabeth is going to emphasize it again as well probably, these are templates. They're a place for you to start. I don't know what your organization is like. I don't know what your culture is like. I don't know what's actually most important to you.

In some cases, what we consider optional, you will consider essential or vice versa. So, take these as a starting point and adapt them to what you need.

With that, we can now switch over to the ID Pro website. Ta-da! Nice. That was a beautiful transition, guys. Thank you. And scroll down the page and figure out what ones do we actually want to look at?

Now, we have some time. This is where it's going to get a little interactive.

So, if we want to click on any of them and actually look at them together So, I'm going to make an executive decision and I'm going to say we should look at the entry level IAM analyst. Oh, boy.

Oh, yeah. Okay.

So, quick reminder is that this is being streamed and recorded, which means if you want to talk, wait for the microphone. I mean, I can repeat everything that you said, but if you have a soliloquy, I'm not going to catch all of it.

So, better to wait for the microphone. We'll get that to you. Okay.

So, I'm going to go ahead and start. I'm going to make sure we have a microphone. We have them right here. Okay. Yeah. Are they on? Yes. These are professionals. I know they're professionals. Okay. All right. I'll do roving mic as well.

So, we have measurable performance indicators at the top, and in this case, the kinds of things you might be measuring would be whether users have access. So, this is systems analyst role. Whether things are happening in compliance with internal policies. User satisfaction. Incident volume. The key skills, sorry, not key management. Not key. Not key. Essential is good. The skills to do the job, which you may develop over time, would be simply a strong background in IT. This is meant to be an entry level into IAM.

So, background in IT. We're looking for skills in analytically looking at a problem and solving it. Attention to detail. Security mindset. Customer focus. Collaboration and willingness to learn. I'm going to pause there, actually, and see if anyone. Yeah. Oh. Okay. Glad. Get him the microphone.

Oh, yeah. Yeah. This is my job. Okay. While you're doing that.

So, one of the things I want to say about strong IT background is a friend of mine, Lance Peterman, works for Dick's Sporting Goods, but he's also an adjunct faculty at the University of North Carolina Charlotte. And what he does there is he teaches classes on identity. And you forget kind of how much you just sort of absorbed as you're in this industry. Because when he's talking to his students and say, okay, so, the backend server, and they're like, what's a server? Right.

You know, having to actually, he has to stop, step back, and explain what client server architecture is. He has to explain what DNS is and why it's always DNS's fault, except when it's BGP's fault. Right? Because they don't know. They have none of that background that we kind of ended up having to learn.

So, that strong IT background is actually really helpful. Even at the beginning level.

Vlad, go ahead. So, yeah. Thank you. Sorry to be first, but thank you very much for putting it together. I haven't seen it yet. Thank you for being first. Anyway. Thank you.

So, really, I understand what you're just saying, but I am not a fan of using the word strong. Because it's not measurable.

Like, strong for whom? What's that? I would say that I met a lot of people who went to this industry, right? Yes. And almost 90% of them were with the strong IT background. But as we mentioned many, many times at this conference and other conferences, it would be very good to have people who are interested and maybe not necessarily know all the details and names, but their interest in the industry getting from outside in would immediately, as soon as they see that, they say, like, I don't believe I have a strong background.

A lot of kind of, you know, Ian was talking about that, like, how we really hate ourself for not doing something. I would say I'd like to use more encouraging.

Again, I'm not an English major or even English native speaker. But maybe encouraging, especially for the entry job, would really help when it just describes on the top. Thank you. What do you think? I like that. I like reducing the value-laden words wherever possible.

So, I think that's something for me to take on board. Any other thoughts, feedbacks on this? Hi. The question is, well, I could also discuss analytical. What is analytical?

So, in a sense of, well, you could describe I'm analytical, yes. But finally, you talk to me and say, well, he's just thinking crap.

So, I think every word on this page, some sort of can be discussed. So, I agree what is strong following your arguments.

Yes, I can agree. But what is the alternative?

So, I would like to have a discussion on what could be done better. So, saying strong, yes. But if you remove the strong, what do we do next? Sorry to be very picky on that, because I think the goal is to get it better in this round, right? The goal is always to get better. That's a really interesting point.

So, I understand where both of you are coming from with this. Yeah.

Yeah, you do have to wait for the microphone. I might get a second microphone so that people can... Sorry for taking your time, but I agree with... Here's the thing. I'm not discussing the word IT background. I'm discussing the word strong. Next to analytical, there's no strong analytical skills. It said analytical problem solving, okay?

So, my point is, again, I'm not an English major. The better is when we encourage people, when we include more people. The word strong immediately excludes a lot of people, not because they're not qualified, because they don't believe in themselves. And it's very often happened to people who just enter in the industry. That's why I would argue that probably some kind of a more encouraging and softer word would appreciate. But analytical is fine. People understand what analytical means, right?

I mean, you don't necessarily need the adjective, do you? IT background. I also like your thought about interest in IT. If you really want somebody who's really green, interest is a nice word.

So, I appreciate the comment. Getting my steps in. I didn't wear my watch, though. I think both are right here, because that's also the sales process, I agree. And then we have to sell our job, and we have to sell IAM, as I found out in our company as well, because there are not many people standing around with IAM capabilities, and thank you for making this great job here.

So, to structure it and then to deliver, to explain what it is, because for many people, it's just... And when they are in, they are so passionate, become so passionate, when they go through this journey, and then they see that there are so many different areas overlapping, you can find your spot here.

So, that's great, I think. Very true. Thank you. I got to say, I mean, I came up with the idea, but the entire implementation, she did it.

Oh, thanks. So, if it doesn't work for you, talk to me. If it doesn't work for you, did we mention it's a template? Make it work for you. Yeah. I bet you you can. Should we go down into some of the functions?

Oh, yeah. So, each one has kind of headings and then subheadings, like this is one of the major themes of the role, and then the individual tasks. I've tried to be as specific as possible.

But, again, different companies will do this differently. So, you might find yourselves deleting entire sections where actually that does not sit in this department.

So, this one, we have identity management, which includes life cycle management for individual user accounts and identity governance, but that's just implementing policy rather than defining policy. Then we've got access management, configuration, policy enforcement, troubleshooting, and then maybe supporting with the performance of access reviews. I wasn't sure if conducting regular access reviews and auditing that process would be at a junior level at all.

So, one thing you won't see here is names of products. That's actually not something we wanted to touch with a 10-foot Ethernet cable because, again, for a template, if you require they have experience with Microsoft Antra, cool. That's between you and your gods, as it were. But maybe you want Okta experience. Maybe you want Salesforce. I don't know. I personally would kind of discourage that, especially for an entry-level job, because all of those tools can be taught. They can all be taught.

It's the underlying principles that actually make it make sense, and then you can apply it because, at some point in time, you're going to change products. I don't know what you're going to change it to. Maybe you'll stay within the Microsoft platform, but Microsoft will change its product. Eventually, you will change products, and your teams need to know the core of why they're doing what they're doing.

Yeah, there was a discussion before this event on LinkedIn, actually, and there was somebody who mentioned just the shared number of vendors that people need to know in this industry, and it kind of dawned on me that if you were putting in your job spec, you must be comfortable with Active Directory. You must be comfortable with SailPoint. You must be comfortable with da-da-da-da-da. You're really splintering the audience of people who have the skills you want down to the bare minimum.

So, yeah, I would definitely concur. Put something generic. And at the end of these, we do say familiarity with cloud-based solutions, for example. Any comments on these responsibilities before we scroll down and start looking at the next page?

Okay, let's scroll down and start looking at the next page. Okay.

Oh, we kind of need to back up. Oh.

Yeah, back up to the website, and then we'll pick another one to poke at. Oh, there's more. Is there more? Is it all in one? There's two pages here.

Oh, there's more. Yeah.

So, we have security and compliance, and this is more about monitoring, assisting, and incident management, ensuring compliance with, you know, it should be internal policy, as well as regulatory requirements. A lot of it is about security and compliance, a lot of assisting, a lot of, you know, learning on the job for the kinds of things that your more senior peers would do. And then we have knowledge and qualifications, which does not, or we should not find specific products.

But you do see reference to familiarity or awareness of some of the protocols that are out there, some of the standards and protocols. One of the things that people still do, and that's try and invent their own crypto, you should never do that. Don't ever invent your own cryptography. Not even my own meme coin? Don't do it. And that's actually where coming up with awareness of IAM protocols. Don't reinvent wheels if you don't have to.

So, while we don't want to emphasize products, we do want to emphasize what those products are built on, so you don't decide, oh, man, someone needs to log into this website. I'll just use an Apache plugin. What could possibly go wrong? There's better ways, and just making sure people know how to spell these particular things helps a lot. Before we move on to another one, one thing I'd be interested in putting to the group is what kind of junior, a lot of you raised your hand and say you hire juniors new to the industry. I'd be really interested to understand what kind of jobs those are.

Are they the analysts, the admins? Are they, or are they on a different side of the identity space?

So, in my experience, the junior folks that we've hired have tended to actually be junior engineers and not with any type of specialty in identity. This actually kind of mirrors my own experience, and I think a lot of people in the industry is that we didn't start out as identity experts.

We sort of fell into it because somebody needed to go do identity, and I've had actually pretty good luck getting talented engineers who can, like, see through the connections of a system and, you know, are eager to kind of learn that and apply that into the identity space and, importantly, identity-adjacent spaces, because, like you said in the intro, everybody is an identity company in some way, because identity is a problem that you have to solve. And so, again, my own personal experience is not actually hiring specifically for identity, but hiring for sort of the related skills.

In my case, it's been a lot of, like, hands-on engineering type of roles that I've been trying to fill that definitely touch and have to know about and learn about the identity side of the house. So, one of the first things I've tended to do is throw people at IDPro and say, there's a lot of good stuff here, go there. Are you hiring senior software engineers? I'll let you hold on to this so you can answer me. Senior engineers and then giving them an identity-related job, or are you talking about junior engineers?

This is, I'm talking about junior engineers in this particular case. Thank you.

So, it's kind of, how many of you actually went into identity on purpose? Nobody. Yeah. Sorry. There was one? Where? Where? I want to see this. My example is very different. I work for a bank, and in our bank, we do have a lot of fintech, as you can imagine. And what's interesting is that some of the people who came to internships, nobody hired an internship for identity, but they're hiring internships for fintech. And when they, one of the persons, this is a real story, one of the persons got real trouble to get access to anything.

You know, the problem was a certain last name had certain characters which are not standard. Let's call it this way. I'm not going to go in details because it's all PII. In English.

And PII, I'm not going to say, but anyway, you understand what I'm saying. So, and the person came to us and said, like, what's going on? And we tried to explain, well, you know, there are some, and I would like to learn more about that.

So, the person switched from the fintech analyst position on an internship, started to get more into what identity is all about and completely switched to the whole field of helping other people as it started as a tech support, more or less, on the, you know, operational problem was identities and then started to learn more and more. And now this person is, you know, getting really, really well, but it was hired as the junior on fintech switch to, you know, that is a story. That's what happened.

So, this is a person inside your organization who found an identity related problem. As an intern who was, who became a full time related to identity, which is. Because they found a problem they really wanted to solve. That's correct. Yes. Because it's exciting when you find these problems. Thank you. And I work for insurance company and our story, we tried to hire people from the outside, like IM people, and it took a while. We understood it's really hard. It's okay. It's just sometimes you are lucky to get.

And we also tried to hire or to teach internally to promote the job offering within a company because we are, we have about, okay, not all of them are IT, but IT people, we have about maybe 2,000 IT people in our company. And response was also very low.

So, people just. And we ended up that the best way work, which work was to hire junior with very much, as you said, just to get people who are interested, who are looking to learn things and to teach them like through working, through just throwing them into real practical tasks. And they become just superb engineers and they grow and they move to more advanced positions then. And that's the way we found the best working for us at the moment.

So, because out there we just can't expect anybody coming in. I suspect we have.

I mean, I talked about this problem a little bit to start. You go to someone and you say, I work in cybersecurity. And they're like, oh, yeah, I know what that means. They don't, but they think they do. And that's cool. But then you go to someone and say, hey, I work in identity. And they're like, right?

So, finding someone, oh, you want to work in this field. It's great. It's awesome. They're like, I have no idea what you're talking about. I wonder if it would be a fun thing to do to start some of these with like a use case. This is the type of problems that this person solves. I love that idea.

Yeah, we could play with that. We could play with that. I'm a librarian, by the way. That's my degree. I'm supposed to be a librarian. That didn't quite work. And I fell into working for an ISP and they said, here is a Galacticom bulletin board system. Can you run it? I don't know. Does it come with a book? I know books.

And, I mean, that's ultimately how I ended up as an identity person because the only thing you were actively doing was, does this person have access? What group do they belong to? Do they get to be an admin? Do they not? How do you change all of that?

I mean, it was literally an identity role, but that's not what we called it because it was a long time ago. I just dated myself so hard. How many of you know what a bulletin board system is?

Three, four. Wow. Okay. I'm old. Damn. All right. Anything else on this one? Not for me. Anybody else? No? All right. Let's find another one. Yeah. Can we navigate back to the list?

Thank you, team of professionals. Thank you. All right. Does anyone have a strong preference for one that we cover next or should I just pick one? I'm just going to pick one then. I'm going to pick standards.

Oh, that's fun. And architecture identity standards because standards are my favorite thing. There you go.

Now, so for this one, I asked all the identity standards architects that I know, can I see your job description? And none of them had one. So instead I had conversations with them and we talked about how the role is basically built upon the role of the architect and then we have a few key elements in here where we highlight the role that they play in developing industry standards. So if we have any identity standards architects in here, I mean, Justin, I know you probably have feedback on this one. I don't know if we have others.

We did, but he ran away. Mark ran away. He ran away. So what are the performance indicators? These are generally applicable to architects themselves and I know we have some of the best around sitting right here up front.

So Hutch, I'm nervous that you're not going to like it. So we have system scalability, resiliency, reduction in security breaches, fraud, minimization of technical debt, and then in this case, because it's a standards architect, authorship of identity standards in a recognized standards body.

Oh, no, it says key. We have to get rid of that. Skills to do the job unrelated to key management. Stakeholder management, ability to influence senior leadership, ability to influence at an industry level. So that again is a new one for this particular role. Collaboration, cross-functional and cross-industry working. Change management, team leadership. There's a lot of skills required to be an architect. Strategic planning, budget, design patterns, ability to track the market, stay up to date on emerging threats, technologies, and then obviously strong written and communication skills. Pause.

I love the fact that even standards people have to understand that there are budget constraints. I mean, so that's worth pointing out. There are definitely some things in here where like things like budget management and team leadership, this just comes from having a senior role and it's in here, but like invited to like remove that if this is not someone who actually manages a team of people or who writes the business cases or runs the P&L. First of all, I love it.

Oh, yay. Thank goodness.

No, I mean, I think it's a fantastic place to start and I would keep pointing out that at the top of these it says, tailor them to your job. Did we mention it's a template? Yeah. So architecture identity standards like for us, Mitsubishi, Mitsubishi doesn't actually want us authoring identity standards.

However, they love for us to be involved in the standards organization to be able to report on what is going on. And somebody who is an identity standards architect in our organization is somebody who's like constantly going through our systems, going through our patterns, going through our, what we call ASDs, our architecture solution documents, and making sure that the standards that at least the ones that we've adopted from the industry are being adhered to. So it's not as, it's not so much, hey, I got this great gig where my company is going to pay me to fly to Bangkok and go to.

IHF meetings. Yeah. It's not as sexy as you think.

I'm just, I'm just going to put that one right out there. Or Iceland for OSW. I would love it, but that's not what they want. They want us, it's like, can you participate on the phone? That's like, yes, I will get on at three o'clock in the morning and sit through the stuff in Bangkok. So it's more of an internal thing, but it's still all based on standards. Great. I think you'll see that reflected a little bit as we scroll down. But I would love to know if you want some of these other sections rewritten.

I love the standards development process, but I can assure you that the conference rooms in Bangkok look exactly the same as conference rooms in Berlin hotels or conference rooms in Seoul or anywhere else because you're in a basement with no windows. All right. Let's roll. Nope. We're going to have another comment. Maybe one more comment on standards. If we speak about standards, which you develop for your business specifically, these are not always the same that you see as external or industry standards. And that would require that you understand well enough your business and your needs.

So it's not too high or too low because it must be relevant to the business so that your business can run efficiently also within budget constraints in that sense, not only if you manage people, but also so that because real life is not perfect. So you need to set those standards properly. So I think that that spin could be added here as well. You work within the context of your business so you understand it well to define the standards for you. Yeah.

So this role is definitely intended to be, and this is another reason to add the use cases at the top, this is definitely intended to be someone who participates in industry standard setting such as the OpenID Foundation. I just saw Gail walk in somewhere. I didn't hallucinate you. That's great. I don't know. This cold medicine is really good. Okay. So could we please scroll down a little bit? So we have a number of different themes of roles.

So one is, oh, I didn't see what the heading was at the top there. Oh, what did I put? Designing the target state architecture. So this is about defining, embedding industry standards in that. So that one is critical to pull out from the standards architect role. Evaluating trade-offs and minimizing and managing technical debt. The target state roadmap with engineering and other partners. And then multi-channel design patterns and continuous improvement.

We then have delivering the target state, which is more of a supporting role, because obviously the architect is not the engineer or the project manager, but they do need to stay engaged, generally speaking. Could we scroll down, please? So this is about supporting the scoping of the design, thinking about the deployment model, maintaining and optimizing any documentation, and then ensuring security and privacy by design. We also have a piece in here around application management and application security. And then standards development. This one is very specific to this role.

So this is about engaging the community internationally, participating in thought leadership and contributing to standards development, if not authoring them themselves. I'll pause here. Thoughts? Feedback? Do you wish you were a standards architect? I do. Yeah. Okay. All right. Could we scroll down a little bit more, please?

But wait, there's more. There is. So we have risk management. So these are all pretty generic and across a number of the different leadership roles. So risk management, mitigation, ensuring compliance with both internal policy and external regulation, engaging in incident response where necessary, financial leadership, people leadership. And then the knowledge and qualifications for this role, I believe is quite long. And it was, you know, there are words in here about strong, because this particular role does require a pretty deep background.

But if there are ways of making it less evaluated, that would be helpful. Could we scroll down a little bit so we get the full list of knowledge and qualifications, please? Perfect. Thank you. So we have foundation in identity and access management technologies, experience and expertise in IAM protocols, such as those listed in IAM and cybersecurity project concepts, experience working with IAM architectures within a diverse IT environment, deployment models, regulatory requirements and standards, and then probably in this case, professional qualifications.

Like the CID Pro, you know, we sort of had to put that in there. Is that the right term or is that the term for the medication?

No, CID Pro is the medication. CID Pro. It has something to do with intestinal health. It's how you write it? Is that what we're saying? No. Okay. What does the medication do? We'll talk about that later. Okay. Okay. Any other comments on this one?

Gail, any thoughts on how to be a standards architect? You said that right when she ate some pretzels. Be a friend of the OpenID Foundation, Gail says. All right. Do you want to look at another one?

You know, well, no. So when I'm not, ID Pro is one of the many hats that I wear. Most of my other hats actually have me involved in standards development organizations as working group chairs or community group chairs or interest group chairs, or for eight years, publisher. It's been a lot of really interesting roles and a lot of ways to see how standards development works in that type of open standards body. And one of the skills, I'm not sure we exactly put in here, but you can't successfully work in standards development if you don't understand the concept of consensus.

I mean, it's this really critical word. And consensus doesn't mean I win. It does not mean that. Consensus means compromise. When you put together a proposal and you submit it and say, hey, I have this great idea. It's perfect. Okay. That's problem number one. It is not perfect. Because you're going to have people that will come in and offer different suggestions, offer different ways, say, you know, yes, but in my use case, it's something different. You have to learn the art of compromise and the art of seeking consensus as opposed to seeking to win. None of the standards work without that.

Now, there's a lot of different types of standards organizations. Open standards organizations are like the ITF, the OpenID Foundation, the W3C, where there may or may not be membership fees, but in a way it doesn't matter because all the work is conducted in the open. All of them have GitHub repositories or their moral equivalents that you can see, what are the issues they're trying to solve? Who's trying to solve them? What kind of debates do they have?

Wait, I have an issue and I want to add it. Go right ahead. You can do that. And so you get a lot more technical debate. And while there's still compromise from an industry perspective, it's a bit more balanced. Then there are treaty-based standards organizations like ISO or the ITUT or ANISA. And those are politically recognized. They're in regulations. You have to be like a representative of your country's delegation. And for the most part, the technology is cute, but that's not, you know, ultimately what they're after is political agreement.

And the technology will compromise on that in many ways, shapes and forms. So understanding that, understanding how to compromise, understanding how to find consensus in your organization, Sebastian has his hand raised, is actually a really important component of being a standards architect, whether or not you're an author on a paper or just listening. I love engaging in working groups as I'm putting on like an anthropologist hat and seeing the way that different groups achieve consensus. It's so much fun. Sebastian. Did you just say ANISA? Yes. Like the European Security Agency.

May I just ask for a show of hands, who of you guys here does know ANISA? I know it. Bummer. So who of you guys lives in a EU country? You should really know ANISA. You should really, really, really know ANISA.

It's, from my perspective, one of the few EU organizations where I feel that my German tax dollars, no, euros, hopefully, are really well spent. Because they really do a great job of compiling security, general security related material and give great guidance. Especially if you guys happen to work in public services or anything that is close to public services, ANISA is a great resource. Look it up. It's really, I'm so sad that nobody seems to know that one really good EU institution. Apologies for interjecting here.

Thank you, Sebastian. No apology. Thank you. And to think, you didn't even have to pay me to say that. So you got an opportunity just to really. How many of you have heard of NIST?

Okay, then. If you're familiar with NIST and you live in the EU, you really should be familiar with ANISA. No judgment, though.

Oh, I'm judging. Oh, okay. Nicely. Nicely. All right. I think we have time for one more.

Actually, I think we have patience for one more. We've got about 30 minutes. All right. Would you mind a team of professionals going back? Are you raising your hand over there? Okay. I'll walk back. That's cool. Steps. Hi. Hi. My name is Stefan, and I come from a company that works very different. I saw in your standards. On my card, I wrote I am solution architect, because my company, it's you say you put all things together. You put the technical part, the business part, and the governance part all together in one EM standard architect. On our side, we separate everything.

We have the security part with PAM in one organization. We have the business architect, BA, business architect, and governance in one other structural org unit. On my part, I came from the DevOps development and operational, and especially in our company, we have divided the identity part and the access management part, the account part in two different EM tools. We have many problems to speak together with two tools in the DevOps.

In your description, it looks so easy putting all together, but in our world, it would be the hell on earth to get all pieces together and find a combined strategy and talk with each other over so many structural organizational problems. So, general question, what would be a tip for an organizational like our to fix these problems, to come to this thinking in job structures and in this environment, I would say?

So, if I understood what you said correctly, it sounds like your particular organization is incredibly siloed. Your job descriptions aren't going to fix that.

I mean, the closest, you can't hire to fix a structural problem in that manner. So, anybody that you do hire is going to bump up against some real interesting challenges. It's almost like you need to have a completely different conversation, not necessarily, I mean, with your senior management, certainly, but with your peers and say, hey, do we have an idea amongst us of how we could solve this? And then present that to your management and say, this isn't working very well. Here's how it's not working. Here's how we suggest you fix it.

What that looks like is why I say talk to your peers about it and see what together you come up with, because I can think of a whole bunch of different things, but I don't know what would work in the culture that you have. So, I would start there before your next hire.

Yes, actually, I had very much the same thought, because I looked at the descriptions, only those, and I thought about my own job, and I'm already at a mixture of things that are in here, and of course, it's a template, and it's kind of a standard, so that makes sense that we don't fit completely, but I was wondering as well, and I completely agree that it's a management thing as well, an organizational thing, and like you said as well, some IMs are more in the teenage phase, trying to mature to a different level, but of course, you're looking for help for that, and so maybe some sort of segregation of duty from the standards point of view from an organization like yours, saying maybe better don't mix these kind of things in a job together, so that you can actually rise to a higher maturity level, and not being stuck in doing, I don't know, incidents, tickets on one side, and trying to solve the complete architecture of a company on another level, because my own experience, that is really hard.

Yes, that's a good point. So, we've talked about designing future state, we've talked about junior roles, you want to do operations or building? There's another couple at the top, which are more product-oriented.

Yeah, that's true. Any preferences? Operations, down we go. Let's do IAM administrator.

Okay, so this one, let's see, so we have performance indicators of, this is pretty similar, I think, to the analyst role, actually, but we have user access, incident volume, compliance, user satisfaction as performance indicators to do the job. What makes it different than an analyst? What makes it different? I think it's more, oh gosh. I think it's the operating a secure environment. I think it is.

I think that's probably the main area where you would see difference, so that's about monitoring the environment, a little bit of IGA developing and implementing IGA frameworks, ensuring security, compliance. I think it's somewhat similar. Some of this stuff is actually a little bit new to me as well. We have a problem, did you say? Vlad? I'm doing it right now, partially. I want a people skills here somewhere, like people skills. People skills?

Because, I mean, when you are an IAM administrator, you're constantly dealing with a situation when somebody is not happy. Yes.

Like, usually, like last year, I did the presentation, this beautiful conference, and I was specifically talking about that, that IAM administrators are visible in organizations only when something happened. If nothing happened, they're invisible.

Well, isn't that true for all of IT? No. Some IT people are more visible because you, you know, want, let's say, for example, if I want a bigger screen. It's because you're not happy, and you want a bigger screen.

No, no, no. It's because they allowed me to do that. It's not because I'm not happy. It's because it's, you know, or bigger computer, whatever. My point is, in particularly IAM administrator, ability to deal with user, with issues, requires not only technical, but also people skills. Yeah.

And I've never seen a successful IAM administrators who cannot talk to business users in normal language, you know, and that is a part of the story, and also definitely ability not only to talk to people who are not happy in terms of users themselves, but also their managers who are constantly calling you and say, request came three hours ago. Why the person hasn't have an access yet? How many times that happens to everybody, huh?

You know, in operations? Yes. I think this is great.

So, I think I would be very, very, and if I ever hire someone for IAM administrator job, the first question they're going to ask them, what you're going to do? How are you going to deal with this situation? Forget about technology. Thank you. Thank you.

We have, Justin stands up. Sure. I think we have, so we have user satisfaction. I think key skill and interpersonal skills is probably one to add, and we do have something under life cycle management around troubleshooting and support. Go ahead.

So, I want to push back on that, but only slightly, in that I think that it's a vital thing for your IT organization to have people skills, but I've been in way too many companies where you have people whose job it is to be the people skills for the nerds, right? Right.

So, that's something that I have been pretty good at throughout my career is translating nerd to not nerd, and not nerd, importantly, back to nerd, which is something that I think gets lost in a lot of things here. You need to be able to tell the nerds why this is important, that this really does have a priority, and it's not just because somebody high up the food chain is having a bad day.

Like, no, there is an actual reason that makes sense. This is why you should care about that.

Now, all that said, yes, you do still need a certain level of interpersonal skills, but it's not going to be the same set of interpersonal skills depending on where you are. The type of interaction that you have, you know, back in my day was down in the data center is going to be very, very different than what you have in the boardroom, and it is not a lack of interpersonal skills, but it is a very different culture. It is a very different way to engage with that space.

So, ultimately, yes, but I think that if we put, you know, high interpersonal skills on a rec like this, people immediately think of the boardroom side. They don't think of, like, how are you going to talk to somebody about their, you know, 119-day uptime and why that's really cool for them, right? That is an important interpersonal skill that I have no idea how to capture something like that, so I have unfortunately nothing to add here, but that's why I wanted to push back to your point.

I think that there is interpersonal communication in everything, absolutely, but I think that we gloss over it too much in terms of thinking, oh, it's only to make things make sense to the not nerds. Like, that's the only thing that we value, and I think that that's losing something.

Yeah, but I think that's also easily addressed with a few more words because it's, you know, interpersonal skills that allow communication both with management and with your peers on other teams, you know, just I think throwing that in there suddenly makes you think a little bit about, okay, who am I communicating with? You might modify that if you're talking to end users, you know, but that would be part of how you would customize this to the role. One short personal remark to your part. Please let us stop to say that only the IT are the nerds.

My experience from my job is that in the business units are also business nerds. If they are talking about their processes, I have done nothing, and the other business department didn't understand nothing. It's not only IT, sir. It's a problem between IT and business, and many times we need guys who can translate between two worlds, but please stop. Not only IT is a nerd. That is true. Thank you. I'm a textile nerd. If you ever want to talk about wool, I'm your person. I'll talk about it all day. Alex? I always feel like nerd is kind of a humble brag anyway.

I mean, I'm looking at this and on the skills, and I know we talked about this a little bit earlier, but it seems like there's a huge service to be provided here. When I think about, like, why, so I strongly suspect that a lot of this is derivative of, like, let's go look at what job postings are out there for these titles, and then, like, see what is consistent, right?

But then I think about, like, the times I've done job postings, and I'll just be confessional here and say, like, I'm busy and worried about other stuff, and I'm, like, scribbling stuff down without actually doing the hard work of actually saying, when you talk about, for example, expertise in risk management, what would, like, what would define that expertise? What frameworks would you be familiar with?

Like, what kind of, you know, like, concrete skills would you have? One of the things that might be magical coming out of this effort is doing some of that legwork for the industry so that when people do a job description like this, they can actually say, you know, like, expertise in cybersecurity, including the MITRE framework, and, you know, like, actually getting into the specifics of what that means.

And then the other thing that'll be nice about that is rather than a word like expertise, which will, like, people will self disqualify, as was mentioned earlier, and it eliminates diversity and lots of other things from the Canada pool. You get into very specifics, like, if you said the MITRE framework, they'll be, like, oh, I had a class on that.

Like, cool, I can do that, right? And so I think one of the things that I would hope comes out of this effort, which is super cool, is, like, going down to the next level on each of these things and really defining what does it mean, like, what frameworks would you know? If you're talking about standards, what standards would you be familiar with?

You know, like, what bodies would you have worked in if you were, for example, a standards architect, right? You know, has been a member of working groups in OIDF, IETF, you know, like, getting into the specifics would be really cool. I like that. Thank you. We can do that. Did I just see another hand? No. I don't think so. Okay. Is there more you wanted to go into on this one? I don't know. We could quickly scroll down and see if there's anything to add, but I don't think so. I think we've kind of covered it. There's a whole other page. I learned how to read the scroll bar on the side.

Yeah, that's good. That's key skill, Heather. Thanks. I've worked in IT before.

Yeah, so here we do have user support. That's right. Could we scroll down a little more, please? So we do have some supporting change stuff in here, which appears in a few roles, and it may not be relevant for every admin or even many, you know, but a lot of folks in IT ops should be advising about the impact of change on their environments, right? So that's worth, and then they do need to implement certain aspects of a target state design. So I think we've probably seen a lot of the knowledge and qualifications before.

Anything else anyone wants to add or any of the roles that you really wanted to dig into? I don't know if we have patience for any more, but if there's any burning desire. I think this is good. You now know where to find them on the IDPro website. I did put them under membership, that thing, mostly because if you're not a member, I wanted you to think about it really hard. I do see some changes to these coming in the future, and I will announce those on LinkedIn, and I'll also announce those in our monthly newsletter and on Slack, as one does.

We'll be adding, I think, some user stories at the top, which might be a really useful way to differentiate your job descriptions from others and help people get a better sense of what you're actually looking for. You know, put in a real-world problem of, this is the kind of situation you're going to have to deal with. And I like the idea of expanding each one to go into a little bit more depth of, you know, for the manager, how would you measure this? What kind of question would you ask to elicit how this could work? That would be a fun thing to ask.

I have dreams of linking them to articles in the body of knowledge. I know that time is precious, but, you know, if we continue down this path, we might get there. Because I suspect there's also going to be people who come to these things as a way to, okay, I know I want to work in tech. What do I need to learn? And they just sort of coast job descriptions to figure out what kinds of things should they be studying. So that will certainly be a use of these in the future, I hope. Gail?

Forgive me if you covered this earlier, but do you have any plans on how to link this to academic courses of study? So as young students are going through their training, how they might think about leaving their university or college educations with the type of raw skills that would bring them into the industry? I would love to do that if only I knew how. Since there isn't, there's, it's so rare. I don't think it's unheard of. I think there's a unicorn in the world where they are actually teaching, you know, you can get a degree in digital identity related things.

But I think that's at one school in Texas somewhere, maybe? Yeah. But beyond that, how do I, how do I get this to the, what will probably be the computer science space? How do I get this to the MBAs who might find it interesting as well? I don't know how to get to those people to let them know that this is a resource that they might play with. If you have any suggestions? All ears. Okay. All right.

I think, so we've got a few extra minutes, but I, I'm hearing, I'm hearing coffee out there and a lot of you raised your hands about jet lag. So I just want to thank you so much for coming. This was a great turnout for today. I want to thank Elizabeth. Great work. Thank you. Great work. And if you have questions, we're here all week. Try to feel.