Qualities of Quality

I’m currently on parental leave, which is something that leaves very little time for any concentrated work effort because your first priority is to be on-call to solve the problems of a baby and you get interrupted all the time. But in between interruptions you can reflect on things and sometimes respond to email threads. I’ve been thinking about one topic in particular, namely quality, over the last week or two, and now my son is asleep, so I’m going to try to write up a blog post about it. In this post, I’m making the claim that

Developer-facing quality is a completely different thing from end-user facing quality, and is usually more important.

In one of the email threads I’ve been responding to, I said that “near-perfect quality code is … a meta-feature” meaning it affects and improves all other features, and that “it’s really a requirement to achieve sustainable speed”. I now think I can express that more precisely by considering different kinds of quality. The kind of quality I believe most people think about is what the end user experiences: product quality. Bugs, UI inconsistencies, etc. Product quality is a (non-functional) feature like any other, and can rightly be prioritised relative to other product features, such as performance, an improved design, a better recommendation algorithm and so on. The kind of quality that is a meta-feature is the quality a developer experiences, what I would term implementation quality. Things like readability and understandability of the code, ease of re-use, and bug-free-ness. Implementation quality doesn’t affect the end user experience, but it impacts the productivity of the teams working on improving the end user experience. These two kinds of quality overlap but are not the same:


While a product can be compelling even if it has poor product quality and therefore a tradeoff between product quality and other product features is meaningful, it’s much harder to motivate not paying attention to implementation quality. Poor implementation quality kills your ability to add features and evolve your product and therefore makes poor product quality a much more serious problem. Poor implementation quality becomes an obstacle to changing your product, and changing the product quickly is key to getting it right.

A very closely related thought is Martin Fowler’s Design Stamina Hypothesis, which is an article you really should read and understand. So I’m not going to summarise it here, just go ahead and read it. Seriously, read it. Done? OK, now spend 4.43 minutes watching Ward Cunningham explaining (technical) debt. Even if you’ve watched that presentation before, it’ll be ~5 minutes very well spent.

Cunningham says that it can be a good idea to take on debt if you’re saying “I don’t understand this domain well enough to know that I’m building the right features or that I’m using the right abstractions for the features I’m building”. The first kind of debt is what Eric Ries is addressing in the lean startup movement, and what we’re addressing at Spotify with the Think It, Build It, Ship It, Tweak It mantra. The second kind is something you should take on and need to continually pay back as you get the required understanding of your domain. It’s not OK to take on debt by not following good engineering practices and, for instance, not cleaning up your code once you’ve made it work. It should be easy to understand the abstractions you’ve chosen, even if they’re not the right ones. Paying back debt should be mostly about fixing your design as you better understand what it should have been, not about fixing bugs or spaghetti code.

The two most important points Fowler makes, I think, are the narrowness of the time interval during which it is meaningful to trade off design/implementation quality for speed, and that once you’re past the point where the two curves intersect, continuing to disregard implementation quality just slows you down further. You can only profitably trade off implementation quality for speed in very short-lived projects. Probably, if you’re expecting a system to have a lifespan of more than a couple of weeks, it’s a good idea to pay attention to implementation quality right from the start. I think there may be exceptions, when you desperately need to get some feature out to survive. But at Spotify, we’re not struggling to survive, we’re figuring out how to build the best music streaming service in history. That’s hard, so we need to make sure that we can adapt our product quickly and easily as we learn how to do it.

In the figure above, I included simplicity as an aspect of both product and implementation quality. This is primarily due to a couple of thoughts: first, an article by Andres Kutt, where especially the section on what he calls functional architecture is relevant. The point he is making is that due to the huge number of features in the Skype web store, it ended up in a state where it was almost impossible to make changes to it. Feature count makes users confused (hence it’s a product quality issue) and it adds code complexity, making the code base less amenable to change. It’s a mistake to think that a feature is free just because you’re not doing active development on it.

A couple of notes on bugs. I include that in both product and implementation quality. The product perspective is pretty obvious – bugs detract from the user experience – but the implementation aspects may be a little less apparent. The first aspect is of course that it’s easier to build something on top of a solid component than a library. So if services and libraries are bug free, it’s easier to make sure that the end user experience is good. But there’s a second aspect as well. Bugs reduce productivity in many ways – for a longer discussion, see this post. The short of it is that unfixed bugs in your code lead to additional meetings, bug management overhead, duplicate reports of the same bug and context switching. So a lot of the time, the best thing you can do for your own productivity is to just fix pretty much everything that’s ever reported. That that also leads to a better end user experience is a nice bonus.

