My slides from ProductTank Sthlm

I was asked to speak about how we align around the product while we maintain autonomous teams. Given that this was a talk to product people rather than engineers or coaches, I tried to keep it focused around product definition and prioritization. As usual, I don’t like to put many words in the slides, so hopefully you get the gist. There is a recording being made, so hopefully that will get posted and then I will link to it here.

Upcoming talks, Fall 2014

20140412-1609571_768702076480956_1657276409185057456_n

I’ve got some talks lined up for this fall, including my first talk in Asia!

ProductTank STHLM – Stockholm, Sweden – August 27, 2014
Nice to talk again in my home city, and super excited to be speaking to a group primarily made up of product professionals. I’m going to give a talk about how engineering and product teams can work together effectively and how we work at Spotify.

Empowering your engineering talent – London, UK – September 22, 2014
Coming back to London for a breakfast symposium on hiring and empowering engineering talent. 

QCon Shanghai – Shanghai, China – October 16-18, 2014
I’ll be one of the keynotes at the Shanghai edition of this international software development conference.

Hope to see you at one of these!

The Myth of the Startup in a Large Company

I was reading this post from John Gruber, which had this paragraph in an ad for the iOS development team at Google:

My thanks to Google — that’s right, Google (kind of awesome, right?) — for sponsoring this week’s DF RSS feed. They’re hiring developers and designers for their iOS app teams, which operate like a start-up within the walls of Google.

and I thought about the number of times I’d heard that line: “Operates like a startup within insert large company name here” or “Operates like a startup, but without the risk.” I’ve heard that line so many times from recruiters, from friends… To be honest, I’ve even said it myself a few times, trying to sell a prospective candidate who I was trying to woo away from a startup.

That notion, of working like you are in a startup, but being part of a much larger organization, is a myth. Anyone who says it is naive, disingenuous or just plain wrong. Large companies that try to build those kinds of teams; be it “innovation lab”, “startup experiment” or “corporate startup incubator” usually fail to achieve the innovation or energy they sought. The result is usually a whole bunch of wasted money and angry employees who felt like they were promised a bill of goods.

Stewart Butterfield, discussing his experience selling Flickr to Yahoo:

They sold out to Yahoo assuming that they’d be backstroking in rivers of money and terabytes of memory. Instead they had to fight for everything: servers, people, time.

This is talking about the inverse problem, but it comes down to the central crux of the issue at large companies: resource contention. This is beyond innovator’s dilemma.

In a startup: all of your attention is spent on finding the right product/market fit, finding customers, finding a flow of income, and/or finding investment. You will make the trade-offs you need to get your product off the ground. Often this may mean choosing poor technologies in the short term to help you get going more quickly. Your resources are limited, you need to make do to get going. Maybe you will take some short-cuts in other areas just to get the product launched. You are fighting for your life and your income, and you will do whatever it takes to get there. Why do you do it? Because you love the energy, or because you are looking for the fiscal payoff. No risk, no reward.

In a big company, you don’t have to make those trade-offs. There is probably a very mature infrastructure to build on; there is a brand to build off of; there is the promise of a paycheck no matter what the outcome. It is these conditions that destroy the innovation.

There is a mature infrastructure, but maybe it is not a great fit for what you are trying to build. Maybe you just need some small tweaks, but the infrastructure team is primarily focused with serving the existing teams that bring in the revenue; it will be hard to get your needs prioritized. Maybe you can even prototype or launch with your own skunkworks infrastructure; that won’t last for long. The corporate infrastructure is vetted, financed, regulatory compliant, and they own their turf and don’t appreciate someone jury-rigging something else.

There is a brand, but that brand is well known and highly controlled. You can’t launch just anything using that brand. It needs to be vetted. This means that instead of focusing on building your product, you are instead focusing on getting internal support. Maybe you launch under some new secret brand. This may work for a little while, but if you are successful, there will be increasing pressure to join the fold. And in any case, launching under a secret brand basically kills the benefit of the being part of the parent company.

The lack of risk is its own deterrent. Knowing that you get the paycheck is nice, but it is also understanding that you have very little ownership in the outcome. It isn’t “your” product, it is your corporations’ product, you are just one of the people on the team. While you may still put in startup hours for the joy of it, eventually you will realize that you aren’t getting the startup reward for all your hard work, and that is pretty demoralizing.

The general problem is that even if you have the deep pockets of a large corporation backing you, you don’t have the ability to do what it takes to survive. From the minute the project is launched, you are on a clock. Because you are part of a larger (presumably already profitable) parent, you will be restricted from certain business models: it’s hard to justify spending a few years taking substantial losses to scale your business quickly when you are seen as a drain on the profits of your parent company. Amazon, with their don’t-ask-us-about-profits model could never have been created as a division of Microsoft. The shareholders would have rebelled.

If you don’t succeed quickly, your team’s resources will be coveted by the teams around you. They are like vultures waiting for you to fail, and they will rush to declare you a failure as early as possible if they think they can benefit from it.

If you are successful and start to grow, you have the same problem. Teams will attempt to co-opt your mission, or take over your team, or switch you onto the “official” technology stack, or just flood you with resources trying to get some of your “startup” energy.

If you are successful by startup standards, that may not be seen as much of a success in a larger parent company where there is an established business. Being slightly profitable is a huge win for a startup; being slightly profitable is a major loss for an established corporation.

So, how can you create a startup in a large company? I think the university model is an interesting approach. Say you are Company X, a large multi-national technology company, and you are constantly challenged by your inability to move at startup speed or innovate. Instead of creating a startup team inside some division; instead create an actual startup.

Solicit pitches from your entrepreneurial employees. Pick one or more, and fund them as independent companies. Give the founders an equity stake in the new venture, but Company X will own a significant stake as well, plus some non-exclusive licenses on the IP. Allow them to recruit from your company, but they will no longer be employees of Company X. If the venture fails, they may be able to interview to rejoin Company X, and they may get to get some of their benefits back, but there is no guarantee of employment. Also, get them out of your building. Allow them to raise outside investment if they need.

By sponsoring your own employees, they are likely to build in a compatible way with the way your company works, given that it is their training. They will know your industry. They won’t be complacent because they can’t afford to be. They will also be invested because they will directly benefit from their success. In the end, you will get the innovation you want, and probably cheaper than if you tried to fund it from within your own cost structure with all of its overhead.

[This post was updated on August 23, 2014. Nothing was removed, but I added some more thoughts about business model limitations and startup success levels not matching the expectations of a more established company]

A recording of my talk from SudWeb 2014

Forgot that I had a head cold when I gave this talk, so my voice sounds a bit rough, and I start a bit slow. So sorry about that, but I’m so grateful for the high quality recording that the SudWeb team did.

Culture leads, everything else follows – Kevin Goldsmith from Sud Web on Vimeo.

Spotify Lead Engineer explains why there are no strong teams without the manifestation of shared values.
From the culture comes anything else.

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.