Gabe Westmaas

Engineering Your Organization

Tilt HQ

As businesses grow, and their products evolve, the teams building those products evolve as well. As a leader it is important to remember that how you design your organization is just as important as how you design your product and your architecture. Your team is how you win in any space, and organizing to help them execute is absolutely vital.

At Tilt, we recently made an organizational change designed to increase ownership, make communication more efficient, and to improve our ability to prioritize product changes that are best for our customers. Organizational changes can often be hard, and seem difficult to implement, but the alternative of leaving inefficiencies in place can be far worse. Below I’ll explain how our teams evolved so far at Tilt, and how the recent changes have impacted our work so far.

Simple Beginnings

From the very beginning, we built Tilt as a platform, not just a simple web application. From day 1, we had an API application, and a web app that talked to it. We knew we’d want to be able to quickly build more apps (and experiments) on top of our API and leverage it as a solid core for our business logic. Given this, the early team structure was obvious: first it was 1 engineer doing everything. Then it was 1 engineer doing API work and 1 engineer doing web/front-end work.

The teams continued to ‘scale up’ with this structure, and it actually worked pretty well—to a point. Eventually, we ended up with 5 or 6 ‘API’ engineers, and 5 or 6 ‘front-end’ engineers, and it started to become clear that maybe we could do better.

But…the Product!

From a product perspective, whenever we’d have a new feature to build, such as search, the team structure began to seem counter-productive towards those feature goals. As a company, we wanted search, but we just had these front-end and backend teams, each with their own set of priorities driven by needs from several other teams, especially in the case of the backend team. So, depending on each teams backlog and current priorities, we’d have to first figure out if both teams could work on search at the same time, or if we’d need to coordinate the backend team to design + implement first so that by the time the front-end team was ready, the backend was built.

There are obviously a lot of moving parts and complexity with this picture, and lots of places for things to go wrong or become delayed. If the backend team misses the deadline, the front-end team can’t fully dive in just yet. If the front-end team finishes early, they may have to pull something else from their backlog while waiting for the API to be ready.

We have a great team of engineers here at Tilt, so we were still able to deliver a great product despite some of these inefficiencies. For a long time we simply relied upon strong communication and a lot of heroic effort to deliver on as much as possible, even if it meant reworking things as the various teams caught up to each other.

Most recently with search, we experimented with mini-teams made up of engineers from various teams that would come together to deliver a feature – they would have separate standups, and be in constant contact until the feature was delivered. But it still had its issues.

Product Teams

We started thinking that maybe these ‘mini’ project teams should actually be what our ‘normal’ teams looked like. If we had more product-focused teams that were ‘full-stack’ in expertise, those teams could work together to more quickly deliver product features and improvements that fit into their product specialty. Looking around the industry, we saw that other smart folks like Spotify and Others had come to similar conclusions. It took us a little while to come up with the right product ‘buckets’ to structure our teams around, but once we did, we made the change and noticed results right away.

The teams we ended up with are as follows:

  • Tilters: Focuses on aspects of the product that revolve around individual users, such as friend invites, Facebook login, profile pages, rewards programs, etc.
  • Tilts: Focuses on all aspects of a tilt, such as the tilt page, organizer tools, tilt creation, tilt invites/tagging, etc.
  • Payments: Focuses on our payments + payouts infrastructure, contribution flows, refunds, chargebacks, and generally all things related to money.
  • Notifications: Focuses on managing communications and notifications with our users. This includes things like Push Notifications, Emails, Notification Center, etc.

Takeaways

Ownership. It was incredibly clear to everyone how much ownership was created and improved by the product-focused teams. Almost instantly engineers started changing their thinking about how they could improve the new product verticals that they owned and had increased responsibility for. While we had decent ownership before, this was of a new breed. Engineers are now more engaged in actively improving the user experience and the codebase, and they can do so with more focus than before.

Communication has improved greatly. It’s become much easier for support, product, and design team members to know which engineers to go to when they have issues or questions about different aspects of the product. There is much less ‘hunting’ to find the right person for a specific feature, and having questions bounce around from person to person. It remains to be seen if we’ll face new and different communication issues that we didn’t have before, but none have become readily apparent thus far.

Prioritization is refreshingly easier. With the old teams, prioritization was more based on what the “backend” or “frontend” needed to do to their respective codebases. Often each team would have lots of separate product features on the roadmap, and prioritizing was tricky, and also involved the cross-team coordination mentioned above. With the new product-focused teams, it has become much clearer how each team should prioritize their respective verticals. There’s no contention between user features and tiltfeatures, for example, as they can be prioritized separately amongst their specific teams.

Problem Solved… Right?

The goal of this reorganization was the goal of all reorganizations – to balance out inefficiencies in the engineering team. It was very important that we acknowledge what new inefficiencies we were taking on in order to remove existing ones. Specifically, some widespread changes become more difficult to implement, as engineers must change code that is “owned” by another team. Also, there is a risk of technology and style drift between teams that we aren’t ready for yet. We decided that we would rather rely on our engineers and team leads to watch for this rather than lay down a bunch of policies to try and prevent it.

Conclusion

At Tilt, we have a culture of experimentation. We really do believe that failures are as important as successes, and, more importantly, a fear of failure will limit one’s success. That’s why we were willing to make these organizational changes, but we’re also constantly evaluating what’s working and what’s not. We’ll be watching to make sure we haven’t traded one set of communication hurdles for another. If we have, we’ll have learned something valuable in the process.

While re-orgs aren’t easy, they really don’t have to be that bad. If anything, after seeing the positive results, we feel like we took too long to finally pull the trigger. You can do better by answering these questions about your organization:

  • Do product managers need to talk to several teams to release almost every feature for which they are responsible?
  • Do you find that teams are often waiting for another team to finish a requirement before moving forward, and that this requirement is delayed because of other priorities?
  • Do you see signs of inefficient communication between teams? This can manifest as missed requirements, a misunderstanding of the goals of the feature, etc.
  • Do you see signs that your teams don’t exhibit strong ownership over their code because they know they will soon move on to other unrelated projects/features?

If you think a change may be needed, be willing to move fast, experiment, admit when you fail, and keep getting better. We’ll check back in over the coming months and see how we’re doing.

Want to help us build the world’s best crowdfunding platform? We’re hiring in San Francisco, Austin, and Toronto! Check out our openings.

« 10 Reasons to Never Use Perl, Ever Roll Your Own A/B Tests With Optimizely and React »