One common misconception about quality and its impact on delivery speed is that things like pluggability/extensibility/configurability of some technical solution are quality. Those are things often labelled as over-engineering. To me, over-engineering is engineers adding waste by inventing features that aren’t actually really needed. The notorious 2002 Standish Group report on feature use concluded that 64% of product features are rarely or never used. Considering that features interact in ways that make code less malleable, the best thing you can do for your own and your team’s productivity is to question any feature that goes into the product you’re working on. Especially if you came up with it yourself. At Spotify, product owners get their scope creep tendencies kept in check by Think It, etc., but nobody really checks that we engineers limit the scope of the code we write. Over-engineering is not about creating something with too good implementation quality, it’s creating something with too many features. In nearly two decades of doing professional software development, I don’t think I ever felt a team I worked in overspent seriously on implementation quality, but I’ve definitely many times felt that we’ve wasted hugely on some feature or other.

I’ve also got some opinions about the use of TDD to drive implementation quality, but my son is going to wake up any minute, so that will have to remain a topic for a future blog post. :) For now, a summary of this post in two bullet points – to be able to move fast with product development, you need to:

  • Be ruthless about minimising the feature count, and
  • Always pay very close attention to implementation quality – but feel free to trade off product quality if needed.

How we do recruitment at Spotify

We get a lot of questions about how we work with recruitment at Spotify. Both from candidates but also from other companies. And it’s a relevant one to ask – it’s hard to find top talent on a market where everybody is screaming for developers. A crucial thing for a quick growing tech company is to hire the right people, actually : Right people beats the right business idea – your employees make all the difference.

If you get involved in our tech-recruitment process you normally go through 7-8 different steps. We will get back to those steps, but in wide terms what we are looking for when it comes to developers are overall technical knowledge which includes an understanding for general computer science and problem solving skills. Besides that you also have to show your specific knowledge when it comes to programming languages and how you handle deadlines, team work and making great things under a bit of pressure. We also evaluate how you work within a group and your ability to give and receive feedback. During all of those interviews we also look on how well you fit into our culture.

So how do we do tech-recruitment more specifically on Spotify? Let me walk you thru the recruitment step by step. Note that this is a general approach and we are trying to be agile and tweaking and A/B-testing the process along the way.

Screenshot 2014-03-24 11.16.13

1. Intro

This is where we look at your CV that you have submitted. If we think you are interesting we will give you a call or send you a mail. What we’re after in this first point of contact is to get a brief oversight of who you are, what you would like to work with and how that fits the needs of Spotify. This includes questions about your current role and work and if you would consider relocating, the length of your notice of termination and salary expectations.

2. Tech Trivia

If you pass the screening phase we will arrange another more technical interview with you. As we are hiring developers from all over the world we will conduct the first two interviews via Skype or Google Hangout. In this interview we focus on your overall technical knowledge which could include questions about general technical nature -memory access time, sorting algorithms, and different IP protocols and of course specific questions regarding the expertise the role acquires. But more than trivia solving skills we are looking for passion and drive.

3. Tech Interview

This interview focuses more specific on programming knowledge. Via EtherPad, shared notepad, you get to code real tasks and we evaluate your work in real time. There’s’ a lot of different tasks to do and what task you get to solve all depends on which role you have applied for.

Final Interview

If you pass phase three we will invite you to our office for a final interview. We arrange all the practical things and basically fly you into one of our tech offices either Stockholm, New York, Boston, San Fransisco or Gothenburg for a day of interviews.

4. Whiteboard programming

This is pseudo coding on a whiteboard and the answers don’t have to be correct code, its more about the problem solving skills you show and how you communicate with the people conducting the interview.

5. Programming.

Exactly what it sounds like. You try to solve a real problem and we’ll evaluate your work. We may replace this interview with a case interview with a ‘real life situation’ to solve. We’ve also done this in ways of looking at candidates code repository on GitHub.

6. System Design

Show us your ability to think big! How would you design a scalable systems with millions millions of users? Where and how would you store data? How would you handle load balancing, security, internet connection fails, login details?

7. Meet the team

Maybe the most crucial interview. You get to meet the team and the team get’s to meet you. Are you a potential new colleague? Would you like to work in this team? We are looking for your passion and drive. Most of our developers have a proven-in-battle-track-record with pet projects, side business or companies. If someone is doing great and going the extra mile – they will most likely do the same when they join your company.

We have a lot of crazy stories about what candidates have done here. For example one candidate had built drone-zeppelin with an integrated camera that he could control with his phone. This is the kind of bold people we look for – we need people with a different mindset, people that dares to create and invent new things!

8. Culture interview

This is the last step and this is where both you and us get’s a chance to discuss the day and the interviews that you’ve been through. We also talk a lot about the way we work at Spotify, how we solve conflicts and what we as an employer have to offer you to get the best out of you. If you are relocating we’ll walk you through the process on how things work in Sweden and /or US. We also discuss things like salary, benefits, stock options and social activities that we do.

We know that this is a very rigorous recruitment process but we think it’s important that both we and you get the best of possible ways get a clear picture of each other. During the day you will meet a lot of people and each and every one of them gives a bit of the puzzle that is you and we ask them four simple questions after meeting you.

  • Is this candidate technical enough for Spotify?
  • Would you like this candidate in your team?
  • Can you learn something from this candidate?
  • Is there any reason NOT to hire this candidate?

