 I'm going to talk to you about how I helped an organization use the concepts of Sociocracy 3.0 in order to self-reorganize and self-reorganizing is probably what you know as squadification if you have read the literature. First I'm gonna tell you that my name is Molloud. It's not Maloud, it's Molloud and you can find me at Molloudinary or at my very recently launched website and blog remote forever. So how do you define a distributed organization? A distributed organization to me is a group of people that are working together for the same purpose but they are not necessarily bound to the walls of an office. They can be working in the same town but from different locations. They can be working in the same country but in different cities or they can be distributed across different countries. A lot of us think of distributed teams as only offshoring companies in India or in like faraway countries. That's not the only form of distributed organization. It can also be like the same company. It doesn't need to be at different like two different companies working together. The organization that I helped or I coached in my last assignment, it was at King, the gaming company that creates Candy Crush. You probably know that game. So I helped the organization that creates the game engine which is a founding component that fuels all the games that are built in King. Although it's not the only engine in the company, there are more but people are choosing this engine particularly in order to build their games which means that the customers of this organization that I was helping were internal game development teams. So here's how the organization looked like. There were three people in Stockholm when Candy Crush was launched. This engine was created by those people and you can imagine the load of work and feature requests that they got after that success. So very quickly the organization started to expand. It was in Stockholm, Barcelona, Bucharest and we had one person in London. So in less than half a year from three people there were about 15, 16 people in the company and that's when I was brought in as the Agile coach to help and coach this company and to basically guide them to move forward, to manage the product, to evolve the product, to address the changes that come from the different game teams. And yeah, this is also how the backlog looked like when I joined the company. As you can see, there were about 600 unordered, unprioritized issues in the backlog. That was huge. It was a lot of work for the product owners. They had no idea where to start, how to prioritize things. Is it more important to create a new feature for Candy Crush or should we address the feature that is requested by this new game that is going to launch and is going to be the next success? What do we do? And we had customers also in a lot of different offices and the offices are also in all the locations that I told you plus a few more and our partners in Apple and Google were based in San Francisco and you need to launch every new version of the game in Apple Store and Google Store and yeah, you can imagine the complexity of the issue. So what was not working in the organization as described by the team members, the leaders and everyone as I was introduced to this assignment was we have unhappy customers. No kidding. We have too many meetings. Who doesn't know that? And we have multiple visions. Usually that is described as we don't have a vision for the product. But you know, that means I have a vision. That guy has another vision. This guy has another vision but they don't necessarily align. But where did we want to be? We wanted to have a culture of feedback and collaboration amongst the developers, the artist and also getting feedback and collaboration from our customers. Maybe someone could contribute to our internally open source game engine. But how did we manage that? We didn't have a proper process or a proper way to do that. What we did have though was continuous integration. So that was a huge plus because that made life so much easier. Another thing we wanted to have was efficient ways of working because there were no defined agreements. Other than we have a daily stand up. We kind of run can ban. We don't really monitor the flow though. It's just a visualization. It's in JIRA. We are agile. But we wanted to be effective. We wanted to be efficient. We wanted to work together. Another thing we wanted to have was transparency because as the organization had grown so fast, the new people didn't have the knowledge. A lot of them were new hires. They were not working in the same company before. They needed to learn. They needed to understand what the product was, how other people in the different locations are working. We did use the Atlassian hip chat though and it was quite active. Although fun and work were really mixed in the middle and it was very hard to concentrate on what problem we're trying to discuss. There were sometimes different threads of conversations going in the same hip chat channel or you call them rooms. That's the Slack channel. The product teams. At some point before it was hired, there was a need for creating a graphical user interface for this game engine that we were creating because a lot of the users of the game engine are artists who create art for the games. Artists don't necessarily like to modify code in order to change the color of a piece of art that they're creating. They'd rather have a menu and select the color. We didn't have that at the time. We started creating an editor for the engine. This was a very new product when I joined. It was less than a year old. It was called an MVP but it was a bit less than an MVP and a bit more than an MVP. It was not really well defined. The rest of the people in Bucharest and Stockholm were working on the old game engine on the tech side of things. I forgot to tell you that the girl in London was the tech writer. She was also supposed to understand everything that was going on and write the documentation that was useful for the customers. What was now working on the product side? Technical depth in the tech product and a lot of bugs in the editor product because we were developing it way too fast and it was in a different repository. We didn't have continuous integration for that repository and we kept getting a lot of new bugs every time that new version of the editor was released. Another thing was delays due to dependencies because sometimes the editor needed a feature that was considered critical but the technology to support that on the engine side was not necessarily there. Those guys working on the editor needed to wait for the engine guys to create that feature that would enable them to create a color selector for the artist to do what they need to do. Another thing that was very hard was that there were a lot of new customers that were choosing to use our engine. When I joined, we had nine customers internally and after about a year and a half, we had 40 customers. This was rapidly growing at a time that I joined. Creating support, delivering support to the customers in the forms of bug fixing, training, helping them create a new feature and basically being hands on with them was one issue and having a look at both the editor and the engine and evolve the product was another issue and to create that balance between the two was a very, very difficult thing. Now, I see a lot of heads nodding. That means some of these problems are probably familiar to some of you. What do we want to have in the product? Of course, we want to have predictability. We want to know what is going to be in the next release of this editor. What is happening on the engine part? What are the most important features that we need to create? We wanted to have end-to-end features developed in each team because in this way that we were working, the dependencies was really, really slowing us down. We wanted to have better quality in both of the products because we were lagging behind on that front. We weren't creating new tests for continuous delivery or continuous integration, sorry. We claimed that we had continuous delivery. That doesn't work, right? We were actually delivering several times a day and our code was not of a good quality. That meant more bugs, more customer complaints, and even more unhappy customers. This is how I felt at the time that I entered when I learned about all these complexity and all these issues, I thought, where do I start? What do I do? I had read about Sociocracy at a time. I had read a few blog posts on the Sociocracy 3.0 website and I had sort of a contact with James who has created it. I started reading more and more and more and I got in contact with people who have been to James courses because there was no course available at the time in short notice. I dug deep into understanding if Sociocracy 3.0 would be useful for us. But why is Sociocracy 3.0? Why did I even think about that? It is exactly that definition. Sociocracy 3.0 is a method for growing effective, agile, and resilient organizations. Yay to that. I want that. It provides a collection of principles and patterns to dynamically steer and evolve organizations. Yay to that. I want that. I'm going to tell you a little bit about the patterns in Sociocracy 3.0 for those of you who probably don't know them so you can understand why this was my choice of coaching this organization. The first one is continuous improvement. Familiar and very compatible. The next one is transparency. We needed that. The next one is effectiveness, equivalence, accountability, consent, which is one of the most important ones. Consent is the absence of objection. It's different from consensus. Consensus means everyone agrees. Consent means no one objects. You might have concerns, but you don't object. This became our critical decision-making model because we needed that. We were growing fast. And imprecisism, which means that knowledge is gained through experiences. In an agile organization, that's kind of an accepted value. So it just seemed like a good choice. Another concept you need to know is the meaning of drivers. A driver is a current reality that needs us to respond. The explanation that I gave you was our driver. And we responded drivers through agreements. This is our driver statement. An explanation of what I told you, basically. This is a long text. You don't need to read that. You heard it right before I showed you this. And what we wanted. What we wanted was a new organization. We wanted our new organization to allow us to focus on both implementing new features and supporting our customers, have good quality, be able to collaborate and also work across different locations. A lot of things. How did it facilitate this? So I created a lot of workshops. Actually, not that many. Most of the workshops were with leaders because I needed to coach the leaders and get their buy-in and to make them understand that they actually need to support us if we are going to make this organization happen. We had a buy-in of the developers because they were all craving for change. They just wanted something that was different, something that might work. So the developers were not hard to convince. When the leaders got the buy-in, we involved the teams. And we had a solution-based roadmap, which meant that a lot of customers had come to us with feature requests and improvement requests. And those are usually solutions that they're asking. They don't come to you and say, hey, I have a problem. Can you fix that problem with however method you want? They come to you and say, hey, I want that feature. And often we don't ask, what problem are you trying to solve? So we end up creating that feature. And when the next customer comes to us with a different feature and asks us to implement that, if it is for the same problem, we end up creating two different features for the same problem. So we focused on the problems that we were trying to solve. And that helped us narrow down the backlog that we had and we killed a lot of things because they appeared to be duplicates. And it was also very easy to form the teams around the problem. So every team would solve a problem. I need to breathe and I need water. There was a lot of conversations about co-location or cross location. Many people had never really worked in cross location teams. They had no idea how that is. They wanted to use a physical board. They wanted to have face conversations. But we couldn't really have that. We needed to work cross location. Although, since we were using sociocracy, we said, if it is, it's okay, I can take it later. We said that if it is good enough for now and safe enough to try, we're going to do this. We started with co-located teams. A team in Stockholm, a team in Barcelona, a team in Bucharest. And very, very soon we realized that that was not working for us because we had talent in different cities. Though we had a retrospective and we changed that because no decision is permanent and we kept evolving that organization over and over again. And at some point after about a year, it became very, very organic. At the end of every quarter, we would gather and we would review the organization and we would change if needed. So we formed the teams. We had a little bit of negotiations between the teams if someone needed to move around or someone needed to be shared between two teams. And every team spent a few minutes to deciding their internal ways of working that meant a scrum can man or anything else, like however they wanted to communicate. And they came with a proposal for their external ways of working. And that meant going through a circle, going through the consent decision making and choosing what works for us now. And we just tried that every once in a while, every quarter we revisited that. So this is how things were and this was a new organization. We created an experiment, we created a lot of experiments that allowed us to become a learning organization. We even started an internal academy because we kept growing, we kept hiring new people. And our internal academy meant that one developer would explain a piece of the product to everyone else in the team who was interested and it would be recorded and forever available. And if that was changed, then a new recording would be made or an amendment would be added, but it was always stored in the same place and it became a knowledge base for every new employee. Another thing that we did was that we had end-to-end features at that time. We started creating the quarterly business objectives all together. It was not coming from the top management anymore. We had the opportunity to feedback on that. We managed support. We iterated over it a lot. We had a team assigned to support for a week and another team for another time, then we had a person assigned to support, then we created a whole team. So it was a lot of iterations until people were sort of happy with what was there. And we got a lot of clarity about who is accountable for what, what is every team working on and what is the way to communicate that. And we created a box ceiling policy to kill all the bugs that we had been accumulated and we tried to reduce that ceiling as we went forward. We started with every two weeks and then we made it every one week and then we made it daily. So we lowered the ceiling after we agreed on how many bugs we were going to aim for for this duration. And of course that improved quality. We had collaboration. We had transparency, predictability. And this was an additional bonus that came. Someone was suggesting it and they thought, hey, Google is letting their employees to use 20% of their time doing whatever they want. What if we introduce that concept and we use that to attack our technical depth? So it was decided, the management supported it and that was created and it helped us a lot because people were eager for that day of the week to come so they could just work on something that was not in the backlog or, I mean, not in this print backlog. And this is my signature post-it. I love it because it meant that we don't have any mandatory meetings anymore. And that was also because we adopted the Sociocracy 3.0. It meant that only people who are affected by a decision go to the meeting in which that decision is being made. And you stay in a meeting only if you get or add value. So we basically introduced the rules of open space to every single meeting that we had and that actually increased participation. That was my presentation and I just put my Twitter handle up there again. Thank you.