People are paying a lot of lip service these days to cross-group collaboration. Our employee survey results show that almost everyone thinks we should collaborate better, but that almost no one does. Gee, whatever could be the problem?
Could it be that groups have conflicts? Conflicting dates. Conflicting visions. Conflicting features. Conflicting requirements. Conflicting priorities, objectives, customer bases, business models, marketing messages, executive direction, budgetary constraints, resources. Hello?!? For crying out loud, most teams have trouble collaborating within their own group, let alone working with other teams.
Yeah, “But I. M.,” you say, “Collaboration is good.” Bugs get fixed once—in one place. There’s no duplication of effort. The user sees one common way to do things; there’s only one user interface to master. Developers need to understand only one API. There are fewer openings for a hacker to attack and fewer holes to patch. Groups can share resources and code. People can focus more on design and less on implementation and test. And, and, and…
So we’re back where we started. Collaboration can be both good and intractable, as can working with other people in general. The key is good negotiation skills, something far too few of us know or practice. So what do we do? I’ve seen two basic methods of collaboration and negotiation used at Microsoft.…
An offer you can’t refuse
The first way is the “collaborate and like it!” approach, which is by far the most common approach used around here. Someone big, loud, and powerful beats everyone over the head until they work together. (Usually an executive tells the groups to collaborate or else.) When that doesn’t work, the executive slaps the two groups together so there’s no other choice.
This corresponds to the negotiation tactic of yelling louder in an attempt to intimidate people to do things your way. Yuck, how juvenile. No one likes this bullying technique, except occasionally the bully. The worst reorgs are conducted in this way, and they are always nasty. Good people leave the group and sometimes quit the company. Feelings are hurt. Productivity and morale drop like a dot-com stock and take months to recover, if they ever do.
Eric Aside While forced collaboration is still used, it no longer dominates at Microsoft. These days, teams have agreements with each other as I describe next, or they simply share source code. It’s far better, but people often don’t understand the reasoning behind the agreement and skip important aspects. This predictably leads to problems, which is why knowing how to negotiate is so fundamental.
Grow up
The second method is a more mature approach to collaboration. It is also a bit subtler. You form a kind of agreement with your partner group. (Yes, I know there are obsessive PMs out there who mess this up by writing detailed and demeaning contracts that demoralize and disengage their dependencies, but you needn’t overdo it like that.) Up front you simply agree to what your group and your partner group will do, what your group and your partner group need in return, and what your group will do if things don’t work out and likewise for your partner.
This method is analogous to the effective negotiation strategy of discovering and disabling threats while fulfilling needs, thus establishing trust between parties and creating a basis for compromise and collaboration. That was a big sentence with lots of big ideas, so let’s break it down.
A shadow and a threat have been growing in my mind
When two groups are okay with the idea of mutually benefiting from working together, the big problem becomes removing barriers, not the collaboration process itself. This philosophy isn’t true if the groups want to defeat one another, like we might feel toward our competitors.
However, for groups within Microsoft or when working with our partners, the real challenge to collaboration is getting all of the obstacles out of the way.
Don’t shoot the messenger
Barriers to good collaboration always come in the form of threats, needs, and trust. Remove the threats, fulfill the needs, and you establish trust. Everything is downhill from there.
- Threats So, say you would like to use Windows Messenger in your application, but you are afraid that the Messenger team’s schedule will not match yours and that they will make last-minute changes that cause your program to break or your project to slip. This is a valid threat.
- Needs You need the Messenger team to grant you a stable code branch around your ship dates, and you need them to verify their builds around your usage of their APIs.
On the flip side, the Messenger team has needs to be met—they don’t want you to cause them grief—no huge feature changes or requests, no additional localization costs. And they want you to use their setup module so that you don’t break the other applications that use Messenger. They need you to agree up front to use the component as is, to cover any additional loc costs, and to incorporate their setup module in your application.
Eric Aside Truly understanding and appreciating your partner’s needs and concerns are critical to successful negotiation. Make sure you are in sync by directly acknowledging each other’s situation and requirements. No compromises yet, just acknowledgment will go a long way to building trust.
- Trust The contract you make, which can be as informal as an e-mail, documents that your team agrees to use Messenger’s setup and cover the cost of any additional loc; their team agrees to give you a frozen code branch around your ship dates (easy with Source Depot) and to use your BVT to verify their drops. You also specify what happens if either of you becomes dissatisfied with the relationship. Then product unit managers (PUMs) from both teams agree to the terms, and you are set to work together as partners.
Eric Aside A Build Verification Test (BVT) checks if a software build satisfies a set of requirements. Using a BVT to check software drops from other teams before accepting them is a wonderful practice. Even better is giving your BVT to the other team so that they can check themselves. That way, they know when they have met your requirements and you never have to deal with an unacceptable build.
After that, you can work out drop locations and schedules and solicit help implementing the APIs. This becomes easy when you both trust that your concerns will be met.
So happy together
The key to maintaining this level of trust is to keep the communication lines wide open. Ensure that PMs from both sides are talking to each other about schedule or feature changes, problems, and surprises. It’s not hard, but if either team forgets, it can spell doom for the project.
Eric Aside A mnemonic the Harvard Negotiation Project recommends is ACBD, Always Consult Before Deciding; that is, don’t make any impactful decisions without first talking to your partners.
When you negotiate this way, by removing threats, fulfilling needs, and gaining trust, you become incredibly effective in all facets of life. A mistake that people often make when negotiating is to jump in with solutions before listening to the concerns of others. If you prematurely present a solution, no one will accept it; they are afraid to get hurt. If you listen well, ask questions, and resolve the issues first, people will be surprisingly open to your ideas.
Eric Aside Be sure everyone feels like a winner after the negotiation is complete and beyond. Losing is a universal threat. One of the easiest ways to ensure everyone wins is by including everyone on the winning team—for example, “Here’s OUR great design.”
This method of collaboration is not magic and it’s not just for working across groups. Good negotiation skills can help you at home, around the neighborhood, within your own team, and with our partners. So get out there—collaborate and like it!
Eric Aside You can depend on me talks more about managing dependencies.
Be First to Comment