Customer Service

Periodically, there will be a horrific customer service experience that somehow catches the attention of the media and for a while we talk about customer service again. Most recently it was Comcast’s famously poor customer service that came under the microscope. Usually when this comes up we like to point to brands that are known for their great customer service: Zappos, Apple, Costco, Amazon, Nordstrom.

These companies deserve their kudos. I’ve had personal experience with the CS teams at all three and I can say they made a potentially painful experience into a very easy one, which only endeared me more to them.

For many companies, it seems like they consider the secret to good customer service to be a secret sauce or impossible goal, but giving good customer service is pretty straightforward. There are a few simple rules.

  1. Respond Quickly
  2. Be honest and genuine
  3. Don’t be a jerk
  4. Trust the customer

Sure to Respond Quickly, you need to be staffed appropriately to handle the flow of customer questions and issues. That might seem cost prohibitive, but the money that it costs to answer a customers question within a few hours will dramatically improve both the perception of the customer service as well as the perception of the company and the brand. Plus, a customer who feels like they are being heard will likely be nicer to the CS representative, which makes for a happier and more productive CS team.

Being honest and genuine is important. If customers don’t feel like they are talking to a real person, the feel like they are talking to a nameless, faceless corporation. That doesn’t endear them to your brand, and that doesn’t make them treat the CS person any better.

The third and fourth points are pretty closely related. If you assume that the people contacting you are honest, you will always try to do the right thing by them. Will that lead to the occasional bit of waste? Sure. But the goodwill it generates from your customers far outweighs the cost of possibly giving out something to a less-than-honest one.

Good customer service creates brand ambassadors for you, not just a retained customer. Look at these two recent exchanges from customers of Spotify:

How Spotify Made My Day

Spotify gave me the greatest customer service experience EVER!

Those exchanges show CS folks as real people, with senses of humor, who trust their customers and actually enjoy helping people. Compare that to Ryan Block’s call. The thing is that people won’t necessarily post or tell friends about a good customer experience, but they will definitely tell as many people as they can about a bad one.

From a management perspective, how do you encourage good customer service?

  1. Make sure that Customer Service is the job of everyone in the company
  2. Trust your CS reps
  3. Reward CS reps on positive interactions, not throughput
  4. Give good training, not scripts

When I say that customer service is everyone’s job, I don’t mean that everyone needs to spend time on the CS line (although nothing will get your CS team some mad respect like being in their shoes for a day or two). What I mean is that you should treat customer service and customer issues as a top priority. CS is your best line to your customer’s issues and they need to be heard. Also, it is ok for employees to reach out to customers on sites like Quora or twitter. It shows that the company cares.

Trusting your CS reps, like trusting all of your employees, is critical. Nothing makes your job stressful like the feeling that you are being watched or that someone is looking to catch your every mistake. That stress absolutely is obvious to the customer on the other end of the e-mail or phone, and it doesn’t lead to a positive experience.

Traditionally, CS has been considered an expense to be minimized. CS Reps were rated on outcomes and throughput, not on answering customer’s needs. It may seem insane to you, but many if not most companies still operate this way. This may work, but it doesn’t create brands that customers love. It creates brands that customers tolerate right up until the moment they can switch. It’s a short-term gain for a long-term loss.

Train your CS reps to actually handle customer issues, and give them the tools and power to fix things. If you have constant turnover in your CS department (a good way to do this is to ignore all the rules above), you don’t want to spend the time or expense to train your CS team beyond the bare minimum. This leads to people dealing with customers who feel helpless themselves that further frustrates the customer. Instead, spend the time and the money to really train up your CS team and empower them to fix as much as possible. Anything a first-line CS rep can’t fix themselves should be an actual bug that they can follow up with developers on directly. Empowering your team and trusting them to do the right thing leads to more positive interactions with customers, which only strengthens your brand.

Treating customer service as an expense to be minimized is akin to showing disdain for your customers themselves; and no one wants to support a company that doesn’t care about their customers’ problems.

The challenge of top-down change and the Microsoft lay-offs

In my talks on engineering culture, I usually like to spend a bit of time talking about how to improve an existing culture or fix one that is truly broken. To create true culture change, I advocate for a bottom-up approach.

I have a few reasons for this:

  1. My audience is frequently made up of individual contributors or first level managers. I want to give them tools they can use to affect change in their larger organizations.
  2. Bottom-up change takes longer, but it is more likely to be truly transformative. It has a better chance of long term success because the whole organization is invested in it.
  3. When cultural change (or any kind of disruptive change) is pushed from senior leadership down, it tends to fail because the middle managers have usually attained their position by being successful in the old culture. This makes them less likely to embrace change and more likely to only go through the motions while actively managing-up to make it seem like they are more active.

