BRS-003: A Tale of Two Cultures
Move Fast and Break Things, Go Slow to Go Fast, & Observe and Learn - which is better.
In today’s newsletter: I talk about two cultures. In the news section, my fav economist calls BS, Microsoft thinks about buying TikTok, and I suggest a book to read, and some newsletter’s to subscribe to.
Welcome to Building Rome(s) - Issue 003.
📰 Newsworthy // 📚What You Should Read Today
Sarah Dayan shares lessons from her 10 years as a software engineer.
How the Tech Giants Make Money, Infographic style. It’s mostly ads.
My favorite Economist calls BS on Secretary Mnuchin. (Atif Mian)
Microsoft wants to buy TikTok. The Verge breaks it down - its all about data, data, and data and maybe some more?
“A Tale of Two Cultures” // Essay
In tech, corporate culture can be rather dogmatic. Along with the big salaries and those free food, gym memberships, other perks, culture is one of the most referenced reasons to work for a company - startup or big corp. The fancy by lines scream to you “We are the cool ones”. Without a doubt, the most famous of the cultural bylines is Mark Zuckerberg’s “Move Fast and Break Things”. It captures the mood in Silicon Valley and tech startups in general. It is this thinking that allowed Amazon, Google, Twitter, Facebook to grow into the giants they are today. But, much of the issues we see in tech are the results of this culture. Another giant has managed to do something different. “Go Slow to Go Fast” was the mantra at Apple. I still recall the day vividly when Kim Vorrath, the VP of iOS Program Office, made the statement in one of our Software Engineering all-hands. I was a believer from the get go. Let’s talk about why this is better than the rallying cry of Silicon Valley. 👩🏽💻
When we think of Move Fast & Break Things, the following things come to mind:
Do everything, whatever sticks sticks. (That is basically the Google strategy; sometimes running two experiments in parallel as a competition. Everything feels ephemeral and getting excited about things both inside and outside Google becomes a challenge. This was true even when I was working at Android Things.)
Constantly subjecting users through experiments leaves for a sour user experience sometimes (Facebook is notorious for this. Try finding the “Most Recent” tab for your newsfeed in the Facebook App.)
Breaking things is necessary and key element of disruption.
Iteration via making mistakes is acceptable, also encouraged; consequences of failed experiments are a necessary cost of innovation.
Move Fast & Break Things does not have to apply to technology only (Uber is a prime example of this.)
In contrast, Apple ran on a counter narrative culture to the Valley’s Move Fast and Break Things (MFBT). Go Slow to Go Fast (GSTGF) is a deliberate effort to identity, understand, assess, evaluate, plan, and then move like hell to deploy features and solutions. Every iOS release that I worked on followed this pattern. We didn’t spend time doing A/B testing or experiments. Here is how it all went down:
It begins with identifying a problem that we cared deeply about or saw an opportunity to bring the Apple magic of simplicity and surprise and delight.
Begin to explore why this particular problem exists and all its facets. (This thinking style comes from Steve Jobs way of working and his uncanny ability to find flaws in everything. Even with Steve no longer with us, I believe his greatest legacy is this thinking style that remains at the heart of how Apple does feature development.)
Identify how we would solve the problem through deliberation, collaboration, and thought experiments between Design, Engineering, and Product Marketing. (Often times it just comes down to asking the greatest question of all times, “How would my mom use this?”. You have no idea how many features I worked on at Apple where this question was used as a guiding principle. Keep it simple.)
When a solution feels “right”, plan it down to the teeth. (“Right” here is a gut check. Its not an A/B testing or focus group, its when we the team working on it feel its right and solves the problem identified. A part of the process is reviewing the design & solution with senior leaders like Craig Federighi, Eddy Cue, Design leaders, etc.)
Then scramble like a roadrunner to ship it. (One of the things that remains unexplainable and truly Apple is how fast we developed features at Apple. Once we set the direction, identified a solution, you didn’t have to struggle with getting teams to focus, everyone understood what was on the line and we must prioritize resources to get this done no matter what.)
The second most common question I as asked while at Apple, first being how much discount I get on Apple products, was how does Apple build products that make them so good. Credit lies with the culture of taking steps deliberately. Although it may seem counterintuitive in an industry where speed is the key to capturing a marketing or innovative feature, at Apple, we focused more on shipping the “right stuff”, not “many things”. That deliberate and coordinated movement is the reason why everything Apple did feels full of surprise and delight. 🤔
The cultural shift in the Valley from the MFBT philosophy to the more GSTGF model is evident. In a recent interview on the NYT Daily podcast, Jack Dorsey, Founder & CEO of Twitter, talks about how much of the problems Twitter faces today comes from a cultural and usage perspective on stems from the consequence of moving fast without recognizing how certain decisions would play out in the long-term. Jack alludes to put his focus now on building a culture at Twitter of Observe and Learn and leveraging more game theorist, social science and psychologists to understand how certain design decisions can impact usage and engagement of users on twitter. This is perfectly in line with how Apple has always operated thus additional evidence that the if you want to ship things with surprise and delight, try going slow to go fast. 🙏🏽
Further Suggested Reading: To learn more about the Apple Way of doing things, I recommend reading Creative Selection: Inside Apple's Design Process During the Golden Age of Steve Jobs by Ken Kocienda - former software engineer and designer at Apple for over fifteen years. I had the opportunity to see Ken in action on some projects and during “How to be an effective DRI” session at Apple University, I got to listen to his story of how they convinced Steve to ship pinch to home screen on the original iPad.
See You Next Time! 👋🏽
If you enjoyed reading this, please do share with your friends, family, colleagues, Linkedin peeps, twittersphere, or you know whatever/wherever you have.
If you haven’t already, please subscribe ;)
Note from Aadil - I am so excited about the sudden explosion in some really spectacular newsletters. I can’t help but feel challenged to bring more and more design thinking to my own. I am going to try new things that I strongly believe will make it for a better reading experience so stick around. Things are getting fun.
Some newsletters I think you should subscribe to -
John Culture - The Beautiful Mess
Lenny Rachitsky - Lenny’s Newsletter
Kalsoom Lakhani - The Rabbit Hole
Jordan Singer - I Build My Ideas
Jordan Odinsky - Jordan Odinsky’s Newsletter
This was a great edition! I was once struggling to launch a product I wasn't happy with. My advisor who worked with Steve Jobs used the phrase for the first time with me "it's okay to Go Slow to Go Fast". It shifts my perspective. Since then we've gathered a ton of data on every time how when we "moved fast to break things" how much time we actually ended up losing in follow up fixed, and backtracking. In some cases moving fast costed 2-3x more than if we had slowed down for the initial release.