-
Notifications
You must be signed in to change notification settings - Fork 0
Collaboration between teams
@arlobelshee Block quotes like these are authors’ notes & comments. Please sign them with your Github ID.
@arlobelshee We should be more specific / precise in our use of terms. In particular, we are using “collaboration” very freely in this document. That’s a problem because we are also trying to have “collaboration” get defined, explicitly, to be the top level on the scale. We should figure out other terms to use in other cases. For example, I’ve been tossing around levels/degrees/methods of interaction when talking about the whole scale. When talking about how two teams are interacting, I try to use the specific level name. When I mean the general case, I try to use interaction. I’m not sure that that is the term we actually want to use, but I think we should pull off of collaboration now & thus only use it when we are explicitly meaning the top-level.
An exception exists, of course, for when we are specifically attempting to co-mingle the issue. For example, I still want to use the word Collaboration in the model’s name. That will help people who are not yet thinking about distinctions orient on the whole.
We are creating this model to help people get a realistic assessment of where they are. Then they can see what is possible and what they could do to get there. The model is only useful if it helps individual teams take specific actions to improve the way they work.
Our precision is not academic. It is for clarity. We find less-precise discussions of collaboration leave teams without a clear idea of what they want to achieve or their next step to get there. This model is designed to help you find that next step.
Collaboration is one of those words, like team, that everyone wishes to apply to their company or set of co-workers. But it has a very specific meaning. Many “collaborative teams” are actually well-coordinated work groups. This may well be sufficient for their needs. But by muddying the terms and claiming themselves to be at the peak those teams lose the ability to see what advances would be possible.
Collaboration is not a single state. There is a scale of levels of interaction. Each person finds themselves in multiple different contexts, and interactions will be at different levels in different contexts. This model is an attempt to help people understand the scopes in which they interact and the degree to which they collaborate in each scope.
There are 3 different scopes for interaction:
- In team: Within my cross-functional team. Between individual humans who are working on the same piece of work. Typically up to 15 people, and includes all roles needed to deliver product.
- Cross-team: Between two different work teams. These may be nearby teams, reporting to the same manager and delivering work into the same product, they may be teams from different ends of the company, or anything in between.
- Working out loud: Between my team and whoever may be interested. This applies to those teams with whom I do not yet know I am interacting.
For the first two scopes, we use the same 5-level scale:
- Competition: Each person has an individual objective. Each person places his goals ahead of those of others.
- Conglomeration: Each person has an individual objective. These objectives are aligned such that they are parts of a larger goal, but the goals are independent. The work is executed individually.
- Coordination: Each person has an individual objective. Those objectives interact. The teams coordinate their efforts to ensure all objectives are met. The work is executed individually.
- Cooperation: Each person has an individual objective. Each person is aware of the people with related objectives and what those objective are. The work is mostly done individually, with people actively doing support work to help each other. People have specific roles and work products move from role to role.
- Collaboration: All people share the same objective, or have objectives that cannot be met without meeting the others. The work is done simultaneously by multiple people with regular and informal trade-offs between people. People have individual talents and each bring their talents to bear on multiple parts of the work. No single part of the work can be associated with any one person.
Working out loud uses a different scale:
@arlobelshee: This is off the top of my head. It would be better to go grab info from the working out loud movement. If nothing else, that will help us be more specific and talk about things beyond just communications media / style.
- Secrecy: The work is intentionally performed in secret. No one else in the company should know about it. The team takes active effort to prevent information from leaking to the rest of the company.
- Obscurity: The team makes no effort to share information except with existing partners. Communications media are chosen to make things work well for the team and its partners; no effort is made to find or onboard future partners. Work product is stored in locked down locations; it would be difficult to share with people not on the team.
- Upon request: The team generally only pays attention to itself and its partners in communications. However, it does advertise its existence to the rest of the company and provide some way for others to ask for information. The team intentionally collects and maintains some communications (e.g. formal documentation) to provide when asked. The team has and uses a collaboration system (SharePoint, Jive, company source control, etc) to store at least some of its work. The team can publish other work to that location upon request.
- Participatory: The team still performs its own work as per Upon Request. However, it is now participating in the workstreams of other teams that are at higher levels. Team members observe Visible teams, participate in their discussions, like/+1 their ideas, and comment on or even contribute to their work products. The team views this interaction with other teams is part of their job. It also uses these interactions to find teams with which to make a more formal interaction relationship.
- Visible: The team stores all of its work in discoverable locations. Wiithout their awareness, anyone in their company or community can look at any of their work products at any time. The team holds discussions using communications media that are public and discoverable. It encourages lurkers to follow internal discussions. It chooses media that put potential recipients in charge of deciding what they wish to hear, rather than requiring the sender to pick the recipients. It also creates summaries & getting started info. This is used both to ramp up new team members and to help non-members orient and quickly join the workstream.
This is a maturity model. It is intended to be used in a distributed fashion. Each team applies it individually to improve itself and its ability to interact with the other teams that matter to it.
Each of the 3 scopes describe fundamentally different contexts for interaction. As such, they are each improved differently. Detail sections, at the end, will describe each level in each of the contexts. They identify the skills you will need to learn, the ways you will start interacting, and a number of other traits. Most importantly, they also list blockers for each level. These are things which, if they are true about the system / company in which you find yourself, will prevent interacting at that level. Blockers must be addressed if the team is to progress.
- Print out one copy of the worksheet for each context. You will need:
- One copy of the Interaction Levels worksheet for your team.
- One copy of the Interaction Levels worksheet for each partner team or category of similar partner teams.
- One copy of the Working Out Loud worksheet.
- Identify the scope to which each applies.
- Fill in the first column. For each box, gather evidence that your team acts in that state at least some of the time.
- Fill in the second column. For each box, gather evidence that your team sometimes does not act in that state.
- You are fluent at any level where you have supporting evidence and no evidence of occasional failure. You are aspiring to any level for which you have evidence of both success and failure.
- Use the Improving your situation section, below, to identify your goal state and next step.
Context: ___________________________________
| Degree | Supporting evidence | Counter-examples |
|---|---|---|
| Competetive | ||
| Conglomeration | ||
| Coordination | ||
| Cooperation | ||
| Collaboration |
End goal: ___________________________________
Next target: ___________________________________
Working Out Loud
| Degree | Supporting evidence | Counter-examples |
|---|---|---|
| Secrecy | ||
| Obscurity | ||
| Upon Request | ||
| Participatory | ||
| Visible |
End goal: ___________________________________
Next target: ___________________________________
The most important level is your fluency, not your aspiration. Collaboration comes from trust. Trust comes from trustworthiness. And trustworthiness is driven by how you perform on your worst days, not on your best days. So if you want to attain a particular outcome, you need to be fluent at that level.
Higher levels of interaction have higher costs. The more people who are involved in each context, the higher the cost for each level. With large contexts, often collaboration is not necessary or not possible. Simply aligning goals and then coordinating may be sufficient—especially if each team is internally collaborative.
For example, if you can align each small team to an end-user value stream, then you eliminate many dependencies between them. Customer scenarios can be shipped from a single team. This reduces the required level of interaction between teams and gives you a better product at a lower cost.
This is not always possible. Some experiences will be large enough that hundreds of people need to be involved. But it is always worth looking, first, to see if you could simply focus a small team tightly around the precise business value and deliver that, then conglomerate that with other teams doing the same.
With this in mind, think through the levels. What is the lowest level that would lead to great success for your team and your company? How could you organize the teams to decrease the levels required for cross-team interactions?
@arlobelshee This section is just notes. Needs to be filled out and/or blended with the sections that follow (which were written first).
- 3 sections, one per scope
- Within team, go for collaboration. Simple maturity model. Goal is to raise fluent level.
- Between teams, pick a level. Improve by reducing the level needed in order to meet the objective and by increasing the level actually present.
- Working out loud, pick a level. Goal is to be fluent at that level.
@aivarsson Parts of this text is copied from below, so duplicates should be removed.
@aivarsson There is a lot of material to add here on how to proceed to different interaction levels. Might be better to have in another section, or a separate article though?
It is almost always worth the investment to get a team to the highest level of interaction – collaboration.
A collaborative team often works like an atomic unit – there is a strong uniting feeling for the whole team, and even though the members of the team might have different skills and expertise areas they work closely together with the same goals and priorities.
Your first step will probably be to create a cross-functional real team of 6-12 individuals (8 being optimal from a team dynamics perspective). Everyone should know who is in the team and who is not. The team should have all skills that are needed in order to deliver value to the customer. Think of it like a startup: if these 8ish people were the only employees, could they provide value that customers would buy?
An important part of collaborating as a team is sharing the same goal. Make sure that the team really shares and buys in to the same goal.
Collaboration requires strong connections between every part. Maintaining each connection carries a time and communication overhead. The benefits of collaboration are big – but as the number of parts grows, the overhead quickly grows bigger and close collaboration might not be worth the extra cost.
This is why it is generally easier to get collaboration in a small team, and why a larger group of 10+ people will rarely have collaboration between the whole team, but instead tends to break into collaborative teams.
The same is true for interactions between teams. Coordination between two teams does not carry a big overhead cost – but trying to get true collaboration between five-six teams is often very hard and introduces a lot of overhead. Usually a better way to go is to reduce the required degree of interaction between these teams.
You often get the biggest benefits from going to either extreme – either removing the need for a connection completely, or get to collaboration. This is true within a team as well as between teams.
@arlobelshee As discussed in email, this last para is a place where we currently disagree. I hold that it is nearly always optimal to push to full collaboration within any given team, but that between teams is more nuanced. The first thing to try is to change some aspect of the system to enable success with lower levels of coss-team interaction. But I don’t think it is always optimal to drive all the way down the scale.
We will resolve this point later.
Your actions will generally fall into one of two camps:
- Decrease the level of collaboration required between teams to deliver customer value.
- Help a team become fluent at a level of collaboration to which it is currently aspiring.
You rarely need to help a team aspire to a higher level of collaboration. Humans tend to do this naturally. They will regularly aspire to a couple levels above what is safe in their environment.
In general, I recommend that a team sequence its improvements into a set of phases:
- Get your own nest in order
- Make friends
- Influence people
In this step you increase the level of collaboration within your own team and you reduce the level of collaboration required with other teams. Note: you are not decreasing your level of collaboration with other teams. You are decreasing the level that will be needed in order to succeed.
Your first step will probably be to create a cross-functional real team of 6-12 individuals (8 being optimal from a team dynamics perspective). Everyone should know who is in the team and who is not. The team should have all roles that are needed in order to deliver value to the customer. Think of it like a startup: if these 8ish people were the only employees, could they provide value that customers would buy?
Most of your efforts here will go into improving the level of interaction in your own team. Get all the way up to the collaboration level. For any scope of up to 12-ish people, collaboration nearly always has a better return on investment than any lower level.
This will require that you start to share work within the team. As you set up systems and norms, consider how you want to progress on working out loud. Use systems that will work well for your target level, even though you probably aren’t working that publicly yet.
Here you are focusing on your adjacent teams. Get fluent at the levels that are necessary for your business. Most teams typically have a couple or a few other teams with which they need to cooperate or even collaborate. Find those. Make friends. Become fluent at your goal level.
Also start building your social networks. Interact with other teams that are working out loud. Follow them. Like/+1 their stuff to give feedback. Forward interesting stuff to others within the same social network system (or via email to pull others into the high-visibility system). Start commenting on other teams’ work products before they are finished.
Now that you’ve got a firm base in your own organization, start to enable discoverability. March up the working out loud scale. Make it easy for those teams that are interested in your work—and should become partners—to find you. Now you won’t have to spend so much effort seeking them out.
You will also spend a lot of your time developing the ability to indentify and quickly sync-up with important remote teams. You will learn how to identify & agree on the style of interaction you need with a particular team. You will learn to quickly get to that level with another team. And you will learn to gracefully exit relationships with other teams when they are no longer of value to your customers.
@arlobelshee The below need to be refactored to take the above into account.
Product connection – both teams are building the same product, or parts of the same product family.
- Remove connection – decouple products, so they can be separately built, released and sold
Technical connection – both teams are using the same system/service/codebase/component/…
- Remove connection – No code ownership, decouple architecture/systems, …
Knowledge connection – one team has knowledge or skills that the other team need
- Remove connection – knowledge sharing, move person with skill
Designated leaders start with all responsibilities that are not part of actually doing the work. As we go up levels we take away responsibilities. They become responsibilities for all members of the team to share.
- Assignment of work – shared with collaboration
- Task breakdown – shared with cooperation
- Team process – shared with collaboration
- Culture – shared with high collaboration
- HR / reviews – remain manager’s responsibility
- feedback – shared with cooperation
- Addressing interpersonal issues – mostly shared with collaboration
- Hold the product vision – shared with cooperation
Coordination
Common patterns
- Project managers
- Communication through proxy
- Planning through proxy
- Defined areas of responsibility
- Up-front planning needed
- Milestones, deadlines
Cooperation
Common patterns
- Defined roles
- Focus on resource efficiency
Exercises
- Market of skills / team chartering
- Understanding of everyone’s goal
-
Collaboration
Common patterns
- First team
- Focus on team effectiveness
- Low WIP limits possible – one priority for the team
-
Exercises
- Definition of team
- Shared goal, vision
-
- Work products are broken into tasks as a team. Each task is assigned to a specific person, but each work product involves multiple people.
- People issues are dealt with via 1:1s with managers. Managers are no longer deciding work breakdowns; they spend time managing the team’s process and .
- Modes of communication
- Feedback – give and receive
- Trust – share your objectives and goals
- Work out loud
- Team members do not know each other
- Lack of working agreements
- Fear of losing independence, privacy
- Play together
- Mob together
- Chartering
- Clarify roles and responsibilities
- “Strong opinions held lightly”
- High metacognition within the team. Many team members are aware of the team dynamics and actively attempting to improve them.
- See beyond roles and responsibilities
- Individual commitments
- Multi-utilization (team members works on several projects)
- Lack of access (people have unequal levels of access to other people in the team. For example, one team member telecommutes or one works in an office while the others are in a shared space)
- Insufficient access to grow or maintain trust
- Empathy
- Communication between teams through delegate
- Work coordinated through deadlines, milestones, handovers
- Unclear team goals, no roadmap or knowledge of which systems to build
- Direct team-to-team communication between the people doing the specific work item
- Default to low-interruption communications (email instead of face to face)
- Team mapping – related teams
- Joint team building (getting to know team members on other teams)
- Make other team goals explicit, visible
- Default to high-bandwidth communications (face to face over email)
These things have been removed from the main flow or are commentary. Might want them; want to keep them in mind. But they are not yet intended to be part of the final work.
- Individual focus
- Discipline focus (discipline, component, tech – “people that are similar to me within the team”
- Team cooperation
- Team collaboration
- Cooperate across near-org teams
- Collaborate across near-org teams
- Cooperate across experience (across departments, across org, …)
- Collaborate across experience