And if both you and we think that this is a good idea – we get at mutual yes and you start working on Spotify!

At Spotify we have very high standards and we like it that way! It’s crucial for our growth that we have the right people on board, without the right people we lose focus and we stop developing. It’s also important for us that you are a culture fit and that you can be a part of and nurture the culture that exists within Spotify. The culture have a huge part in our success so we really recognize and value it.

So do you want to give us a try? We’re hiring and we are looking forward to see you in the process!

And if you want to get the inside look of Spotify – follow us on Instagram #JoinTheBand

Spotify engineering culture (part 1)

Here’s a short animated video describing our engineering culture.

This is a journey in progress, not a journey completed, and there’s a lot of variation from squad to squad. So the stuff in the video isn’t all true for all squads all the time, but it appears to be mostly true for most squads most of the time :o)

Here’s the whole drawing:


(Tools used: Art Rage, Wacom Intuos 5 drawing tablet, and ScreenFlow)

Part 2 hasn’t been recorded yet. Stay tuned.


How to shuffle songs?

At Spotify we take user feedback seriously. We noticed some users complaining about our shuffling algorithm playing a few songs from the same artist right after each other. The users were asking “Why isn’t your shuffling random?”. We responded “Hey! Our shuffling is random!”

So who was right? As it turns out, both we and the users were right but it’s a bit more complicated than that. It also tells a nice story about how to interpret users’ feedback.

Our perspective

Since the Spotify service launched, we used Fisher-Yates shuffle to generate a perfectly random shuffling of a playlist. However, perfectly random means that the following two orders are equally likely to occur (different colors represent different artists): Two random ordersA side note: I think Fisher-Yates shuffle is one of the most beautiful random algorithms and it’s amazing that such complicated problem can be solved in 3 lines of code in some programming languages. And this is accomplished using the optimal number of operations and optimal amount of randomness.

Gambler’s fallacy

At first we didn’t understand what the users were trying to tell us by saying that the shuffling is not random, but then we read the comments more carefully and noticed that some people don’t want the same artist playing two or three times within a short time period.

It is known that we humans are sometimes bad at estimating probabilities. Suppose that you use a coin every day at work to decide where to eat lunch. The first four days of the week the coin decided that you should eat Thai food, but you prefer Indian. You might think “The coin decided four times this week in favor of Thai, it must be Indian today”.

If you think the coin has higher probability of deciding for Indian on Friday, you are wrong. Throwing the coin for a millionth time is the same as throwing it for the first time. After all, it is just a simple coin, it has no memory, doesn’t know who threw it, etc. So both heads and tails have the same probability on Friday – 50%.

Another example: people often think that if they haven’t won anything in a scratchcard lottery a couple of times in a row, they should have bigger chance of winning now. This phenomenon is called Gambler’s fallacy and it’s the same fallacy that lead to the mistake about Thai/Indian food.

Let’s go back to our users who have also fallen victims to Gambler’s fallacy. If you just heard a song from a particular artist, that doesn’t mean that the next song will be more likely from a different artist in a perfectly random order. However, the old saying says that the user is always right, so we decided to look into ways of changing our shuffling algorithm so that the users are happier. We learned that they don’t like perfect randomness.

The algorithm

It seemed like a problem that must have been solved by somebody else before. Indeed, we found a blog post The art of shuffling music by Martin Fiedler that solves precisely the same problem. However, his algorithm is complicated and could be very slow in some cases, so we modified it to better suit our needs.

The main idea is very similar to the methods used in dithering. Suppose we have a black and white picture that uses a few hundred shades of gray.

Michelangelo's David

We would like to simplify the picture even further by using only pixels of two colors, black and white. We could use random sampling: say a pixel has an 80% shade of gray, then it will have 80% chance of becoming black and 20% chance of becoming white. We process pixels one by one and for each one we randomly decide its new color based on the original shade of gray. However, the result is very far from satisfactory.


As you can see, the black pixels form clusters and there are also big white spots. It would be better if the black and white spots were spread out more evenly. Other algorithms like Floyd–Steinberg dithering avoid clusters and produce much better results.


The clusters seen on the previous picture almost fully disappeared. We can take inspiration from the dithering algorithms to solve our problem with clusters of songs by the same artist; we will try to spread them throughout the whole playlist. Suppose we have a playlist containing some songs by The White Stripes, The xx, Bonobo, Britney Spears (Toxic!) and Jaga Jazzist. For each artist we take their songs and try to stretch them as evenly as possible along the whole playlist. Then we collect all songs and order them by their position. A picture is better than a thousand words.


