Speaker A My pleasure is to introduce this morning Zandy Rein Sagan. And Zandy is the chief operating officer at San Antonio Federal Credit Union. I've been a consultant there for a number of years, but the good news is you won't have to listen to consulting. The other thing is that Zanny wouldn't want me to say this, but it's important inside our organization for the managers to teach other people about what we call the leadership framework or Requisite principles. And Zany is an incredible teacher and insists that her direct reports take this very seriously as well. So this isn't something that's just going through the motions, but really lives it, preaches it, and occasionally will chastise us when we're interviewing people to say, make sure that you tell the people that you're interviewing for selection purposes that this requisite stuff is important because I don't want to have them in my office where I have to explain it to them. Like, you guys didn't get your job done, and now I have to explain it to them. So we take it seriously. So looking forward to hearing this story. I've not seen Sandy's presentation, so I'm looking forward to hearing how what did you say?

Speaker B Thank you, Michael. Actually, he hasn't seen it. No one's seen it because I'd rather do things more as a conversation than a presentation. I've sat through a lot of bad presentations in my life and so I try not to put people through that. So I like to start with a couple of disclaimers. First, that I am not an expert. I am just a girl who met Requisite organization when I first came to Fhcu. Actually, I was introduced to it before I was an actual employee, and I just kind of fell in love with it. And it's very much a part of how I lead in my expectations in my organization, like Michael said, and it's kind of what Fred said. I have a loving relationship with our. The second disclaimer is English is not my first language. I speak Texan. So I apologize for the y'alls and the all y'alls and the fix and two and anything else really awful. I tell people I'm from Texas and they go, no kidding. That's when I realize I have an accent, but I hear no accent. I'm going to start off with the one and only slide I have. I'm not big on slides either, but this is just an overview of the whole organization at SACU and kind of our progression with Ro throughout our organization. So it basically just symbolizes where we were. This is really Zandy's belief and analysis. You could ask five other people at the organization, they might think differently. But I arrived very late in 2007. So in 2008, even though we had an L Five design, the organization for the most part was operating at level two, just fighting fires, doing what we needed to do, getting things done. But there was no design work at higher levels by 2010, still level five design. But we had brought in a lot of well defined level three roles. So we were starting to see real process innovation, system innovation and work at that level in 2011 because people like me, we had level three roles in place, people assimilated to It. We were actually getting to do some level four work in 2012, we had a CEO change, which actually the man who brought me into the credit union, actually introduced Requisite to SACU, became the new CEO. So that's when it really started going through the whole organization instead of just those areas that worked for Steve, who is our current CEO. And we actually started seeing some level five work in 2012 because Steve was running things at level five. And right now we have a level six design that's pretty recent happened, like in January, I think, maybe late December. And we really are operating at level five. We really have that level of strategy and business focus. So that's Sac as a whole. What I'm here to talk about is how we drove Requisite into an It organization, the financial services industry. I'm sure most of you use your bank account differently today than you did five years ago. It's rapidly changing, just discount all the regulation, but just the technology. And the technology that our customers, and we call them members, accept. So technology in the credit union isn't just primarily about infrastructure anymore. It's really a big part of the services we provide and has to be. And the demand is big. We have USAA. I don't know how many of y'all have heard of USAA, but they are really the leader in self service channel. They have to be because they don't really have a branch infrastructure. So they're really the technology bar for financial services in our marketplace and frankly, beyond. So there are new expectations for technology and it now has to be a big part of that. I have no doubt that if we hadn't implemented Requisite in It when we did, we wouldn't be in a position today to take care of It and to operate differently. And I believe we are. That being said, it's time to redesign. And so we're redesigning after five years so that our mission and role with new technologies will meet those higher level expectations. So what was the state of the It organization back in 2008? Well, it was very typical, very kind of legacy. Everybody did everything. Whoever yelled the loudest or had the biggest title got the attention. Whatever fire was burning got the attention. I actually came in before I came back to the credit union. That's a long story to a different presentation, but I came back as a consultant first and did kind of an organizational review of how the credit union was using technology. And so my findings report was pretty large. They're very much laggard in infrastructure technologies and just the way they were doing things. Formal processes were nonexistent. Documented procedures, forget it. It was all in everybody's head because we had a lot of tenured employees been doing the same thing for 25 years. So that's where we were. And obviously Steve is a very bright person and he knew what we needed to be in the future and that that wasn't going to cut it anymore and it wasn't able to meet the current needs, much less the future needs. So when he talked me into coming back, I had some very basic high level objectives. Nothing huge because actually an organization couldn't have taken it. We had to improve service and remove the chaotic service style we needed to improve the ability to deliver large scale initiatives. I mean, they could handle the day to day and they could handle whatever fire came up, but they couldn't deliver new initiatives. And that's why we were so far behind in technology. So it was very important to change that or we weren't going to get anywhere. We needed to upgrade the technology because I had come from the outside, it was very obvious that just very basic new technologies weren't even being thought of or planned for. And then we had to build an organization that could handle all of that because it's going to be a pretty big shift for everybody and everybody was going to come out of their comfort zone. So our big challenges were that while we had a very dedicated, hardworking team that all hands on deck style wasn't going to work. We couldn't have everybody in level two situations. We had to be able to complete initiatives. We actually had a new phone system, a voiceover it phone system project that had been going on for two years and it wasn't even at business case completion. I mean, business case wasn't even close. We had absolutely zero defined processes, much less written procedures. As I said, zero process innovation. They had installed a new core processing system. For those of you who are not in the financial industry, the core is everything and basically is your engine and it really is the indicator of what you can and cannot do well. They had just converted to what I believe is the best core system in our industry. But because of how it was operating, they couldn't take advantage of what that system could do for. So I used to call it when I worked for that vendor, everybody just converts to a mirror. So they just make the new system do what they did before. They didn't take advantage of the new capabilities they had. It had been exposed to Ro, had kind of like dipped their toe in the water because it was under Steve and Steve was already trying to get some traction with it. But the things they learned were translated into dysfunctional behaviors. Kind of the main thing they took out of it was telling people well, you can't ask me for that. You can't talk to me, okay? That's not really what you're supposed to get out of it. And everybody was just working really hard to keep things going. So how did we give our own legs an It? Well, the first thing know, Steve brought me in, but it was very know the non negotiable is Requisite organization and that's really how we bring everybody in. Now this is the non negotiable. You have to be sure that you want to live under this structure with these principles and are okay with throwing away the legacy style of management. Know it's very people that's very interesting. I'd like to do it, but it really is a non negotiable, especially since Steve is CEO now. So I came in, steve made me do a whole lot of reading, a whole lot of assessments, a whole lot of stuff before I was even an employee. So I was committed to it. It excited me to know that I would have this system to help me build things up because I was brought up in the old legacy style of management. And as I got more into requisite, I just kind of went a really bad manager. And this is why I failed sometimes, or especially why people failed under me. So I was brought in in this newly designed CIO role, and the goal was to keep me in level four work. I didn't even office in the It area. And I had told Steve, it's like, I don't want to be down there because if I am, I'm going to be pulled into everything that's going on. And that wasn't my role. And frankly, I've been in this a long time. I wasn't interested in being in the middle of every fire anymore. I'm sorry.

