Avainsana: team work
How to Access Collective Intelligence in Your Teams: The CoDev Collaboration Method
For most organisations, whether public or private, there is barrier to accessing collective intelligence, sharing institutional knowledge, and developing professional practices through collaboration. This means that it can take longer for individuals to solve issues that come up when they lack the experience in doing so. Whether these be inter-personal, logistical, time management, product development, etc. Each organisation has myriad skills and knowledge that cannot be quickly identified and utilised in peer groups. Sharing Knowledge and Collective Intelligence People have a variety of past professional experiences both inside their current organisation and in previous work experiences. This means that there is a lot of uncatalogued and untapped knowledge present at any one time in any one space. It is the aim of CoDev to open this experience up and make it accessible to the peer team around them. CoDev Collaboration Requirements The CoDev collaboration method (short for co-development) is an innovative professional co-development model that is becoming increasingly popular to begin to create shared knowledge and problem-solving in organisations while also developing leadership skills. Developed in the 90s by two French-Canadians,this method is predicated on sharing between teams and within teams depending what the issues to be tackled are. It is ideal for smaller groups of between 5 and 8 participants. And can be a regular meet up or set up ad-hoc when an important problem requires this kind of approach. The method consists of 6 official steps and one additional unofficial pre-step (or a step 0). This method can take anywhere from 90 minutes if you want to deal with just one problem or longer if you want to tackle more than one. In this simple technique, there are many underlying elements that must be understood to get the most from it. 5 Foundational Pillars For the CoDev method to really work, it is essential that each person comes to the session from a place of empathy. This is because it requires: Active listening Kindness Commitment Confidentiality Truthfulness In order for all of these conditions to be met and accessible, the participants need to want to be there and be open to hearing what others have to say. And at appropriate times, each person will need to commit to being silent - no matter how much they wish to interrupt or to say something. Each participant must understand that their experience will be heard and it will be duly considered and valuable - whether it is used to move the issue forward or not. Holding Space and Withholding Judgement Another important aspect of this CoDev method is the space that is held for people to be vulnerable while asking for help. This encompasses kindness, active listening, and confidentiality. By doing this, holding the space and judgement, a participant feels able to be truthful and committed to the process. A Time-Based Framework The CoDev approach is time-based. This means that each step has a set time limit. This time-based approach allows the process to move forward and avoids conversations becoming unproductive or off-topic. A time limit helps to make sure participants keep their advice to the point. Respecting the time set aside for each part is essential even when it may be frustrating for the participants. Deterring Early Solutions Another reason to enforce the process as it stands is to deter any early suggestions of solutions. Humans are natural problem solvers and we love to help people in general. This is mostly a good quality but when it comes to exploring problems and hearing their context and needs, suggesting solutions too early in the process can stifle creativity and deeper understanding. By sticking to the process as it is laid out, you make sure that the problem is fully explained and understood as possible for any ideas, comments, or solutions begin to direct the discussion in a specific direction. CoDev Participant Roles In this collaboration process there are 2 roles available. There is the problem owner (sometimes called the “client”) and there are consultants. The problem owner is taking their problem to the consultants for a consultation. This consultation will consist of many things based on the consultants’ previous professional experience. This process is meant to prioritise actual professional experience rather than expertise or academic training. The 6-Step (+1) CoDev Process Step 0 - Choosing the Problem Although this is not an official first step, it is an important one. An individual participant’s problem must be chosen to discuss. Step 1 - Presenting (the Situation) The problem owner starts by providing as much detail as possible while being as clear as possible. At this time, all consultants are silent. Step 2 - Clarifying (the Problem) The problem owner is only answering the consultants’ questions as briefly as possible. At no point should a solution be put forward and the questions are only for clarifying and understanding the problem. There is no judgement about the problem. Step 3 - The Contract This is the time where the problem is fully defined and the problem owner states what they are looking for from the consultants. Step 4 - Consultation This step requires each consultant (going around the table one-by-one) to share their thoughts, impressions, opinions, comments, ideas, suggestions with the problem owner. The problem owner is expected to stay silent. Step 5 - Summary & Action Plan The problem owner recaps what they have heard and shares it back to the consultants and then creates an action plan for going forward which the consultants can also contribute to. Step 6 - Review In this last step, all participants take stock of the session and share how they felt about it. Each person can evaluate the CoDev session and determine what they key learnings were. Benefits of this Approach The benefits of this approach are many for each peer group. First, the ability to solve sometimes complex problems in the organisation through the group’s experience (collective intelligence). Second, building a collaboration mindset in the organisation. Third, developing skills such as active listening, feedback, perspective-taking, cooperation, and trust. This approach is best used as a recurring session with the same people. This allows them to build trust in the group and to dig deeper and be more honest about struggles. It is also important to make sure that there are no hierarchy (peer groups) issues and allows them to create a learning community amongst themselves. Many of these can exists at the same time within an organisation of course. This is encouraged. This is a simple approach with a multifaceted outcome. It requires each participant to fully participate and respect the rules for it to be fully effective and it also requires a dedicated facilitator. The facilitator must be willing to move the process along when they see that it is moving off task or running over time. Author Pamela Spokes works as a Service Designer in Metropolia’s RDI team. Originally from Canada, Pamela has years of experience in university admin focusing on international recruitment, marketing, and the international student/staff experience. With a Bachelor’s from Canada, a Master’s degree from Sweden, an MBA in Service Innovation & Design from Laurea, and her AmO from Haaga-Helia, she is interested in purposefully designed experiences that are centred around the user. Don’t be surprised if she knocks on your door to talk about learning co-creation methods through intensive learning experiences. Source Payette, A., & Champagne, C. (1997). Le groupe de codéveloppement professionnel. PUQ.
This Meeting Could Have Been A Workshop
We all know the meme: This meeting could have been an email. But what about this one: This meeting could have been a workshop. So how could a meeting be a workshop? One opportunity to change a meeting into a workshop is when the whole team needs to get a common understanding of a certain topic or issue. This is the perfect chance to have a workshop. The workshop format allows everyone to have a say even if they are the quietest in the room. The key to this egality is to start with something called brainwriting. This is not what you typically think of as brainstorming. Typical brainstorming is often a situation where the loudest or the boldest get their opinions put forward. This is the opposite of what we want. In brainwriting, there is silence. Only writing ideas. Or, if you plan ahead enough, there will be silence and music! There are many Spotify playlists that are meant for the quieter parts of a workshop. Then the talking comes back when you go through the ideas and issues that have been mentioned. We recently did this in our team. Here is a run down of how it was planned and what the outcome was. The brief We are a new team working on a new project that is not necessarily as clear to everyone as possible. I was a new team member and was not involved in creating the proposal that was approved. So to get everyone on the same page, a mini workshop was held. Using the walls of one meeting room, there were 5 post-it sections: Requirements (Minimum Viable Product, MVP) Personal Vision Ideal Assumptions Outcomes Requirements was first as it was to list all the requirements of the actual project. What needed to be fulfilled in order for the project to be complete and within the regulations. Personal Vision was second because it was important to me to understand where the vision of this project came from. This is where we could discuss the original vision of the project and how that is reflected in the requirements. This is really important going forward to understand the original vision even if the project is different. Ideal was next and this refers to what is the ideal outcome of this project. If everything goes perfectly, which we know it probably won’t, what does that look like for each person. What elements will the outcome have or will have accomplished? Assumptions are very important to get out on the table in the group. What assumptions are we working under that everyone else should know? Many times, assumptions can sink (or seriously delay) a project or any kind of collaboration. If the assumptions are out in the open, they can be acknowledged, openly tested, and understood by everyone. Outcomes was the final section of this workshop. This allowed us to reflect up on what outcomes we, as a group, wanted to achieve. Not necessarily what the project required, but they could even be more strategic or even more granular and personal. Maybe one person wants to learn how to use a certain software or wants the bigger team to be featured in the media for their work. This helps to put different levels of professional goals on everyone’s radar so when opportunities arise, they can be passed on to the right people. We also added another section that was titled: “Issues to think about”. And this is a section where we gathered just 3 words. But they were big words - Relationship, Community, and Process. These words were more like markers or triggers of things that we need to keep in mind as we go through the project...something that we will tackle later in the project but that we need to be reminded of. What kind of relationship do we want to create with the users of the outcome of the project? What kind of community do we want to build (do we even want to build a community?) and What is the process we want our users to go through. Things to keep in mind as we go forward. Time allocation This took about an hour and we did all the sections at once, we didn’t stop and discuss each before we moved on to the next. We did them all with brain writing (with just a quick clarification of what each meant when needed) and then went through each one at the end in the order they were presented. This process may take a little longer depending on how many people are involved. Outcome This process made sure that everyone’s thoughts and ideas were put forward fairly and equally and everyone were able to say what they wanted to say. This workshop also built up a common understanding for the entire team of the project and also what constituted success for each individual and for the project. Author Pamela Spokes works as a Service Designer in Metropolia’s RDI team. Originally from Canada, Pamela has years of experience in university admin focusing on international recruitment, marketing, and the international student/staff experience. With a Bachelor’s from Canada, a Master’s degree from Sweden, an MBA in Service Innovation & Design from Laurea, and her AmO from Haaga-Helia, she is interested in purposefully designed experiences that are centred around the user. Don’t be surprised if she knocks on your door to talk about learning co-creation methods through intensive learning experiences.