From Twitter Spaces to Independent Artists: Leading Org-Based Innovation

Imagine a future where anyone can be a musician. Now ask yourself what that has in common with building Twitter Spaces. The answer? Org-based innovation. 

On this week’s episode of Dev Interrupted, we’re joined by the talented Pablo Jablonski, the engineer responsible for leading the team behind Spaces. Today, Pablo is reshaping the music industry as the VP of Engineering at United Masters. 

In this free-flowing conversation, we unravel the intricacies of building Spaces, discuss Twitter’s pivotal role in public discourse and break down some of the historic challenges faced by Twitter’s engineering team.  

Pablo also explores how United Masters is bridging the gap between artists and their dreams, empowering them to take control of their own destinies. Taking cues from his time at Twitter, Pablo and his team are building a platform that aims to dismantle the music industry’s traditional hierarchies. 

Pablo Jablonski: "The thing that I've not only taken from Twitter to United Masters, but just have always believed my entire time as an engineering leader, is that you can't build effective teams if the mission statement is the technology. The mission statement has to be the people that we're serving and the customer problem that we're solving."

Episode Highlights

• (2:00) Building Periscope & Spaces at Twitter
• (7:10) Twitter's 10 Rules for Communication
• (12:59) The impact of modeling behaviors
• (15:55) Twitter today
• (22:54) United Masters
• (26:14) Applying lessons learned at Twitter
• (34:24) Any problem can be interesting
• (37:30) Future of the music industry

Episode Excerpt

Conor Bronsdon: What were those 10 rules for communication?

Pablo Jablonski: I'm gonna see if I can remember all 10 of them, but I know most of them.

One of them, which was very controversial at times within Twitter, is obvious if you're in a startup, which was, we are self-reliant. That was a single rule that basically played the part of saying whenever we can do things ourselves, we will. And at Twitter, there was basically the idea that Twitter has spent a decade building different teams of people who are able to accomplish different sets of things, and the expectation is that you work with those teams of people to accomplish those things because it creates a better sense of just like overall, unity and also just being able to like, have the code base have a follow more defined pattern.

But for every group that you work with, it's another group you have to communicate with. It's another set of dependencies. You have to operate it within, and it also means that if something breaks, it's another set of people who have to then understand how to fix that thing that went broken, right? We took the more sort of radical approaches saying if we can do it ourselves, we will.

This means we actually maybe didn't employ some of the different functionality or team usages that other teams at Twitter might have provided. But it allowed us to really internalize the knowledge of what we were building. It allowed us to move faster from a dependency perspective. And when we launched quickly, we had bugs we expected to have. Our team knew how to fix them.

We knew what we were doing. We knew how to fix them because it was our code, so that one was controversial at times because there were definitely teams at Twitter that thought we might have; we should have taken more advantage of what Twitter might have already. But that one was necessary for us to move in at the pace that we did.

I'd say that was the most controversial of all of them. The other ones are pretty, non-controversial, but important. Another one that we talked about a lot was the idea that collaboration is key. collaboration, cross functions, and collaboration between engineering, product design, and research that is absolutely key to a successful product.

However, we also need to recognize that it will be impossible to always reach a consensus, right? We have the idea that collaboration is key, and consensus is notch. We have to go into it understanding that we will not always agree across all the functions about what we should do, and that's. We have to timebox ideas.

We have to timebox decisions, we have a conversation, and then we have to make a decision, and we have to move forward. So we had a very hard rule that every decision has one approver, that's, there's one person who makes the call, and that person is always the subject matter expert, right? If it's a product decision, the PM is a final approver.

If it's an engineering decision, the engineer has a final decision. And if we had that rule upfront, it would have allowed for this cross-functional collaboration. But we all had an agreement. Hey, the product person might disagree with the engineering decision but is an engineering decision, so the engineer has a final call.

We're good with that, and we're moving forward, and that really allowed us to move a lot faster and allowed us to move at a pace that we weren't like spending weeks discussing the same thing over and over again, which is something that you would see quite a lot of Twitter because there were so many groups and so many different stakeholders that these conversations could go on for weeks, and that was something that we knew we had to get ahead of.

So you really wanted to get this out. So that's one, that's another really big one. Another one that we had that I, that was also very important, and this is actually the number one rule was the first one. Yeah. The first rule was, take care of yourself first. it was us acknowledging that we were gonna be asking a group of people to work very hard for a period of time to get something out.

If people didn't take care of themselves first, things would fall apart.

Full Transcript Here