Speaker C Sandy, what year was this?

Speaker B This was very late 2007, so let's say beginning of 2008. Good.

Speaker C I'm sorry, I just want to know. It was about two years after they were first beginning to pilot.

Speaker B Yeah, actually the pilot directly written sac was an Acousto that was very run, very separate from the credit union. So I didn't even include those years long because it was very isolated. They built that business using recipes. But first things first. I was in a level four role. I wanted to stay out of the firefighting, but I had an organization to build. So I did have to dip down and design level three. I had to assess what the organization was going to need to look like to accomplish those objectives. So I designed roles for level three, then the level threes, and I designed level two roles. And I was only really involved in that because the level threes were kind of new to requisite. We followed the principles. Probably many of you have read a book on professional organization, designing the Professional Organization. It was written by Ralph Robotom and David Phillips. So we modeled especially the development roles from their levels of practitioners. Model for professionals. So it started with beginning practitioners, main grade and senior. So for developers, for example, we had developer, senior developer, developer, and we used that as a model. Clarifying roles was key. Not every role's priority could be or should be situational response. It was very hard to get them to understand that, because really in it, those of you who are in it, you kind of get your self esteem and feeling good about what you do by fixing somebody's problem, no matter how trivial it is. It was for me when I was a programmer, what made me feel good was writing a program that someone would go, oh my gosh, you're so wonderful. It was like a simple little five minute program. That's kind of what feeds people in Ikea. So to pull them out of that was not easy. But what helped is that we did a structured design. Everybody knew exactly what their role was and how it was different from their manager or different from everybody else in the organization. I had to get the right people in the right roles, and I didn't get it right the first time. Both level threes I put in place, I shouldn't say level three. Both people in level three roles, I'm trying to break ourselves with that. They just, while I still to this day believe they were capable at level three, and they valued level three, I mean, I gave them the option. I didn't say, this is your new role, this is the design. Would you like it? They just couldn't change how they worked, try as they might. Try as hard as I might, I can't tell you how many times I had to go, is that your work? And I go like, I'm not sure we're all working here, but doesn't really sound like level three work. Why are you programming? So I gave it two years, probably a year too long. But finally, I removed both of them and brought people from the outside who'd never worked and had never heard of requisite, but it still worked because they came in different perspectives not already embedded in their old way of doing things and were open to learning requisite. And even them operating a different way once they were in place onboarded. Kind of got the lay of the land. Then the real transformation finally clicked. We combined not only Requisite principles, but project management principles. So it wasn't like a one thing fix. They didn't know how to manage projects. Nothing was formal. Project plan was an Excel spreadsheet with anybody done its own time. So initiatives that floundered before we actually completed successfully, before we started, and this was really important before we started any project, we assessed what level of work was needed on that project team and in what role. When I got there, even like especially cross organizational teams, they didn't call them project teams. I can't even remember what they called them. But I'd be in there because I had already been exposed to requisite. I went, okay, there are four levels of people on this project team, all with the same work. Everybody. We didn't have different levels of work accountabilities or anything. We're all doing the same thing, four levels. So that was one of the first things we did. What level of work do we need to get this done? Is there going to be process design involved? Is this just a fix? Something that already works, projects or something totally new? Everybody knew what their roles were and the work to be done. They knew now how to work collaboratively and across the organization. Even though it supported the whole organization, it can still get siloed and they just kind of end up with their tunnel vision. This is how we do it, this is how we fix that. So they were exposed to real collaborative and cross functional work. We introduced software development. Lifecycle. Another formal process. Originally I learned about it at Eds, but we just kind of put our own spin on it and adapted it to our organization and what we needed to do. All the processes, even our project management. We used the standard project management methodology, but we used that to design it for our organization. We brought in external expertise when we needed it. The It before kind of tried was like, oh, we need virtualization, okay, we're going to send some people to class and then try and do it. And it took way too long. Kind of like that's why? Another reason we couldn't get anything done. So we actually brought in that expertise and on a contract basis. And not only were they to implement the new technologies, they were to train the people on our staff. So that's how we did it and that made a huge difference. And by doing all that we did, it actually ended up being a leader in the organization transformation. We led in process and system design. It wasn't the only part of the organization that was just in situational response. So people would see, people across the organization would see how we were doing things and gosh, I guess we should do that too. Just project management, process design. When I first floated out project management and I wanted to build a team and bring some people in to manage all the organization's project, the most common response was, oh, we don't really need that, we manage our own project. Well, I kind of stepped back, okay, we're going to do it for It projects. There's always cross functional resources even on It projects. And they'll see it and they'll see the difference. They'll know what's expected of them on that project team and when, as opposed to how we were doing it before. It's like, oh, I need you to do that tomorrow. So that kind of worked because they did all of a sudden all the other business units were asking for project managers. They wanted some of that. So everyone kind of noted that this was how you got things done. Even business cases were something the credit union didn't do. They basically was very much a patriarchal type environment. Somebody wanted to put in a new system, rarely was appropriate due diligence done. They just kind of went to the CEO like I need $150,000 for this new collection system or else our delinquencies are going to go crazy. Well of course the CEO went can't have that, signed it and they had purchased a system that they couldn't get implemented with the kind of new importance of the self service channel which I call home banking, mobile Banking audio Response we had to build an Eservices team for that focus. Although that channel is totally technology based and a lot of financial institutions put e services under it, I didn't because ultimately the self service channel is a business. It's just a technology based business. So it was still under me as CIO, but it had totally separate level three leadership. I had a business operations manager put in place as well as an individual contributor technology architect and I actually modeled that role after the technology staff specialist in Jackson's book. We went from mobile banking being on the project list for about four years with nothing happening to getting the Eserv team built, getting the mobile banking vendor selected in like four months and then five months later we were live with mobile banking. We were so late with mobile banking because USAA is in our space and they were like way ahead of us. I really believe we wouldn't have been able to do what we needed to do with mobile and the rest of the self service channel if we weren't already modeling and living requisite. So now let's talk about the future from Stratum five. I'm not the CIO anymore. Like I said, I'm the COO. It's a level five role. But it's not just a level five, it role. I actually run the whole direct business now just to give you a short story, we actually have split the Creighton's organization in two. There's the indirect business which is indirect auto and our mobile home division, don't tell Anthony I said mobile. It's manufactured housing, mobile home, manufactured house. Those businesses are very different because the business, the loan is not acquired through the member, it's acquired through a broker or a car dealer and we basically buy the paper. So it's not really a face to face or any kind of contact with a member until we buy the paper, get it originated and then it looks like any other loan, it's our member, we talk to the member or whatever. So those businesses are very different. So we split it. So I have the direct business even though it is traditionally one of the support functions and away from the business it is also in the direct business now as well, because our direct business is about technology. We have an older membership, so we still have a lot of members that want to come to the branch just to do whatever. But the future is about the technology aspect of our direct business. Our branches are way bigger than they need to be. We need more technology in the branches. The call center is very much still what's my balance? Give the balance, goodbye short turnaround times, so the call waiting numbers don't go way up. That kind of conflicts with what we want. And what we want is to steer members towards the best channel for them and make sure they know about the new capabilities, they know the service. Just because someone's older doesn't mean they don't want the technical option. It may be that they just haven't been taught. I think about my mother all the time. She'd go to the credit union all the time in our little town. And I'd go, Mother, why don't you use home banking?

