 |
by Kent Aitken |       |
Note: I’ll be at the Digital Governance Forum today (January 28-29, 2015). Drop me a line if you’re there and say hi.
Collaboration bests complexity. It helps us suss out hard-to-see impacts of our actions, reveals our ideas' redundancy, and helps us improve our plans.
The typical approach after brainstorming is over to send around a set of summary notes. But, it's difficult to contextualize a mass of notes. There's no visual hierarchy to provide cues about what's important. Essentially, we're expecting our audience to simultaneously identify good ideas and assign responsibility to themselves or others, from an email that looks identical to the hundred others they'll receive that day.
It doesn't have to be as structured as the above, but the principle stands: it's much easier for people to walk through a series of small, concrete steps. And it's much easier to take ownership of an idea - the "Who's responsibility is this?" question - after working through the how and why, even briefly.
Why?
I love meeting with people, talking and learning new things, and hearing new takes on subjects. Those interactions are resoundingly worthwhile. In the end, it's so easy to share ideas with others, to ask for feedback, and to give help. So, even if it's relatively rare that you really, truly connect and improve the idea, it's worth it.
Yet, if we can further honour that time by maximizing the chances of those ideas positively influencing the systems in which we work, we should.
Last week I wrote about the unnecessary villainizing of talk. I worried that we subtly discourage the sharing of, and discourse around, ideas that are less than fully formed.
There are also times to rightfully skewer talk. It obviously does occur that an idea should happen and doesn't due to a lack of follow-through. But the more interesting cases are when it’s not solely a matter of personal responsibility, but rather, the requirement to productively fold such talk into a hierarchy.
Where last week's post was about talk in general, this one will focus on asking for input, and in particular, what we hear back.
Where last week's post was about talk in general, this one will focus on asking for input, and in particular, what we hear back.
Ideas plus Hierarchy
 |
| Complexity Kryptonite |
This collaboration could be requesting meetings with experts, bouncing ideas off colleagues, facilitating working groups, or running engagement activities. For all of these, there is a worst case scenario that I detest: asking people for their time then being unable to turn it into something productive.
I learn a lot, and I love the discussions, but it’s not enough.
And it's particularly hard in large organizations. Those soliciting ideas and those approving them have different incentives and mandates, and different information about the exercise. It’s no one’s fault; rather, an inevitable product of hierarchies.
Often, it’s a personal failure on behalf of the idea steward, the person tasked with analyzing the talk - ideas, feedback, input - and moving it forward. I have to admit to this - failure to understand my environment, to frame and communicate ideas well, and to give those ideas a chance of success in the hierarchy.
So, I'd like to explore three approaches that stack the deck for those ideas in a hierarchy.
1. Get In Front of Your Process
What do you have control over? Actually, really, reliably?
You need to know your role and limits, inside out - and be transparent about it. It’s far more powerful to have done that up front, than to have to answer the question when asked.
You need to know your role and limits, inside out - and be transparent about it. It’s far more powerful to have done that up front, than to have to answer the question when asked.
For example, SpaceX CEO Elon Musk is currently destroying multi-million dollar rockets trying to get them to land on a drone ship off the Florida coast. His tests can end in fiery explosions yet he retains trust, because of how he sets expectations and lays out the chances of success beforehand.
Next rocket landing on drone ship in 2 to 3 weeks w way more hydraulic fluid. At least it shd explode for a diff reason.
— Elon Musk (@elonmusk) January 16, 2015
@ID_AA_Carmack Full RUD (rapid unscheduled disassembly) event. Ship is fine minor repairs. Exciting day! pic.twitter.com/tIEctHFKHG
— Elon Musk (@elonmusk) January 16, 2015
(For a non-explosion-based example, I’m very proud of my colleagues’ work on this report following a massive consultation.)
We’re in this for the long haul, and projects don’t supersede relationships. Promise where you can, and admit it where you can’t.
2. Get Others in Front of the Process
If you're the liaison between the hierarchy and the universe with which you collaborate, you're in the best position to understand both. Lay out what is expected of both collaborators and the hierarchy you represent. This is where "plans are useless, but planning is indispensable".
Is someone's commitment required to make this collaboration or dialogue a success? Make sure they see or approve the plan, and make them part of the story, by name or by position. As explicit as "At this point, X person will do Y."
Make them promise where they can, and admit it beforehand where they can't - so you don't over-promise on your organization's behalf.
Is someone's commitment required to make this collaboration or dialogue a success? Make sure they see or approve the plan, and make them part of the story, by name or by position. As explicit as "At this point, X person will do Y."
Make them promise where they can, and admit it beforehand where they can't - so you don't over-promise on your organization's behalf.
3. Make it Easy for the Hierarchy to Internalize Ideas
The showstoppers get done. What about the bulk of simply good ideas?
The typical approach after brainstorming is over to send around a set of summary notes. But, it's difficult to contextualize a mass of notes. There's no visual hierarchy to provide cues about what's important. Essentially, we're expecting our audience to simultaneously identify good ideas and assign responsibility to themselves or others, from an email that looks identical to the hundred others they'll receive that day.
Here's an example alternative. Following the last big workshop I ran, I listed the dozens of action phrases that followed some variant of “we should”, “you should”, or “the organization has to”. For each, I introduced the idea, then walked my team through these questions:
Idea
|
Should we do this?
|
Now, or later?
|
Us, or partners?
|
How?
|
Are there alternatives that achieve the same goal?
|
If partners are handling this, what do they need from us?
|
Who, specifically, is responsible for this?
|
| "We should X" |
It doesn't have to be as structured as the above, but the principle stands: it's much easier for people to walk through a series of small, concrete steps. And it's much easier to take ownership of an idea - the "Who's responsibility is this?" question - after working through the how and why, even briefly.
Why?
I love meeting with people, talking and learning new things, and hearing new takes on subjects. Those interactions are resoundingly worthwhile. In the end, it's so easy to share ideas with others, to ask for feedback, and to give help. So, even if it's relatively rare that you really, truly connect and improve the idea, it's worth it.
Yet, if we can further honour that time by maximizing the chances of those ideas positively influencing the systems in which we work, we should.
No comments:
Post a Comment