How does collaboration begin?
The question was posed in a discussion on LinkedIn. It received the following response:
Is the question "how does collaboration begin" or "how do specialists become generalists"? I assume the latter.
Um, well, that wasn’t the question. What’s the value in assuming a different question, because you’d prefer to answer the other question? After a number of comments extolling the virtues of the generalizing specialist, a person showed genuine interest in moving himself and his team in that direction. He want to get started. That’s a good thing.
Instead of helping him get started, however, people just reiterated the end state. Just do. Just be. Just blah blah blah. There’s a certain word in the question. It’s a little word; nothing ostentatious. But I think it’s kind of an important word. The word is begin.
The word appears in the following context:
I think I still have my original question: given a new team of specialists, how does the collaboration begin?
What he was asking for was help in locating the start of the path to collaboration, hidden beneath the underbrush of old assumptions and habits; and then, maybe, a supporting arm to hold onto for the first few steps, until he found his footing on the unfamiliar ground.
But that isn’t what he got. He still had his original question. That’s because no one had answered it, up to that point in the discussion. All they had said up to that point was collaboration blah blah generalist blah blah blah.
Maybe what’s needed here is another metaphor, to go along with all the other metaphors we use to describe our work. Couldn’t hurt, right?
Recently my family and I took a class together. It was an NRA-certified basic pistol class. Most of the emphasis was on handling firearms safely. One of the things you might do with your firearm is to hand it to someone else. As you might imagine from many years of watching movies and television, there are many different ways to hand a firearm to someone else. You could, for example, drop it on the floor and kick it across the room, loaded and cocked. This is analogous to the way software development specialists hand off work between functional silos; you know, the old "throw it over the wall" thing.
Now, it might surprise you to learn that the NRA doesn’t particularly recommend this method of handing off firearms, in most cases. It turns out that a number of things could potentially go awry. Several of those things can result in unhappy endings. Strangely enough, handing off software development artifacts in this manner also invites unhappy endings. Hence the value of collaboration.
We’re certainly not experts after one training class and an hour at the gun range, but here’s what we were taught about handing off a firearm: First, you clear it, then you hand it off. "Clear" means you check the magazine, action, and chamber to make sure there’s no ammunition in the gun. Then you ask someone else to look in the magazine, action, and chamber to confirm there’s no ammunition in the gun. You’re still holding the gun at that point. Making sure the gun is pointed in a safe direction at all times, you can then hand it to someone else. The procedure for that is to look at the person while he/she looks at the firearm. You present it to him/her, pointing it in a safe direction at all times, stock first. You don’t let go of it until he/she verbally confirms that he/she has a firm grip on it. You look at the firearm to see for yourself that it appears as if he/she does, indeed, have a firm grip on it. Then you can let go.
It’s just slightly different from dropping the gun on the floor and kicking across the room. In particular, there’s a fair amount of looking, listening, double-checking, confirming, and generally paying attention.
So, what’s the connection? On a software development team of specialists, a typical work flow is for an analyst to hand off an artifact to a programmer, who later hands off an artifact to a tester. These various interim artifacts eventually become a piece of working software. Traditionally, the hand-off procedure is to "throw it over the wall" to the next functional silo in line. It’s exactly the same as dropping a loaded gun on the floor and kicking it across the room, spinning in all sorts of unsafe directions and colliding unsafely with all sorts of unsafe obstacles.
If your current state is that your team comprises a group of siloed specialists, and you’d like to know how to begin a collaborative style of work, then learning how to do a safe hand-off might be a good first step. You’re certainly not going to leap directly and immediately to being a team of generalists who can seamlessly do any work the project calls for.
To begin to collaborate, try to hand off interim development artifacts in the same way as you would hand off a firearm. Say you’re a programmer and you think you’ve gotten a piece of work close enough to "done" that a tester can work with it. Instead of logging into some project management tool and marking the task as "ready for testing," invite a tester to sit down with you. Show and explain what you’ve done. If you’re the tester in that scenario, ask questions. Be as certain as you can that the two of you have a consistent understanding of what’s going on. Stay together while the tester begins to do his/her work. Be sure things are proceeding smoothly before you withdraw and pick up the next programming task.
Use the same sort of care with all the hand-offs in your workflow. You’ll find that people begin to get a pretty good sense of one another’s work…what others are looking for, how they approach things, how they conceive of the development process, etc. You’ll be well along the path toward the generalizing specialist model before you even realize it.
That’s how collaboration begins.