 take a nap before HP tonight. But thank you for coming to hear me share my kind of war stories from collaboration in an HD world. And HD, in this case, is highly distributed. I'm Rania Moser. And for the period of this story that I'm going to cover, I was a software development manager at Rackspace for our public cloud deploys. This morning, no, yesterday afternoon, right after lunch, I gave a talk on the service-oriented deploys, which was a summary of everything we had done over the last three years of work with a deeper look at what we had accomplished over the last six months. And this talk is really taking some of that same period of time and that same work that we did in talking about how we were managing the team, how I was managing the team, and how I was making it effective as possible to deliver these pretty impressive technical achievements. To start us off, this is a quote by Rolo Rismay. He is an American existential psychologist, and it kind of gives you an insight into what we're going to be doing in this talk. It's a little of psychology, a little sociology, a tiny bit of technology, and just a lot of, hopefully, common sense in communication. Because really, it's communication that leads us to community, which is understanding intimacy and mutual value. And that is truly one of the keys to having an effective team, whether you're co-located or distributed around the world. And so this talk is really my story of about an 18-month period of how I learned some valuable lessons. And I could go back in time and tell my younger self, this is what I would share with myself. OK, so most of us work for global companies. Some of us work for smaller companies, but a lot of us that are involved in OpenStack work for global companies. Rackspace is an example of that. Giant number of customers, almost 6,000 employees. We have offices all over the world. And staying connected is really hard. Then you factor in the actual OpenStack community, which had almost 1,500 contributions from 169 different organizations in the KELO cycle. 792,000 over 3 quarters of a million strings were translated into another language. So we are definitely a global community. And we're definitely solving complex problems. There were almost 400 new features added, over 7,000 bug fixes across all of the different projects, as well as the common libraries, and over 100 supported plugins and drivers on the marketplace site. So this is the reality of the world that we're working in and living in on a day-to-day basis. Whether it's in our own companies that we're employed by or that we run ourselves, or in our larger open source community. And so I believe that as a community, we do want to deliver really good software continuously as possible, quickly as possible, so that we can satisfy our customers' needs, whether they're a paying customer, creating a VM on our public or private cloud, or an operator. And we're a developer. And we're creating tools and software that they're going to actually have to deploy and maintain. Agile is something that's near and dear to my heart. It was originally introduced in the year 2001 when a bunch of guys, 17 or so, got together at a ski resort and said, hey, we're all working about the same way. Let's kind of write this step down. And the Agile manifesto was born. It's 15 years old now. So some of the questions are, how do you adapt this idea of Agile software development, which we know we need, into a distributed team? So let me tell you my story. I joined Rackspace in April 2012, helped them launch their public cloud in August 2012. And in April of 2013, I was promoted from a software development lifecycle manager, kind of a scrum master type of a role, to a full-on software development manager. And I was given a team. And I had been previously in government contracting for the Army Medical Command in the United States, and was kind of missing my co-located team. I was like, oh, yeah, this is going to be great. I'll have people, get to mentor, I'll get to lead, I'll have this vision, and it'll be great. We'll be implementing it. It's like, maybe it'll look like this. We'll be huddled around. And I'll be at the center, everything like that. Or maybe it would be more like this. We'd be side by side, fitting the puzzle pieces together. Or quite possibly, maybe it would be hard and sweaty. But we'd be a scrum team, running down the field together. Me, their captain. And in reality, this was my team. We were all over the world, quite literally. There was a 13 and a half hour time difference from one end of the team in Bangalore. It's through Johannesburg, South Africa. And then three of the four time zones in the United States. So we had East Coast, Central in Texas, and then on the West Coast. And that was not what I thought I had signed up for. But I was still excited. I was like, OK, we can make this work. Yay, I get to work from home a lot more. This could be good. And so I'm so distracted because my preview slide isn't coming up. So I don't know what I'm saying next. But so this was my reality. And I had to figure out how to make it work. And so this is the start of my highly distributed team. And so a distributed system, of which I truly believe a group of people is a system just like a group of software, is where the components are communicating and coordinating their actions only by passing messages. So just passing messages. And this is from an actual distributed systems concepts and the design textbook that I had in my undergrad. A team, according to Marian Webster, is a group of people who work together. So a highly distributed or an HD team, for me, is a group of people who work together virtually and are relying on technology to communicate and coordinate their actions. Because we're not co-located. We're not in the same space. And this is my take on it. And it might change over the next year or two as I continue to work with distributed teams. But this is how I understand it today. And so the question becomes, can agile work in an HD team? These are the buzzwords we have. Self-organizing, adaptive planning, evolutionary development, early delivery, rapid response, cross-functional. You see frameworks like Scrum and Lean and Kanban. And how do you apply those things most of which are have a co-located mindset to a very distributed team? And so if we go back to our agile manifesto, it actually gives us a pretty good insight into what we need to maybe focus on a little bit more to be effective, even though it may not be what we have thought of as ideal. You think of the agile manifesto as created for co-located, scrummy-like teams or that what would become really a scrum-like team. So how do we look at this now? So agile says individuals and interactions are more valuable than process and tools. Okay, so if your individuals and interactions can't be right together right there all the time, maybe you can bump up your process and tools a bit to get a little bit to be more effective. Working software is more valuable than comprehensive documentation. Definitely agree. However, when you're working on something that people are 12 hours away and you can't ask them, hey, how does this work? Your documentation becomes a lot more important. Customer collaboration versus contract negotiations. Now, I was an internal, all my customers were internal. So I didn't have to do quote, unquote, contract negotiations, but collaborating with somebody and having somebody in, say, Texas understand that the team in South Africa aren't awake and can't help right now is really important. And so setting up those negotiations and kind of treating it like an agreement, a contract, becomes really important. And then responding to change versus following a plan. What I have found is, yes, you're gonna respond to change, have to be flexible and adaptive, all of those great things, but your plan is even more important than if you are all able to be in the same room and adapt and adjust course daily. Having that guiding path through becomes really, really critical to keeping everyone on the same page. And for people to know, hey, I have a question, this doesn't feel right, I don't think this is the right direction. If they know where you're going, then they can actually help keep you steering the right course. So we have some theory, I really like theory, I just finished graduate school, so I'm still in theory heaven. But so here's the lessons learned on effectiveness in an HD team, and there are four major themes that emerged. Now to come up with this group, I actually reached out to some of my old team members. Most of us have moved on to other positions, some at Rackspace, some with other OpenStack companies, some have moved to Germany and are live in the life with lots of beer. And so I reached out to them and I was like, hey, what were the things that you learned that you take away and reflect on the most? And this is what we came up with, is to treat it distributed first, treat your teams distributed first, it's your lowest common denominator, but value that face to face time and make it a priority, spend the money to get together, take the time away from families even though it can be hard to do that. Working groups, you have a team, but find the sub teams, find the pairs, find the threesomes, the smaller groups of people to focus on different parts of the problem. And finally, actually engineer the team. Letting it just happen, I've seen it work great in an office. On many teams I've had, you just emerge, you go through your storming and your forming in those different stages of team development. In a distributed team, if you wait for it to just naturally occur, it could take forever and it may never actually happen. So actually taking time to engineer the team. So let's go through each of these themes and actually gonna explain to you the tools and what we were doing that helped make this possible. And I'm sure there are some things where I was like, and this was really bad and we would do it this way if we could go back. Okay, so distributed first. So here's my crazy team all over the world. Two of us are in San Antonio, Texas, we're rock spaces headquarters. Two of us are in Johannesburg, South Africa and we could have lots of face to face interaction, lots of talks, lots of conversations, but it completely left the rest of the team out and it made it extremely difficult to move all together. So really distributed first is about treating everybody even if you're in the same office as if they are a distributed remote employee. And then that puts everybody on a level playing field. So here's one of the ways that we did this. This is how we actually did our daily stand-ups because we did still do daily stand-ups. And we combined a written document of this that everybody no matter what country they were in filled in at the end of their workday. The document, and so you could also use a Google doc now that that exists to keep track of the same information. It had relevant links to our sync archive, our team calendar, we were doing release engineering for the public cloud so it was kind of a look at what was coming up in terms of schedules, our backlog, things of that nature are all there so that there is any, where do I go? Question. And every day it's a pretty standard scrum stand-up. What are you doing today and what did you accomplish yesterday? What are your blockers? And we could use this written dialogue to say, so for example, Vec, who's actually Kevin Mitchell, who's a Nova core and he's here floating around in the Nova design sessions, if you happen to see him, he could put, I need a review on this pull request and let people know who are coming on later in the day that he needs help on it. So when they come up, they will take the review and merge it. And it helps put it up in all of the chatter of a GitHub email saying, hey, this one's important for what we're doing right now, please take a look at it. It helped me a lot in keeping track of all of the different components that were going on. And then in conjunction with this written stand-up, we also did a verbal stand-up. It was usually audio only. And it would be whoever was in that time zone so normally it was 10 a.m., central time, and which was late enough in the day for South Africa to still be at work, but not so early that the people living on the West Coast hated me. And so that was the 10 a.m., central time was like the magic happy spot. I would periodically over the course of that 18 months try to get rid of it, because I don't like meetings. I mean, even though I'm a manager, I was a people manager and I say the word process all the time, I really don't like meetings. But every time I would drop the stand-up, things would start to shift and get weird. Because this was a group of people who could go three weeks, three months without actually talking to each other. And they finally even, they would even pull pushed back and say, no, we have to talk. We don't want to do it every day either, but we have to, we get too much value from it. So combining the written documentation with the verbal stand-up was the best. And then occasionally we'd also do a later in the day one which would correspond more with Bangalore. Luckily we only had Bangalore for about six months of this process, so it did shrink down to a more manageable size. Everybody moved to South Africa. So then the other big important part is to have your always on place, that central cubicle that everybody sits at that you can go by and talk to people. For us, it was IRC, for most of OpenStack, it is IRC. This is just a copy of the OpenStack, the at OpenStack channel on FreeNode right now. And so this is where we would have our own channels on our own rack space specific IRC. Some teams actually have password protected IRC channels on FreeNode. A lot of teams are starting to use Slack now because I have to say it is really nice in terms of integrating with your email and all of your other forms of communication. And so this is where we would do work collaboration and also the social, just hey, how are the kids doing? What movie did you see? It helps if you have a couple of extroverts on your team. I am mostly extroverted, but actually I had some engineers. I had two of them actually. They were more extroverted than I and so we're perfectly happy to start chatting people up in the channel when it was kind of in a lull of the work so that we would have those conversations that you would have sitting, having coffee in the break room type of a thing. And it helped build trust and connection and community within our team. And the last piece is the video conferencing. When we were doing all of this about two years ago, video conferencing was still really not great. Now this is just a random screenshot from Google Hangouts off of the internet, right? But we actually are using video now, VIDYO, which is based on Google Hangouts. And that one has really transformed how we work. So this way now, when there's a meeting, we used to have an audio-only conference using a TeamSpeak server, which is something gamers use. It's really crisp voiceover IP that works all over the world quite well. But we can have the video connection. And so this way, any meeting that we have, everyone is in there. Even when, so I'm in there in the meeting and the guy sitting behind me who's on my team is in the same meeting and we're having to coordinate making sure we mute at the right time or we hear each other and it's very confusing. And I get distracted seeing the back of my head and deciding if my hair looks good or not. But I mean that's literally what you have to do when you're putting distributed first. Lowest common denominator, if you have a group and you wanna get them into a conference room and there's even one person that has to be meeting, I strongly advise if one person has to do it for whatever reason, everyone should be there. Now if it's a situation where someone was sick and should have made it and there just need to be home for whatever reason, those are those ones you can play by hand. But when your team as a whole is a distributed team, go with that distributed first. So lessons learned, wall of text so that you can kind of summarize it. Treat everyone if you're remote, even if you sit next to each other. As part of that resist the hallway conversations when you're making important decisions. I've heard that a lot and it's really hard. I love talking to people when I'm in the zone, love talking to people, troubleshooting. So when you do have those in-person communications and don't beat yourself up about it, just make it a priority to catch everyone up as soon as possible so they don't feel left out. Can't tell you how many times. Before I was an actual dev manager, I would be the one telling the rest of the remote and especially the Nova developers, hey this is the direction we're going with the cloud and they're like, I'm glad someone told me because I didn't know. And they feel so sad and they're like sad pandas. They feel so left out even though they wouldn't move to San Antonio so it's kind of that catch 22. Find your always on communication channel for real time business hours chat. OpenStack is 24 seven so we often times where both the team was online a lot at late at night but at least keep it for your business hours. For us this was IRC, it might be Slack, Skype. It could also be a video based where everyone just hangs out on a video channel. I don't know anybody that does that yet and I really hope that doesn't become the expectation. Do your updates written so that everyone can consume them no matter what time zone they're in and if one person has to be in a video conference everyone should be in the video conference on that one to one basis to avoid the whispers and the side conversations that happen when you've got 10 people in a meeting and 10 people in a room and two people on the conference and little sideways conversations. Okay, so valuing face to face. We would meet about once a quarter. Our initial team was formed with a one week kickoff. Everybody came to San Antonio, came to the mothership and communed with the space that we call Castle and drank too much soda and ate too many food trucks and had a good time and we really got to know each other and then we would try as much as possible to repeat that. The best cadence was about every two months which works out to about once a quarter as you stagger it and it led to moments like this. So this is a group of, this is some, I'm watching Brian Rosmeita sitting up front and he knows a lot of these people. And this was a San Antonio, we were at, how I don't even remember, Blue Star, somewhere in the Blue Star complex. Just chatting, having food, eating together from a cultural point of view that is still like a huge, just constant across all cultures, across all individuals, breaking bread, eating food together and if you like beer, drinking beer. And these were so important and when we had the team come together, it was never required and I swear, because there were sometimes people were like, no, I just can't, I don't wanna come out, I don't wanna do anything. It's never required to come and hang out after hours. But sometimes it was, let's go see a movie together. And we wouldn't do it during work hours like you would maybe if you were doing a team onsite. But because you don't wanna waste the time that you're here when you've traveled halfway around the world. But we would go and share. Teenage Mutant Ninja Turtles was one I remember. That was ridiculous and fun. So really on the face to face, kick off your team in a single location. Return to your central location for every two months or so if you can for one week at a time. One of the things I started doing that worked really well is when you have remote employees and you're celebrating a holiday and everybody gets a Christmas party or a turkey, Thanksgiving is big. Everybody gets a turkey sometimes. Or you did a really great job on a project and so they order you pizza in to the office. Or you're working really late and they order you pizza in so you don't have to leave. And one of the things we found is like, hey, if you want to go to a movie and take your family, here's your budget, I'll approve your expense report up to that point. If you wanna order in lunch because we're ordering in lunch, go ahead and do that and I'll approve your expense report. It's a little extra paperwork for them but it gives them that option to at least have that sense of, hey, I'm doing this, the rest of the team is doing this. Things are, this is good. And celebrate the small things. This was one of the things that Scott Mutes who will show up later in this, he was the guy down in Johannesburg, South Africa said was that we could have done a better job of this. We were so focused on getting to the next thing that we were not good about stopping and saying, hey, great job to each other, to ourselves, it was just kept on going. And so celebrating those small milestones, even if it's just a pause at a stand up to say, hey, great job, back to work. It really is an important thing to call out. So, all righty, working in groups. This one is fun. I don't know how many of you have heard of the Pomodoro technique but this actually worked. Oh, I have a couple, I saw a couple of head nods, a hand, good. Scott actually introduced it to the team and it worked really well. So the concept of a Pomodoro is you just take 25 minutes of work, you take a three to five minute break, that becomes a Pomodoro I, or Pomodoro E. It's a singular for Teneto in Italian. And then after four of those cycles, you take a longer break, 15 to 20 minutes. And the idea being that frequent breaks followed by mental focus actually increases mental clarity and agility. PomodoroTechnique.com is where you can go to learn more. It is a registered trademark of the company. But Scott brought this in. And what we actually started realizing was that we could pair on a Pomodoro, a tomato timer as we called them because Pomodoro was too many syllables to type in IRC, too many letters. And so, and allow us to focus, allow two or three individuals to focus on the same time period. Helped balance the different personalities. Some people were very scattered and like squirrel, I fall into that category. And some people like to stay focused for a really long time. And 25 minutes was that kind of individual common ground that worked really well when we were pairing on things. Another really important thing when you're working in groups is to just embrace Conway's Law, which is that from 1967, it's been around a long time. It's that an organization that designs a system is going to create something that reflects that system. When we first started, we tried to do all the stand-ups at the same time. And either, and someone was always either staying up late or waking up really early. We tried to work on all the same code and everything. And it just, it was too difficult. We were too far apart. Our communication channels, even though we were working really well to keep up with them, just didn't align with that. And so putting together Conway's Law, embracing it, being intentional with it, and just saying, here's as you're designing the system, knowing what your team is going to, how your team is going to be structured, becomes really beneficial. Just to kind of embrace that rather than fighting against how you're actually structured. Okay, so some lessons here for this is the sharing the tomato timers. And these are actually, some of the quotes that I got back were really fell into this category. So I actually put them here. It's like saying it, let us stay focused on the same thing and balance personality. So these are from actual team members. We would, we were heavy users of something we called ride-alongs where we would either do a screen share through the video chat or something like that or actually just a Linux screen with an audio connection to just go through and work on some of these complex issues. This was really great and we needed to share knowledge, transfer, teach. And then we also expanded it out to other members of different teams as we started introducing the tools we were creating that these other teams were going to use and we wanted to share that knowledge as we would do the ride-alongs. Acknowledge Conway's Law and make it explicit in designing the system and dividing the work. And one of the interesting ones that I had almost forgotten about was we were collaborating on our story writing. We were doing kind of the extreme programming scrum methodology of creating stories. We wouldn't point them but we would do pretty basic user stories and I was a horrible mean person and I made everybody write them with me. Mostly because there was one of me and like eight of them and I was like, help, please. I'm trying to understand all of this and what they realized not only were they actually learning really valuable skills on how to break down which would help them in their careers that continue to grow in technical leadership but it also helped them understand where the changes were coming from and why and helped break down those communication barriers even further and it made my life that which is a little bit easier. So, all right, last one, engineer the team. And here's Scott Moots. He's a really smart former HD team member of mine. You can find him on Twitter at scottmoots.com. He's actually a native Vancouveran and so I'm like, how do you say that? So shout out to Scott. And he and I are both of the same opinion that the emergent organization theory of just let the chaos naturally evolve into order and it'll happen if you just give it enough time and space and that you actually when you're in a highly distributed setting you need to balance that with your directive styles so that you can give it some structure, send it where it needs to go, be purposeful and intentional and filter the bad behaviors while cultivating good ones. As you go, that's more into just good management so we're not gonna go quite into there but that was really important. It's just to be really intentional just like you would engineer software for a system or a problem, look at your team, engineer your communication, the tools that you're using and be intentional. And how we did this was one of the building blocks was we was introduced to the five dysfunctions of a team which is a book by Patrick Lincione and I gave a book to all of the team members and I knew they wouldn't read it and so we took 30 minutes and we watched and I just kinda walked them through a slide and we talked about it and that was enough to just be like, hey, this is where we're going. I'm sure some of them did read it but I'm a realist, I'm enthusiastic but grounded in reality. And so I just wanted to talk briefly through the five steps that the absence of trust. This is really the number one problem I see in a lot of teams, it's just the absence of trust and it's really being invulnerable in the group, not being willing to share and talk, ask for help when you need it. Don't have to be super authentic, airing your dirty laundry, nobody really wants that but finding that appropriate sharing and openness to keep things, to make sure that people realize you're a human being. A fear of conflict is another one that's really big and that's seeking artificial harmony over constructive, passionate debate. You know, this is more than the personality conflicts, those again are natural part of being humans. This is choosing not to advocate for your idea because you don't wanna come across as too pushy and so instead you just step back and let other people do it. And that's really actually very bad for a team because it leads directly into a lack of commitment. Cause if you didn't get to really be heard and be understood because you don't trust your team, you don't feel like you can actually speak up for what you believe in, you're not going to be committed and you're gonna just feign buy-in and then you'll be ambiguous to the solution and the decision going forward. This is not to say that everybody has to agree 100% on every decision or we would never get anything done but at least giving the time for that conflict to happen and allowing people to buy in and have a full commitment which then leads to accountability and without it you're going to avoid making people accountable. You'll settle on low standards because and not call out your peers on your counterproductive on their counterproductive behavior because you don't care and you don't trust them. And ultimately that's going to lead to an inattention to results which is really a death for a project or a product or a team before it starts because you start putting your personal success, your personal status and ego above that of the team's success which makes it really difficult to do anything. So this is a really great one. There's some great activities that you can find. I actually do some of my reviews out of a lens of this when I'm asking for peer feedback, saying thinking about how do you trust and what do you feel about this just to guide us through something structured. All right, so engineering the team lessons learned. Balance your emergent and your directive strategies and realize that you're going to need more, a little more directive strategies than you might if everybody was in the same country. Build trust because that is the foundation for all the goodness that will take place. Know that as you're doing your directive strategies that you don't want to get into micromanagement because the lack of micromanagement for your team is going to be a sign of trust and effective communication that things are working well if you don't have to be on top of every little thing. And even though some of this is process heavy, codify your process and wrap them in buttons which reduces the, hey, how does this work again? And it also reduces the amount of documentation you have to write, just put it in to it. A lot of what we ended up doing was we would take a deploy process, put it into Jenkins and make a button and then you didn't have to think about it when you needed to do something. Okay, so my final thought before I open it up to any questions is from Vernay Myers. She's actually a lawyer and an author and an inclusion consultant. And she's written extensively about inclusion and diversity and I had a chance to see her speak a couple years ago and her viewpoint is that you have, everyone has a particular worldview that's shaped by your identity, your larger culture and your life experience which means that each of us have our own personal culture and so as you're navigating this highly distributed team world or even a local team, keeping that in mind is really helpful, I found, to being successful as we go forward and thank you very much for your attention. Here's my contact information. If you'd like to reach out to me on Twitter or my personal blog and you all have a great rest of your summit, thanks so much. Please use the mic at the back if you wanna have questions. Oh thank goodness, someone's getting up. It's like the hardest thing when you're a speaker, you're like, nobody has questions, oh my gosh. You know, I teach so I actually understand that stress up there. So I'm in a very similar situation as you in terms of, I've used that exact slide of showing I have guys in San Francisco and as far east as Cyprus. One of the biggest things we keep hitting is stall decisions, so you have that very small window of crossover time, you can talk about something and if you try to send an email out, here's my idea, you wake up the next day, someone brought up a different point so then you wait until I reply the next day and so on. How do you, I don't need to term force because it sounds negative, but how do you force the decision to be made? Not in either direction, but do you have any ways of saying all right, this has to be nailed down by Tuesday and if nobody disagrees, this is what we're gonna run with or have you guys encountered any situations like that? So I would say that going forward with at least a quorum, getting as many people as you can to kind of buy in to the idea and then pitching it as, hey, here's the way we think we should go and if you can get one of the peers and not the manager so that it's actually, people can disagree and not worry about their job, then that's great. The other one is if you can adopt just a really iterative approach, then the small decisions can, will add up over time. That said, I really haven't solved that because probably one of the biggest challenges we had was we would get together in that window of overlap, we would all agree on what we were writing, the language we were writing it in and we would come in the next day and one of the people would have written it in a completely different language and not what we had agreed to at all and finally we ended up removing that particular person. So that one's still a work in progress because it is the challenge of how to speed up the decision-making while still allowing everyone to be heard so they can commit to it. I wish I had a better answer. It's hard, you're not alone, yes sir. So I've worked and led highly distributed teams for over 30 years, we were a real leader for all the unfortunate aspects of that and I can affirm everything that you said right on for all of it. The problem that we're struggling with right now is you do need some non-real-time communication because well, I mean, I live in Hawaii and so time zone-wise I don't wanna get up for three AM meetings every day of the week and we have people all over the globe as well. We're really struggling because so many people out there like to pull up their agile book and say we don't have to write things down. I mean, I don't know where that idea comes from but it is a prevalent idea that we shouldn't be writing things down, we should just be busy working and if you have any insight on how to, other than hitting people over the head with the book, try to work with it. Yeah, at some point, yeah, agile has come to be synonymous with we don't have to design and I don't know why and if anybody figures it out, let us know and in the meantime, please go back and talk to your architects and that agile software development is not a replacement for good architecture and I think OpenStack as a whole is starting to learn that very, very painfully. I, in order to get around it, I did a lot of the writing down myself and then over time as people on the team started realizing, hey, that's actually kind of helpful to have. I'll go do this and then it becomes, they start to see that it actually works. Also, what I have found kind of useful in explaining it is that the agile pieces in the software development work, there should be an extensive amount of effort, you know, not fully, not the amount of time you'll spend on the actual development but on the upfront part, figuring out your plan, your path. Yes, it's gonna be wrong. Yes, it's going to change and this isn't to say a project plan with weeks and timelines and hours and Gantt charts but to actually go through and say, hey, this is what we wanna build. We think this is what it's going to look like. All right, let's go and actually even to start with some epics at that top level so that then you can start grouping your work and finding your pockets where they can work in that smaller group and you usually don't need the whole team there to do the initial design. You can do the initial design and then send it out for commentary and review and rebuttal and arguing. Another thing OpenStack is really good at and then go from there. So that's how I have structured it. It's kind of scrum waterfall but not as bad, not quite as bad. So yes, sir. Yeah, another question is if you have a team that has a lot of alpha people in it and you're finding you basically have a lot of chiefs and not enough people following the rules, how do you manage that sort of situation? What type of strategies do you go around in terms of making it work at the same time, not suppressing the energies there, which are really good? I did a lot of one-on-one time because I had a lot of chiefs. I didn't go into detail but every single one of these engineers with maybe one or two exceptions were very senior, 10, 15 years of experience. They didn't need to be here, they could go anywhere. And so there's a lot of one-on-one, just talking with them, letting them hear, letting them know I understood, I get it. And being a go-between, between that's like, hey, well, there's this other idea that we're bouncing around. And that works really well because it gave them that sense of importance that they needed without having them go completely off the reservation. So in some sense you'd be like a manual conduit between, okay, that's what I'm saying. Especially, and sometimes you just have to let them vent, especially about each other. Because there's even, things get misinterpreted and feelings can get hurt even when you've got introverted, very strong engineering type who are doing good work. Thank you. All right. Last one, I was just curious on your opinion of companies that really frown or don't allow remote work like Google and that Yahoo. Works for Google and Yahoo because for right now they're at the top of the world. There will be a point where they will not be and they will be struggling. This next generation of workers, my generation and beyond especially are demanding a balance that we've never demanded before from our work. The ability to have a life and a family as well as a fulfilling, rewarding career and remote work is how a lot of us accomplish that. And so I think that the millennial generation as they are disparagingly known coming up are going to, they're not going to stand for it for too much longer. And so Google can get away with it because it's Google and everybody wants to work for them apparently Yahoo can, Amazon can, but I do believe they are in the minority going forward just as the culture shifts. So thank you all very much. I'm at time and you all have a great rest of your summit. Take care. Thank you.