[protected-iframe id=”bbca0bb4ac9e246d1abfc398eb6d526d-14960843-61002135″ info=”http://new.livestream.com/accounts/74987/events/2117818/videos/22054848/player?autoPlay=false&height=360&mute=false&width=640″ width=”640″ height=”360″ frameborder=”0″ scrolling=”no”]
Input sound file:
1003.Day 2 Batch 2
Session Name: Metamorphosis: Everything Must Go First
Actually Barb, you’re 19 seconds early. Very impressive. You get a special reward for that. We’ve had basically every iconic firm cross the stage over the last 36 hours, Amazon, Facebook, Rackspace, Google, and there’s really only one left that we haven’t and we’re going to rectify that now. We have Kevin Scott who leads engineering for a company some of you may have heard of, LinkedIn. Just out of curiosity, is there anyone in here who’s willing to admit that they’re not on LinkedIn? Raise your hand. That’s what I thought, exactly zero. That says it all, so let’s how they do it behind the scenes.
Kevin Scott 00:49
Hello everyone, my name is Kevin Scott, I’m the head of engineering at LinkedIn. I am here today to share some stories about metamorphosis, the dictionary definition of metamorphosis is a change in nature from one thing into a completely different thing. In a certain sense, this is what we’re all looking to do, we start companies, we want them to change into successful companies, we launch products, we do all manner of things. The fundamental thing that we’re driving through and managing through and building technology for is metamorphosis. Specifically, if I can figure out how to use this– here we go. The shape of these metamorphoses many times is something that looks like a quest for the Holy Grail. I draw this curve all the time for people when I’m trying to explain to them what it is that we’re going after, and how sometimes we get into binds that are difficult to work our way out of. Sometimes, we’re questing for the Holy Grail, and the Holy Grail is this exponential. You pick your growth units on the vertical axis, it could be dollars, it could be members, it could be traffic, it could be data volume, you just pick your unit that matters to the particular business or product or thing that you are building. Then time is on the horizontal axis, and it may be that you’re looking for this exponential in the context of a startup, you founded a brand new business. It may be that you’re launching or attempting to build a very complicated new product, or it could be the case that you’re building some challenging piece of technology, and you are seeking massive success.
Kevin Scott 02:48
Usually, when you’re questing after this exponential, you can think of things in two discreet stages, and there’s a third stage I haven’t drawn here because just for the moment I’m less interested in it, and that’s the stable state of things, where growth has tapered off. Initially you’re looking for traction, and at some point you hope that if you have found that traction that you will get to the scaling mode. When you’re in the finding traction mode, you’re trying a bunch of different things. You’re trying to figure out what’s going to work. You have probably a hypothesis that you started the project with, a set of goals or objectives that you’re working towards, and you’re doing a bunch of things, trying to figure out if your hypothesis was right, you’re refining your hypothesis, you’re trying a bunch of things. If you’re a startup company you’re raising money, at T zero you’ve got a finite amount of runway you’re trying to manage, and find that market fit before you run out of money and something bad happens. When you’re in this phase of trying things out, you’re looking for this traction, it’s usually the case that you’re operating at small data level, small traffic levels, you have a small user base, and the technology’s easy to change. This is true even if you’re building what seems to be a fundamentally technology-driven company. So even if you’re building a search engine, there are certain things that you can do to build your search engine in the early stages, that don’t require massive investments in technology. That’s a good thing, because it’s really challenging when you’re in this finding traction stage to understand what it actually is that you need to invest for in the future. You’re refining your hypothesis as you go, so you really don’t want to get yourself into a state where you have locked yourself into a set of technology decisions that are going to prevent you from iterating and moving around inside this space that you need to move around in to find your fit and your success as a business. Focusing too much on building out your structure and your technology early can kill you, because you’re wasting time building infrastructure that you may or may not need right now, when really what you need to be doing is iterating on your product.
Kevin Scott 05:04
The interesting thing that happens is once you’re at the end of this traction-finding stage of the curve, you’ve done a good job, you’re successful, you’ve found your market fit, and all of a sudden you’re at the knee of this exponential curve. You find yourself many times wondering “What the hell have I done?” You are now officially growing really fast, and you have to move very quickly to put all of your infrastructure and progress and everything in place so that you can handle all of this growth. What you’ve probably done while you’re looking for your market fit, is you’ve wound up with an architecture that looks something like this. This is the Royal Ontario Museum, sorry if I’m offending anyone who are fans of Daniel Libeskind’s architecture, so you’ve got this juxtaposition of old and new, and it’s probably not the prettiest thing in the world, and it almost certainly isn’t going to thoroughly meet the needs that you have now you’re in this high growth mode. You’ve probably accumulated a bunch of technical debt. You made decisions that you wish you hadn’t made, and you’ve got to clean them up, you’ve got probably some enormous technology challenges, process things, and things about the technology team itself that you’ve got to clean up now, and you’ve got to clean it up in short order. You still have product to build, so even though you’re successful you can’t just stop building product altogether and focus on the back-end of the thing that you built.
Kevin Scott 06:38
You have a bunch of things at this point, typically, and I’ve done this a few times now and advised a bunch of companies that have been in this mode, that are just purely emotional, non-technical things. They’re things about people that sort of prevent you from moving forward. You may believe that you can incrementally evolve the set of things that you’re doing to help you meet this exponential growth, which is an ego thing. It may be that you know what needs to be done, but you’re afraid to do it. There’s all sorts of uncertainty and doubt that you’re having to deal with, but none of that matters. If you don’t put all of those things aside, and really identify what your set of problems are and prioritize, you’re going to be just as doomed as if you hadn’t found your market fit in the first place.
Kevin Scott 07:25
I want to talk a little bit about LinkedIn. In early 2011, we were just filing our Announcer to go public, and we IPO’d on May the 19th. We were in this interesting state that I just depicted in this visual metaphor. Everything was growing rapidly, we were hiring engineers very fast, we had a ton of code that was being written. We had immense growth in traffic, data, member base, everything that was good was growing fast. We had some amazing technology bets in place, along with an aggressive product road map about what we were going to do in the future. But, we were in a space where we couldn’t build things as fast as we wanted to build them. We had this very clear set of goals. We wanted to build great products for our members and we wanted to encourage entrepreneurship within our development teams. The reality of our situation was that we had too much friction, and that friction was discouraging engineers and product managers from taking the sorts of risks that we wanted them to take. We weren’t moving fast enough, it took weeks to get things out to the site, and our fundamental thesis was that we were going to build great products by putting things out there and gathering data and being able to iterate very quickly. We were in this state where team growth meant slower iteration, as we were adding people, we were going slower and slower. We were living Fred Brooks’ mythical man-month. The incremental improvements that we trying to make to the processes and tools and infrastructure that we had to help us manage our software development process, were not helping us, they just couldn’t solve our problems as quickly as we were creating them.
Kevin Scott 09:12
What we had to do, was something that we call project inversion. In November of 2011, five months after we had gone IPO, we stopped all new forward product development. We put a moratorium on it, we put 100% of the engineering workforce at LinkedIn at the time to work on fundamentally revamping the way that we did software development. There’s a ton of things that we did, and the thing that I don’t want you guys to walk away from is that you may not need to do exactly this set of things, because what you may need may be completely different from what LinkedIn needed. We believe that agility and rate of iteration and changing our engineering culture, where individuals owned the end-to-end lifecycle of code they were producing was very important. We did all of these things to help do that. We transitioned from a feature branch to a trunk-based development model, we built continuous integration systems, we changed things about how software was developed. The net of all of this was that we accomplished the goal we set out to accomplish, we were able to grow the software development team, we were able to get to a point where hundreds of software developers can push code out to the site virtually any time they want to. We have teams today who rather than having month long iteration cycles in the development process, push code a couple of times a day, with full iterations, like idea, push, test, gather data, iterate.
Kevin Scott 10:51
The big bets here that we made actually paid off, and the lesson that we learned here obviously is when you get into this situation– and you sort of feel it. You will understand as an organization when you’re blocked out, when you’re no longer making the changes that you need to make to get up this curve as much as you’d like to. The biggest thing was getting confidence inside of the team that they could actually make this big bet, which involved some interesting staging that we did, and a lot of planning, and a lot of getting the entire team involved in the whole process. I wanted to make sure I’ve got a few minutes to answer any questions that you guys may have, so happy to take those right now. Yes?
Audience member 11:44
If you go back to your last slide, how do you measure innovation? What metrics do you use to show the rate of innovation has substantially increased?
Kevin Scott 11:52
I think it’s difficult in general. Every product that we’ve developed at LinkedIn has a slightly different set of success criteria. We looked at things like how fast code was moving to the site, but that does not necessarily measure innovation. You can fling a lot of code, and it can all be crap. I’ll give you an anecdote. The LinkedIn Influencers product, which is a short-term content publishing platform for C-level executives, and influential people in industry has been a very successful thing for us. In quick order we’ve accumulated a very large following, that puts us on par with some very well-known business publications, just in terms of audience size. That whole project took six weeks from idea to actual delivery and starting to get traction, simply because we had done this set of things. Before, four weeks would have been the iteration cycle, and it would have probably meant that this whole project would have taken a couple of quarters to get done. The fact that we could get it done in six weeks, and as part of that six weeks we were incrementally launching all along to small test audiences, was one of the real positives signs that things had improved.
Kevin Scott 13:21
The other thing that we did, we have hundreds of engineers, so part of our challenge is you want engineers to feel like they have the tools and the environment they feel like they need in order to do their job. You can measure their satisfaction with what they’re doing. We could quantitatively look at the satisfaction of our developers over time, and see that they were much happier with their environment post-inversion versus pre-. I’ve got time for perhaps one more question.
Audience member 13:58
You mentioned two months of no new deployments, could you tell us a little bit more about how you actually got that approved, and then how it worked during those two months, how was life?
Kevin Scott 14:09
Part of getting something like that approved– one, it was easy, I’m the Head of Engineering, I can decide what the engineers get to do.
Kevin Scott 14:19
But it does require a huge amount of trust on behalf of the board of directors and the CEO, and the product managers and the company to believe that that’s a bet worth taking. The good thing is, we had been so transparent and so analytical about the problems that we had, that everybody could clearly see that this was something that we needed to do. You had all of the constituent pieces in the company, from the board down to product managers managing a particular feature saying, “I can’t get my stuff done fast enough.” We had tried a gazillion different little incremental things, and we just weren’t moving, in a certain sense we just knew that it had to happen. So the buy-in was there before the decision was actually made.
Thank you, Kevin.