Policygenius Day-in-the-Life: Software Engineer
At Policygenius, we believe that insurance helps people when they’re at some of the most challenging moments of their lives. Every day we come to work with the goal of making it easier for people to compare and buy insurance, so they have a helping hand when life gets hard. Here’s how our product engineering teams work towards this goal on the daily.
Tools and Languages We Fancy
Here on the Policygenius engineering team, we strive for architecture and tooling that reduces toil, and strikes the right balance between exciting, cutting edge technologies and maintainability. Our day-to-day tools include:
- Workflow: Git and Github for version management/code reviews, and Clubhouse for our backlog/iteration planner, with Zapier to connect our various apps.
- Site Reliability: Sentry, Datadog, and PagerDuty are there for site reliability monitoring, though thankfully we have a solid Site Reliability Engineering team, so our PagerDuty stays pretty quiet.
- Analytics/Data Pipeline: Segment for collecting and syndicating analytics events, BigQuery as its backend, and Tableau for reporting, with Airflow tying our entire data pipeline together.
- Deployment: Kubernetes for our container orchestration, which we manage using Terraform and Helm, and BuildKite for our continuous integration system.
As for languages and frameworks, we’re a polyglot engineering team, though a majority of our products currently rely on a Ruby on Rails monolith. We’re in the process of breaking our monolith up into Go and Ruby microservices, with some gRPC to facilitate some of the communication between them. Our newer front-end applications, such as our Life Insurance and Home and Auto product flows, as well as our internal CRM, are React/Redux apps backed by GraphQL APIs.
Product Discovery Track
Every new feature starts its life as a twinkle in a stakeholder’s eye. That twinkle takes the form of a “north star” OKR, such as “Increase Life Application Bookings”, that are then prioritized on a tertile basis. We plan as a company in tertiles: 4 month periods instead of 3. Sounds weird, I know, but it helps us take larger swings during planning cycles and spend more time iterating.
Once a team’s “north star” OKR is outlined, the product managers will build a bunch of hypotheses out of user data and interviews. We follow a dual track development process at Policygenius, with the discovery track amounting to user interviews, user prototype testing, quantitative surveys and focus groups.
The discovery track is led primarily by Product Managers and Designers, though we strive for engineers to participate by sitting in on occasional user interviews and being very hands-on during solution brainstorming. We believe that engineers, through their knowledge of new technology trends and extensive hands-on exposure to the product, are an important ingredient in conceiving innovative product features.
Once we start solidifying a solution, we will model out an epic and think through technical decisions and ways to de-risk development through spikes or workshopping technical designs with engineers from other teams.
Product Development Track
While all that discovery goodness is happening, Product and Design will outline user stories for it in Clubhouse and finalizing high fidelity designs in Zeplin. Every Thursday, each team has backlog grooming, where user stories are clarified by Product/Design and estimated based on relative complexity.
We have an Iteration Planning Meeting first thing every Monday, where Product, Design and Engineering on a team sit down and commit to that week’s iteration. Throughout the iteration, engineers will have brief kick-offs with Product and Design to make sure we’re aligned on a feature’s behavior and design. We’ll run daily stand-ups to uncover any blockers or set up some pairing time to share context or unblock a given feature. Once a feature is fully built and supported by some good test coverage, we’ll grab either the Product Manager or Designer on our team for a desk check before requesting a code review from other engineers.
We use BuildKite for our CI platform, and alongside manual code review, each feature branch runs its suite of unit, integration and feature specs, as well as frontend asset size checks, linting and GraphQL API contract testing before it can be merged. Once merged and on staging, Product and Design accept the feature, and also have nightly user testing done as an additional safeguard against regressions before deploying to production.
Finally, if the feature is going to be deployed as an experiment, we’ll configure an experiment in Optimizely or feature flag, depending on the size and complexity of the experiment.
Tech Initiatives
Outside of feature work and team-specific tech debt work, engineers also have 20% of their time allocated to work that pushes our platform as a whole forward.
These tech initiatives develop organically, with a given engineer outlining a critical, large area of tech debt or platform optimization, and specifying the scope and underlying value of the given tech initiative. This engineer will recruit other engineers to develop a plan and ultimately solve the tech initiative over the course of a tertile. Some examples of tech initiatives may include building a new user micro-service, creating a streaming data pipeline proof-of-concept, or designing a new testing architecture. Taking this approach to tech initiatives has empowered engineers to make meaningful improvements to our development workflow and grow ourselves as engineers by solving problems outside of our product roadmap. You can find more information on how we’re building a generative work culture through tech initiatives here.
We’re Growing!
We’ve gathered a pretty great bunch of product, design and engineering folks to tackle some pretty tough problems in the insurance industry. Fun fact: we still need a lot more. If you’re interested in what we have going on here and want to help us on our mission to make insurance suck less, mosey on over to our careers page to see if something fits.
