Like many software companies moving from the early to growth stage, we’ve experienced our fair share of challenges and pains. At the start of 2012, there were ~50 Mozzers, a very flat management structure, and things like process, communication, and planning were fairly simple. But over the next 12 months, we more than doubled to nearly 120 (today 130+) and a lot of those suddenly became much harder.
Earlier this year, Miranda from Moz’s product team did some research into new processes that could potentially scale with the company’s growth. They interviewed dozens of Mozzers, ran some brainstorming sessions, and came up with a set of recommendations. At an eteam meeting, Adam & Anthony (who run product & engineering, respectively) proposed that we make the move from primarily functional teams to feature teams.
In functional teams, the makeup at Moz looks like this:
- Engineering (with sub-teams)
- Product (with sub-teams)
- Marketing (with sub-teams)
- Operations (with sub-teams
But feature teams would look more like this:
- Open Site Explorer team (comprised of folks from product, engineering, and marketing)
- Data Warehouse team (comprised of folks from engineering, marketing, and operations
- Rankings team (comprised of folks from engineering, product, and marketing)
This structure is designed to help teams be more collaborative, less silo’d, and more productive, especially at companies that are achieving some scale. In functional teams, we often encounter an issue whereby team X designs something, team Y builds it, team Z is supposed to market it, and team Q needs to support/maintain it. No surprise, it’s not always fun and engaging to work on a project/product someone else designed or built when you had no input. But if everyone who’ll be working on the project/product gets to kickoff and give feedback along the way together, you get some of that same magic that small, early-stage startups have where everyone is working in concert towards a shared goal.
I had just one complaint – the naming convention. For some, the term “feature teams” has specific connotations and conjures up pre-existing notions of how that structure should work. Since we were getting a little creative and making our own version, I wanted a name that was unique, and wouldn’t carry any baggage from the past. And, since I’m obsessed with Adventure Time (Halloween costume evidence here), we picked “Adventure Teams.”
For several months, we worked to circulate and iterate on the Adventure Teams concept. Through September and October I built a slide deck that was reviewed by most of the folks who’d given feedback about structure and process to Miranda, as well as the mangers. This week, I was supposed to present it to the company at our weekly Lunch & Learn session, but had some emotional health issues and so Adam stepped in to deliver it. I was sad to miss it, but heard the hour went well.
You can see the deck below:
I have no doubt that this new process will have plenty of challenges and in a year, we’ll know much more about what works and doesn’t than we do today. But I’m excited for this new system. I think it’s empowering to the Moz team and will result in faster production and iteration on our roadmaps.
If you have feedback or ideas, we’d love to hear them!