As you can see, songs from an artist are nicely spread out and it looks pretty random to a human eye. Let’s look in more detail how the algorithm works.

  • Let’s say we have 4 songs from The White Stripes as in the picture above. This means that they should appear roughly every 25% of the length of the playlist. We spread out the 4 songs along a line, but their distance will vary randomly from about 20% to 30% to make the final order look more random. You should be able to see that the distance between the red circles on the line is not the same.
  • We introduce a random offset in the beginning; otherwise all first songs would end up at position 0. You can see that both Britney Spears and Jaga Jazzist only have one song, but the random offset causes them to appear at a random place in the playlist.
  • We also shuffle the songs by the same artist among each other. Here we can use Fisher-Yates shuffle or apply the same algorithm recursively, for example we could prevent songs from the same album playing too close to each other.

All in all the algorithm is very simple and it can be implemented in just a couple of lines. It’s also very fast and produces decent results.


The algorithm is now rolled out to everyone using our desktop client and other clients will follow soon. Thanks to everyone who gave feedback on our Community page.

Further reading

  1. What does randomness look like?, a blog post by Aatish Bhatia
  2. Clustering illusion on Wikipedia
  3. A very lucky wind, a radio episode about a couple of interesting random phenomenons
  4. Dither on Wikipedia
  5. How Randomness Rules Our World and Why We Cannot See It by Michael Shermer

How it is to be an Agile Coach intern at Spotify

It all started in the middle of April, I had been studying agile for 7 months at a school called Agile Academy and it was time to spread my wings and do the internship. The first week at Spotify was filled with all the things I’ve only read about in books; there were boards everywhere, retrospectives going on in meeting rooms and real-life POs!

From day one I was invited to different kinds of meetings and workshops. Just by grabbing a soda people said hi and invited me to see how they worked. It felt so amazing with the openness and all the friendly people. By not having my own team to concentrate on I got to meet most of the teams in the tech department at the Stockholm office and learnt so much. One day I could be in a brainstorm session with a squad, another day be in a workshop for POs. On all these different kinds of meetings I had three questions in mind:

“What’s good with this meeting?”
“What could be improved?”
“Why should it be improved?”

This was a good way for me to better understand how the teams at Spotify work and also an easier way for me to be more observant and get answers to my questions after the meeting. By participating in the meetings I could also support the Agile Coaches with an outsider’s perspective.

Agile Coach at Spotify

After a couple of weeks as an observer and participant I got to try out the role as an Agile Coach. “But what’s really the role of the agile coach, what does she do?” was a common question I got.

Well, the main purpose is to help the teams to become high performing and improve the process and workflow.

The Agile manifesto values:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

For me this feels like a natural thing to do, but just because something feels natural doesn’t mean it’s easy to comprehend. And this is where the Agile Coach comes in. I’ve heard people say that to be good at something, you first have to follow the rules, then change them and lastly ignore them. That’s where I think Spotify is, there is even an “Agile a la Spotify” manifesto.

So how do Agile Coaches work?

  • Observe, interact and facilitate meetings.
  • Teach Agile.
  • Coach teams, squads, and individuals to high performance.

When I came to Spotify I had just passed the scrum master test and got a certificate. I mostly knew about scrum and less about agile coaching. It was fascinating to see how much an Agile Coach actually does coach. From thinking that the Agile Coach was a leader, someone people should follow, to see that she actually is a person more in the background. The Agile Coach is not here to solve your problems for you, or answer your questions, she is there to coach you to high performance by teaching agile and challenging you to think for yourself.

Summer internship students 2013

My internship experience

It all started with me and my mentors doing a futurespective; what is it that I want to learn and how should we get there? We decided to start with me observing meetings, workshops and standups to get basic knowledge about how the different teams and processes works. After a couple of weeks I took every opportunity I could find to try it out and do it on my own and that led to me e.g. facilitate retrospectives in different teams, facilitate a book club on Lyssa Adkins’ “Coaching Agile teams”, coach Agile to three boot camps, and at the end I even got my own team!

I spent a lot of my time on researching and reading up on Agile, but the greatest learning experiences came from putting myself in new situations e.g. coaching individuals. Working with people is complex, you can never predict what will happen which is scary as hell but at the same time very interesting and fun!


I’ve also learnt more practical stuff like different ways of facilitating meetings, most of all retrospectives, once I tried an icebreaker before the retrospective that were about people writing two notes were they write something crazy/unexpected about themselves and then people have to guess who did what, it ended up with a lot of fun facts. It’s always good to start a meeting with an icebreaker, it doesn’t have to be as big as this one, but something that makes everyone feel more comfortable from the start.


While doing retrospectives I wanted to try out a lot of different ways in how to facilitate meetings, so e.g. I tried  “the four L’s retrospective”, “mad, sad and glad” and “the sailing boat”. Retros are mostly about reflection – what’s going well, what is not going that well, what or how can we improve, and what actions should we take? It’s really important to reflect in order to grow and become better at what you do, but I think that one of the most important parts with it is the follow up; did we really improve what we talked about last time? If not – why, and what can we do to make it happen?



