Collaborating or Cooperating?

I had the opportunity to attend a workshop last week, and this question came out in the discussion during one of the days.

Do we collaborate, or cooperate, with others on our teams, and with other teams?

It got me thinking. First of all, I wasn’t sure there was really a significant difference. But the more we talked about it, the more I realized that there is a difference. And it’s not a trivial difference. One isn’t better than the other. They’re just different, and they each offer something.

When we cooperate, we agree to work together, but on our own things.

I know how to do something, and you know how to do something. But we both need to complete our work in order to deliver whatever it is that we’re doing. So we each work on what we know, put it together, and volià! We do our own work, and we make sure it fits in with the work the others I’m cooperating with.

When we collaborate, we work together, on the same thing.

This likely sounds a bit odd. I know how to do something, and I’m pretty good at it. You also know how to do that same something, but you’re not as good as me. And, there’s something else that needs to get done. Why on Earth would we collaborate, when we could just cooperate?

The more I thought and reflected on this, the more I came to this conclusion:

When the type of work is so simple that I know how to do it myself, or it’s straight forward in the solution, I can do it myself. And I can cooperate with others who are also working on simple items. We can work together to make sure whatever it is we’re doing goes together neatly.

When the type of work doesn’t have a simple, straightforward, or obvious solution, I benefit by collaborating with others to come up with a potential solution. It’s likely a potential solution because it’s not simple, it’s not obvious, and we can’t be sure our solution will work.

In this case, it’s not about getting the most out of us, but rather getting the best out of our combined knowledge, skills, and experience.

When I cook with my wife, Kathy, and we’re following a recipe, we cooperate. I chop the onions and garlic, while she melts the butter in the saucepan. Once I’m done the onions, I go on to grilling the steak, while she sautés the onions & onions I’ve just cut in the pan with the melted butter, and adds in a bit of salt and pepper. See? That’s us cooperating.

When we’re planning a family vacation, we collaborate. For us, it’s as much about where we go, as how we get there. So while Kathy typically picks the destination on her own (or proposes a couple of ideas), we figure out how we’re going to get there together. That means we look at the map together, and think about how far we can drive before our kids drive us nuts. We look at landmarks, parks, shops, and other sights along the road and talk about which we’re going to stop at, and which we’re going to skip (which is important, because my wife would have us stopping at all of the shops). We figure out how each decision we make impacts where we’re going to spend each night, and how we can optimize the number of things we get to see and do so everyone in the family gets to see and do things that are of interest to them. This isn’t always simple. And often results in a bit of negotiating, but we do it by collaborating with each other.

Sometimes, we’ll want to research something that we’re going to pass along the way. In the context of collaborating, we’ll jump into coordinating. I’ll research the various nature walks in the park we’re going to be driving through so I can see as many waterfalls as possible. Kathy will look into the shops in the town just outside the park. We’ll have boundaries – I have to find the walks & waterfalls that we can do within three hours, while Kathy finds the three most important shops she wants to see (which typically means she picks seven or eight, and we end up stopping at ten to twelve).

While we’re cooperating, we’re leveraging our individual interests and experiences.

We keep each other, and our children, in mind – I don’t pick the crazy hard walk since our 7-year-old daughter won’t be able to keep up, while she considers the shops our fourteen-year-old son might be interested in.

While we’re collaborating, we’re building our combined understanding of what our experience will involve. We build a shared understanding of what it is we’re going to do on our vacation.

We need to do both.

When I think of how this applies to work, there are times when I need to cooperate with others, and there are times I need to collaborate with others. There are times when my work is simple enough that I can do it on my own, making sure it aligns and integrates with what my colleagues are working on. There are also times at work when I need to collaborate with others because we work in a complex environment, and I don’t have all the skills and expertise to arrive at the hypothesis that’s most likely to result in a great result.

I’d suggest that cooperating allows us to get the most out of everyone, and collaborating allows us to get the best from everyone. I believe we need both.

Functional Fixedness

Let’s say you have a candle, a box of thumbtacks, and a book of matches. Can you figure out a way to affix the candle to the wall in such a way that when lit, the wax will not drip onto the floor?

There’s a psychological bias that sometimes prevents us from seeing possible solutions that are right in front of us. One common bias is called functional fixedness.

Last summer, I was lucky enough to spend a number of weeks in Alaska. As part of this trip, I got to spend a bit of time on the Mendenhall Glacier, where some beautiful glacial water happened to be flowing. Not expecting it, I didn’t have a cup or glass or container to use to drink the water. It was a little below the surface, so lying down and putting my face directly in the water wasn’t really an option – I guess I could have made it work. But being the creative person I am, I used a flash diffuser I happened to have in my camera bag, while others who were with me couldn’t enjoy the pure, ice cold, crystal clear, glacier water.

