For Mia Forte, being one of the first million users of the Lose It! app is a statistic the software engineer wears like a badge of pride. When she first applied to work at the healthtech company three years ago, she never anticipated that down the line, she’d be in rooms with data scientists, marketing professionals and other developers making business-altering decisions.
Thanks to the team’s recent organizational restructuring, that’s exactly what she’s been doing.
In 2019, Lose It! split up conventional departments to make what they now refer to as the core team, the social features team and the NextGen team. Each team is made up of a total of five to 10 marketing, engineering and data science professionals who bring expertise from their respective fields to the group.
What they do
While such a team structure isn’t necessarily common in the Boston tech world, it isn’t the first example of development stemming from heterogeneous ingenuity. Over the last few decades, cross-departmental groups have benefited companies both big and small. According to Inc., success stories include Northwestern Mutual Life’s information systems department and Reprint Management Services, a business whose owner found the results of the structure to be “immediate and impressive,” implementing the process into all future products.
Eric Puidokas, president of Lose It!, attributes the success of the groups to the food search team, a group whose work spurred the idea for the model as a long-term strategy.
“When everyone was aligned that way, development just became so much easier. We felt like everyone was running in the same direction,” he said. Not only did it eliminate contention over who decided how resources were allocated, it gave developers a sense of autonomy they didn’t previously have.
He doesn’t see that changing anytime soon.
“It scales really naturally,” he said. “Our plan is that, as we grow and those teams start to get a little bit too big, we will split them off and create new ones.”
How The Cross-Functional Teams Came About
Tell us about the cross-functional nature of the engineering team. How did that structure specifically come to be?
Pete Wierzbinski, engineering manager, product: For the longest time at Lose It!, we started off as individual teams, which included the iOS team, the Android team and the infrastructure team. Those teams grew out as the company grew. Then a couple of years back, we decided to create the food search team because food search is such a critical part of the app. And it worked well. Then we saw onboarding needed a lot of work. So the food search team became the onboarders team. Starting this year, we became focused on the cross-functional teams.
Eric Puidokas, president: When we used to plan out work, we had to consider both the functions and developers. I think on the dev side, we’ve really seen the benefits of cross-function. But when you look outside of engineering, you see the marketing team wanting to utilize engineering resources. I think there was probably a little bit of a frustration or a need to actually use resources outside of one department’s skill set.
When the marketing team would ask for resources to work on a project, there would always be contention over who got to decide how those resources were allocated. And so we started to look for mechanisms to put those groups together. And rather than marketing and product working against each other, we could say, “Get one marketing person, get an iOS developer, get an Android developer and put them in a planning group together.”
The food search group convinced us this model made sense. Before 2018, we used to pair up developers from around the company to work on a particular project. Once the project was over, we’d break up that group. By the end of it, they would start to get in the flow and learn how to work with each other and communicate well.
FUNCTIONAL TEAMS AT LOSE IT!
The Structure’s Impact
What is an example of a specific benefit you’ve seen that working cross-functionally brings about?
Mia Forte, software engineer: The company values are much more highlighted in that small-team context because you’re actually able to sit in on these conversations; you’re able to speak up. When I was new to the company, it was really valuable to feel like my voice mattered. That smaller team format amplifies that tenfold. When this method was announced, I was ecstatic. I think it’s such an improved workflow for most engineers. We get the benefit of working with data science and marketing.
These conversations and ideas from different points of view in the same room happened, but not everybody got to be a part of those conversations. Most engineers weren’t a part of the planning process. To be in the room, to have the door open, so to speak, is really, really valuable from a career standpoint and from a growth standpoint. Starting your career, you want to be able to have that space in your working environment.
And then there’s the actual technical benefit to have to learn to trust your own voice and trust your own instincts. In a much smaller format, you get the benefit of saying, “Hey, doing that amount of work in that period of time is not something I am capable of, but let me suggest an alternative. Here’s what I am able to do in that period of time.”
As you work together more as a team, you all start to trust each other more. The bane of any engineering team is underestimating tasks, which always happens. But it happens a lot less in that smaller scale format as time goes on.
When I was new to the company, it was really valuable to feel like my voice mattered.’’
Puidokas: There’s a line to walk. If you shuffle people too much, they never get into rhythm. If you never shuffle them, they get stuck in their ways and don’t have new ideas. So for the past couple of years here, we said, once a year, we’re going to shuffle the teams for long enough that you get that rhythm, but not stuck in your ways.
How do you decide between a project that’s more timely and one that will have the biggest positive impact?
Puidokas: The social team is currently working on a project involving reporting posts within the app’s social network. Historically, it’s been something we’ve had trouble focusing on. It’s always hard to make a case for it. A lot of times it’s weighted against things that could make the company more money; things that are going to have higher utilization, like food logging. This process of really constraining the focus down has allowed us to make progress on such things.
That’s the thing I really love about being a product person. There are areas of the app that I think we were less proud of before but couldn’t really justify why we’d go work on them. Reframing it in this mechanism means we can choose areas of the app and make sure they get better. Every single circuit, every single set of work that we plan, we can guarantee that something’s going to improve.
Why wouldn’t you just bring more people into the groups that are working on projects that will make the most amount of money?
Puidokas: It’s always a tricky balance between the short-term and the long-term. A lot of times, making more money is a very short-term decision. It’s something that’s very measurable. But these other things, like making a healthy social network where our users are able to encourage each other to be successful, that’s something that doesn’t pay off immediately. It’s like weight loss. You don’t hit your goal in a week; in a month; sometimes if your goals are big enough, you don’t even hit them in a year. But it’s still important that you figure out mechanisms to make progress. It’s really about figuring out the forcing function to get out of that short-term tunnel vision and make sure you’re doing enough work on the long-term.
The Teams’ Future
What challenges are associated with this model of work?
Wierzbinski: These teams do work on very specific areas of the app. So, if you see something outside of your team that you might want to improve on, it might fall into someone else’s purview to fix. For example, on the social team, Mia saw an issue during food logging. That’s not quite the social team’s job to fix.
Our solution to that is a pitching process. We do eight-week circuits similar to sprints. The first week of every circuit is a planning week, which starts off with people pitching ideas of what’s important, short-term wins employees can get, and long-term progress they can make. Then we open up the floor to others at the company to come in and pitch ideas. Through the remainder of planning week, we flush ideas out, cut them down and then bring them back to the organization to get everyone’s final feedback. It’s not a democracy, but it gives a good idea of what the company as a whole feels is really important.
CIRCUIT SUCCESS
How do you see this model scaling?
Puidokas: It scales really naturally. There’s an ideal team size of five to 10. If it’s too big, you start slowing down. If it’s too small, you can’t cross enough disciplines. Our plan is that, as we grow and those teams start to get a little bit too big, we will split them off and create new ones. Our headcount determines how many focuses we can have each year. This year it’s three. We’re hoping to hire a few more developers and, hopefully next year, we can have four.