One of my new favourite things is Kanban. Kanban is really good when you want to learn fast from your previous experiences, and also when you do not want to plan too much upfront – you might not need what you thought was important when you’ve seen the outcome of an other story. But one of the most important things with Kanban which really appeals to me is that it makes it easier to focus – get rid of that multitasking! Having many things in progress might seem to be good at the time because it looks like we’re doing a lot… But it isn’t necessarily that good if we’re not completing things – unfinished stories don’t bring any value. So if you work together to get things done and stop multitasking it brings more value to the client and it also makes the team move forward faster, more engaged and motivated.

Lean coffee

Lean coffee was also a new thing for me, it’s a good tool when you have a lot to talk about, if you need to sync and also in new groups when people might be scared about taking too much initiative. By letting everyone share the subjects they want to talk about, then prioritize them and timebox the discussions you’ll hopefully won’t be distracted and get the most value out of the discussion.

Spotify has been an eye-opener and I’ve never felt so welcomed anywhere as I’ve felt here.
One of the things that I really will take with me (which is something I hear a lot in the office) is an echo in my head that says “You can always improve!”.

Street team

When my internship came to an end I got the question if I wanted to join Spotify’s Street team (students that work with marketing and communication between their schools and Spotify), and of course I said “YES!” So now I’m working in the Street team and we recently organized the first Swedish student tech conference; Student Techfest.
101 students came from around the country for a two-day gathering full of inspiration, lightning talks, networking and a whole load of tech sessions at the Spotify office.

The opportunities Spotify gives students are really amazing and I’m proud over being part of their team and being able to have had my internship there. If you want to apply for an internship program at Spotify, please visit our job page and see what’s out there for you!

The Curious Case of Student TechFest

The story of how Student TechFest came to be starts with Sofia von Celsing in People Operations asking us in the Spotify Street Team: “What would happen if Sweden’s most talented and passionate tech students could meet at the same place?”. Half a year later we arranged Sweden’s first tech conference exclusively for students. It was awesome!

Held at the Spotify HQ in Stockholm, 101 extraordinary university tech programmers, entrepreneurs and designers from all over Sweden met under the same roof between September 27-28, 2013. It was the result from months of planning and execution from the Spotify Street Team, Spotify’s student ambassadors. Here’s how the event came to life…

Photo: Henrik Björkman

Photo: Henrik Björkman


Sofia von Celsing (project manager for Student TechFest), started Spotify Street Team in 2011 as a way to show students what it’s like to work at Spotify. Today the Street Team in Tech consists of Oscar, Poscar, Lisa, Sofie, Jesper, Anton and me (Marcus). A tightly knit team of students representing Sweden’s top tech universities, really enjoying life both at Spotify and at our universities in Stockholm, Linköping and Gothenburg.

In March 2013, Sofia presented us with the idea of a student conference for the first time. From there on, we were all over ears. It didn’t take long before we had written a project plan and started to brainstorm about the concept which would later become “Student TechFest”.

The work really took off in the beginning of June. I was able to work with Student TechFest during my summer internship at Spotify, being the project leader. The rest of the team worked alongside their ordinary summer jobs, either at Spotify or elsewhere. We all had our own areas of responsibility, like content, marketing, web, sponsorship, etc.

Our common goal was laser focused on connecting Sweden’s most passionate tech students with each other, in the coolest way possible.  With a lot of previous experience in separately organizing events for Spotify at different universities, the exciting new challenge was to organize a major one together. Not only a better one. The best one.

This is in fact exactly how we wanted you to feel at Student TechFest. Street Team Chalmers University represents! Photo: Henrik Björkman

This is in fact exactly how we wanted you to feel at Student TechFest. Street Team Chalmers University represents! Photo: Henrik Björkman

Making it happen

We got a budget, we got free hands to do our own thing, and full support from the whole organization – engineers, recruiters, event organizers, HR and social, the lead team… Actually, since the work with Student TechFest started, we have gotten to know so many people from all areas within Spotify, that meeting everyone has been a reward on its own. Student TechFest was a team effort from the whole company.

Spotify Street Team: Fiona Rolander, Oscar Carlsson, Oscar Söderlund, Anton Petersson, Jesper Bratt, Marcus Nygren, Sofia von Celsing, Lisa Gruneau and Sofie Thorsen. Foto: Henrik Björkman

Spotify Street Team: Fiona Rolander, Oscar Carlsson, Oscar Söderlund, Anton Petersson, Jesper Bratt, Marcus Nygren, Sofia von Celsing, Lisa Gruneau and Sofie Thorsen. Photo: Henrik Björkman

Planning the content and booking speakers was a long and important process. Not only did we need to get a bunch of interesting and talented speakers (that were available at the given dates!), we also wanted to balance the conference nicely with regards to our audience. To make this happen we decided to mix techtalks for the whole audience with smaller sessions where the students could choose based on their own preferences (backend, design, web etc). This format helped us create a diverse and interesting conference while keeping our core view, that is, emphasize what tech in the real world is all about.

