BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Articles Q&A on the Book Competing with Unicorns

Q&A on the Book Competing with Unicorns

Key Takeaways

  • The world’s best tech companies work differently.
  • They don’t do traditional Agile.
  • Building products is different from automating inhouse systems.
  • Empower. Trust. Get out of the way.
  • Take away the excuses.

The book Competing with Unicorns by Jonathan Rasmusson explores the culture of tech unicorns like Google, Amazon, and Spotify, and dives into the techniques and practices that they use to develop software.

InfoQ readers can download an extract from Competing with Unicorns.

InfoQ interviewed Jonathan Rasmusson about how startups are different, creating teams that are capable of building great products, getting comfortable with the unknown, missions, bets and dibbs, software development at Spotify, and how unicorns view culture.

InfoQ: Why did you write this book?

Jonathan Rasmusson: I wanted to take people behind the scenes and show them how some of the worlds best tech companies develop software.

InfoQ: For whom is this book intended?

Rasmusson: Anyone who delivers software for a living: developers, testers, designers, project managers. But really it’s for leaders, and people who set up and organize teams focused on product and software delivery.

InfoQ: How are startups different from traditional enterprises?

Rasmusson: Startups put a premium on learning, whereas traditional enterprises reward following a plan.

Startups begin life with a hunch, and a pile of unknowns. They need to get out there and discover: who their customers are, what problem they are best suited to solve, and what product they need to build to solve it.

Traditional enterprises typically don’t have any of those problems. They know exactly what system needs to be automated, who their customers are, along with the requirements.

This leads to two very different ways of working. One puts a premium on learning, while the other rewards following a schedule.

InfoQ: How would you define unicorns?

Rasmusson: A unicorn is a wildly successful software startup with a valuation of over a billion dollars. They include some of the most popular companies in the world like Apple, Google, Amazon, Facebook, and Spotify. They are called unicorns because this level of growth and success are rare, which is why you see so few of them.

InfoQ: What can we do to create teams that are capable of building great products?

Rasmusson: Trust. Empower. And get out of the way.

Unicorns like Spotify trust and empower their employees in ways few traditional companies ever would. They give them missions instead of projects. They let them set their own priorities and create their own work. They don’t try to manage them the way traditional enterprises do. They give them a goal. Ask teams what they need to get there. Provide it. And then get out of the way.

InfoQ: You mention in the book that working at a startup means working in the unknown. How can we get comfortable with that?

Rasmusson: I think it starts with culture. You need to develop a culture that supports trying and failing, exploration and discovery, and not blindly following a plan. There is no plan. You need to discover the plan for yourself. And that’s only going to happen if you have a culture that supports this way of working. If you punish failure, no one will fail. But no one will really try either.

I remember this one time, a colleague of mine accidentally broke Spotify on a major third-party streaming service. He had accidentally pushed the testing configuration into prod, thereby breaking production.

After some digging and realizing that he had caused the error, he sent an email to the entire tribe describing what the problem was, how it occurred, and apologized. He was a new hire and he felt really bad.

The response from my boss was classic. Instead of coming down on the person, and demanding changes to how we release changes into production, he basically said:

"Don’t worry about it. These things happen. Breaking prod is a kind of badge of honor. You aren’t the first. You certainly won’t be the last. And the fact you were able to do this speaks more to deficiencies in our systems -- not your abilities as an engineer or new hire."

This response was perfect. Not only was our leader signalling that mistakes were going to happen, he was signalling that they were OK -- and that it was part of the game. And the answer isn’t less autonomy and more rules. It’s, "We trust you. We got your back. Get out there and try again."

InfoQ: How do missions work? How do they empower squads?

Rasmusson: Missions are goals unicorns give teams, after which they leave them to figure out how best to meet themselves. Instead of creating a project, hiring a team, and then giving them requirements around how to stream music in the car, a mission would be: "Win the morning commute" and then leave the team to figure out how best to get there. It’s not completely hands off. Leadership will have some ideas around what success looks like, but it’s up to the team to figure out how to get there.

And that’s how they empower. Missions engage teams to get off their butts, not wait to be told what to do, and figure out the best way forward themselves.

InfoQ: What's the purpose of company bets and dibbs and how do they work in practice?

