Leading Cultural Change in an Organization

Mary G. Fisher

Software Engineering Manager at Curative



One of the companies I worked at was still using paper records. It was a company that provided professional liability insurance. They tend to be behind in the 21st century. Some people in the department pushed back on change for fear of how it might impact their jobs and teams. The other part of the BIG problem was that not being electronic made it difficult for the claims representatives to pull up their case files when necessary in court or on the road. We were falling behind in the industry because we could not provide our customers with an online application or renewal process for their medical malpractice insurance. We also had very manual claims and stop-loss payments processes.  It was cumbersome and took longer than usual to get payments done.

It was challenging for the claim representatives to carry those giant binders and quickly find any information they needed. Amidst that, our customers were starting to look to our competitors who started to provide online services. Customers were also not able to make quick changes or requests to their policies. People these days are so used to online that we had to migrate our system asap or risk falling behind in the market.

Actions taken

I created a committee with the department leads and individuals from each team. We had also done a “request for proposal” with multiple document imaging systems, and we evaluated those, with representation from each department, claims, underwriting, finance, marketing, risk management, and HR. Once we picked our document imaging system, we helped form a strategic vision and initiatives.

First, I started with documenting each department’s workflows in business process diagrams. This acted as a good starting point to determine how they may want their “To Be” workflows to be in the new system. I demoed the different ways the system could be configured. I did not want the departments to be in a difficult position to determine how their workflows could work in the new system. Neither did I want them to be unsure of where to begin.

We planned on which department we wanted to start rolling out first and in what order. What we did was pick the most painful department to begin working with at first, which was Underwriting. Naturally, they had the most challenging process, plus that was where the insurance for these medical practices started, with their insurance policies being created.

We picked particular forms to start with 一 we developed some electronic forms, so they did not have to do those processes manually. We also  worked with them to take their existing files and break them down to figure out how they wanted to put them into the system. We figured out what file types they wanted, did they want to break each year separately or all in one file and layer each year by the oldest to the newest, or whatever worked best for them. Our priority was to work closely with them to determine those requirements.

Rolling out of one department, it took us about 2 - 3 months to complete it. The process went like this: gathered their requirements, configured the system, developed their electronic forms and scripts to integrate it with the main business application, scanned a few existing files into the system, and had the department test it to verify it was how they wanted it to be. Once we had all of those tasks completed, we back scanned all the documents. It was a giant room of documents that we all had to work with.

The good news was that they immediately started using the electronic system instead of the paper. It went pretty successfully that we shared it with the following slated department. The initial department we started our system with shared their lessons. We ensured that everyone involved 一 the leads, and some people who knew the processes inside and out 一 were empowered to help make the decisions.

Getting everybody into the document imaging system took about a year, but it was very much worth it. Every time we would automate one group, they would pass on the positive feedback to the other, which helped influence everyone else to get on board. It helped us figure out what worked for one group may not work for another.

Lessons learned

  • One of the lessons I learned from most companies that I worked with is to empower the people in the teams to make the decision. If they are not given the autonomy to decide or make a change that they are most comfortable with, they would feel that they have no control. Nobody wants to build a work environment where you throw work at people; instead, change it so they get to decide what the process would be like.
  • Remove barriers to ensure that there is strong communication involved in the requirements gathering process. Have them translate their current workflow into how they want to work in the future. Also, empower them with knowledge of the new system and how it could be configured to make better decisions for themselves.
  • Provide incentives. For example, we had annual goals tied to these, which were measured based on their performance. Incentives always drive people to work towards the end goals and demonstrate new skills or roles with the change.

Be notified about next articles from Mary G. Fisher

Mary G. Fisher

Software Engineering Manager at Curative

CommunicationOrganizational StrategyTechnical SkillsSoftware DevelopmentCareer GrowthCareer ProgressionSkill DevelopmentTraining & Mentorship

Connect and Learn with the Best Eng Leaders

We will send you a weekly newsletter with new mentors, circles, peer groups, content, webinars,bounties and free events.


HomeCircles1-on-1 MentorshipBounties

© 2024 Plato. All rights reserved

LoginSign up