The ultimate goal of a growth team is to enable, activate, and retain paying customers on the platform who like the functionality so much, they’re willing to refer others to it—which creates a flywheel of satisfied customers and boosts revenue along the way.
The work is done, your team has spent the days, weeks, months, building a new feature and it is ready to deploy! But wait - will this new feature break everything? Build confidence in your new feature with a test fest.
Gusto is a custodian of some of your most sensitive personal and financial information. We take this responsibility seriously, and are constantly reviewing our security posture and data handling practices for ways to improve well beyond the industry
It’s been two years since we gave the world a look at a “normal day” as a Gusto engineer [https://engineering.gusto.com/a-day-in-the-life/]. Since then the org has grown nearly three-fold and matured as an organization.
In this final part of the series, we will take a closer look at how to actually bring an experiment to life as a full-fledged feature. If you think the hard work is complete once the project is defined, think again!
I embarked on a mission with fellow Gusto engineer Alyssa Hester to find and complete an experiment solely focused on customer outcomes. In this first post of this series, we’ll talk about how Alyssa and I found an outcome-based experiment and defined a realistic minimum lovable product (MLP).
photo by https://www.pexels.com/@cqf-avocat-188397Over the past few months, multiple teams at Gusto have been rallying behind initiatives that help businesses navigate the uncertainties brought by the Coronavirus pandemic. Among these projects is the Paycheck Protection
My team recently embarked on a journey toward unbundling our part of Gusto’s monolithic Ruby on Rails app. A monolithic app is a single application that contains code across many domains. The boundaries are unclear. The domains