Almost every time I advocate this bottom-up approach, I get a question asking if top-down change can also be effective. Sometimes this comes from a senior executive looking to lead change in the organization. Often this question comes because there are two high-profile large companies in the industry trying to change their cultures in very public ways: Yahoo and Microsoft.

When Steve Ballmer was promoting his “One Microsoft” plan, I would make the claim that the chance of that succeeding was nearly zero for reason #3 I mention above. Having worked at Microsoft in the 90s and early 2000s, I know the culture that many of the current Microsoft executives and middle management rose up through. Microsoft spent decades building a highly competitive culture. A restructure and top-down initiatives to encourage collaboration was unlikely to reverse decades of competition.

I pointed to the approach that Marissa Meyer was talking at Yahoo as having a better chance of success. Yahoo was implementing new review policies that seemed harsh to many in the company. This was coupled with “silent layoffs” and a significant effort to eliminate people in the company that were not interested in the new culture that the company was trying to create. While this seemed unreasonably severe, it made a clear point: this was the new culture and the old way of working would no longer be tolerated.

In the memo that Satya Nadella sent to Microsoft outlining the layoffs that he was undertaking today, one section caught my eye:

In addition, we plan to have fewer layers of management, both top down and sideways, to accelerate the flow of information and decision making. This includes flattening organizations and increasing the span of control of people managers. In addition, our business processes and support models will be more lean and efficient with greater trust between teams.

This was a stark difference to Steve Ballmer’s approach to culture change. Coupled with the largest layoff in the companies’ history was a clear message that a central target was the company’s management. This serves to underline the seriousness of the change. Flattening hierarchies and removing managers will also eliminate or weaken those who would be most likely to fight the cultural shift.

I think this has a much better chance for success than the One Microsoft approach, but is still not guaranteed. Changing the way that 100,000 people approach their jobs is an insanely difficult task, after all.

The “house cleaning” approach may be a successful tactic in affecting cultural change in a large organization, but it is also very dangerous. The morale implications are significant. It would be most effective in a “do or die” situation where a drastic action is necessary to save the company itself.

There is an argument that Yahoo was in this position when Marissa Meyer joined the company. The aftermath of the shakeup was a feeling of confidence in the future and hope rather than fear or concern from the folks I know there.

Microsoft is not in a dire situation. While many in the industry and the press look at the company as sliding into irrelevancy; it is still amazingly profitable. This radical restructuring combined with layoffs may be greeted with significantly less enthusiasm from the employees. Satya Nadella may be taking advantage of his honeymoon period here, and that may be the thing that saves this.

I’m going to continue to follow the progress of both of these leaders and companies as they try to evolve. It will be fascinating and instructive.

I hope for the Microsoft and Yahoo employees’ sake that they are successful.

Appowr interview from Budapest

A bit out of context: “Think it, Build it, Ship it, Tweak It”, “Go Big or Go Home” and “Play Fair” are some of Spotify’s core values, but you get the idea.

It was really great meeting Jacqueline Do and the Appowr and Layer Gloss crew in Budapest.

Thoughts on emulating Spotify’s matrix organization in other companies

I was in San Francisco in December for a conference. While I was there, I ended up connecting with a couple different companies who have been inspired by Henrik Kniberg’s whitepaper on Scaling Agile at Spotify, and who have been trying to implement some of those ideas in their own companies.

I think Henrik’s paper does an excellent job on describing the what and how, but it seems that the “why”, and some of the critical ideas can get lost when others read it.

If you haven’t read Henrik’s white paper, I’d suggest that you read that before reading the rest of the blog post. I will do a quick recap here though.

Spotify’s engineering and product organization (now over 600 people) is split into several large groups called Tribes. Each Tribe is responsible for a set of related features or engineering functions. For example, our largest tribe is the Infrastructure and Operations Tribe, whose name is pretty self-explanatory. I am the Tribe Lead of the Music Player Tribe. We handle importing audio from our label and distribution partners, storing and streaming the music, search, collection and playlists, artist pages, music metadata and the music knowledge graph that supports things like the above, but also ads, discover, radio and the like.

While the whole company works on the same product, Spotify, each tribe is set up so that it can work as independently as possible. As you will see below, a critical aspect of our organizational model is to give autonomy at every level. This helps remove decision-making bottlenecks and unnecessary dependencies, which improves velocity.

