Transforming a 150-Year-Old Non-Profit

Okay, so the NAIC/NIPR is the National Association of Insurance Commissioners and National Insurance Producer Registry. They're two separate companies. NIPR is a wholly-owned subsidiary of the NAIC. I know that when I say I'm talking about insurance, everyone gets very excited. Hold your applause for it.

We exist to protect insurance consumers by supporting and enabling state insurance regulators. NIPR also tries to make sure producers are licensed, have the correct amount of education, and are not committing felonies in one state and then moving to another and continuing to try to sell insurance. That used to be a problem, and that's one of the reasons NIPR was formed.

Our annual revenue is around $100 million. We have a lot of different customers: nine million direct, a lot of those from NIPR as producers; regulator staff; the 56 members of our association, which are the chief regulators in the 50 states, Washington, DC, and the five territories; insurance consumers; and the insurance industry, which buys data and other facilities from us. We have an online website called Insure U where we curate information so people can learn more about insurance and the insurance industry. I didn't know about it until I joined, so we'll work on advertising that better.

We have about 600 employees across the two companies: about 500 in NAIC and about 100 in NIPR. Of that staff, about 250 are technology-related, including software development engineers, quality, and operations. We have about 20 top-level applications. Applications is a difficult word to quantify, so we have several hundred actual small apps that make up those 20 larger apps. Not really microservices, unfortunately, but we're moving that way.

Where do I fit in? I'm the chief architect. I report to the CTO. The CTO reports to the chief operating officer, and the chief operating officer reports directly to the board; the CEO also reports directly to the board. The board is four members of our 56-member association. It's an unusual pairing, having both the COO and CEO basically running the company together, but it's worked out really well with these two individuals. The CTO owns all application development and operations. When we started this, the CTO did not own the operations side of the house.

My responsibilities are all technical aspects of the cloud and data transformations, and I'm also helping lead the cultural transformation. I help organize the local DevOps Kansas City meetup and the DevOps Days Kansas City conference. I was able to bring in another organizer to help lead this cultural transformation.

We'll talk about the NAIC's transformation journey. There's only 30 minutes, so we can't talk about everything. I will be at the Speakers' Corner to answer questions. Feel free to reach out to me on LinkedIn, and I can connect you to other people in the company who may be able to answer your questions more effectively.

Let's start by defining what our problem was. If we didn't have a problem, then we probably weren't going to do this. It's important to recognize that you have a problem, and then you can probably start measuring to make sure you're solving for that problem.

We had silos: not only development and operations silos, but within development many different silos for different business areas. Each one has a different culture and different processes. All of their Jira projects look different from everybody else's. It makes it very challenging to move people from area to area because they're basically joining a brand-new company. Everyone is using different technologies in different areas of the company.

We also were not being as efficient as possible. I said we had about 500 associates in NAIC, and every new person is highly scrutinized, so we can't really add more people. We need to make the most effective use of our people that we can. We're a nonprofit, so we don't generate a lot of revenue; we're trying to make sure we don't generate too much revenue. We have to reinvest that back into the company, so there's a real balancing act around not spending too much. The industry also doesn't want us to spend too much. We get our money indirectly from all of you, so thank you. I joined to make sure we spend that as efficiently as possible and give back as much as we can.

We also want to improve our technology. We are using a lot of older tools. It has been very much like was talked about in one of the keynotes: keeping the lights on and doing with less. We don't have enough money for that. We don't have enough money to write tests, because that's overhead. Trying to move through that has been challenging.

We have a plan called State Ahead. It's available for free access to anybody on naic.org, and it will tell you our three-year plan. We're in the first year of that plan, so we have two more years. All of that is public. Also, all the fiscals I write for the budgets we request are public, and you can all comment on them, so please don't. All of your comments are taken into account, and then we decide if we move forward.

As we started this journey, we decided we needed to hold culture as the most important part, because my experience and the CTO's experience is that if the culture isn't right, everything tends to revert back to the way the culture is. It's similar to Conway's Law, where the organization influences the technology, but I think the decisions we make about technology are highly influenced by our culture. We kept that as one of our top priorities.

