I recently spoke at the Agile People Conference 2016 about how I coached a distributed organization use the principles and patterns of Sociocracy 3.0 (also referred to as S3) in order to self-reorganize. In this blog I have collected the most frequently asked questions from the audience after the talk and my answers to them.
You can watch the full video of the talk here:
If you have any more questions, please post them in the comments below and I will answer to every one of them.
How did you know enough transparency and accountability was established?
As for many of the other decisions made in this organization, we created transparency through several iterations and we kept measuring it periodically. We visualized everything! And we created a few short meetings (each for 15 minutes) described below.
SoS (Standup of Standups)
In the first iteration, all of these distributed teams agreed to have a Standup of Stanups meeting every Wednesday and every Friday. One representative from each team was invited to this meeting. Technically everyone was invited, but one from each team attended. The representatives took turn to give an update about their team’s progress, plans and whether they had an impediment they needed help with. And if they needed help with something, they asked and some other team offered to help. Just like a regular daily standup meeting, some discussions were scheduled for after the SoS meeting.
The SoS meeting was eliminated completely after we all learned to create a written visualization of the status of the work. To be honest, it appeared to be a waste of time after we had had it for three weeks. Instead of this meeting, everyone was automatically reminded to update the status page (plan, progress, problems) once a week. All teams got to do this at their own time when they found a moment during the day. The result was not only to give an update to the organization but also to have the latest status and the history of the work available at all times.
As I said in the talk, each team had full ownership of their internal agreements and processes and how they wanted to visualize their work. For communication between the teams however, we had global agreements. We made all of our decisions using the consent decision making model suggestion by Sociocracy 3.0.
PoP (Planing of Plannings)
We agreed to have one planning meeting for all teams distributed across different countries. Every Friday everyone who thought they would add or get value (or cake) attended this meeting. Product Owners attended this meeting to get updates about the progress and give updates about priorities. When something was finished, we got to see it visually on the planning board and we clapped its movement to the ‘live’ column.
Each week before this meeting, the Product Owners made sure the backlog of ‘next’ issues to be developed, is prioritized. During the week prior to the meeting, the Product Owners gathered all the necessary information to put these issues in a ‘ready’ state for developers. This allowed the teams to confidently ‘pull’ their next item i.e. feature, improvement, system, refactoring, etc, to their team backlog. Gradually, the team members who didn’t attend the meeting trusted their representative to chose the item on their behalf. That was mainly because they all had chosen the ‘next’ item together before the meeting. Sometimes there was negotiation between the teams and the product owner about who pulls in what. I boldly claim that’s a sign for having true cross-functional teams.
The representative of each team for SoS or PoP was not a fixed person. We wanted to share the responsibility amongst all members. Therefore each team had their own way to rotate the representative role inside the team.
Distributed Demo (Review meeting)
Every Friday, before the PoP, there was a Demo (or review) session where we also served cake. The format and tool choice for this meeting also evolved in iterations. In the end, I facilitated the demo session such that everyone in the distributed organization got the same experience. Everyone was equipped with a camera and a microphone. They all sat at their own desks and took turns demonstrating their team’s work. The demo-ers then took questions, feedback and comments. Sometimes there was a need to further discuss an issue. In such cases, interested people discussed the issue afterwards.
Sometimes product owners, customers or other stakeholders joined the demo. They often sat at a conference room and watched the demonstrations. They could also ask questions after the demo.
How do you know when people are unhappy? How do you motivate them?
This is a common question for managers who have not worked with remote teams. If the only reason you need to see people is to know whether they are unhappy(!), you have bigger problems than that. But if you want to make sure you’re doing the right things so they stay happy, then I can share with you what I did.
When you’re working remotely, you need to sharpen your writing skills. You need to learn how to convey a tone of voice or an emotion trough writing. Luckily the millennials and Gen-Z are quite comfortable with this style of communication. They use emojis and internet memes to add a tone to their message. That’s what happened with my teams. Naturally the more experienced people also got onboard the IM culture.
As their coach, I was a member of all the chat rooms and often monitored the overall temperature of the conversations in each room. When the usage of memes was going down, often I threw in a meme or a question asking what they were going to demo and engaged others in a conversation about it. If I got low energy responses, I knew something needed attention. Otherwise I tried to cheer up the *room* or I used 1:1 chats to speak to individuals.
I also kept track of the biweekly happiness survey. All team members responded to a one-question survey I sent to them. The question was: “How do you feel?”
They could chose from these five options:
I then visualized the team’s responses on a pie diagram and put it on a health check page on the common wiki page for everyone to see. This page triggered the curiosity of the product owners or other leaders. With a little help, they could then address the underlying issue.
At some point in time, we had six teams. I facilitated all retrospectives. Clearly for the distributed teams, one needs to be creative in facilitation methods and tools. Most of the time we used a free tool called web white board. This tool works just like a regular white board with post its on. I captured the issues that related to unhappiness and helped the teams with those issues.
It’s really important to create the same experience for everyone, when you are working with distributed teams.
Join the remote forever tribe to read about the different retrospectives formats for distributed teams.
Distributed hack Day
We spent every last Friday of every month to explore and sharpen our skills. A few people chose to create something using a new technology. Some worked on fixing things in the product that were annoying to them but were not high priority. Another group worked on creating a new tool to be used by the team. We had ideas of all kinds. The most important thing was that this day was sacred. No meetings or disturbances were allowed on this day. It was a full day of calm and tapping into creativity.
When people stopped showing up to the hack day, I knew there was pressure on the product development or support. The same applied to other fun or free activities.
In my humble opinion, you cannot motivate a group of people by using specific methods. However here’s just the common sense coaching approach that I undertook:
- Chatting 1:1 with every single person in the organization
- Creating personal relationships with people
- Recognizing people as human beings
- Truly caring about them, their fears, their hopes and what they care about
As a leader, when you come from a place of authentic and willingness to help, your people trust you.
When you open up and show a little vulnerability, you make a human connection. You allow others to open up to you too. They can then speak their truth. And that’s what I did. That’s how I knew the underlying issues despite what the symptoms meant in a general case.
When you open up and show a little vulnerability, you make a human connection.
How did you make design decisions with remote people?
In the beginning, just like many other organizations, we had a startup meeting for each new feature. They were long boring and endless meetings most of the time. We changed a few things to address this issue. The most important and effective decision was to have no meeting mandatory.
No mandatory meetings
The values of this decision for the organization were tremendous. Most importantly, it helped people to really think about whether or not they needed to call for a meeting to discuss something or make a decision.
If you need to inform people about something, you can very well use an email to do so. They can then read it when they chose to. There’s no need to ask people to interrupt their productive flow state to just listen to you especially if it’s not urgent. You can also create a wiki page on the intranet. You can inform people in a chat room. And if you really want to offer this information face to face, you can wait for a weekly meeting.
The reality that most of the topics you tend to create meetings for can be solved via email or IM.
Asynchronous distributed design meetings
Since we had realized the value of asynchronous written communication, we made design decisions in that fashion too. One or two people with the most expertise and passion for the new feature (or system) created a preliminary design proposal. They made it available for everyone in the organization via the internal wiki tool. Everyone could then have a look at the proposal at their own time and comment on it.
After a first round of comments, the original proposers then reflected and improved the design as the discussion went forward. Anyone could edit the wiki page (there’a reason it’s called a wiki). Usually after a few days, we had an acceptable design ready to be shared with the entire team and the POs. This made it easier for any team to estimate the work required and for the POs to prioritize better. Most of the time, those who had started the design conversation were the ones implementing the feature. But that was not the case for all features.
Tips or tricks for improving communication in remote teams
I can write a whole book about this topic. Here I will mention just the most important ones from my experience.
In this particular organization that I was coaching, we visualized almost everything. The product vision was visualized on Confluence. I have to add that this company had a team of Confluence experts who had created a great setup for using of Confluence. We visualized the product roadmap and also what team was working on what item as well as the state of each item i.e. live, in acceptance testing, in implementation, in planned, in unplanned, etc. We had a visualization for all the global agreements, happiness barometer of each team, support issues, bugs and all meeting minutes.
On the product side, we had flat screen TVs in all locations to visualize the status of our Continuous Integration. We also had a running demo of a customer product on another TV. This allowed other people passing by in the office to stop, play around with the live (or in production) product and get a better understanding about what we had created.
Asynchronous written communication
I cannot emphasize this enough. Most decisions are not made in one meeting. From those that are, many did not require a meeting in the first place. There are many tools that companies are already using to enable asynchronous written communication amongst their employees. For example, Jira is used for tracking issues. We literally used Jira for communicating with our users and our team members. The comment field (which most organizations do not use) became yet another effective channel of communication for us. We tagged people in our teams and in the rest of the company to ask question. Sometimes we used that field to provide clarification by adding links to design documents or other documents, etc.
We used Confluence for many other decisions. As I explained above, we made design decisions on Confluence. Developers communicated with each other through comments and collaborative documents on Confluence. We even decided our next fun activity or get-together using a voting macro on Confluence.
Instant messaging is an inevitable tool for a distributed organization. We categorized our work into the teams chat rooms, product feature chatrooms, fun vs work chat rooms, customer support chat rooms, you name it. We also retrospected this division and evolved it periodically.
Make an effort to chit chat with your remote colleagues. Ask them about their new apartment, their pet, their kids, their last vacation, their future plans. Share photos of yourself from your beach office or balcony, wherever you’re working from. Use video for your daily meetings if possible. Just remember that geographical distance should never become an excuse for you to care any less about the person.
And above all do not treat your employees or colleagues like children who need to be monitored and controlled. Trust that they care about the success of the product and the company as much as you do. Instead make good agreements and help create a collaborative environment for everyone to thrive.
People offer their best work when you assume people are whole, smart and responsible.
If you liked what you read, share it with your friends and press the button below to subscribe to Remote Forever and learn about new posts, workshops and courses.
Comment below if you have any experience with any of the topics described in this post.