As the engineering lead on the Flexible Pay team, I often get asked by my colleagues, “What is it like to work in a startup within a startup?”
First, some context: Two years ago, Gusto decided to build the Flexible Pay feature, offering employees the opportunity to access their paycheck on their own timeline, and without any added cost to the employer. Instead of building it as part of an existing org, we chose to incubate this v1 product. The intention was to allow the team to go from zero to one as quickly as possible. So we carved out an envelope budget, and started the team with a PM and an engineer in a tiny conference room. By immersing themselves in the problem, talking to customers and through constant learning, experimentation and iterating, a product-market fit began to emerge. The project has now grown to a cross-functional team of 15. We encountered situations that are common to any incubated greenfield team within a big organization. If you’re starting such an endeavor or even thinking about it, here are some things to keep in mind.
1. Align your idea to get buy in
For a typical startup, getting an idea off the ground involves pitching to investors. But unlike a startup, we were part of an existing organization with a mission, values, and business objectives. At Gusto, our mission is to create a world where work empowers a better life. Personal prosperity is a key pillar in achieving this mission.
One of our early engineers often wondered why US workers were only paid at the end of the pay cycle rather than getting their wages after a day’s work. When you combine this with the fact that 40% of US workers need help to cover a $400 emergency, it created a compelling pitch to our leadership team. As a payroll company that facilitates workers receiving their paychecks, we were in a unique position to solve this problem by letting employees access their earned income prior to payday. By enabling personal prosperity for our customers, we could enhance Gusto’s core business and offer a differentiated benefit to both employers and employees.
2. Allow people to break their traditional roles
It is critical to be flexible, especially early on, when there are more roles than people. The benefit of an established org around you is that it gives you access to a lot of advisers in various functions. They can help you avoid common mistakes, point you to the right resources and save you time and money.
Eventually, though, your team must do the heavy-lifting and wear all the hats that your advisers wear during their day jobs. In our case, this involved marketing and customer acquisition, wireframing, conducting user research and providing support to early adopters.
This, in turn, created a tight feedback loop that allowed us to adapt the product, test assumptions and change course when something wasn’t working.
3. Avoid hard dependencies in order to move fast
Since we were building a feature on top of Gusto’s existing payroll product, there were pieces of Flexible Pay that required changing other teams’ codebase. Rather than asking the teams to incorporate our requests in their quarterly plans, we took the work on ourselves. This meant we had to ruthlessly prioritize and constantly make tradeoffs. Engineers had to be nimble and frequently switch context.
Our engineers had previously worked on other parts of the system, which meant they could easily build complex flows interacting with multiple domains such as payroll, payments and onboarding. This would not have worked without constant communication, pairing and code reviews from other teams. Though there were moments when a change caught the dependent team off-guard, in most cases we were able to give plenty of lead time and get the team’s input and approval.
4. Identify and hire specialized roles early
One strategy that gave the team a lot of autonomy was to have a dedicated budget. We carved out a portion from the overall company budget, with the intent to short-circuit the dependencies between recruiting, finance, legal, credit policy, and accounting. This allowed us to sit outside the company’s operational planning, and empowered us to make decisions around hiring, partnerships, external counsel and financing. Being a financial product in a highly regulated space, this meant we prioritized hiring a full-time legal expert, a financial analyst, and product partnerships lead as some of the early team members.
5. Rely on existing infrastructure
As tempting as it was for us to have own dedicated service, it really helped to lean on existing infrastructure, developer tools, monitoring, alerting and security systems. This allowed us to focus on the core functionality that we were building, instead of having to figure out solved problems, such as getting a CI system in place.
This works until you have found product-market fit. Once you do, it is just as vital to quickly pivot and build for the long term. One way to do this is to provide a strong technical vision alongside the product vision and make sure the team is not in 'prototyping mode' as you begin scaling.
6. Take the right shortcuts
Since the team is expected to move fast, there will be a temptation to take on technical debt, cut corners, avoid tests, code reviews, or design reviews. While some of these may seem like things a startup would do, we still have the company’s established brand and reputation at stake, especially in the financial domain. We followed our engineering best practices, and ensured features were fully tested and code reviewed for the most part. Instead we were deliberate about cutting scope, and favored building simpler interactions over more complex ones. These simpler paradigms allowed for getting things in front of customers faster, throw out things that didn’t work, and only polish things which we intend to keep.
7. Be accountable
Treat the rest of the company as your investors. Sitting outside the regular operational planning cadence doesn’t mean that our team didn’t set goals and measure results. We were meticulous with what and how we measured, ensuring we were getting the right insights to inform quick decisions. We shared progress updates with the core team members on a weekly basis, and provided updates to leadership when we made big strategic changes.
Hopefully these learnings will help you think about building a startup within your company. While the approach cannot be applied to every initiative, it has been working well for us while building Flexible Pay. It provides us with the right balance of autonomy to make quicker decisions and support from Gusto’s specialized functions to overcome hurdles faster. As evidence we’re proud of going from zero to one with a sophisticated financial product in under a year!