Ludvig Strigeus hosting a session about TinySpotify. Photo: Henrik Björkman

Ludvig Strigeus hosting a session about TinySpotify. Photo: Henrik Björkman

With that said a lot of time and effort was spent trying to create an appropriate lineup and achieving these goals. We managed to bring in a bunch of internal and external speakers from both startups and established companies (Mozilla, iZettle, DICE, Netlight, RemoteX, Advisa). Topics included everything from backend and frontend (Cassandra, MapReduce, machine learning, mobile development, JavaScript) to design and more general life lessons (scaling agile design, working as an engineer, what school did not teach me).

When September 27 arrived I think we all could draw a sigh of relief with everything falling in place. We had booked all slots, things were under control and we were confident with our schedule. Not to mention all the work with the applications! Our website quickly received over 10 000 page views, and hundreds of impressive applications showcasing projects, passions and future ambitions. We had even done a PR tour across Sweden. Boiling the list down to only 101 students was extremely hard, and took two full days where we all met at the HQ. We had so many applicants with impressive work done and amazing personalities, that we were truly humbled. Our own expectations for the event grew…

The students arriving to the headquarters in Stockholm. Photo: Karl Johan Krantz

The students arriving to the headquarters in Stockholm. Photo: Karl Johan Krantz

“Don’t worry about impressing anyone. Focus on being present.”

It felt like magic when the buses arrived on the Friday morning, and the students entered the building. Everyone gathered in the cafeteria. After some snacks and socializing, the hosts Navid Modiri and Ashkan Safaee introduced the Student TechFest manifesto, one of the rules being “You are all here because you have been chosen out of the hundreds who applied. That means you rock. Don’t worry about impressing anyone. Focus on being present.” Another one was “The speakers are not here to impress you. They are here to inspire you. Talk to them – ask questions. But also help them. You know a lot of things they don’t.” Suitably, immediately after the manifesto CEO Daniel Ek got on stage for an intimate interview, sharing openly about successes and failures, fears and hopes. It was a great icebreaker for the following lunch, meeting up in smaller groups around the office, getting to know eachother better.

Later we had tech talks, did an unconference session, and had a Q&A onstage together with Swedish gaming company DICE and the consulting company Netlight. Day one of Student TechFest ended at a cosy italian restaurant, where we had a troubadour and DJ playing. It felt good. Really good. If this was our “soft start”, what would the rest be like?

Photo: Henrik Björkman

Photo: Henrik Björkman

My colleague Fiona said: “The breakfast was the first time I realized how good Student TechFest was becoming. The atmosphere there was just amazing. The sun was shining in, the students talked to new people, laughing and bonding.” We had started to see what it meant bringing such great people together.

For me, seeing how happy and amazed everyone was made my heart all fuzzy. We had worked so hard for this. The feeling held on strong during the whole day. It wasn’t that hard in the start: Christian Heilmann, evangelist from Mozilla, had a great energy on stage. He was brilliant, joking about the things he did not learn in school.

After his keynote, which you’re able to read more about on his blog, Student TechFest transitioned into an unconference. Students could choose freely between twelve sessions, divided into three blocks, with content varying from development to design to culture. Just to pick one example, many jaws dropped during the session with Ludvig Strigeus. He talked about what lead him to be able to build the Spotify client and a 48 kB version, TinySpotify. He emphasized the value of understanding things from the ground up, almost to the extreme. My personal favorite of that kind of madness/genius was how he reverse-engineered the Monkey Island game engine on his spare time (> 20 000 lines of code). That’s passion, and it was truly inspirational. As students could only attend three out of twelve sessions, the students were eager to interview each other on the different sessions, and what they had learned from them.

Danielle Jabin, Data Engineer at Spotify, having a session about how her university studies translated to working in the tech industry. Photo: Henrik Björkman

Danielle Jabin, Data Engineer at Spotify, having a session about how her university studies translated to working in the tech industry. Photo: Henrik Björkman

After the three sessions, we all met up in the cafeteria again. We had our last keynote and some fun surprises for the participants, giving out prizes and congratulations to winners. We thanked everyone who had helped make the Student TechFest happen. We took a group photograph. It really felt like Student TechFest could have been over. The students even returned to their hostel… in anticipation for the big finale. You didn’t think we’d stop without a music festival, did you?

From TechFest to TechFestival

During the time the students got dressed for success, we prepared the cafeteria for “Student TechFestival”. At Spotify, we have a motto that says “Go big or go home”. In the context of a music festival at a student conference, this could mean a lot of things. We had synthetic grass, food stands, open bar, photobooth, fake tattoos, ice cream stand, beach chairs, a decorated terrace. It was wonderful. (Thanks to the event bureau OneMotion for putting it all together, it wouldn’t have been possible without you.)