Each tribe is composed of squads. A squad is a team that is responsible for a single feature or component. For example, there is a squad that is responsible for search, a squad responsible for the AB test infrastructure, etc. As each tribe is set up to be as autonomous as possible, each squad is also set up to be autonomous. In the context of a feature development team, this means that each team is a full-stack team. A full-stack team is responsible for both backend implementation as well as the user interface implementation, on all platforms.

A typical feature squad would have web service engineers, iOS, Android, web and desktop engineers as well as testers, an agile coach, a product owner and UX designer. With this staffing, the squad has everything they need to implement anything related to their feature. They don’t have to wait on another team to implement the pieces they need. They also have autonomy and local decision-making ability, so there are few impediments on their speed of execution.

To this point with Tribes and Squads described only, Spotify may seem like a traditional, hierarchical engineering organization, but this is where the similarity ends. Unlike a traditional organization, a squad does not have a single engineering leader whom everyone on the team reports to. In fact there is not a single leader for the squad. The Product Owner and UX Designer work with the engineers and testers collectively to make decisions about their features.

Spotify is not a “no manager” culture though. We feel strongly that managers have a role in supporting the people who work for them. Managers have an important role to play as technical and career mentors and organizational communication conduits. Rather than have management hierarchies follow organizational ones (creating a de facto command-and-control structure), we instead have first level managers responsible for technical functional areas across multiple squads.

We call these reporting and functional groupings “chapters.” Again, as an example, reporting to me, the tribe lead, are Chapter Leads. In my tribe, there are currently three backend (services) development chapters, two front-end development chapters (including all the UI developers), a core library chapter, and a test chapter.  These seven Chapters span eight different squads. Almost every chapter lead has reports in 2 squads, and a few of them have reports in three squads. Almost all chapter leads work within a squad in some capacity as well, either as developer or technical lead, and not necessarily within a squad that has members of their chapter.

This chapters/squads matrix organization is critical to our organizational agility. It allows the squads and the tribe to be more fluid. We can spin up a new squad to take advantage of an opportunity or handle an issue without worry about changing reporting structures. If a squad completes its goals and has no reason to exist anymore, we can dissolve it without punishing a manager. This is a very important difference to a traditional hierarchy, because it gives us a lot of flexibility and helps us avoid the old political issues around empire building and resource contention.

In addition to our Tribes, Squads and Chapters, we also have virtual organizations called Guilds. Guilds are cross-tribe organizations centered on different technical or interest areas and their membership is voluntary. The guilds serve as ways to promote cross-tribe collaboration and communication, especially around things like best practices. For example, we have guilds for Web Development, Agile Practices, Leadership, Test Automation, etc. The guilds foster developer-to-developer communication, which is one of the ways that we keep all these autonomous teams from all going off in completely different directions.

From Henrik’s paper, this diagram illustrates the organizational structure I discuss above:

Screen Shot 2013-11-09 at 7.30.08 AM

I’d like to give some more background around why we have implemented this organizational model at Spotify; elaborate on our goals for implementing it, and discuss the aspects of our culture, which have been critical to its success. It is really great that other companies have been inspired by the way we work, but I think if you implement only parts of the model or try to impose it on a very different corporate culture; you will have a difficult time achieving the same level of success with it that we have had.

If you are considering using the Spotify organizational model within your company, there are a few things that will be critical to your success:

Our organization model assumes that engineering is doing development with agile methodologies. Our goals for autonomy mean that we do not prescribe any particular development framework our squads must subscribe to. However, all of squads use agile development methodologies. While we do our best to minimize dependencies between squads and tribes, there will always be some since we are all working on the same product. Any individual squad choosing to build using a traditional waterfall or other non-agile process would not be able to keep up with the rapidly changing teams around them. If they tried to impose some sort of process on other teams so that they could follow a longer-term development plan, they would start slowing down the rest of the organization.

A critical requirement in making our organization model work well is that the entire company works with and understands agile practices and processes. While our legal team isn’t doing scrum or kanban, they are used to working with engineering teams that use agile processes. Having the entire corporation understand and agree with agile means that no line of business area becomes an impediment to the speed of implementation. Think of this in terms of Amdahl’s law, applied to a development organization. If your development teams are working quickly in parallel, but marketing or legal is not supportive of an agile approach, they will become a bottleneck that will slow down the overall speed of the company.

Similarly, implementing this with just one team as a test in a larger engineering organization will be prone to issues. A traditional engineering organization is not usually set up for autonomy. Adding a single autonomous team within that web of dependencies is likely to hamper and frustrate the team and skew the results of the experiment.

