Spotify Engineering Culture - Part 1
-
0:06 - 0:07One of the big success factors here
-
0:07 - 0:10at Spotify is our Agile Engineering Culture.
-
0:10 - 0:12Culture tends to be invisible.
-
0:12 - 0:13We don't notice it
-
0:13 - 0:14because it's there all the time.
-
0:14 - 0:15It's kind of like the air we breathe.
-
0:15 - 0:17But, if everyone understands the culture,
-
0:17 - 0:19we're more likely to be able to keep it ..
-
0:19 - 0:21.. and even strengthen it as we grow.
-
0:21 - 0:23So, that's the purpose of this video.
-
0:23 - 0:24When our first music player
-
0:24 - 0:25was launched in 2008.
-
0:25 - 0:27We were pretty much just a scrum company.
-
0:27 - 0:29Scrum is a well established
-
0:29 - 0:30agile development approach ..
-
0:30 - 0:32and it gave us a nice team-based culture.
-
0:32 - 0:34However, a few years later,
-
0:34 - 0:35we had grown into a bunch of teams
-
0:35 - 0:37and found that some of
-
0:37 - 0:38standard scrum practices
-
0:38 - 0:39were actually getting into the way.
-
0:39 - 0:41So, we decided to make all these optional.
-
0:41 - 0:43Rules are good start, but then
-
0:43 - 0:45break them when needed.
-
0:45 - 0:46We decided Agile matters
-
0:46 - 0:47more than Scrum and ...
-
0:47 - 0:48... Agile Principles matter
-
0:48 - 0:50more than specific practices.
-
0:50 - 0:51So, we renamed
-
0:51 - 0:53the Scrum Master role to Agile Coach.
-
0:53 - 0:54Because, we wanted Servant Leaders
-
0:54 - 0:55more than a Process Masters.
-
0:55 - 0:57We also started using the term
-
0:57 - 0:59Squad instead of Scrum Team.
-
0:59 - 1:01And our key driving force became Autonomy.
-
1:01 - 1:03So, what is an Autonomous Squad?
-
1:03 - 1:05A Squad is a small cross-functional
-
1:05 - 1:07self-organizing team ..
-
1:07 - 1:09usually less than eight people.
-
1:09 - 1:10They sit together ..
-
1:10 - 1:12and they have ene-to-end responsibility
-
1:12 - 1:13for the stuff they build,
-
1:13 - 1:14design, commit, deploy,
-
1:14 - 1:16maintenance, operations,
-
1:16 - 1:17the whole thing.
-
1:17 - 1:19each Squad has a long-term mission ..
-
1:19 - 1:20such as "Makes Spotify
-
1:20 - 1:22the best place to discover music."
-
1:22 - 1:23or internal stuff like
-
1:23 - 1:25infrastructure for A/B Testing
-
1:25 - 1:27Autonomy basically means that
-
1:27 - 1:28the squad decides what to build,
-
1:28 - 1:29.. how to build it and
-
1:29 - 1:31.. how to work together
-
1:31 - 1:32while doing it?
-
1:32 - 1:33There are of cause
-
1:33 - 1:34some boundaries to this such as
-
1:34 - 1:36the squad mission,
-
1:36 - 1:37the overall product strategy
-
1:37 - 1:39for whatever area they are working on
-
1:39 - 1:40and short-term goals
-
1:40 - 1:42that are re-negotiated every quarter.
-
1:42 - 1:45Our office is optimized for collaboration.
-
1:45 - 1:46Here is a typical squad area.
-
1:46 - 1:49Squad members work together here
-
1:49 - 1:50with adjustable desks
-
1:50 - 1:52and easy access to each other's screens.
-
1:52 - 1:53We gather over here
-
1:53 - 1:55at the lounge for thing like
-
1:55 - 1:56planning session and retrospectives.
-
1:56 - 1:58and back, there is a huddle room
-
1:58 - 1:59for smaller meetings or
-
1:59 - 2:01just get some quite time.
-
2:01 - 2:02Almost all walls are whiteboards.
-
2:02 - 2:05So, why is autonomy so important.
-
2:05 - 2:07Well, because it's motivating
-
2:07 - 2:08and motivated people
-
2:08 - 2:09build better stuff.
-
2:09 - 2:10Also, autonomy makes us fast
-
2:10 - 2:12by letting decisions happened locally
-
2:12 - 2:14in the squad instead of
-
2:14 - 2:15via a bunch of mangers
-
2:15 - 2:16and committees and stuff.
-
2:16 - 2:17It helps us minimize hand-offs
-
2:17 - 2:18and waiting.
-
2:18 - 2:19So, we can scale
-
2:19 - 2:21without block out with dependencies
-
2:21 - 2:22and coordination.
-
2:22 - 2:23Although, each squad has
-
2:23 - 2:24its own mission.
-
2:24 - 2:25They need to be aligned
-
2:25 - 2:26with product strategy,
-
2:26 - 2:27company priorities,
-
2:27 - 2:28and other squads.
-
2:28 - 2:30Basically, be a good citizen
-
2:30 - 2:31in this Spotify eco-system.
-
2:31 - 2:33Spotify's overall mission is
-
2:33 - 2:33more important than
-
2:33 - 2:35any individual squad.
-
2:35 - 2:36So, the key principle is
-
2:36 - 2:37really be autonomous
-
2:37 - 2:39but don't sub-optimized.
-
2:39 - 2:40It's a kind of like a Jazz man.
-
2:40 - 2:42Although, each musician is autonomous
-
2:42 - 2:44and plays his own instrument
-
2:44 - 2:45They listen to each other
-
2:45 - 2:46and focus on the whole song
-
2:46 - 2:47together
-
2:47 - 2:48That's how great
-
2:48 - 2:49music is created.
-
2:49 - 2:51So, our goal is loosely coupled
-
2:51 - 2:53but tightly aligned squads
-
2:53 - 2:55We're not all there yet.
-
2:55 - 2:56But, we have experiment
-
2:56 - 2:57a lot with different ways
-
2:57 - 2:58of getting closer
-
2:58 - 2:59In fact, that applies
-
2:59 - 3:00to most things in this video
-
3:00 - 3:01This culture description is
-
3:01 - 3:03a mix of what we are today
-
3:03 - 3:05and what we are trying to become
-
3:05 - 3:06in the future.
-
3:06 - 3:07Alignment and Autonomy
-
3:07 - 3:08may seem like
-
3:08 - 3:09different end of a scale.
-
3:09 - 3:11as in more automy
-
3:11 - 3:12equals less alignment.
-
3:12 - 3:14However, we think of it more like a
-
3:14 - 3:16two different dimensions.
-
3:16 - 3:17Down here is
-
3:17 - 3:19low alignment and low autonomy,
-
3:19 - 3:21a micro-management culture.
-
3:21 - 3:22No high-level purpose
-
3:22 - 3:23, just shut up and
-
3:23 - 3:24follow orders.
-
3:24 - 3:25Up here is
-
3:25 - 3:26high alignment, but
-
3:26 - 3:27still low autonomy.
-
3:27 - 3:28So, leaders are
-
3:28 - 3:29good at communicating
-
3:29 - 3:29what problem needs
-
3:29 - 3:30to be solved.
-
3:30 - 3:31But, they also tell
-
3:31 - 3:32people how to solve it.
-
3:32 - 3:35High alignment and high autonomy
-
3:35 - 3:37means leaders focus on
-
3:37 - 3:38what problem to solve.
-
3:38 - 3:39But, let the team
-
3:39 - 3:41figure out how to solve it.
-
3:41 - 3:42What about down here then?
-
3:42 - 3:43Low alignment
-
3:43 - 3:45and high autonomy
-
3:45 - 3:46means team do whatever they want
-
3:46 - 3:48and basically all running in
-
3:48 - 3:49different directions.
-
3:49 - 3:50Leaders are hopeless
-
3:50 - 3:51and our product
-
3:51 - 3:52becomes a Frankenstein.
-
3:52 - 3:53We are trying hard
-
3:53 - 3:54to be up here.
-
3:54 - 3:55aligned autonomy
-
3:55 - 3:57and we keep experimenting
-
3:57 - 3:58with different ways
-
3:58 - 3:59of doing them.
-
3:59 - 4:01So, alignment enables autonomy.
-
4:01 - 4:02The stronger alignment we have
-
4:02 - 4:05, the more autonomy we can effort to grant.
-
4:05 - 4:07That means the leader's job
-
4:07 - 4:08is to communicate
-
4:08 - 4:09what problem needs to be solved
-
4:09 - 4:10and why?
-
4:10 - 4:12and the squads collaborate with each other
-
4:12 - 4:13to find the best solution.
-
4:13 - 4:15One consequence of autonomy
-
4:15 - 4:16is that we have
-
4:16 - 4:18very little standardization.
-
4:18 - 4:19When people ask things like
-
4:19 - 4:21which code editor that you use
-
4:21 - 4:22or how do you plan?
-
4:22 - 4:24The answer is mostly
-
4:24 - 4:25depends on which Squad
-
4:25 - 4:26some do Scrum sprints
-
4:26 - 4:27others do Kanban
-
4:27 - 4:29some estimate story
-
4:29 - 4:30and measure velocity
-
4:30 - 4:31others don't
-
4:31 - 4:31it's really up to
-
4:31 - 4:32each squad
-
4:32 - 4:34Instead of formal standards
-
4:34 - 4:35we have strong culture of
-
4:35 - 4:37cross-pollination
-
4:37 - 4:38when enough Squads use
-
4:38 - 4:39a specific practice
-
4:39 - 4:40or tool such as
-
4:40 - 4:42Git. That becomes the path of
-
4:42 - 4:43least resistant
-
4:43 - 4:45and other Squads tend to pick
-
4:45 - 4:46the same tool
-
4:46 - 4:47Squad starts supporting
-
4:47 - 4:48that tool and helping
-
4:48 - 4:48each other
-
4:48 - 4:49and it becomes
-
4:49 - 4:50like a de facto standard.
-
4:50 - 4:51This informal approach
-
4:51 - 4:53gives us a healthy balance
-
4:53 - 4:55between consistency and
-
4:55 - 4:55flexibility.
-
4:56 - 4:57Our architecture is based on
-
4:57 - 4:59over a hundred separated systems,
-
4:59 - 5:00coded and deployed
-
5:00 - 5:01independently.
-
5:01 - 5:02There are plenty of interactions.
-
5:02 - 5:03But, each system focuses on
-
5:03 - 5:04one specific need
-
5:04 - 5:06such as play list management
-
5:06 - 5:08search or monitoring.
-
5:08 - 5:09We tried to keep them
-
5:09 - 5:10small and de-coupled
-
5:10 - 5:12with clear interfaces and protocols.
-
5:12 - 5:14Technically, each system is owned by one Squad.
-
5:14 - 5:16In fact, most Squads own several.
-
5:16 - 5:17But, we have an
-
5:17 - 5:18internal Open-source model
-
5:18 - 5:20and our culture is more about
-
5:20 - 5:21sharing than owning
-
5:21 - 5:23suppose Squad one here needs
-
5:23 - 5:24something done in System B
-
5:24 - 5:26and Squad 2 knows that code best
-
5:26 - 5:29They typically asked Squad 2 to do it.
-
5:29 - 5:31However, if Squad 2 doesn't have time.
-
5:31 - 5:32or they have other priorities.
-
5:32 - 5:35Then, Squad 1 doesn't necessary need to wait
-
5:35 - 5:36We hate waiting.
-
5:36 - 5:37Instead, they're welcome
-
5:37 - 5:38to go ahead edit
-
5:38 - 5:39the code themselves
-
5:39 - 5:40and asked Squad 2
-
5:40 - 5:41to review the changes.
-
5:41 - 5:43So, anyone can edit any code.
-
5:43 - 5:44But, we have a culture of
-
5:44 - 5:45peer code review.
-
5:45 - 5:47This improve quality and
-
5:47 - 5:49more importantly spread knowledge.
-
5:49 - 5:51Over time, we evolved design guidelines
-
5:51 - 5:53, code standards, and other things
-
5:53 - 5:55to reduce engineering friction.
-
5:55 - 5:56But, only when badly needed.
-
5:56 - 5:57So, on a scale from
-
5:57 - 5:59Authoritative to Liberal
-
5:59 - 6:00We're definitely on
-
6:00 - 6:01the Liberal side.
-
6:01 - 6:02Now, none of this would work
-
6:02 - 6:04if it wasn't for the people.
-
6:05 - 6:06We have a really strong culture
-
6:06 - 6:08of mutual respect.
-
6:08 - 6:09I keep hearing comments like
-
6:09 - 6:11my colleagues are awesome.
-
6:11 - 6:12People often give credit to each other
-
6:12 - 6:13for great work and
-
6:13 - 6:15seldom take credit for themselves.
-
6:15 - 6:16Considering how much talent
-
6:16 - 6:17we have here
-
6:17 - 6:19There is surprisingly little ego.
-
6:20 - 6:21One big Ah-ha for new hires
-
6:21 - 6:22is that autonomy
-
6:22 - 6:24is kind of scary at first.
-
6:24 - 6:25You and your Squad mates
-
6:25 - 6:26are expected to find
-
6:26 - 6:27you own solution.
-
6:27 - 6:28No one will tell you
-
6:28 - 6:29what to do.
-
6:29 - 6:30But, it turns out
-
6:30 - 6:31if you asked for help
-
6:31 - 6:32you get lots of it
-
6:32 - 6:32and fast.
-
6:32 - 6:34There is genuine respect
-
6:34 - 6:35for the fact that
-
6:35 - 6:36We're all in this boat together
-
6:36 - 6:37and need to help
-
6:37 - 6:38each others succeed.
-
6:39 - 6:40We focus a lot on motivation.
-
6:40 - 6:41Here is an example ...
-
6:41 - 6:44an actual email from the Head of People Operations
-
6:44 - 6:45Hi Everyone,
-
6:45 - 6:47Our employee satisfaction survey
-
6:47 - 6:50says 91% enjoy working here
-
6:50 - 6:51and 4% don't.
-
6:51 - 6:52Now that may seem like
-
6:52 - 6:54a pretty high satisfaction rate
-
6:54 - 6:56especially considering our growth pain.
-
6:56 - 6:58from 2006 to 2013
-
6:58 - 6:59we've doubled every year.
-
6:59 - 7:01and now have over 1200 people.
-
7:02 - 7:03But, then it continues
-
7:03 - 7:06This is of course not satisfactory
-
7:06 - 7:07and we want to fix it.
-
7:07 - 7:09If you're one of those unhappy 4%,
-
7:09 - 7:10please contact us.
-
7:10 - 7:12We're here for your sake,
-
7:12 - 7:13and nothing else.
-
7:13 - 7:14So, good enough isn't
-
7:14 - 7:15good enough.
-
7:15 - 7:16Half a year later
-
7:16 - 7:17things have improved
-
7:17 - 7:20and satisfaction rate was up to 94%.
-
7:20 - 7:22This strong focus on motivation
-
7:22 - 7:23has helped us build up
-
7:23 - 7:24a pretty good reputation
-
7:24 - 7:25as a workplace.
-
7:25 - 7:27But, we still have plenty of problems
-
7:27 - 7:28to deal with. So, yeah
-
7:28 - 7:30we need to keep improving.
-
7:30 - 7:32Okay, so we have over 50 Squads
-
7:32 - 7:34spread across 4 cities.
-
7:34 - 7:36Some kind of structure is needed.
-
7:36 - 7:38Currently, Squads are grouped
-
7:38 - 7:39into Tribes.
-
7:39 - 7:39A Tribe is
-
7:39 - 7:41a light-weight matrix
-
7:41 - 7:43Each person is member of a Squad
-
7:43 - 7:44as well as a Chapter.
-
7:44 - 7:46The Squad is a primary dimension,
-
7:46 - 7:47focusing on product delivery
-
7:47 - 7:48and quality.
-
7:48 - 7:50While the Capter is a competency area.
-
7:50 - 7:53such as Quality Assitant, Agile Coaching, ..
-
7:53 - 7:54or Web Development.
-
7:54 - 7:55As Squad member,
-
7:55 - 7:58my Chapter lead is my formal line manager
-
7:58 - 7:59is servant leader focusing on
-
7:59 - 8:01coaching and mentoring me as an engineer.
-
8:01 - 8:04So, I can switch Squad without getting a new manager.
-
8:04 - 8:06It's a pretty picture, hah?
-
8:06 - 8:07Except that it's not really true.
-
8:07 - 8:10In reality, the lines aren't nice and straight
-
8:10 - 8:12and things keep changing.
-
8:12 - 8:13Here is a real-life example.
-
8:13 - 8:14from one moment in time
-
8:14 - 8:15for one Tribe.
-
8:15 - 8:17and of cause it's all different by now.
-
8:17 - 8:18and that's ok.
-
8:18 - 8:20The most valuable communication happens
-
8:20 - 8:22informal and un-predictable ways.
-
8:22 - 8:25To support this, we also have Guilds.
-
8:25 - 8:28A Guild is a lightweight community of interest.
-
8:28 - 8:30where people across the whole company gather
-
8:30 - 8:32and share knowledge within a specific area.
-
8:32 - 8:34For example Leadership, Web Development,
-
8:34 - 8:35or Continuous Delivery.
-
8:35 - 8:38Anyone can join or leave the Guild at anytime.
-
8:38 - 8:39Guilds typically have a mailing list,
-
8:39 - 8:42bi-annual un-conferences, and ...
-
8:42 - 8:43other informal communcation methods.
-
8:44 - 8:46Most organizational charts are illusion.
-
8:46 - 8:48So, our main focus is community
-
8:48 - 8:50rather than hierarchical structures.
-
8:50 - 8:52We found that a strong enough community
-
8:52 - 8:53can get away with
-
8:53 - 8:55an informal volatile structure.
-
8:55 - 8:57If you always need to know exactly
-
8:57 - 8:58who is making decisions.
-
8:58 - 9:00You're in the wrong place.
-
9:00 - 9:03One thing that matters a lot for autonomy
-
9:03 - 9:06is how easily get our stuff into Production?
-
9:06 - 9:08If releasing is hard,
-
9:08 - 9:10we'll be tempted to release it seldom
-
9:10 - 9:11to avoid the pain.
-
9:11 - 9:13That means each release is bigger
-
9:13 - 9:15and therefore even harder.
-
9:15 - 9:16It's vicious cycle.
-
9:16 - 9:17But if releasing is easy,
-
9:17 - 9:19we can release often.
-
9:19 - 9:20That means each release is smaller
-
9:20 - 9:22and therefore easier.
-
9:22 - 9:23To stay in this loop
-
9:23 - 9:25and avoid that one.
-
9:25 - 9:27We encourage small and frequent releases
-
9:27 - 9:29and invest heavily in Test Automation
-
9:29 - 9:31and Continuous Delivery infrastructure.
-
9:31 - 9:34Release should be routine not drama.
-
9:35 - 9:37Sometimes, we make big investments
-
9:37 - 9:38to make releasing easier.
-
9:38 - 9:41For example, the original Spotify desktop client
-
9:41 - 9:43was a single monolithic application.
-
9:43 - 9:44In the early days,
-
9:44 - 9:46we've just a handful of developers.
-
9:46 - 9:47That was fine.
-
9:47 - 9:50But, as we grew, this became a huge problem.
-
9:50 - 9:51Dozen of Squads have to synchonize
-
9:51 - 9:53with each other for each release.
-
9:53 - 9:54And it could take months to get
-
9:54 - 9:56a stable version.
-
9:56 - 9:57Instead of creating lots of process
-
9:57 - 9:59and rules and stuff to manage this.
-
9:59 - 10:00We changed the architecture
-
10:00 - 10:02to enable Decupled Releases.
-
10:02 - 10:04Using Chromium embedded framework,
-
10:04 - 10:07the client is now basically a web browser
-
10:07 - 10:08in disguised. Each section is
-
10:08 - 10:10like a frame on the website
-
10:10 - 10:11and Squad can release
-
10:11 - 10:12their own stuff directly.
-
10:12 - 10:14As part of this architectural change,
-
10:14 - 10:16we started seeing each client platform
-
10:16 - 10:18as a client app
-
10:18 - 10:21and evolve three different flavors of Squads.
-
10:21 - 10:22Client App Squads
-
10:22 - 10:23Feature Squads
-
10:23 - 10:25and Infrastructure Squads.
-
10:25 - 10:27A Feature squad focuses on
-
10:27 - 10:28one feature area
-
10:28 - 10:29such as Search.
-
10:29 - 10:30This squad will build, ship,
-
10:30 - 10:33and maintain search related features
-
10:33 - 10:34of our platform.
-
10:34 - 10:35A Client App squad focuses on
-
10:35 - 10:37making release easy
-
10:37 - 10:39on one specific client platform
-
10:39 - 10:41such as desktop, iOS, or Android.
-
10:41 - 10:43An Infrastructure squad focuses on
-
10:43 - 10:45making other squads more effective.
-
10:45 - 10:47They provide tools and routines
-
10:47 - 10:49for thing like continuous delivery
-
10:49 - 10:51A/B Testing, Monitoring, and Operations.
-
10:52 - 10:54Regardless of the current structure,
-
10:54 - 10:56we always strive for a Self-service model.
-
10:56 - 10:58A kind of like a buffet,
-
10:58 - 10:59the restaurant staffs
-
10:59 - 11:00don't serve you directly.
-
11:00 - 11:02They enable you to serve yourself.
-
11:02 - 11:05So, we avoid hand-offs like the plague.
-
11:05 - 11:07For example, an operation squad
-
11:07 - 11:08or client app squad does not
-
11:08 - 11:10put code into production
-
11:10 - 11:11for people.
-
11:11 - 11:13Instead, their job is to make it easy
-
11:13 - 11:15for feature squad to put their own code
-
11:15 - 11:16into production.
-
11:16 - 11:19Despite the self-service model, we sometimes
-
11:19 - 11:21need a bit of sync between squads
-
11:21 - 11:22when doing releases.
-
11:22 - 11:23We manage this using
-
11:23 - 11:25Release Trains and Feature Toggles.
-
11:25 - 11:28Each client app has a release train
-
11:28 - 11:30that departs a regular schedule.
-
11:30 - 11:32Typically every week or every three weeks
-
11:32 - 11:33depends on which client.
-
11:33 - 11:35Just like in physical world
-
11:35 - 11:37if trains depart frequently and reliably,
-
11:37 - 11:39you don't need much up-front planning.
-
11:39 - 11:41Just show up and take the next train.
-
11:41 - 11:43Suppose these three squads
-
11:43 - 11:44are building stuff and
-
11:44 - 11:46when the next release train arrives
-
11:46 - 11:48feature A, B, and C are done
-
11:48 - 11:50while D is still in progress.
-
11:50 - 11:53The release train will include all 4 features,
-
11:53 - 11:55but the unfinished one is hidden
-
11:55 - 11:56using a feature toggle.
-
11:56 - 11:57It may sound weird
-
11:57 - 11:59to release unfinished features
-
11:59 - 12:00and hide them.
-
12:00 - 12:01But, it's nice because
-
12:01 - 12:03it exposes integration problem early
-
12:03 - 12:05and minimize the need for code branches.
-
12:05 - 12:07Un-mearged code hides problems
-
12:07 - 12:09and it's a form of technical debt.
-
12:09 - 12:11Feature toggles let us dynamically
-
12:11 - 12:12show and hide stuff in test
-
12:12 - 12:14as well as production.
-
12:14 - 12:16In addition to hiding unfinished work,
-
12:16 - 12:18we use this to A/B Testing
-
12:18 - 12:20gradually roll-out finished features.
-
12:20 - 12:22All in all our release processes is better
-
12:22 - 12:23than it's use to be.
-
12:23 - 12:25But, we still see plenty of improvement areas
-
12:25 - 12:27so we'll keep experimenting.
-
12:27 - 12:29This may seem like a scary model
-
12:29 - 12:32letting each Squad put their own stuff
-
12:32 - 12:33into production
-
12:33 - 12:35without any formal centralized control.
-
12:35 - 12:36and we do screw up sometimes.
-
12:36 - 12:38But we learned that trust
-
12:38 - 12:39is more important than control.
-
12:39 - 12:41Why would we hire someone
-
12:41 - 12:42who we don't trust.
-
12:43 - 12:44Agile at scale requires
-
12:44 - 12:46trust at scale
-
12:46 - 12:48and that means that no politics.
-
12:48 - 12:50It also means no fear.
-
12:50 - 12:52Fear doesn't just kill trust.
-
12:52 - 12:53It kills innovation
-
12:53 - 12:55because the fear to get punished
-
12:55 - 12:57people won't dare try new things.
-
12:57 - 12:59So, let's talk about failure.
-
12:59 - 13:01Actually, no
-
13:01 - 13:02let's take a break.
-
13:02 - 13:03Get on your feet,
-
13:03 - 13:04get some coffee.
-
13:04 - 13:06Let this stuff sink in for a bit
-
13:06 - 13:07and then come back
-
13:07 - 13:09when you're ready for Part 2. Okay?
- Title:
- Spotify Engineering Culture - Part 1
- Description:
-
An attempt to describe our engineering culture.
This is a journey in progress, not a journey completed. So the stuff in the video isn't all true for all squads, but it appears to be mostly true for most squads.
(NOTE - Part 2 hasn't been recorded yet. Stay tuned!)
- Video Language:
- English
- Duration:
- 13:12
![]() |
Thibaut Labarre edited English subtitles for Spotify Engineering Culture - Part 1 | |
![]() |
Siriwat Jithunsa edited English subtitles for Spotify Engineering Culture - Part 1 | |
![]() |
Siriwat Jithunsa edited English subtitles for Spotify Engineering Culture - Part 1 | |
![]() |
Siriwat Jithunsa edited English subtitles for Spotify Engineering Culture - Part 1 | |
![]() |
Siriwat Jithunsa edited English subtitles for Spotify Engineering Culture - Part 1 | |
![]() |
Siriwat Jithunsa edited English subtitles for Spotify Engineering Culture - Part 1 | |
![]() |
Siriwat Jithunsa edited English subtitles for Spotify Engineering Culture - Part 1 | |
![]() |
Siriwat Jithunsa edited English subtitles for Spotify Engineering Culture - Part 1 |