Back to resources

Leading Cultural Change in an Organization

Changing A Company
Company Culture
Strategy
Cross-Functional Collaboration

12 October, 2021

Mary Fisher
Mary Fisher

Software Engineering Manager at DrChrono

Mary Fisher, Software Engineering Manager at DrChrono, shares how she led cultural change in an organization transitioning a company from paper to digital, entailing the benefits of digital solutions.

Problem

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.

Discover Plato

Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader


Related stories

How to Maximize Employee Retention in Engineering Teams

25 May

Vimal Patel, Founder and CTO at iMORPHr, shares how he retained all of his employees since beginning his software development company in 2019.

Building A Team
Company Culture
Hiring
Retention
Psychological Safety
Vimal Patel

Vimal Patel

Director of Engineering at iMORPHr

Managing Different Timezones: Inclusive Collaboration Methods

19 May

Jonathan Belcher, Engineering Manager at Curative, shares an unknown side of synchronous communication tools and advises managers on how to handle a team that’s spread across the globe.

Remote
Internal Communication
Collaboration
Cross-Functional Collaboration
Jonathan Belcher

Jonathan Belcher

Engineering Manager - Patient Experience at Curative

Creating a Company Culture That Balances Helpfulness and Productivity

16 May

Alexis Philippe, Vice President, Product & Engineering at Amilla, describes his one simple rule for creating a culture of helpfulness that doesn't disrupt productivity.

Mission / Vision / Charter
Company Culture
Collaboration
Cross-Functional Collaboration
Alexis Philippe

Alexis Philippe

Vice President, Product & Engineering at Amilla

Streamlining Product Processes After a Reorganization

16 May

Snehal Shaha, Lead Technical Program Manager at Momentive (fka SurveyMonkey), details her short-term technical strategy to unify processes among teams following an acquisition.

Acquisition / Integration
Product Team
Product
Building A Team
Leadership
Internal Communication
Collaboration
Reorganization
Strategy
Team Processes
Cross-Functional Collaboration
Snehal Shaha

Snehal Shaha

Senior EPM/TPM at Apple Inc.

Navigating Disagreements When It Comes to Priorities

9 May

Pavel Safarik, Head of Product at ROI Hunter, shares his insights on how to deal with disagreements about prioritization when building a product.

Innovation / Experiment
Product Team
Product
Dev Processes
Conflict Solving
Internal Communication
Collaboration
Convincing
Strategy
Prioritization
Pavel Safarik

Pavel Safarik

Head of Product at ROI Hunter

You're a great engineer.
Become a great engineering leader.

Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.