While I’ve mentioned autonomy in several places already, I cannot understate its criticality. Each squad must be empowered to make their own decisions, not only on features, but also on development model, infrastructure, and implementation. Every decision that has to be approved outside the team means a delay that slows development. Each dictated implementation or infrastructure decision means that a technology that doesn’t fit to the way the team works or something new that must be learned before the team can build. This is a challenge to coordination, but in practice it isn’t as bad as it might seem. Best practices and technologies do spread from team to team through avenues like guilds. Teams adopt these practices and technologies on their own schedule or pioneer new ways of working if it makes it easier for them to deliver value to our customers and then spread their learnings to the other teams.

Trying to layer the tribe and squads model over a traditional reporting hierarchy would be very problematic. While we have many long-lived squads at Spotify, we are constantly creating and disbanding squads as new needs arise or missions are fulfilled. Squad membership will also ebb and flow as required by the needs of a squad’s mission. Traditional hierarchical organizations are self-perpetuating and restructuring them is very disruptive both to the management chains as well as the individual team members. You would gain some of the benefits of the Spotify model by building full-stack teams in a traditional organizational hierarchy, but you would lose a lot of the overall speed benefits that we leverage with our matrix organization.

In conclusion, if you are looking to improve the speed of your development and are inspired by Spotify’s organizational model, there are a few things that you need to understand. Our model works because it is layered on top of our corporate culture. Our culture values autonomy, agile processes, democratic teams, and servant leadership, amongst other things. You can certainly take some of the ideas from the way we work and apply them in your organization, but without the cultural underpinnings you may not get the same returns.

Some other references worth checking out are Henrik Kniberg’s keynote at the Paris Scrum Gathering and my keynote at the { develop: BBC } conference.

The Known Unknowns

…there are known knowns; there are things we know that we know. There are known unknowns; that is to say, there are things that we now know we don’t know. But there are also unknown unknowns – there are things we do not know we don’t know. – Donald Rumsfeld

Last week I held a day of training for the managers and folks interested in becoming managers in my organization. I did this with a couple of the folks from Spotify’s awesome People Operations team, Paolo and Mats.

As part of the exercises we identified which management skills, values and responsibilities were the most critical for our organization. We then did something like a spider map to help us evaluate our own competencies in these areas, but also to set goals on how we’d like to improve over the next few months. The exercises themselves were awesome, and they identified some truly great qualities of managers and leaders that I hadn’t thought about. I’ll try and write about them in the future.

One thing that struck me as I did this self-assessment was how low I was rating myself on some areas. Areas that my managers had told me that I was strong in. I rated myself low in areas that I would even call my own strengths. The reason was that I had come to realize how much better I could be than I am right now. I knew how much more I had to learn, my known unknowns.

I had noticed this before, in other areas. For years, when I interviewed C++ developers, one of my favorite questions was “how do you rate your C++ skill on a scale from 1 to 10?” Sometimes, I’d add the context of “1 is your dog, and 10 is Bjarne Stroustroup.” What I was looking for was not an assessment of what they knew, but an understanding of what they didn’t know: the known unknowns. I wrote C++ code professionally every day for over 15 years and I would have rated myself a 7 (and that was before C++11 came out). Anyone who rated himself or herself higher than that either was just not being honest (it was an interview situation after all) or they knew so little of the language that they didn’t have a clue how inexperienced they were.

I now realize that this just part of mastery. You reach a plateau in your growth and it seems like you are getting pretty good, but then you grow a bit more and you realize that there is so much more to learn. Ad infinitum.

BBC Academy Video on Engineering Culture

This video only works with UK IP Addresses. Sorry about that…

This includes some short clips from my talk at the BBC in November and has several engineering leaders from the BBC talking about their culture. A good, quick intro.

This page has some more information about the speakers: BBC Academy – Engineering Culture

Some Upcoming Talks in Europe

Happy new year! I’ve got some talks coming up this winter and spring that you may be interested in. In both of them I’ll be talking more about building strong engineering teams and how we build with Agile and Lean at Spotify.

Software 2014
Oslo, Norway - February 26-27, 2014

This is the yearly conference of the Norwegian Computer Society. I’ll be talking as part of the Lean development track. My talk is on Wednesday at 9:45.

Sud Web 2014
Toulouse, France - May 16-17, 2014

The format of this conference looks really great. I’m excited that they asked me to speak. I’ll have more details as the date approaches.

If you are attending either of the conferences above, let me know in the comments or over twitter. Really looking forward to meeting up with people.

My Slides From My BBC Develop Keynote

I had a great time at the BBC Develop conference in London this week. The BBC were gracious hosts, the audience had some good (and not too easy questions) and the program had some really good talks; so I learned quite a bit and met some excellent folks. Special thanks to Tanya Rai, Colin Savage, and Simon Stevenson at the BBC for inviting me and putting on a great day.