We put people first, and this is evidence of our focus on culture and trying to create more of a learning culture. We did lunch and learns where, about twice a month, we bring someone in or have someone internal to the company give a presentation. It doesn't even have to be on a technology thing. It's about teaching others and making our culture more of a teaching and learning culture, where we're always trying to contribute knowledge back in and get knowledge back out of the system.

We also encourage training and outside opinions. We brought in people, brought in multiple companies to help train us, and got consultants to come in and give us their opinions so we can learn from them.

We aligned our organizational structure. The operations team used to exist in a different area of the company, and we moved them in very quickly after I started. Now the operations and development teams are under one leadership. We still have silos there that we're actively meeting regularly to figure out how to integrate all of those teams and make the operations side feel like they're not outsiders still. Because we brought them under the same leadership, that doesn't mean they don't feel like outsiders just like they did before.

We also identified influencers to give them more authority and more freedom to make decisions and engage their areas. We particularly did this in operations so individuals over there who are passionate about this stuff can get the resources they need to move forward without us or other leadership holding them back. That helped enable small wins with staff. They were able to create Terraform deployment scripts for databases or internal networking work. Internal operations staff still working in the regular data center were able to create new pieces of infrastructure and start to migrate on their own.

We also use an award system. This was the coolest thing joining this company. When I go to a new company, they always tell me about this award system they have, and then I never actually witness it happening. It's like, "Don't do that. You'll get fired." Within about a month, maybe less, one of the people who reports to me got one of these for a project that ended the week before, and I was shocked that there was that fast of feedback in the system. I use these to target specific behaviors I want to encourage in the culture we're building. I think that is probably the most effective tool I've had at this company.

We also needed to understand our context. The CTO and I and multiple others have been interviewing peers, managers, and customers. We send out surveys. We needed that initial feedback, but we also need continuous feedback from all these individuals to make sure we're going the right direction. We send out regular small surveys that are very targeted. We do cloud panels where people get to ask us questions.

We introduced Slack, which blew up. Everybody ended up on it. Etsy created something called Mixer, and there's a Slack app called Donut, which I renamed to Mixer for nostalgic reasons. We have a Mixer channel where people can join, get matched up every two weeks, and go have coffee. We have had some of the greatest interactions and acceleration of projects because two people met and now they're off building something new to help the company.

We also did application analysis. We created an Excel spreadsheet that listed lots of valuable information about our applications. It's very time-consuming, but if you don't know your application's dependencies, you're going to break a lot of stuff, and that's really time-consuming. It's better to do some of the research up front. You won't figure out everything, but at least you'll have a baseline and a document started that you can add to.

We also focused on business value. We introduced a scheduler because we had cron jobs everywhere, and it was a disaster and hard to troubleshoot. We aggregated those into one common scheduling system. That was a great quick win. We made sure we didn't recommend anything unless we did substantial research. We wouldn't have recommended that solution if we didn't think it was going to be a winner, because it was very early and we didn't want to risk essentially collapsing the transformation program because of a giant fail at the very beginning.

We introduced Dynatrace, an APM tool, which has proven over and over again to be helpful. Even the most rudimentary of these tools is valuable. The ability to troubleshoot a customer problem in real time with data is immeasurable.

We also had grassroots projects that we tried to support. If we identified those, we would try to support them. We really needed to tell people that we can spend the money, we can upgrade, and we can afford the technology, especially if it is providing business value, if it's one of our differentiators. We want to commoditize the things that aren't differentiators for us.

Our first project was a cloud project. We explored serverless. It's all done on Lambda. We learned a lot from that process. It was a redesigned application, and we wanted to start pretty small and gain some fans. We wanted to get a good solid win; we wanted the COO to be bought off on this and to help drive the change and champion it to the board. This was a great example. We had operations heavily involved, and it went really well.

But it was small. A lot of people say, "Take something that's really critical to the business and do that." I like to build up a little bit more. Doing smaller things that are less critical and getting a cadence of wins has proven out pretty well for us.

