 How much time do we have before start? For how many of you is this your first Agile conference? Cool. And how many are the first? So obviously those people, this will be your first Agile India, how many first Agile India? How many of you are actually practicing Agile, or at least really trying to, in your organization? And I'll ask one more. How many of you are in large organizations, thousands of people? Sure, yeah, I'd say 1,000 counts. So I'm Doc, Doc Norton. I'm with Groupon. And the talk today is on creating a global engineering culture. So to get started, I want to give you a little bit of context. I'm going to kind of give you the history of Groupon, which sort of sets the stage for what it is that we're doing now. So most folks don't know Groupon actually started as a completely different company. It was called The Point. It was actually a social media company. It was designed to get groups of people working together to solve problems and for common causes. And in 2007, The Point started. And it got some traction. And it actually started to become popular in APAC as well as in the US. And in 2008, something interesting happened. A campaign was run by a group of people. And normally, these campaigns were to, again, solve some kind of social problem. But what they did was they ran a campaign to save money on items by buying as a group. And it caught the attention of Eric Likovsky, who is now our CEO. And he started saying, hey, maybe there's something here. Maybe we should do something with this. But The Point had a mission. It was a social causes company. So it took a little while. And finally, due to some financial pressure, et cetera, they decided, you know what? Let's give it a shot. And in 2008, Groupon was launched as a side project. And the intent was just to raise some capital to help propel The Point to its next level. Something interesting I wanted to show you this. This is Groupon's first ever logo and ad banner. So in 2008, Groupon was 10 people. So that's, well, we're going on six years now. We just celebrated our fifth birthday a little while back. By 2010, Groupon was 300-plus people. And then it took off. By 2012, there were over 10,000 people. Groupon became the fastest growing company in history. It was actually by plan. See, the business model was proven. We proved that people actually wanted this. People were buying it. We were growing. So there's definitely a market there. There was definitely a good margin there. From a business standpoint, this was a great idea, except for one problem. Anybody with a WordPress website could do this. Anyone could compete against us. And they were. So if we were going to actually survive, the only way we were going to do that was to consume everything that stood in our way. And that was exactly the strategy. So we grew through massive acquisition. The way that we got into each country was we would look and we would see who's in that space and who's winning. Who's competing against us there? Or has copied our model and is generating the most buzz, not necessarily even the most profit, just the most buzz. And we'd snatch them up and we'd dump money into them so that they would scale and clear out the rest of the market. So we spread to many different countries. And we started to expand our offering. We ended up very shortly with development centers in Brazil, Chile, Germany, India, Japan, and of course in the US. The challenge with this, though, was that there's a bunch of different languages being used, a bunch of different platforms, and a ton of different practices. So what you have is this large company that's actually a bunch of tiny companies all kind of cobbled together. And all of a sudden we have over 1,000 engineers worldwide. Eight platforms, actually more than eight platforms in 48 different countries with 40 million different customers and over 400 million deals in our inventory. This is huge. Here's some of, not all of, but some of the things you can find on Groupon these days. So obviously the first one's just the deals and freebies and getaways and goods, grassroots, live, reserve. And there's others. And we have products that are for the merchants. So there's payment centers and gateways and point of sale, et cetera. Just because we're here, I wanted to point out, in our Chennai Development Center, getaways, the entire front end for getaways was actually developed there and is still being written there. And goods, a significant portion of our entire goods offering was also built right here in India. The goods, to give you an idea, two and a half years ago didn't exist at all. It was just a concept. Last year, over $2 billion, awesome, batteries. So $2 billion in revenue last year, more than $2 billion in revenue last year. So in 2.5 years from zero to $2 billion, that's just one aspect of our business. Now that's all context. I just want to give you a background of where we came from and how fast we grew and what we're doing now. There's over 1,000 engineers at Groupon all around the world. So with that context, let's talk about Groupon engineering's culture. So I joined Groupon just a couple of years ago. I joined in 2012. And I joined in the US offices. I actually joined in the headquarters in Chicago. When I got there, morale was at an all-time low, right? High attrition rates, people were leaving left and right. Engineers were getting together in conference rooms just to complain and commiserate. Things weren't moving very well, right? We had a monolithic code base. It was Ruby on Rails. It had been written very rapidly over a short period of time and had grown into this just huge thing. It was very difficult to make changes. It required a lot of coordination. The company had just attempted a major redesign, a complete new-looking feel of the site, and it was an abject failure. Months and months and months and months of work, and they finally just abandoned the projects. You can imagine how people felt, right? Everyone in engineering was demoralized. The company was unhappy. They'd put in a huge investment in this rewrite, in this new-looking feel, and they got nothing for it. And so all of that time, actual innovation and new product delivery was slow. The only way that we were still actually getting new features out was we were still buying companies. And obviously, no innovation was happening, right? There were a lot of frustrated employees, and there was just an absolute lack of trust. Things had just kind of fallen apart. And Chicago was in what some had described as a death spiral. Basically, what was happening was the folks that were still there were so unhappy about having lost their coworkers and having all this work to do and having no successes that they would leave, which would make it worse for the people that were there. So it was accelerating. In this kind of environment, what happens is people start to look out for themselves first, right? This kind of environment is a world saturated with dopamine. Dopamine is a chemical that we actually produce internally. We have several chemicals that we produce internally that compel us to do certain things. Dopamine is actually good. Dopamine helps us feel good when we achieve something. The thing about dopamine is you should only get it in small doses. And in a toxic environment like this, when we turn internally, when we begin to only think about ourselves, when we are in defense mode, when we are in constant fight or flight mode, dopamine has got a constant drip into our blood system. And it actually feeds into that negativity. And it just gets worse and worse and worse. So what do you do? What do you do in a situation like this? First thing, listen. You start by listening and listen genuinely, not just to the words, but to the actual message. Two or more times a week to this day, I meet with random engineers throughout the Groupon organization. When I first started, it was very concentrated on the US. It was very concentrated on Chicago. Today, you'll find me on a phone call with someone in Berlin. You'll find me on a phone call with someone in Chennai. If we can jabber, that's even better, if we can see each other face to face. And when I get the opportunity to travel, I make sure that I set up appointments to meet with the engineers. Yeah, I spend some time with managers. Yeah, I spend some time with VPs. But I spend the majority of my time with engineers, one-on-one in a closed room. And the only question I ask is, how do you find it here? What is your life like at Groupon? And some of them will tell me, and some of them are afraid. But I listen. So we listened in Chicago, and we learned a lot. There was a lack of mobility. There were unclear career paths. There were management issues. It was hard to move code. It was hard to start a project. And there was no learning opportunity, right? People had been there for a couple of years and they had learned nothing new. They had done nothing new. So how did we help? Let's just run down the list, right? So lack of mobility. People were frustrated because they didn't have the opportunity to actually move around the department. They also didn't have the opportunity to move up the chain. That's a slightly different problem. So maybe I've been a Rails developer for a number of years, and there's a team that's experimenting with closure. And I would love to work on closure. And I go to my manager and I say, hey, I'd really like to move to that team. And my manager's response is, yeah, now's not a good time. Well, now is never a good time, right? So we drafted an engineering internal transfer procedure. It's about a page and a half long. It is literally a procedure. It is just step-by-step what you need to do to actually transfer. There's a portion that's for the engineer and there's a portion that's for management. So portion for the engineer says tell your manager. The portion for management walks through what we need to do in terms of HR, actually coordinating the move, et cetera, right? But here's the deal. No engineer can be denied a transfer. Now, it may be a matter of when, but it is not a matter of if. So it may turn out that you're in the middle of a very critical project. We're gonna be done in two months. Let's set a timeline. When that two months is up, we'll have one week of hand-off transition and then you move to the new team. Or it might be how's noon, right? It depends on the situation that you're in. What the deal is, you know what the situation is. And now is not a good time, is forever. Two months, while that's long, is finite. You know when it's going to be over. You know when you get to make your move. So now it's just a matter of planning, right? So, unclear career paths. You know, we were a startup and we were a startup that grew so fast. We still had a very startup mentality. Now there were no job titles at Groupon. You know, you were a member of technical staff or something along those lines. I don't even remember what it was, right? And the only reason we even had those was because the HR system that we chose mandated that you fill a title in when you entered someone in for payroll. All right, fine. So everyone got the same title. It was no big deal. But as you get bigger and bigger and bigger, it's obvious that there's a hierarchy here. It's obvious that, you know, this person has got more responsibility or is in charge of this team or whatever. And how do I get there? What are my opportunities? And you couldn't really talk to your manager because your manager didn't know either. So we created job ladders for engineers and managers. We actually created two separate tracks. Engineers, so now as a software developer, you can stay as an individual contributor all the way through your career at Groupon. You can actually be basically at an SVP level and still be an individual contributor for software or you can opt to go into management track, right? And we created salary bans around that and everything else. So we made it clear what the actual pathing was. Management issues. So there were many management issues. And mostly it was a matter of really good technical people had just kind of evolved into a team lead role and then when we decided we needed managers, it was just natural that they then became the manager and they weren't necessarily trained. They didn't necessarily have experience as a manager and having responsibility for other people is different than having responsibility for a code base or an architecture. So we did training for all managers, ran that through, every manager went through it. We brought in JANA, which is a tool that is a very good resource for managers to be able to look up anything on how to give feedback, how to do one-on-ones, how to handle critical situations, et cetera. And we instituted mentoring programs where skilled managers would meet with others, other managers to talk to them about like what's going on in your teams, what's happening and kind of help them find their way. So it was hard to move code, right? It was also hard to just get simple things done. So the internal operations team started to work and actually streamlined a bunch of processes and actually allowed for really smooth exceptions, right? So it used to be that when you wanted to move code, it was a couple of week process. There was paperwork involved, there was checks and balances, there was approvals, you're waiting for signatures, on and on and on and on and on. Now, we're publicly traded, so we have certain compliance issues that we have to deal with, but the process today is actually really simple. You get on the ops calendar for a code move. How do you do that? You put an appointment on their Google calendar, right? Anyone can do it. Then, how do you actually do the things? How do you actually move the code? What happens during that process? We need documentation, we need to know who proved what, we need to know who moved what, we need to know who did what. In the past, that was all paperwork. Today, it's hip chat. You go into hip chat and you say SRE, which is the name of our ops group, basically, and they respond, yes, and you have a conversation and you tell them what it is that you're doing, you do your thing, and that's where all the documentation is. It was hard to get your machine configured, right? It was hard to get a project started. Folks would come in brand new to the company. My experience, brand new to the company, wanted to set up our development environment so that I could actually look at the code and work with the teams, et cetera, and I do have three, well, I'll say I did have three commits in the code base somewhere. I'm pretty sure at this point, some other engineer has actually refactored that code away into something that's much better, but it took me four days to get my development environment set up. Four days. Basically, my first day was orientation and the rest of that week was bashing my head against my desk, wringing my hands and clenching my teeth, wishing that I had a machine that was just set up for me. So now the machines are basically set up when you come in. There's VMs that are available. It's still not perfect. We're still working on it. This needs to be rolled out on a broader scale. And the internal tools team has created tooling and platforms that allows you to really easily start up an app. So in the past it was almost impossible but now they actually have what they call Skeletor. And you can basically fork Skeletor and that gives you all of the A.B. testing frameworks that we use, all of the reporting, all of the metrics, basically all the fundamentals and you have a base app that you can start with and then get working on whatever is this new idea that we wanna build, right? And lack of learning opportunities. So we did a few things around this. We actually created a personal growth benefit. We piloted it last year in the US and this year it was actually going global. I'm just finishing up the documentation on this to get it out. But basically the personal growth benefit is every engineer in the organization, there is a budget now that is available for them to be able to go to conferences to get training, to purchase books. We've even had individuals that have come and have said, I want to take this college course. We'll group on pay for a portion of that course or the course in its entirety and we have done that as well out of this budget. We're working on internal knowledge shares. We also offer Safari Books Online, Code School and other tools to engineers. So now there's actually resources available for learning as well as running internal brown bags and that type of stuff. So these things all helped, right? Things got better. But how do you get continuous feedback on this? Like how do you, one, how do you know that it's still working? And then two, how do you actually start to scale this kind of stuff, right? How do you reach out to multiple people in the organization? How do you actually, so how do we get continuous feedback? Well, we did a few things. The first thing was, we instituted director's office hours. It was weekly and it is now monthly. But what happens is managers and directors make sure that there are several folks in a large conference room and engineers can come in and can ask any kind of questions, can raise any kind of concerns and issues. Think back to when you were in school and your professors had office hours where you could just drop in and see them. It's the same kind of concept, right? That we're just making sure that there's a venue where you can actually ask these questions and get information. If we're not getting it out there good enough, here's an opportunity to come ask us. Of course, you can always ask at any other time, but it doesn't always work out that way. You're busy every day on a day-to-day basis. It's nice to know that hey, on Thursday at noon, if I go in this room, these folks are gonna be there and I can actually ask them questions. We also do employee engagement surveys. These are only once a quarter. And the results are shared with all employees, including whatever the plans are for addressing any known issues that come up. Now, this is actually company-wide, so this is not engineering specific. This is to the entire organization. I like the engagement surveys. I think they're very valuable to the organization. I had a couple of challenges with them. One, they weren't really focused on engineering and I really wanted to be focused on engineering. And two, they're only once a quarter. And I didn't think that was often enough. So we instituted the engineering check-in. Check-in goes out once a month. It's 12 questions. They are scientifically designed to measure employee engagement. I say scientifically designed because after looking at a ton of different options and reading all kinds of material, everyone having all different sorts of recommendations about how you measure employee engagement, I found a Gallup study that had been done many years ago with hundreds of thousands of people across hundreds of companies over a 10-year time period. And what they had actually done was distilled a set of many, I don't know, I think it started off with like 250 possible questions and they statistically distilled it down to these 12 key questions that are indicators. So we send that out every month and get feedback from the engineers. We've been doing this for over a year in the US and it is now starting to scale out on a national basis. We actually anonymize the data. So I am the only person in the company right now that can see who responded what, right? No one else can see that. Any other form of this data that's visible is anonymized. We're working on writing a system that even I can't see that. So this is a histogram that we show and it basically shows the quality of answers, right? Do people strongly agree with the statement or strongly disagree with the statement and at what level? And I will show it for the entire engineering organization. We'll also show it to VPs for their subset, directors for their subset, managers for their subset. The only rule that I really have is if you have three or less people that participated in the survey, I don't show the answers to you. I don't share this graph because I don't want you to be able to decompose it down into a particular individual. That's not what this is about, right? We then also look at, yeah. Can you hear it? Can you hear it? Yes. Can you hear it on our floor? Yeah, oh yeah, absolutely, absolutely. So, well, the Gallup study is regularly available. I can actually walk through all 12 questions but I don't think you wanna write them down. And I believe I've got a blog post on this as well on my blog. So yeah, so I didn't even, I kind of, my intro was sort of weak, right? So my title is actually Global Director of Engineering and Culture. My email is doc at groupon.com. Feel free to reach out to me. And you can find me anywhere as docondev, D-O-C-O-N-D-E-V. It's short for doc on development. And my blog is docondev.com. So we actually trend this over time, right? We don't just look at these at each month. We actually trend it over time. We look at how are things going, what's happening, right? So this one in the last year, I've had opportunities at Groupon to learn and grow. People say, yes, I strongly agree or I disagree, et cetera. And this dot graph, the way that it works is if it's up, right, big and blue, that's good. If it's down, left, small and red, that's bad, right? And we just kind of watch how is it trending. So we can see that it's actually trending up, about a year ago. I believe this one right now is actually, this particular one, it's interesting, it oscillates around. And the pattern that I'm starting to see is, it oscillates around kind of quarterly reviews, right? So we may want to do something about that. And then I share this with the managers and with directors, and if we see certain trends or certain patterns, I'll actually send them an email and say, hey, I see this happening in your team. This is kind of the feedback that we're getting. Here's what you might want to do in a one-on-one. Here's some resources that are available to you. If you've got any questions, please let me know, right? And then we also just have an overall engineering satisfaction metric that we use. And you can see this on some of the big screens around the office. All right, so that's some of the stuff that we started with, right? But I want to go back to something. You recall that rapid growth that we talked about? Well, here's what we were hoping to put together during that time period. Modular, sleek lines, beautiful, clean-looking, right? That's what we were hoping to put together. This is kind of what it felt like. This is kind of what it felt like behind the scenes. And remember, we just had an attempt at a major redesign that new-looking feel that had colossally failed. So what are we gonna do? Well, we just rolled up our sleeves and we made an entirely new plan for how we were gonna actually renovate this website. We learned a lot from the prior attempt. And in 2013, we set up working to actually fix our platforms, right? So we went from this huge monolithic, nasty app to service-oriented architecture, node on the front end. Now, I'm talking very specifically right now about what happened in the US. So here, the platform is a different platform. It was all Java-based in the first place. It wasn't Rails-based. And teams here were maintaining and continuing to build features and functions on that platform to reach parity with what we had on the US platform, as well as to do things specific to this market. And they were working on a lot of stuff that was actually being funneled into the US platform first. So the teams here were kind of very fragmented as this was going on. The new app is all node on the front end. The services on the back end are in a number of different languages. Obviously, Ruby and Rails is still a very big component of the application. There's Java. There's Clojure. It's basically whatever language the team feels is appropriate for the challenge at hand, right? This looks like it's out of sequence. Oh, we did it. We achieved it. But it was a very, very difficult effort. And it was very pushed kind of from the top. At least that's how people felt about it. There wasn't buy-in before it started, right? Again, we had just tried this and failed. And then suddenly we're gonna try it again. And there were a lot of folks that were really concerned about it. There were tight deadlines. It was done, we had to be done before the holiday rush. There was a lot of pressure. There were a lot of late nights. There were concerns over quality. And basically there was silent compliance. So I actually saw at one point there was a meeting where probably 20 different teams were coordinating. We all were dependent upon this one particular service. We were all coordinating to move into production at the exact same time right after the service went live. And this ultimately is a versioning issue, but that's a separate topic, right? One of the teams that I was working directly with had tested this service in staging. And it was clearly broken. It wasn't some kind of weird staging data issue or something along those lines. It was clearly broken. 17 of the teams gave a green light before it came to the 18th team who said, no, we will not move this. We will not go into production with this. It is broken. And one by one, the prior 17 teams kind of looked at their shoes, shuffled around and said, well, it does seem to have some kinds of problems, right? We created an environment where people weren't speaking up anymore. It was just silent compliance. They were doing whatever was asked of them to just get through this thing. So we did a retro afterwards. The retrospective was several teams, many, many people. And we actually ran, I think, six different retrospectives. We gathered a bunch of information. We aggregated that and we shared it back to management with recommendations about ways that we can change our communication, ways that we can better plan the project, ways that we can actually coordinate our work. And it's a good thing that we did it because now we're on project unity. So this year, what we're doing is we're moving to a single platform. Remember, we had like eight different platforms? Now we're moving to just one. And that means that we're gonna have not just a few teams, maybe a team from Chennai and one from Chile and several from the US, everyone is going to be involved in this. And it's gotta be rolled out right. This, just quick, is a 30,000 foot view of our future simplified architecture. And by the way, every single one of those boxes that you can kind of see there represents another diagram that's at least this complicated. As a part of this effort actually, our Chennai office is gonna be staffing up and they're gonna take on consolidation of Japan, Korea, Taiwan, Indonesia, Ticket Monster, basically all of APEC, right? What happened? What happened through, as we started, as we moved to this service-oriented architecture, we started to see new behaviors emerge. And it was interesting because people were happy about having more autonomy over their work and all these things that we had done, yet there were still problems. There was a lot of animosity started to show up, right? We were seeing more and more differences between the teams. Things that we hadn't seen before because teams operated basically in isolation. If I worked on this area of the code, I didn't have to integrate with you. Now even though we've gone to service-oriented architecture, we're also integrating all of these various systems. We started seeing a lot more blame, right? So if you wanna integrate with the checkout page and then they deny you a code move because you don't have any test coverage. Okay, you got a deadline, but fine. So you create the tests that they asked for, right? But then they kick it back again because they think your test code is too tightly coupled. It's test code, right? So there's just differences of opinions, differences in the ways that we actually work and trying to actually work together has become actually more, there's more tension. As a result, what ended up happening was a call for standards. All right, we need standards in the organization, right? We need to establish standards and we need to enforce compliance and that will solve this problem. If we just codify how it is that we're supposed to actually behave, how it is that we're supposed to write our code and how it is that we're supposed to interact, problem solved. How many of you agree with that? A couple, okay. So I tweeted this, you focus on compliance and what you get is complacency. Focus on connection and what you get is consistency. We are connected, we are built to be connected, right? How many of you are familiar with Daniel Pink's work? A few, all right. So Pink wrote this book, Drive and in that book he talks about what it is that drives human beings and he said it's autonomy, mastery, and purpose, right? Our ability to have some control of our own destiny and our day-to-day work lives, autonomy. Our ability to grow and expand into better and better things, right? Mastery. And then some reason to actually do this work, purpose. And I agree with him, but I think he left something out. He left out connection. You know, Fowler told us this morning, you need a good group of people that work well together. That's how you make agile work. Agile-smagile, that's how you make any organization work. A good group of people working well together. Like I said, we're social creatures, right? We dominate this world. We are at the top of the animal kingdom, right? We didn't do that through independence. We did that through interdependence. We are the only animal that can communicate at this level. We formed this kind of communication to be able to actually share ideas and to be able to actually better work together and to better protect ourselves from predators and outside world, right? We're the only animal that's established market for trade. We're actually biologically programmed for connection. So I mentioned before, chemicals that can release when in a stressful situation. There's another one that gets released, serotonin. Serotonin is released when we give and when we get back, right? When we support someone else, our body injects serotonin into our system and it makes us feel good. And when someone helps us, the same thing happens, right? Oxytocin gets released when we feel a deep connection. When you see your spouse, when you see your children, you know that feeling. That's oxytocin. Sorry to diminish it to a chemical release. It's still a beautiful thing, right? But we are biologically programmed for connection. We need one another. Now, I'm not saying that you need me specifically, but in general, mankind needs one another. So if we're gonna fix this problem for once and for all, let's take a look at Group on Social Network. So if I look at this, whether it's between offices, whether it's between verticals, whether it's between language of choice, it basically turns out to be exactly the same. When you look at this social network, these connections are relatively few and they're relatively weak, right? Some are barely connected at all. And in fact, one group is basically not connected to anyone else. And it's through these paths that cooperation actually happens. So let's zoom in to one of these teams. Not particularly well-formed. Everyone is connected through some path, right? So no one is completely out. But in a lot of cases, you've got a jump that you've gotta make to actually talk to another team. You've gotta go through someone else. You don't know anyone on another team or you don't know them well enough. Of course, we can always sling out an email, but you know what that's like, right? You know that if you don't know anyone on the team that moves code between the servers, when you make the request, it takes two weeks. But that team over there keeps getting theirs moved in two days. Why is that? It's those connections. Some teams are worse. Some teams are even worse still, right? So if we take a look at these teams, then we actually kind of zoom back out a little bit and we look at the connections actually between them. It's still weak. It's still too few. Look how many jumps. I mean, first of all, there's folks up here that have basically no connection to the rest of the world, right? And this team can't talk to anyone over here, right? They've got no connection. This is what it looks like. This is what it looked like. What happens here? Well, you start to hear this word a lot. They, right? They don't get it. They're not as good as us. They're hard to work with. They have bad ideas. You start to hear they, an awful lot in environments like this. What do we want? We. We want a we environment. What we want to hear is we are in agreement. We rock. We'll work on it together. We can figure it out. We want something with multiple connections. Something that looks more like this. And then organizationally, more like this, right? These are personal connections. So how do we get there? Well, the first thing we did was we established something really simple. We made cohorts. Cohorts are when you come into Groupon, you go through orientation, right? Now, that orientation used to basically be, hey Skippy, welcome to Groupon. Here's your security badge. Here's your HR papers. Have a nice day. Now we're actually walking people through. What does it mean to be a member of the organization? And what does it mean to be a member of the engineering organization? And how do you get your machine set up? And where do you look for information? And who can you talk to about this? And who can you talk to about that, right? So we're actually sharing a bunch of information. Well, we're doing these in clusters. And those clusters become cohorts. The idea is these are not people who are on your team. These are people who are gonna go off and work someplace else, but you all start at Groupon together. So you're all connected with one common thing, and that is you started at the same time. So we actually set up a couple of initial monthly meetings for them after they leave orientation, where they can kind of share and talk about what's happened. In that last meeting, we had them actually brainstorm on ideas for potential future meetings. And at that point, it's up to them. But from the day that you come in now, you have a network of people that you have a common interest with, that you're meeting with and can share. We implement a geek on. So two or more times per year depends on how well we can actually get it coordinated. Engineering end product take off an entire week and they hack and work on. I'd say anything that you want, that's not really true. It cannot be a part of your regular work, right? It cannot be, oh gee, we're behind schedule. Let's take geek on and get caught up or hey, there's this feature that they asked for and we couldn't fit it in. So let's do that during geek on. But you have to be able to squint at it and see Groupon in there somewhere. So it's not launching your own home-based cat rental business or something, right? Projects are actually voted on when it's all done. And that's all done by the engineers. They vote on all the projects and the executive team actually funds them for additional 20% time. Literally funds the project to make sure that it actually can get through to completion, right? And again, from a social connection standpoint, we discourage people from working with their regular team. We actually want them to work with folks they don't normally work with. Choose a language you don't normally work in. So again, creating those social connections, right? This is G-Stack. So G-Stack is an internally built tool. It's much like Stack Overflow. And what happened was there was a team that was distributed enough and they were large enough that they were getting a lot of common questions. People were asking the same thing over and over again as they joined the team. And I said, gee, this is kind of getting tiring. Yes, we could put it up on a Wiki somewhere. Yeah, sure, we could put it on a blog somewhere. But wouldn't it be cool if we had like a Stack Overflow sort of thing that you could search and you could actually like ask a question and you could get multiple answers and people could vote on those answers, et cetera. So kind of more crowdsource the, what's the best answer. So they built it and it worked and we liked it. So we scaled that out. We give out a Rubber Duck award every so often for awesome answers. A little story behind the Rubber Duck. So I've actually read this in a couple different places but the legend at Groupon is that it happened at Groupon. One of the engineers that joined the organization would come in and would ask a bunch of questions, right? Would ask about how to do this or how to do that or would have a problem he's trying to solve and would go and ask someone. And one day he felt, and he was kind of embarrassed that he was asking so many questions and he had a Rubber Duck on his desk. And so he started to just ask the Rubber Duck. He would ask the question, of course, it wouldn't say anything. So he would begin to explain why he was asking. Well, see, I'm thinking this and I'm thinking that and all of a sudden he'd have the answer. He didn't have to ask anyone. The Rubber Duck had given him the answer. So now when someone gives an awesome answer, we give them a Rubber Duck. This is Love Monster. Love Monster was built internally by a team as a kind of sideline for fun project. And in its original implementation, you would go in and you would type in someone's email address and a reason that you love them and it would send them an email. It would say, so-and-so loves you and here's why. And then they started logging that. So you could actually go in and you could see loves that have been set out in the past. You could actually vote on them. Now we're using it as, it's all reinforcing feedback. It's all positive feedback, right? It's all from your peers to your peers. It's real time, it's positive. We're actually starting to integrate this into a comprehensive 360 review system. Teams have integrated with HipChat, they've integrated with G-Stack. It's just all kind of getting bigger and bigger and bigger. And there's some other possible future integrations. We started interest leagues. The leagues, what we started to discover was that in different offices, people would get together just on their own over lunch and would talk about whatever they wanted to, whether it was Java or if it was closure, something along those lines. And we said, hey, these are great ways of actually spreading information. So all we did was put some budget together and start to actually encourage this behavior. So now we have several leagues. There's the Java League, the Node League, the Ruby League, there's an onboarding league, there's a speaker league and there's probably other leagues that I'm not even aware of where they're all self-directed, people get together and they talk about all these varying interests. So now what we're actually doing is, remember that need for standards? We're connecting all of these people together through all these different avenues. Guess where those standards are gonna come from? Those standards are coming from the leagues. The people who are hands-on keys doing the work and talking about this stuff on a day-to-day basis are the ones who are actually drafting the standards. It's not someone with a highfalutin title who is writing up a document and we're forcing it down. Culture clubs. So culture clubs existed in Palo Alto and now we're spreading them all around. And this again was a group of people who got together on their own and said, hey, we should do some fun stuff for the office. Maybe we can make valentines and put them out around the office or maybe we can, right? And then we said this is awesome. So we started actually providing them some funding and now they do bigger and better things. They'll bring in cupcakes, they brought in a in-chair masseuse, et cetera. The last culture club event was actually held across multiple offices at the exact same time. It was on Valentine's Day and it was just a day of appreciation and someone built this, which is an add-on to the Love Monster that takes love and turns it into floating hearts that go across the screen and we had it up on all the big monitors all around the company, right? Now, you may have noticed a thread in all of these things that I'm talking about in terms of how we're kind of creating a culture. We found all of these things in the organization already. All we did was give them a platform. All we did was help get the word out. We found excellence and we shared it. We didn't bring in an outside consultant. We didn't start at the very top, right? All of these things existed at Groupon and they existed because people wanted them and they willed them into existence and that's beautiful. I didn't talk about vision statements. I didn't talk about values. I think those things are valuable. I think they are important, right? But I think it's about connection. When you start a tiny little company, you can easily establish a culture. But to retrofit, it would take an immense cult of personality to be able to retrofit a culture onto an organization and we've seen it in the past. We've seen some of these great leaders that have turned companies around and when that leader moves on, the company falls apart. Connection is sustainable. Find pockets of excellence, spread the word. You're not creating it. You're actually uncovering it. You are not an architect. You're an archeologist. Culture's gonna change. Keep listening, keep digging and keep promoting the beautiful things that you find. Focus on connection and much of the rest will actually just fall into place. I think I'm over time, am I? Quite a bit? Five minutes, okay, all right. Well, I'm around for the entire length of the conference. I'm around, I've got questions, I wanna talk again. Doc at Groupon, you can find me anywhere, it's doc on dev. What happened? What happened through, as we started, as we moved to this service-oriented architecture, we started to see new behaviors emerge. And it was interesting because people were happy about having more autonomy over their work and all these things that we had done, yet there were still problems. There was a lot of animosity started to show up, right? We were seeing more and more differences between the teams. Things that we hadn't seen before because teams operated basically in isolation. If I worked on this area of the code, I didn't have to integrate with you. Now even though we've gone to service-oriented architecture, we're also integrating all of these various systems. We started seeing a lot more blame, right? So if you wanna integrate with the checkout page, and then they deny you a code move because you don't have any test coverage. Okay, you got a deadline, but fine. So you create the tests that they asked for, right? But then they kick it back again because they think your test code is too tightly coupled. It's test code, right? But so there's just differences of opinions, differences in the ways that we actually work, and trying to actually work together has become actually more, there's more tension. As a result, what ended up happening was a call for standards. All right, we need standards in the organization, right? We need to establish standards and we need to enforce compliance and that will solve this problem. If we just codify how it is that we're supposed to actually behave, how it is that we're supposed to write our code, and how it is that we're supposed to interact, problem solved. How many of you agree with that? A couple, okay. So I tweeted this. You focus on compliance, and what you get is complacency. Focus on connection, and what you get is consistency. We are connected. We are built to be connected, right? How many of you are familiar with Daniel Pink's work? A few, all right. So Pink wrote this book, Drive, and in that book he talks about what it is that drives human beings. And he said it's autonomy, mastery, and purpose. All right, our ability to have some control of our own destiny and our day-to-day work lives, autonomy. Our ability to grow and expand into better and better things, right? Mastery, and then some reason to actually do this work, purpose. And I agree with him, but I think he left something out. He left out connection. You know, Fowler told us this morning, you need a good group of people that work well together. That's how you make agile work. Agile-smagile, that's how you make any organization work. A good group of people working well together. Like I said, we're social creatures, right? We dominate this world. We are at the top of the animal kingdom, right? We didn't do that through independence. We did that through interdependence. We are the only animal that can communicate at this level. We formed this kind of communication to be able to actually share ideas and to be able to actually better work together and to better protect ourselves from predators and outside world, right? We're the only animal that's established market for trade. We're actually biologically programmed for connection. So I mentioned before, chemicals that can release when in a stressful situation. There's another one that gets released, serotonin. Serotonin is released when we give and when we get back, right? When we support someone else, our body injects serotonin into our system and it makes us feel good. And when someone helps us, the same thing happens, right? Oxytocin gets released when we feel a deep connection. When you see your spouse, when you see your children, you know that feeling. That's oxytocin. Sorry to diminish it to a chemical release. It's still a beautiful thing, right? But we are biologically programmed for connection. We need one another. Now, I'm not saying that you need me specifically, but in general, mankind needs one another. So if we're gonna fix this problem for once and for all, let's take a look at Groupon's social network. So if I look at this, whether it's between offices, whether it's between verticals, whether it's between language of choice, it basically turns out to be exactly the same. When you look at this social network, these connections are relatively few and they're relatively weak, right? Some are barely connected at all. And in fact, one group is basically not connected to anyone else. And it's through these paths that cooperation actually happens. So let's zoom in to one of these teams. Not particularly well-formed. Everyone is connected through some path, right? So no one is completely out. But in a lot of cases, you've got a jump that you've got to make to actually talk to another team. You've got to go through someone else. You don't know anyone on another team or you don't know them well enough. Of course, we can always sling out an email, but you know what that's like, right? You know that if you don't know anyone on the team that moves code between the servers, when you make the request, it takes two weeks. But that team over there keeps getting theirs moved in two days. Why is that? It's those connections. Some teams are worse. Some teams are even worse still, right? So if we take a look at these teams, then we actually kind of zoom back out a little bit and we look at the connections actually between them. It's still weak. It's still too few. Look how many jumps. I mean, first of all, there's folks up here that have basically no connection to the rest of the world, right? And this team can't talk to anyone over here. They've got no connection. This is what it looks like. This is what it looked like. What happens here? Well, you start to hear this word a lot. They, right? They don't get it. They're not as good as us. They're hard to work with. They have bad ideas. You start to hear they, an awful lot, in environments like this. And what do we want? We. We want a we environment. What we want to hear is we are in agreement. We rock. We'll work on it together. We can figure it out. We want something with multiple connections. Something that looks more like this. And then organizationally, more like this, right? These are personal connections. So how do we get there? Well, the first thing we did was we established something really simple. We made cohorts. Cohorts are, when you come into Groupon, you go through orientation, right? Now that orientation used to basically be, hey Skippy, welcome to Groupon. Here's your security badge. Here's your HR papers. Have a nice day. Now we're actually walking people through what does it mean to be a member of the organization? And what does it mean to be a member of the engineering organization? And how do you get your machine set up? And where do you look for information? And who can you talk to about this? And who can you talk to about that? And right, so we're actually sharing a bunch of information. But we're doing these in clusters. And those clusters become cohorts. The idea is these are not people who are on your team. These are people who are gonna go off and work someplace else. But you all start at Groupon together. So you're all connected with one common thing. And that is you started at the same time. So we actually set up a couple of initial monthly meetings for them after they leave orientation. Where they can kind of share and talk about what's happened. In that last meeting, we had them actually brainstorm on ideas for potential future meetings. And at that point, it's up to them. But from the day that you come in now, you have a network of people that you have a common interest with, that you're meeting with, and can share. We implement a geek on. So two or more times per year depends on how well we can actually get it coordinated. Engineering end product take off an entire week and they hack. They work on, I'd say anything that you want, that's not really true. It cannot be a part of your regular work, right? It cannot be, oh gee, we're behind schedule. Let's take geek on and get caught up. Or hey, there's this feature that they asked for and we couldn't fit it in. So let's do that during geek on. But you have to be able to squint at it and see Groupon in there somewhere, right? So it's not launching your own, you know, home-based cat rental business or something, right? Projects are actually voted on when it's all done. And that's all done by the engineers. They vote on all the projects. And the executive team actually funds them for additional 20% time. Literally funds the project to make sure that it actually can get through to completion, right? And again, from a social connection standpoint, we discourage people from working with their regular team. We actually want them to work with folks they don't normally work with. Choose a language you don't normally work in. So again, creating those social connections, right? This is GStack. So GStack is an internally built tool. It's much like Stack Overflow. And what happened was there was a team that was distributed enough and they were large enough that they're getting a lot of common questions. People were asking the same thing over and over again as they joined the team. And I said, gee, you know, this is kind of getting tiring. Yes, we could put it up on a Wiki somewhere. Yeah, sure, we could put it on a blog somewhere. But wouldn't it be cool if we had like a Stack Overflow sort of thing that you could search and you could actually like ask a question and you could get multiple answers and people could vote on those answers, et cetera. It's a kind of more crowdsource the, you know, what's the best answer. So they built it and it worked and we liked it. So we scaled that out. We give out a Rubber Duck award every so often for awesome answers. A little story behind the Rubber Duck. So I've actually read this in a couple of different places but the legend at Groupon is that it happened at Groupon. One of the engineers that joined the organization would come in and would ask a bunch of questions, right? Would ask about how to do this or how to do that or would have a problem he was trying to solve and, you know, would go and ask someone. And one day he felt, and he was kind of embarrassed that he was asking so many questions and he had a Rubber Duck on his desk. And so he started to just ask the Rubber Duck. And he would ask the question, of course it wouldn't say anything. So he would begin to explain why he was asking, well, see, I'm thinking this and I'm thinking that and all of a sudden he'd have the answer. He didn't have to ask anyone. The Rubber Duck had given him the answer. So now when someone gives an awesome answer we give them a Rubber Duck. This is Love Monster. Love Monster was built internally by a team as a kind of sideline for fun project. And in its original implementation you would go in and you would type in someone's email address and a reason that you love them. And it would send them an email. It would say, so-and-so loves you and here's why. And then they started logging that. So you could actually go in and you could see loves that have been sent out in the past. You could actually vote on them. Now we're using it as, it's all reinforcing feedback. It's all positive feedback, right? It's all from your peers to your peers. It's real-time, it's positive. We're actually starting to integrate this into a comprehensive 360 review system. Teams have integrated with HipChat, they've integrated with G-Stack. It's just all kind of getting bigger and bigger and bigger, right? And there's some other possible future integrations. We started interest leagues. The leagues, what we started to discover was that in different offices people would get together just on their own over lunch and would talk about whatever they wanted to, whether it was Java or if it was Closure, right? Something along those lines. And we said, you know, hey, these are great ways of actually spreading information. So all we did was put some budget together and start to actually encourage this behavior. So now we have several leagues. There's the Java League, the Node League, the Ruby League, there's an onboarding league, there's a speaker league, and there's probably other leagues that I'm not even aware of where they're all self-directed, people get together, and they talk about all these varying interests. So now what we're actually doing is, remember that need for standards? We're connecting all of these people together through all these different avenues. Guess where those stands are gonna come from? Those standards are coming from the leagues. The people who are hands on keys doing the work and talking about this stuff on a day-to-day basis are the ones who are actually drafting the standards. It's not someone with a highfalutin title who is writing up a document and we're forcing it down. Culture clubs. So culture clubs existed in Palo Alto, and now we're spreading them all around. And this again was a group of people who got together on their own and said, hey, we should do some fun stuff for the office. Maybe we can make valentines and put them out around the office, or maybe we can, right? And then we said, this is awesome. So we started actually providing them some funding and now they do bigger and better things. They'll bring in cupcakes, they brought in a in-chair masseuse, et cetera. The last culture club event was actually held across multiple offices at the exact same time. It was on Valentine's Day, and it was just a day of appreciation, and someone built this, which is an add-on to the Love Monster that takes love and turns it into floating hearts that go across the screen, and we had it up on all the big monitors all around the company, right? Now, you may have noticed a thread in all of these things that I'm talking about in terms of how we're kind of creating a culture. We found all of these things in the organization already. All we did was give them a platform. All we did was help get the word out. We found excellence and we shared it. We didn't bring in an outside consultant. We didn't start at the very top, right? All of these things existed at Groupon, and they existed because people wanted them and they willed them into existence, and that's beautiful. I didn't talk about vision statements, I didn't talk about values, I think those things are valuable, I think they are important, right? But I think it's about connection. When you start a tiny little company, you can easily establish a culture, but to retrofit, it would take an immense cult of personality to be able to retrofit a culture onto an organization, and we've seen it in the past. We've seen some of these great leaders that have turned companies around, and when that leader moves on, the company falls apart. Connection is sustainable. Find pockets of excellence, spread the word. You're not creating it, you're actually uncovering it. You are not an architect, you're an archeologist. Culture's gonna change. Keep listening, keep digging, and keep promoting the beautiful things that you find. Focus on connection, and much of the rest will actually just fall into place. I think I'm over time, am I? Quite a bit? Five minutes, okay, all right. Well, I'm around for the entire length of the conference, I'm around, I've got questions, I wanna talk again. Doc at Groupon, you can find me anywhere, it's Doc on Dev.