Seventy-eight percent of workers in the United States report living paycheck to paycheck at least some of the time, according to a Harris Poll conducted last year. And while budgeting may help some break that cycle, many hourly workers simply aren’t able to pick up enough shifts to make the equation add up.
That’s not necessarily because there aren’t enough companies who need them.
Shiftgig has built an online marketplace to match companies with expert bartenders, cashiers, administrative assistants and everything in between. The goal, said Director of Product Irem Metin, is to provide a flexible way for hourly workers to make more money.
“I’ve never been part of an organization where the mission is such an important part of how people think about what they’re building,” she said. “It brings in a particular type of person who looks for meaning in their work.”
We spoke with Metin and CTO Rick Bowman to learn more about that mission, how their team is rebuilding their platform with cutting-edge cloud technology and how Spotify inspired Shiftgig’s mode of collaboration.
WHAT THEY DO: Shiftgig’s two-sided marketplace technology matches hourly workers with companies in need of their services.
THE STACK: Python for back-end microservices and React for front-end web applications. Shiftgig’s mobile teams develop native apps using Swift and Kotlin. Shiftgig also leverages a range of AWS tools, including Athena, Lambda and Kinesis.
INNOVATION SPRINTS: Quarterly events where team members pitch new features and spend two weeks building them.
CS DEGREE?: Not required.
SQUADS: Inspired by Spotify, Shiftgig divides its tech teams into small, self-contained teams that conceive, design and deliver new features independently.
IDEAL CANDIDATES: Technologists who think about how their work impacts the end user, and who aren’t afraid of stepping out of their comfort zones while collaborating on projects.
WE SPOKE WITH
Rick Bowman, chief technology officer: In charge of big-picture decisions about team structure, talent development, adopting new technologies and sunsetting old ones.
Irem Metin, director of product: Leads the team responsible for researching user challenges, discovering new ways to address them and prioritizing the product roadmap.
What was it about Shiftgig that enticed you to join?
Rick: I used to work for a D.C. startup called HelloWallet, whose mission was to improve financial wellness for all Americans. But we really struggled to reach hourly workers. What many of them really needed — in order to break the paycheck-to-paycheck cycle and start saving — was a way to earn additional income. It’s hard for any one person to drive up pay rates across an industry, but what we can do is offer people flexibility and opportunities to work more if they want to. That’s what Shiftgig does.
It’s hard for any one person to drive up pay rates across an industry, but what we can do is offer people flexibility and opportunities to work more if they want to.”
How do you work toward that goal?
Rick: Our company has gone through multiple pivots. It started as a job board before turning into a one-sided marketplace with satellite offices in 14 different cities. Today, we’re a two-sided marketplace — and we’re really doubling down on our technology. Our product and engineering teams have really rolled with the punches and stayed with us throughout those pivots because they believe in the mission.
Irem: I’ve never been part of an organization where the mission is such an important part of how people think about what they’re building. It brings in a particular type of person who looks for meaning in their work.
One unique challenge of building a marketplace like yours is that different users need different things from your product. How do you address that challenge?
Irem: The key is to actually understand how people work. Our brains are wired to do things a certain way, and we need to make sure our products line up with that. We can’t expect users to do the work for us. It requires us to constantly talk to users and gather data about what they want from our technology.
You’re currently moving your platform to the cloud. What’s that process been like?
Rick: Leveraging the cloud effectively is important because it reduces repetitive work. We no longer have to spend time ensuring that our servers are running efficiently or keep them from going down. But it also matters for scalability. Our business has tons of seasonality. If we run our own servers, we can’t adjust our capacity without buying and setting up more of them.
Our team has been really engaged in figuring out not only how to run what we have in the cloud, but how to actually build for the cloud. To do that, we’re leveraging a lot of the latest technologies Amazon has to offer. We’re building a serverless environment, deploying individual functions rather than entire applications and using streaming technology to avoid outages. Basically, we’re investing heavily in making our own lives easier.
Our team has been really engaged in figuring out not only how to run what we have in the cloud, but how to actually build for the cloud.”
Irem: My team is building an AWS microservice for the first time, and I can tell how the approach has changed our mentality. Teams are empowered to research available technologies and really think hard about the best solution for each problem. Sometimes, that means we use different data stores for different functions. It allows us to break down problems really effectively and move a lot faster.
You mentioned that teams get to make a lot of decisions on their own. How are those teams structured?
Rick: We’ve adopted a lot of techniques from Spotify that encourage empowerment of individual contributors and small teams. The goal is to create self-contained squads that are as small as they can possibly be while still being able to make decisions and deliver products independently. Our squads consist of native iOS and Android engineers, one or two back-end engineers, two web engineers, a UX designer and a product manager.
Our teams are empowered to make choices, but they’re also responsible for uptime and for supporting and maintaining their code in the long term. That tends to elevate everyone’s game. At many companies, developers hand their code to a QA team responsible for figuring out if it works. Then someone in operations takes responsibility for keeping it running. If you’re responsible for maintaining your own code, you’re less likely to pick a random new technology without thinking through what it will be like to maintain and support it.
Why did you decide to structure your teams that way?
Rick: Speed. Our teams can incept, research, prototype, build, deliver and operate a feature from beginning to end. Having as few cross-team dependencies as possible keeps people from blocking each other. It’s also easier for small groups to make quick decisions.
Our squad structure is based on agile practices, but we’ve adopted some other concepts to make it scale. We have “chapters” organized around core functions, allowing people with similar roles to surface problems they’re encountering and share key discoveries in weekly meetings. We do that to avoid creating knowledge silos within squads.
Does that way of working attract a particular kind of person?
Irem: Definitely. Some product managers like to come up with their own solutions and tell engineers to just build it that way. That would never fly here. No one person can come up with better ideas than a squad can. Everyone needs to understand what everyone else is doing and be open to feedback, as well as to different perspectives about how to solve a problem.
It also creates opportunities to step outside of our comfort zones and learn new things. When one of our teams needed more back-end resources, a front-end engineer stepped up and said she could get the work done — it would just take her a bit longer. And the team chipped in by answering questions she had while figuring it out. It helps us deliver faster, but it also helps us grow as professionals.
Some product managers like to come up with their own solutions and tell engineers to just build it that way. That would never fly here.”
How involved are your teams in designing your future roadmap?
Irem: If you can articulate a strong business case for feature, we will build it. Some of our features have also been developed during innovation sprints. Our worker onboarding process was developed during an innovation sprint, as was our tool for providing feedback to workers after a shift. The fact that our teams built these really impressive tools in two weeks says a lot about their passion and their focus.
Rick: One of our principal architects even built a coding apprenticeship program for non-engineers during an innovation sprint. One of our team members just graduated from that program. Sprint-based processes can sometimes feel like you’re just marching forward to make very small amounts of progress at a time. Innovation sprints allow us to take a step back and think about bigger ideas.
What are you most excited about in the year to come?
Irem: This year, our focus is on features that will delight our users. We’re trying to make it more efficient for workers to join the platform, and make it easier for clients to enter and track orders on the platform — particularly at the last minute. We’re also enhancing the feedback we provide to workers to help them understand how they’re doing and how they can improve. That project aligns very closely with our mission.