Speaker C Oh no.

Speaker B Then one time she wanted me to do something. I went, Well, I'll get home banking set up for you. And I did the transfer or whatever she wanted. She was just kind of watched. And then she went from not using it at all to using it every day to check her balance. Because they like to do that, not me. Like to see something dropping. And it was the same with the debit card. I'd take her to the grocery store and she'd write a check. I'd be humiliated. See me? And I showed her how to use I don't know how to use that. And I showed her how to use it and she's whipping. So we really need to show them. I think there's an inclination to write off the older customers. Like, oh, they'll never use self service. I just think we need a different approach and people have to be comfortable with technology to use it. But the self service option is better for them, it's better for the credit union. A self service channel transaction costs us anywhere from ten to branch. Transaction cost us between 15.

Speaker C Can you tell me what your headcount and assets under management were in 2008.

Speaker B And then in 2014? The assets, we actually are shrinking a little bit by design. So we were probably 2.9 or something around there and we've shrunk to 2.8 something. So we're not really growing asset size, but that's by design. Employee camped amazingly through a lot of change and a lot of addition. Really has kind of stayed around 676, 80 throughout all of this. A lot of that's because the branches, most of the elimination of roles has been in the branches. And even though we have 5000 sqft in the branches, we don't staff those branches like we used to in the operations area. When I got back, we had to redesign, we had to discover everything that was being done and in this one area. And we didn't have to eliminate anybody's job because we knew some things were going to change. We started using temporaries as people dropped off, but just by looking at the work and organizing it in a more requisite way and designing requisites and this is just our first stab. We eliminated three and a half ste, so we're gaining efficiency just through design. Even though we've added a lot of management roles, we have also eliminated we were never higher than an L Five organization. There were seven levels in lending, so we delayered some areas. So it's kind of interesting. We really haven't gone crazy with it. How did you eliminate the wastage from development? How did I eliminate eliminate the wastage from development? Like programming the wastage? Well, just by having process, it eliminated so much rework. We installed quality assurance and formalized QA testing playbooks for whatever we needed to do. So just by doing that, we didn't have to do things five times, put something in, it actually worked. We didn't have to pull it out and rework it and do everything again. Our failover process, which is basically our disaster recovery, if our main core platform fails, we fail over to another one. When we used to take ten to 12 hours of downtime just by getting formal processes in place, everybody knowing what their role is, what needed to be done, and it was one of my objectives. It's down to 2 hours and my ultimate goal is no downtime. That's a little ways we need the vendor to help with that.