Throughout the evening, we had celebrated artists Beatrice Eli, Frantic Sunday and Yamarill performing on stage. A lot of people enjoyed when the DJ duo Yamarill divided the audience into three teams: everyone was instructed to hold their smartphones in the air, and could see their how much their team danced on the projector screens. We had also invited Spotify employees and friends to join the party. Our chairman and co-founder Martin Lorentzon was there dancing and talking to students! Simply put, we couldn’t have wished for anything more: we had created the event we had dreamt about for 6 months.

Frantic Sunday on stage. Photo: Henrik Björkman

Frantic Sunday on stage. Photo: Henrik Björkman

The journey does not stop here…

I think we will see a lot of our future summer interns and master thesis students being Student TechFest alumni. However, we can for sure twist and tweak the concept for next time. Interaction is essential, and I’m sure even more of it would for sure be appreciated at a future event. Discussions, hacking and workshops between the students would allow them to get to know each other really well, which is important for them keeping in touch also after Student TechFest.

As I learned throughout the project, I started to uncover my own manifesto as a project leader, forming Student TechFest:

  1. Help awesome people do awesome stuff.
  2. Instead of talking about Spotify for two days, let’s focus 100% on doing a fantastic student tech conference. It is the best way to show who we are!
  3. Be unconventional. For example, we decided on only serving vegetarian food. No pizzas, no fast food. And you know what? The feedback was great.
  4. See the bigger picture. In the long run, we will help the startup and tech scene to grow by supporting ambitious students, and developing their skills and personalities. That was a great motivation for giving the project everything we got.

Looking back at Student TechFest, it was the coolest event I have ever attended (and organized). Moreover, we have gotten so much encouragement from the participants. I can say for the first time ever that a spreadsheet with graphs has made me happy. The big success: we, the Spotify Street Team, connected some of Sweden’s brightest students with each other, the result being beyond what we could have imagined. In the meantime, we also had loads of fun and succeeded in showing what Spotify is all about: work hard, play hard.

I would like to finish this blog post by saying thank you to everyone involved in Student TechFest. Everyone who participated and applied, all Spotify employees, invited speakers, the artists, our event logistics agency OneMotion, our sponsors. Most of all, I want to thank  Sofia von Celsing, and my colleagues in Spotify Street Team – whom without the event would never have happened. Thank you for having done such a tremendous job with putting Student TechFest 2013 together. Let’s do it again!

Best regards,
Spotify Street Team

Do you want more?

  • See more awesome pictures from the event (on Facebook)
  • Read a blog post from one of the participants
  • Check the website
Photo: Henrik Björkman

Photo: Henrik Björkman

What it feels like being an ipad on a stick on wheels

We like experimenting with geeky tools. All in the name of science of course…

How about sitting on a beach in Thailand and participating in conference in Stockholm by remote-controlling an ipad on a stick on wheels? Sounds like a fun experiment, doesn’t it? How many geek points is that?

And hey, I just happen to be on an island in Thailand right now, and there’s this cool event Lean Tribe Gathering happening at the Spotify Stockholm office, and I recently bought a double. I saw one of those things driving around the office a few months ago, and it instantly popped to the top of my must-try-someday list.

So what was the hypothesis? I’ve heard that it’s only an experiment if you have a hypothesis. Otherwise it’s just playing around, and I wouldn’t want to be accused of that would I?

The conference was an evening of lightning talks and open space (= big room with lots of mingling and small groups of informal conversations, like a cocktail party under the guise of a conference). Will I hear and see the presentations? Will I be able to roll around and freely participate in the open space? Will I feel like I’m really there?

So my hypothesis was: “I can fully participate in this conference using a double”.


So how did it work out?

It worked! The hypothesis was falsified, unfortunately, but it was still really cool! I sat on the beach near a restaurant with good connectivity, pulled out my ipad, logged on to my double in Stockholm, and started driving around and talking to people. Geek heaven!

Alone on a dark beach because it got rather late. +6 hrs time difference.

I was totally impressed, but also slightly disappointed, at the same time. Impressed that I felt truly present at the conference, but slightly disappointed that I felt more like an observer & comic relief than a real participant.

Watching the lightning talks

The controls were a bit clumsy, and my internet connection was a bit shaky. But I could get around fine, slowly, and I was able to make it to the front of the room right by the stage.

For the lightning talks I could see and hear the speakers fine (they had mics), and I could make out about half of the slides (depending on colors used, font size, etc). All in all I got the presenter’s message. But I didn’t need a double for that, someone could have put a laptop on a chair and connected me via skype/hangout. On the other hand, it was nice to be able to “turn my head” from time to time, to follow the speaker’s movements, or see the audience and the room.

Mingling in the open space

The open space part was really fascinating. Driving around this… thing…. and feeling like I’m really there. Weird.

However, although it was fun and cool, in practice it didn’t really work that well because of the background chatter. I could roll up to a group of people, but I could only pick out about 20% of what was being said, because of all the other discussion happening around me. Also, the ipad speakers are too weak for this kind of situation, people could only hear me speak if they bent down and put their head really close. So I felt more like an observer than a participant.