When it comes to innovation, people and businesses are constantly hampered by functional fixedness (and other biases), which causes us to overlook elegant solutions hidden in plain sight.

Consider deflating a soccer ball and using it as a bowl. Why not?

Sometimes, the words we use constrain our thinking. It’s important to use the most generic words when we first start talking about a problem or an opportunity.

There’s a great quote about buying a drill. The quote is that people don’t want a drill; what they want is a hole.

But I’d like to take this a bit further – we don’t really want a hole. What we want is somewhere to put in a bolt. But even that isn’t what we want. What we really want is to bolt pieces of wood together. And we could explore that further by understanding why we want to connect those pieces of wood. Maybe there’s a better solution. Maybe not. What if I changed my goal to “connect” pieces of wood? What if I used the word adhere. Or laminate. Or join. Do different possibilities come to mind when I simply change the word? A functional fixedness can be caused by how the problem is framed.

The most dangerous words I hear in organizations are “that’s how we do it here”.

By the way, here’s a solution to the candle problem I started this post with:
If you empty the box of thumbtacks, you can attach the candle to the inside of the empty box with some melted wax, and then tack the box to the wall. The box acts as a shelf that supports the candle and catches the dripping wax. Because the box is presented as simply a container to hold the tacks, it’s often difficult to see it as anything else.
It’s Duncker’s Candle Problem.

As you’re going through your day, challenge those things you consider absolutes.

Safe to Fail

I’ve just returned from speaking at an Agile conference in Winnipeg. Yes, Winnipeg in November. It actually wasn’t too cold, and the quality of conversations were amazing, so all-in-all, an amazingly worthwhile and valuable experience to learn and share.

I wanted to think about failure this week. Something I’m pretty familiar with!

In order for innovation to occur, we need to be in a safe environment. Only when it’s okay to get something wrong will we be willing to push the boundaries.

I often hear from folks who work in financial services, insurance, health care, and even telecommunications say that we can’t really take risks. So what’s the alternative? If we’re going to dream and make a real impact, we can start be making really small experiments. We need to be pushing the boundaries in a way that doesn’t put our customers at risk, and doesn’t put us at risk. So we need to find safe ways to fail. We need to encourage each other to look at tiny bits of work that we’re doing, and look for those improvements that might not revolutionize our work and industry. But if we keep at it, I believe we’re likely to find that the sum of our improvements can make an impact.

I participated in a Lego Serious Play session in Winnipeg. I was having some fun creating a model of what I would do with team members who let me down. The model shows that person being pushed off the top of a tall tower by another team member.

Have you ever worked in an environment when you made a mistake, and got punished? Maybe it was significant enough that it resulted in a lower performance review at the end of the year. Maybe it was by public shaming. Maybe it was just an idea that wasn’t aligned with your manager, and you were told that in a meeting.

Regardless, how likely are you to take another risk in that environment?
Yeah. Me neither.

When someone takes a risk through a controlled experiment, we should celebrate the learning that comes from that experiment. No matter the outcome of the experiment, because learning is an outcome that can be used to guide and inform the next experiment.

If we’re running huge experiments, with months of investment, and weeks to roll back if we find an issue, there’s a huge risk! Not only is the initial outlay expensive (we’re risking a lot of money, time, and effort to begin with), but we’re also risking the fact that no one might want to use whatever it is we’re creating for them. Oh, and by the way, we’re not learning anything along the way.

In project management, we talk about the “iron triangle”. That is, there are three elements that need to be managed during a project – they are Cost, Quality, and Scope. (There’s a joke here that on almost any project, you can pick two of them at the expense of the third). But that’s not the point I want to make. Imagine if I deliver on all three of those elements – I deliver exactly what was asked for (scope), I deliver it with on time and on budget (cost), and I build it perfectly, in a way that it’ll last forever (quality). Sounds like a successful project.

But wait a second… If no one uses it, if it creates no additional revenue, if it doesn’t help with customer satisfaction… Would you really call it a success?

If we have a hypothesis, we need to look at running the smallest experiment to validate it (or disprove it).

Once we’ve validated it, let’s invest more money and release the next experiment.

Lather, Rinse, Repeat.

But in order to enable this, we need to have a safe environment to encourage experimentation. And failure. That creates opportunities for learning.

And that seems like a safe way to lead to success.