Speaker C Has project management protocols and processes that you use ever cause problems with holding requisites?

Speaker B Not at all, because we in it. In my organization, we have the luxury of basically running the system called project management, so everyone knows what their role is. It's not perfect, but it's so way better than it used to be when nobody knew what their role was and we never couldn't hit a date, even if we set one benbi. How do you reconcile between a steering committee in a project management environment that has the authority and accountability? Yeah, it's very interesting, the steering committee thing. We don't have steering committees. I don't feel steering committees are requisite just by their nature. In project management, one of the main things we do is a project charter that maps out what everyone's authority is, what the decision making process is. Is it consensus building? Does it fall back to their executive sponsor? We decide that at the beginning and ultimately whoever the executive sponsor of the project is, makes that decision. Is it going to be his decision or her decision, or she delegating the authority. And a lot of this doesn't have to be delegated. If it's a level three project, it's that level three manager's project and they should have the authority that they need to run it.

Speaker C Do you measure the employee engagement or satisfaction and evolution over time.

Speaker B Yeah, obviously we always start with fear and kind of not buying it. It's like, okay, this is the latest and greatest management thing. Ultimately, unless you have managers that are modeling it, that believe in it, that don't say, oh, Ro is something we have to do, then it can build. But I can tell you there's some people who did not come around and left either on their own or kind of were helped out, but we give them time. We know that this really is ultimately a culture change more than a system change, but it always started out with fear and doubt and just kind of, well, I'm just going to keep doing what I'm doing and see how long I can get away with it. But it's grown. I wouldn't say 100%, but more times than not, people go, gosh, it's really nice to know what my role is, know who my boss is, and to have a boss that can actually add value to what I do, instead of everybody expecting everything out of you and you're a help desk person. That answers your question.