How did we sell this to the top? We bought books like Leading the Transformation and The AWS Way, and there have been several others since then, like The Phoenix Project. We visited Microsoft and AWS when we were trying to decide which cloud vendor to go with. We also visited peer companies: other nonprofits like us, or companies similar in size or with similar sized infrastructure, and learned about what they were doing. We shared case studies. When we were doing all this, we included the naysayers, because the best solution is just to provide them all of the knowledge you have, and then they'll hopefully make the decision based off your knowledge.

This was really valuable because it created a shared experience that we could all look back on. We could say, "At AWS, this person said this," or, "This was the story at AIAS." I think AIAS is another nonprofit, and we can reference back: "They were doing this with their data platform." That shared experience is valuable for talking about it for the next year or two.

We also made broad involvement, enlisting almost every department in the company. The Mixer example was not necessarily selling to the top, but someone from the library research department joined Slack when it was still in beta, joined channels, and started ordering books that were being talked about. I gave her an award. That's the kind of thing we want in our culture: to keep facilitating that kind of interaction.

We also did Cloud 101 and AWS training with leadership so they would understand more about what is involved, where we're going, and the level of effort it will take. We didn't just talk about the upsides. We were completely open that there were a lot of downsides and risks, and we wanted everyone on the same level playing field of understanding that this wasn't something we could do overnight.

We also talked about it publicly, like we're doing now. We've done meetups and AWS events. We try to share it as often as possible. The documentation is online for free to look at, and we request feedback. We also use Gartner Research because executives get sold on Gartner Research. Choose wisely.

How do we sell this to our staff? We needed to make sure we chose the right teams and the right projects. In these types of transformations, some teams don't yet have enough knowledge to be successful in one of these events. You need to pick the people who are most passionate and then give time and space for other teams that are less skilled to become skilled in these new technologies or concepts.

Most of the stuff we're doing, when we're thinking about AWS, Kubernetes, containers, and microservices, means you stop thinking, "I'm going to log in and press some buttons on this system," and start thinking, "I have this overarching service, and these are my SLAs and SLOs, and this is how it needs to interact with the customer." We also wanted to make sure we didn't choose a project that was too large or so insignificant that it wouldn't matter.

We discussed our transformation goals and how we were going to measure them, which has changed over time. We wanted everyone on the same page with where we were headed and what we thought success looked like. The most important thing I've learned about sharing often is that you need to keep sharing over and over and over again. You'll get very bored of saying the story, but suddenly in a meeting you may see a twinkle in someone's eye the third or fourth time you've said it, and they finally say, "Oh, hey. The way you said it this time, finally that worked." Keep changing it and keep going over and over again.

Also hit the hard questions up front. At the very beginning, when we did our first cloud panel, we were asked basically, "Am I going to get fired?" We were very clear that the goal of this is not to fire anyone. We have 500 positions. One question I've learned to ask is, "Well, how long is your backlog?" Most people complain about not having enough time to do anything. If I'm giving you three extra people because of automation, then you're probably going to be able to execute on your backlog and maybe finish off that seven years of work sitting there.

We also wanted to make sure everyone learned so they felt included. Those teams that weren't ready to make the leap yet needed enough knowledge and opportunity for knowledge as possible. We send people to conferences like crazy. The COO is constantly asking, "Can we spend more? Can we send more people to conferences?" A lot of people are like, "We're kind of tired." Conferences are hard.

We also do lunch and learns and self-paced learning, a lot of online courses. Linux Academy and a whole bunch of different kinds; basically whichever one you want to use, go use it and learn. We've also brought in experts from GitLab, Heptio, New Context, and Second Watch to teach us. These are experts in these fields, and we want to learn from them, so we bring them in to teach classes.

Project two was kind of an iteration on the data capture and was similar to the first project. The third project is something we've been working on around business intelligence. We create a lot of reports. A lot of what we give back to commissioners are reports with algorithms run so they can have data about different companies. We found that a lot of what we have for applications now can be solved with Tableau. We can make it a Tableau dashboard and might eliminate three applications. Not running applications is the best thing to do as an app developer.

