Plato Elevate Winter Summit has been announced (Dec 7th-8th)

🔥

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

Preparing Your Team for the Remote Workplace

29 November

Vadim Antonov, Engineering Manager at Meta, dictates how he brought a brand new team into the remote learning process by ramping up onboarding and creating a mentor system.

Alignment
Remote
Internal Communication
Coaching / Training / Mentorship
Data Team
Cross-Functional Collaboration
Vadim Antonov

Vadim Antonov

Engineering Manager at Facebook

Delegate successfully as a first time manager of Product Managers

24 November

Andrew Tsui, a Product Leader, works to build great teams that are independent, demonstrate mastery of their domain, and fully commit to their purpose.

Scaling Team
Building A Team
Delegate
Coaching / Training / Mentorship
Psychological Safety
Cross-Functional Collaboration
New Manager
Andrew Tsui

Andrew Tsui

Director of Product at Startup

What it takes to become a great product manager

19 November

James Engelbert, Head of Product at BT, shares his deep understanding of the traits of a successful product manager and how to get aligned with the organization’s path to success.

Product Team
Personal Growth
Leadership
Strategy
James Engelbert

James Engelbert

Head of Product at BT

The art of managing up

19 November

James Engelbert, Head of Product at BT, shares how managing up is all about being an excellent manager to bring the best out of a team.

Mission / Vision / Charter
Managing Up
Internal Communication
Strategy
Stakeholders
Cross-Functional Collaboration
James Engelbert

James Engelbert

Head of Product at BT

Managing Team Collaboration After an Acquisition

10 November

Han Wang, Director of Engineering at Sonder Inc., shares the ins and outs of working successfully with the other half of the team after a merger.

Acquisition / Integration
Large Number Of Reports
Company Culture
Performance
Han Wang

Han Wang

Director of Engineering at Sonder Inc

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.