At one point I joined a smaller group (4 people) sitting a bit further off, away from the main chatter.  That worked perfectly, I could join the group and really be part of the conversation.

REAL telepresence

The cool thing is that I was really there. I mean that thing rolling around was ME! On one hand I was like “wow, awesome, I teleported to Stockholm and shapeshifted along the way!”. A true out-of-body experience. On the other I hand I was like “HELP! I’m stuck inside this thing! My body has become and ipad on a stick on wheels!”.

I had the distinct sensation of “Wow, so this is what it’s like being a drunk tetraplegic with bad hearing and a weak voice.”

Tetraplegic, because I’m effectively paralyzed from the neck down – the double doesn’t even have legs or arms. I could see and hear, and I could roll around like in a wheelchair. But slowly and carefully, and I sometimes needed assistance when things got in the way. Sometimes I got assistance, even when I didn’t need it, which felt both good and bad at the same time. Gradually people noticed that I could get around quite nicely myself, with some patience. I can’t turn my head, but I can turn my whole vehicle from side to side to see what’s going on. Of course, I don’t know what it’s really like to be a tetraplegic but I guess it’s probably something like this.

Drunk, because that thing sways quite often to stay in balance, and sometimes bumps into things or trips on small objects and falls flat on it’s face (happened only once, but it felt horrible).

Bad hearing and weak voice, because of the background noise in combination with my rather limited microphone and speaker. I often couldn’t follow the conversation going on, and people had to lean in close to hear what I was saying.

Another interesting thing. Sometimes when I rolled up to a group of people, they stopped talking and stared at me instead. As if I was some kind of object (and maybe I was…. or maybe not? Any philosophers out there?). Lots of smiles and laughs of course, and the occasional shocked surprised as someone realized that “hey, there’s a person inside that thing!”. In some cases I felt more like a comic relief than a true conference participant. While listening in on a conversation (well, trying…) I sometimes noticed people staring at me, and they couldn’t see that I was staring right back at them. A weird feeling of eye contact and, well, not.

Although, I admit, it was quite fun to sometimes bump into people and see them shriek in surprise at being accosted by an ipad on a stick on wheels, with a grinning guy on the screen. Even earned me a kiss on the cheek once. Or at least that’s what I think she was doing. It wasn’t a slap at least, I don’t think.

I asked one guy for some coffee, and he almost did, until he realized what he was talking to :o)

Running out of batteries

Unfortunately the ipad on the double wasn’t fully charged from start, so it started running low quite quickly. I didn’t want to disrupt the ongoing presentation, so I tweeted for help, and someone kindly plugged me in.


During a break, I logged off to make it charge faster (which it didn’t). Then later, when logging in again, I found myself standing a few meters away from the nearest person. I wanted to be unplugged so I could move around! Heeeeelp! but nobody could hear me! Now what? I guess I could tweet again, but it might take a while for someone to react.

Ah, I could display a message on my screen! But how? The app on my end will only send the video stream, i.e. my face on the camera. I can’t get it to display something else. Ah, I could write a note! But darn, I’m sitting on a beach in Thailand and no paper or pen nearby.

Then I realized that I had my laptop with me (as backup solution). So I fired up textedit and wrote a message


I made the font huge (as in covering the whole screen), and pointed my ipad cam at it. And moved it back and forth a bit for effect (causing the text to pulsate). That worked! People at the conference saw the message quickly and unplugged me.

The charger didn’t work though, so I was still at about 10%. I figured I’d just participate as long as I could, and the battery would die when it died. That was also a weird feeling, knowing that at any moment I will “die”, my double will go limp, and I’ll suddenly wake up back on the beach in Thailand. Total Matrix moment! I saw the battery counter go lower and lower, and my minutes were numbered, so I had to make the most of it. Carpe Minutus! Seize the minute!


  • Double is a supercool and practical gadget, looks nice and takes very little space.
  • Watching a presentation works
  • Having conversations in small groups works, but not if there’s other conversations happening nearby.
  • Moving around works, but slowly, and not with big thresholds or stairs.

Features I would love to have:

  • the ability to “tilt my head” upwards a bit. I could look down at my wheel via a nifty fold-down mirror (great for navigating around chairs and such), but I couldn’t look up, and the robot is rather short even when fully extended, so often I found myself involuntarily staring at someone’s chest as they talked to me. A bit awkward, especially with girls….)
  • the ability to display a message or sketch, not just my videocam & face all the time.
  • the ability to plug myself in for charging, like the docking pads that lawnmower robots use.
  • a louder speaker, for noisy environments
  • a directional mic that can be activated/deactivated, in cases where I want to hear the person in front of me and ignore the background noise.

Oh, and If you’re going to sit on a beach in Thailand in the middle of the night, make sure you have mosquito repellant. And don’t forget the hands! I have like 30 mosquito bites on my hands, I’ll probably get dengue fever or something. But heck, sometimes you have to make sacrifices for science!