We've really focused on that. Rupert Klein, who is running it, has been amazing. We have a Viz-A-Thon coming up; people from all over the city are coming in. That's really the culture of DevOps applied to data. We're trying to make sure we have the culture, and trying to make sure the tools help facilitate more of that and more federation. We have a centralized core knowledgeable about the space, and evangelists on the edges helping teach their areas. They come back to the central group if they need access issues resolved or have particular questions.

Selling change across the company is much easier now that we have a couple of wins and an example, particularly the Tableau culture we've developed. It's being widely adopted and solving problems really fast. The commissioners have really enjoyed it. We have an auto data piece that basically all the commissioners want now. We did it for two states, and now we have to do it for everybody, which is a bit overwhelming, but it's great to have the problem that everybody wants the tools we're developing.

For learning, we need to understand and translate what technology and culture change means to the business. Everybody needs to be on the same page across the business, including developers, operations, business, and leadership.

We also need to share. No matter if it's a big win or a small win, just share it. Share it over and over again, share it in the hallway, send emails. If a team has done really well, make sure you recognize that and praise them publicly. Slack has been great for this. We're able to congratulate people in real time, publicly, so everybody can see it.

We also need to continue to grow. This is all more than tech. We need to explain to everyone in the company why this is so important and what it will mean for our future. We're focused on data moving forward, and we need to get our bedrock ready so that when we start to accelerate our data program, all of our infrastructure is very solidly placed.

Now we're in the acceleration phase. We've laid a lot of the groundwork and done a lot of the cultural transformation pieces. We've created a platform team, a centralized team, which some people have claimed is creating another silo. This is all a timing issue of perception. That's been a challenge. We've tried to stave some of that off with training, but we don't have enough people who know enough about the newer tools and culture to bring everyone in at once. We would drown in requests.

We're using a model where this centralized team creates a migration platform, and all of this will be self-service. We're using GitLab, Kubernetes, and Terraform, and filling in the blanks where the infrastructure and idioms of the company are different from what's provided. We're trying to provide that as a completely self-service system where developers come in and take on the burden themselves.

We also offer internal consulting. If you have questions, ask us and we'll try to partner with you. If you need a month of our time, then we'll schedule time and bring you through. Some teams are like, "Just give us the stuff and we'll go and do it. Leave us alone. We can solve our problem if you give us the right tools."

We're trying to bring in more people now and make sure they have education. Whenever we do education, we include operations people, even desktop support people, because we think some of those jobs may be different in the future. We want to make sure they are trained, and we bring in security because they should be trained on the things we're doing. Bringing them in as early as just learning about it has been really valuable, because when you talk to them about it, they don't have the burden of not understanding the technology.

Thank you. I have another slide that I'm supposed to leave up. When this gets published, I'll have some resources on here. Things I'm looking for: right now we're still working through some organizational architecture decisions so we can mold the organization to the way we want our applications to look, kind of using Conway's Law. We don't have a definite decision on where we want to take our organization. There's a DevOps Topologies website that we've been using, and we kind of have an idea, but case studies and examples are helpful to convince other people.

How have you gone about migrating hundreds of applications? The next two years are going to be us migrating all of our applications. Some will be redesigned; some will just be moving JBoss into Kubernetes. We're moving off Subversion onto GitLab.

If you want to share, I'm more than happy to come and talk at other companies or help meet with leadership teams. We want people to come meet with our leadership teams and present at our company. We're working on funding people to come in. If you come in, I would also have you speak at the DevOps KC meetup. We want more sharing, and we're trying to do that actively within the KC community, but we're more than happy to do it outside of that.

Have you done BYOD? This is a big issue right now. We have a bunch of VDI, and we don't want that anymore. It's creating lots of limitations. He works at NIPR; he's the director of IT there. He's very happy about this, and I've heard good stories and bad stories about BYOD. If you have tips, please let me know.

If you've open sourced any tools, we're working on that now. I basically stole the stuff from Google's open source docs online. But if you've actually done it and have some lawyers we can talk to our lawyers, that'd be awesome. Thank you.