Scaling the Small-Startup-Get-Things-Done Mentality @ JoyTunes
Why we started working in pods, and what we found out along the way
JoyTunes is enjoying massive growth, with business growth exceeding the pace of team and company building. Expanding the team and the company are good challenges to have, but challenges nonetheless. To continue growing rapidly, we have to be especially mindful about how to do it right so that we can become a truly spectacular company; one that creates wonderful music learning services for all and that can move very fast.
tl;dr we implemented an extreme startup within a startup structure, called pods, to maximize impact velocity and reduce the risk of becoming mediocre. This structure offers many benefits while presenting quite a few challenges. We like it.
JoyTunes is creating a music learning companion for every household. Our service, situated on the crossroads of music, lifestyle, education and consumer subscription, is quite unique. More importantly, we’re trying to build something really, really big. Our growth strategy is all about building an amazingly impactful and fast moving company, even when we’re much larger in size, or rather, especially when we’re much larger in size. This lends itself to a somewhat different structure and process, as seen in some lessons we describe here. But first, what problems are we trying to solve?
Maximizing Impact Velocity
In the past, at JoyTunes and in other companies, many of us have often experienced the frustration of feeling sluggish, as if everything in the company was moving annoyingly slowly. Every feature and/or decision required an endless cycle of approvals, jumping up and down the hierarchical pyramid along with countless meetings (sprinkled with some fun office politics, gotta love those) that were missing context and a clear goal.
These are just some of the issues we were so concerned with when scaling the company. There are many others.
It is not uncommon to hear CEOs of companies with over 200 employees say things like, “how I miss it when we were 40 people, we could really move fast back then.” Some mention specifically the law of diminishing returns, meaning that employee #231 doesn’t add nearly as much impact as, say, employee #28. Moreover, for some companies, adding more people actually reduces their throughput: aka negative returns.
This outcome of diminishing returns is quite understandable. When you’re a team of 15, you focus only on what matters most to get by. As you grow, you start adding processes, departments, supporting disciplines, managers, managers of managers, IT for managers of managers, etc. As we scaled at JoyTunes, this phenomenon really troubled us. So, somewhat naively, we decided to challenge the common wisdom. We declared war on diminishing returns.
Pods Perspective 1: declaring war on diminishing returns
Edge of a Cliff
Reflecting on JoyTunes’ history, we started by pinpointing when we ‘crushed it’ and when things were quite bad. An (extreme) example of this happened just after downsizing our already small team. The resulting core team, while 30% smaller, moved much faster than before and achieved incredible(!) impact.
More recently, our 300%+ growth in revenue+users in the past year was fueled largely by a series of cliffs that our very small team had to tackle and overcome. I can’t stress this enough, the team has been unbelievable in doing the unimaginable.
Sparing you the gory details, a combination of a few principles can be identified that distinguished JoyTunes’ extreme good times from, well, not-as-good times:
- Focus, or, rather, a strong sense of “to be or not to be”
- Lots of passion
- Intense teamwork and ownership
- Doing whatever is needed, no ego
This list isn’t that surprising, I imagine. Interestingly though, these so called ‘good times’ were in reality quite bad in the more realistic sense. We were experiencing an existential threat; in other words, we were about to die.
Looking back, when we reached the edge of a cliff and we needed something to happen no matter what, we made it happen. It’s as simple as that. But as we grew, we noticed that spark starting to fade. Going into a culture/org frenzy, we started exploring what’s out there. We considered a lot of structures, like traditional departments, product teams, holacracy, and, of course, Spotify’s squads.
With all these references in mind, we came to a rather simple conclusion: let’s just (sort of) keep doing what we do now. Basically, and not for the first time, we went from our gut-feeling in the beginning, moved through an extensive research phase, only to end up in a place similar to our starting point. The difference is that now we’re equipped with guiding principles and a whole lot of confidence.
Pods in a Nutshell
The pods are small, focused startups, composed of roughly four to ten strong and resourceful people sharing a clear goal and lots of ownership. Pod members ideally possess all the disciplines and resources needed to make a (mind-bending) dent, and have the ownership needed to do whatever it takes to get it done. They must be able to move fast, make smart (and hard) decisions, work closely with each other and deliver loads of impact and value to our many users.
For example, a pod responsible for usage in the app currently includes senior developers, a development lead, a product lead, musicians (yeah!), marketing leads, a data guru and a product designer. In revenue/impact terms, the relative impact, or rather the specific weight of each pod member is higher than that of our team members when we were much smaller — a small (work in progress) win over diminishing returns.
The core principles we defined internally:
- Smallish, limited resources — forces everyone to make difficult decisions all the time. There’s no ‘cream’, everyone is super important.
- Hands on, do whatever is needed, no ego.
- Focus! Every pod has a goal on which to focus, and, more importantly, a list of all the things they’re NOT working on.
- Ownership, independence — in pursuing its goal, the pod owns its own fate. There are no top-down plans forced on the team. The pod decides on a plan for achieving their goals and executes it accordingly.
Pods Perspective 2: small startups within a startup
Guilds as a Crucial Complementary Element
To complement the pods, we started to define our professional guilds. This approach is not unique to JoyTunes, but it’s important to highlight the guilds as a crucial part of the pod structure, enabling its growing scale.
Generally speaking, the guilds are responsible for advancing the professional level in the company. They set a super high bar for hiring, and offer continuous training, syncs among members of different pods, mutual learning opportunities, etc.
The guilds offer an alternative view of the pod system. In the now common matrix management structure, all iOS devs, for example, sit together in a team, all designers are in a team, etc., and a business owner / product manager syncs with relevant people across teams. The primary dimension is therefore who you sit with, which takes up most of your attention and time, while the secondary dimension of this management matrix is the business challenge/goal.
In the pod system, we flip the primary and secondary dimensions of the matrix (aka transpose), having all team members that sit together work on a strategic goal of the company, whether they are developers, designers, marketing, business development, etc., and the professional guilds become the complementary second dimension.
Pod Perspective 3: transpose (management_matrix)
As an example, the dev guild at JoyTunes is all about learning new tools, code review, training sessions, dev conferences, deciding on dev issues across the company, talks, syncing release cycles, etc.
Does this scale?
The short answer is yes. The ability, or lack thereof, to scale the small startup mentality was the main reason for insecurity when moving in this direction. This was the issue we explored the most. What we learned from other companies, like Spotify and Netflix, is that, basically, such scaling can be done, but that it requires additional guidelines and adaptations which we implemented immediately. I will cover these in a separate post.
Training
As with other small startups, people are expected to learn on the job, and quickly. While this creates a high bar for hiring in general (described below), it also means that the pods must be structured in a way that there needs to be a mentoring mechanism for decision making, product-market fit, leadership, and even getting-shit-done attitude. We used to throw people off the deep end, only to see some drown miserably. Throwing in some floaties helped, but lacking swimming guidance, 4 out of 5 people will continue to float around after a year. Floating means being stagnant, and for what we’re trying to build, being stagnant means, well, the end of life, universe and everything.
Pods Perspective 4: a crash course in startup building
Known Bugs (Features?)
We discovered quite a few challenges while working this way. Some were tagged under ‘known issues’ while others were flagged to be mitigated (work in progress). Here’s a selection of some bugs:
- Blind Spots — gaps between pods aren’t covered using this approach. While this can be mitigated, it’s more of a feature than a bug.
- Very(!) high bar for hiring — the impact of each person joining is equal to or even greater than that of an early employee in a small startup. This means we require strong thinkers who enjoy having a strong impact on the product and the users’ experience.
- Doesn’t work that well with occasional/part-time work. Creative solutions are needed to address this issue.
Pods are the Best Thing Ever Invented
No, they are not. In fact, they are not even a sufficient nor necessary structure for attaining amazing velocity. But we found them to be very (!) helpful in optimizing what we care about most, while dealing with disadvantages, as discussed above. As an agile coach from Spotify once told us, “All structures are bad by definition. You need to choose what’s really important for you and optimize for that.”
We optimized on our impact velocity and that has proved itself effective time and again. Still, we keep reminding ourselves about what matters: impact velocity, and not processes or “rules”, even those relating to our beloved pods.
Also, work in progress….. yada yada yada.
This blog post was written in light of a talk I gave to Aleph portfolio founders, Product and R&D leads, on the topic of Working in Squads
