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

🔥

Back to resources

The Changing Face of Life Insurance

Dev Processes
Leadership
Convincing
Ownership

24 September, 2021

Ben Picolo
Ben Picolo

Engineering Manager at PolicyGenius Inc.

Ben Picolo, Engineering Manager at PolicyGenius Inc., talks about an industry-changing that his team shipped amidst the chaos in the product line.

Problem

Early in 2020, my team shipped a significant new feature that changed the model for how we sold over half of our sold life insurance. Traditional life insurance underwriting follows a lengthy, invasive application process. Your application can take up to 30 - 40 days to be fully approved. Our new system would allow a significant number of people to get their health insurance over the phone within a day. We spent about 8 months building the MVP, and it was a great success.

Doing this required creating a complicated new distributed system, and we intentionally cut corners to complete the project on time. When we shipped it out, it became a massive success. Keeping it running, though, took significant manual engineering intervention. While spending significant efforts on maintenance, we had to add more features and carrier options, which made it incrementally more unsustainable and led to a tipping point. Despite keeping the service up and running for 6 months in this state, we needed significant reinvestment in the original systems to sustain the growth.

The essence of the problem was that sometimes justifying technical features to product managers and other leaders in and outside your organization is a challenge. Convincing those leaders that spending a significant amount of time on work that’s less visible can be hard to do.

Actions taken

My goal was to spend 1 - 2 months of the team’s time reinvesting in the distributed system we had already built. From something "crappy", to something that we needed to keep growing and sustaining the business.

To demonstrate impact for the product leaders in the room, it was important to us to demonstrate the customer problems this system created 一 what are the real problems it creates? We needed concrete evidence. We spent time documenting the specific problems caused by the existing system: more time spent waiting for a significant portion of our customers, painful back-and-forths with insurance carriers when applications weren’t in the expected state, and frustrated customer success teams that didn’t feel they had the information they needed to help their customers.

The original system was missing a cohesive definition of “success”. It relied on a hodge-podge collection of alerts to identify potential breakdowns. Because of this, we couldn’t reliably notify users when actions needed to be taken on the application.

I wrote up a strategy document to take to our product manager. Whenever I write up strategy documentation for technical work, I rely on the methodology proposed by the book "Good Strategy Bad Strategy." I compile the specific problems the product is facing, the underlying systems causing those problems, and how we need to rebuild the system or our processes to accommodate for that. Focusing on that user-facing story, and the reliability outcomes users expect, helps decision-making parties understand the problem. By framing the problem this way, I brought our product manager into the know on everything they needed to know to push on this problem as well as I could.

Information in hand, it was easy to lay out our argument to the CEO and talk about the problems in the technology and what we needed to rebuild. We planned to make sure that it was sustainable for the company, and in doing so, the CEO was impressed and product leaders endorsed the project. Using product-driven arguments was critical for getting the whole team on board with a gritty technical project.

Lessons learned

  • When trying to sell a technical debt project, you have to start with the user. Try to figure out how users are impacted by something because, ultimately, the users are your source of business. If you can frame a technical problem in terms of how it is impacting your actual end-users, it would be an easy sell to anybody in the organization.
  • You can rely on SLAs and SLIs in order to measure user outcomes. It gave us a strategy on what we could do and applied it on the chart to pinpoint how the problem was affecting our users. Although it is uncommon for more product-led organizations, there's no harm in giving it a shot. Take advantage of the tools from the product-facing side.
  • Get small to large information written down in an accessible format for people to share and discuss. Also, when there is a problem, lay it out to the team in a way that helps everyone at every level to get aligned. Others might miscommunicate or forget a lot of the necessary details. There is no other successful way to do it.
  • PMs are always looking to help you achieve the goals the team cares about. They want to help you push those tech objectives. By translating them into a language that they know and understand, they can drive those technical projects alongside you. Don’t ask your product people to be on the sidelines for technical debt objectives. Make it their priority as well.

Discover Plato

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


Related stories

Improving Team Execution in a Remote Environment

29 November

Vadim Antonov, Engineering Manager at Meta, details his process of implementing an organized execution system for his cross-functional team.

Alignment
Remote
Leadership
Delegate
Feedback
Vadim Antonov

Vadim Antonov

Engineering Manager at Facebook

Firing Somebody for the First Time

23 November

William Bajzek, Director of Engineering at Sapphire Digital, remembers the first time that he needed to make the ultimate sacrifice on behalf of the well-being of his team.

Leadership
Firing
Team Reaction
William Bajzek

William Bajzek

Director of Engineering at Sapphire Digital

Transitioning From Tech to Product Management

23 November

Nicholas Cheever, Divisional Vice President, Global Supply Chain Technology at Trimble Transportation, talks from his experience on how to excel in a PM role when transitioning from tech roles.

Ownership
New PM
Nicholas Cheever

Nicholas Cheever

Divisional Vice President, Global Supply Chain Technology at Trimble Transportation

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 Benefits of Stakeholder Communication

17 November

Piyush Dubey, Senior Software Engineer at Microsoft, shares how to understand the stakeholder communication process better and why it is essential.

Meetings
Internal Communication
Collaboration
Ownership
Stakeholders
Piyush Dubey

Piyush Dubey

Senior Software Engineer at Microsoft

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.