Speaker C I think we've got time for two more.

Speaker B Okay, I just want to make an observation. We found this too. You know you're in trouble when you hear someone say to another person in an organization, so do you want us to do Ro or do you want us to do our work? It's like, hello, do ro. It's a way of understanding work processes, et cetera. And it's like, oh God, how do you break that down? Whenever I hear somebody say that, I go like, okay, we're not there yet with that person or that area, because it's not something we do. For me, it's just integrated in everything I plan or do. It's just canvas or paint every day. I still refer to the book and all my resources on a regular basis.

Speaker D Because by the sounds you had a strong methodology, a PM type of methodology. One question is, did you follow a global one like a PMI? And then did you leverage the PM tools more? Or did you also bring in the Ro tools like Qqtr and to roll that out? Because I know people, I love how you said people just want to get things done so they can embrace sometimes PM earlier than Ro. So your thoughts about that?

Speaker B Right, so first question, yes, we used PMI as the basis, but the level three manager I brought in designed our version of it. So we have an Epmm enterprise project management methodology. So it's just SACU's spin on it, but the basis for it is PMI. We bring requisite into every project. There's usually a task assignment first, and that's where it starts. So it starts out with the task. What's the output? When does it do? What's the quality and quantity expected? What resources do you get? And how does. It have to be integrated. It usually always starts with that, especially if it's a delegated down project. Now, I preach all the time. It's like I shouldn't have to task assign everything we need to get done. There's level three work inherent in a level three role, and they should be initiating projects on their own, and so they can choose, depending on what the project looks like, whether they task assign. But even if you look at our project charters, it's very similar to a task assignment, and it clearly lays out the roles, the accountabilities, the authorities and those kinds of things. So it's all interwoven.

Speaker C Jerry, the last one actually just a comment. One of our most successful CEO clients, guy who turned around a big steel company in Canada, would say early on to people who were afraid and confused. He would explain, first of all, this is the only way I know how to manage, and this is why it helps me. I don't expect at the beginning you'll like it. I don't expect at the beginning that you'll want to do it. I don't even expect that you will do it unless you want to work here. And then that gets people's attention.

Speaker B It's a big nomination. You can kind of rebel in the beginning, but there's a limit.

Speaker C Thank you very much.