Prior to Gusto, I built products in a world where the Product Management (PM) team “owned” the product. The PM team would come up with the product strategy, write the specs, and hand everything off to engineering. From functional specs to development and then on to testing and release, all of these steps were orchestrated by project managers, who helped create and refine formal procedures. The boundaries were well-defined and visible: PMs sat on one side of the building and engineers on another.
When I joined Gusto, I discovered that EPD (Engineering, Product and Design) teams work very differently. Teams are organized into missions. A mission has a well-defined charter around solving challenging problems for our customers, whether internal or external. Missions mix groups of people across Engineering, PM, Design, and other cross-functional teams like Data Science, Credit Policy, or Operations. This diverse group sits next to each other, constantly interacting and developing a strong camaraderie.
As an example, we recently worked on paying employees faster by “reverse wire.” When we rolled it out to our first pilot customer, we ran into an issue fetching their payroll funds. Our operations team member made us aware of the issue, our engineer diagnosed the issue and looped me in, and I was on a call with our vendor within 15 mins. After many back-and-forth calls with the vendor, we gingerly babysat the first payroll transaction to ensure the customer’s employees got paid on time!
I thus witnessed first hand the power of small teams. Small teams that care about the same challenging customer problems take on ownership without needing to be told exactly what to do, work out the right amount of process for them, and unleash creativity in unexpected ways.
And while this approach may sound obvious, I remember “escalations” like the above to be much more stressful before Gusto. We would have meetings one after the other and my role was to provide business justification to team members who were much further removed from the customer problem at hand. In contrast, thanks to the power of small teams, I see a lot more smiles here!
Are there drawbacks to this world? Sure, no system is perfect. For example, when we were building the functionality above, we had two engineering teams that didn't know what the other was doing because they were working on completely different parts of the code. I have observed that providing and encouraging easy mechanisms to give and get feedback helps us improve quickly. The solution in this case was a lightweight 5 min stand-up every week that drew the teams even closer together. The important learning is to develop organizational structures deliberately and intentionally. When in doubt, err on the side of fewer formal, top-down processes and let teams self-organize around a well-understood mission centered on solving important customer problems.