Rasmusson: Bets are about focus. Instead of trying to do 100 things across the company, company bets are really big rocks that require the effort of the entire organization.

For example, shortly after arriving at Spotify, I was the coach responsible for the team that was tasked with integrating Spotify into the Sony Playstation. This was the number one bet in the company, which meant that if we needed support from any other team in the organization, we got it.

This was a huge undertaking. It required working with Sony teams spread around the world. It required the knowledge and expertise of countless teams within Spotify, all against a tough deadline. If we didn’t have a means of communicating the urgency across the company,  program across Spotify, coordinating and getting the resources needed would have been very tough. But because everyone in the organization knew what this initiative was, and the importance it carried for the company, a lot of teams put their day-to-day work on hold, helped us deliver, and ultimately ship.

Dibbs (Data, Insight, Belief, and Bet) are how companies like Spotify create hypotheses around bets. Instead of just saying, "We think it would be good if we launched Spotify in Japan, or put Spotify on the Sony Playstation," they will create a DIBB and try to back up that hypothesis with some real data and insights.

For example, one summer Spotify noticed that people weren’t listening to music as much as they used to when returning to work after summer vacations. And they didn’t immediately know why. That’s when someone at the company had a hunch that maybe they were, just not how they used to. So they created a DIBB around mobile. The bet was that more people were listening to music on their mobile phones, and fewer on their desk-tops. And if this were true, it would mean that we as a company were not optimized for the right thing! We should start looking at hiring more mobile developers, training people in iOS and Android development, and build infrastructure for shipping mobile applications.

InfoQ: What does continuous improvement look like at Spotify?

Rasmusson: It’s everywhere. It’s not an option. Spotify gives teams great autonomy in how they work. One thing they don’t compromise on however is continuous improvement. You will improve.

They do this in a variety of ways. Teams hold retrospectives. Company-wide bets are reviewed after they are delivered. Teams are continuously engaged with work satisfaction surveys, and are constantly monitored for things like stress, happiness, and fulfillment. It’s not perfect. But they really try to help you and your team improve.

InfoQ: How do data scientists support teams?

Rasmusson: Data scientists help teams decide what metrics make sense to collect, and then distill them into insights the team can use. So a team that is looking to increase engagement in a particular part of the app might reach out to a data scientist and ask, "What kind of test could we run to determine whether the share controls should appear at the top or the bottom of the now playing screen?"

InfoQ: How does the Spotify culture look and feel?

Rasmusson: Empowering and safe. The thing I liked the most about Spotify culture is the empowerment they give when it comes to doing your work. They want you to be successful. They want you to do your best work. And they sincerely feel that the best way to do that is to empower you, trust you, and let you direct your own work as much as possible.

And you are never alone. You are a part of a team. Spotify puts more work into forming, managing, and monitoring the health of their teams than any other place I have seen, because they know the company is going to live and die by their success. Which is why every team has a trio of managers that meets regularly, monitors and tracks how the team is doing, and does whatever they can to help them out. Help can come in the form of training, mentoring, communicating and making introductions to other parts of the company, or even changing the composition of the team if that would help the team or the individual.

So they focus on setting up highly trusted empowered teams, and then build the rest of the company around that.

InfoQ: How do unicorns view culture?

Rasmusson: That depends. Not all unicorns view culture the same way. Apple used to be highly secretive. Netflix likes to think of themselves as a sports team. Google is all about engineering. And at Facebook they really want you to ship products. All these companies view culture differently, and it’s usually heavily influenced by the founders.

InfoQ: What's your advice for putting things that we can learn from unicorns into practice?

Rasmusson: Take away the excuses. Give teams missions. Support them with what they need. Then take away any excuses they might have traditionally had for failing. Don’t like the schedule? Let them create the schedule. Disagree with the priorities? You set them. Let teams drive them. Let teams own them, empower and trust, and they will deliver.

About the Book Author

Jonathan Rasmusson is an experienced programmer with an aversion for titles. Rasmusson has helped some of the world’s leading software companies find better ways of working and playing together. When not cycling to work in the throes of a Canadian winter or practicing his broken Swedish, you can find him sharing his latest thoughts on software programming.

Rate this Article

Adoption
Style

BT