This post is an expansion on something I raised a few months ago in my post “Herding Cats“:
If it isn’t written down somewhere that stakeholders can get to it, it didn’t happen. Even if it is written down, if it’s not well indexed, it still didn’t happen.
I’m going to start by assuming that everyone reading this recognizes the importance of keeping notes or minutes (which are not the same thing) for the meetings they participate in. It comes back to an old adage “If you didn’t write it down, it didn’t happen.”
If you are on a project that spans years, however, the records of your meetings can become less and less helpful. You know the group made a decision at some point, but when? Who was there? What were the reasons? Can you actually point to the discussion later so you don’t have to repeat that process again?
It has taken me longer than I care to admit, but I’ve finally worked out a structure for my records that help both the immediate need for a reference and the longer term need for an index. This can be adapted based on what collaboration tools you have available.
Meeting Name, Date
- Open Action Items
- Label (e.g., AI-20190807-00), Owner, Description
- Label (e.g., D-20190807-00), Description
- Closed Action Items
- Label (e.g., AI-20190807-00), Owner, Description, Date Closed
I usually put the Action Items and Decisions in table format. Depending on the collaboration tools, these records can be in one big file that rolls over annually (so you have your 2019 notes, archive them, then your 2020 notes, etc.), or in one file per meeting. If you do the latter, copy the decisions and closed action items into a single file that can serve as an index for the year.
“You are always saying yes to something.” Jen Casey
I recently listened to a podcast (“The Inner Boss“by Jen Casey, episode 152) that made me think about how I approached decision making. I was originally going to say “consensus-based decision making” but really, this applies to any decision making at all. From what to have for dinner, to whether to approve a change to a technical specification, or even whether it’s time to end a contract, it’s worth considering the following:
“You are always saying yes to something.”
When I first heard that on the podcast, I thought “Well, I’m pretty sure that decision I made last week about whether to turn on my video camera for a conference call at the demand of some stranger was a pretty hard ‘nope’, not a ‘yes’.” Which, while true, wasn’t the point. That particular decision was a hard nope to what I considered a somewhat manipulative demand to control the meeting, but it was also a yes. In that case, it was a yes to “I am going to position myself in a less than positive light to this individual who feels the need to see the person they are talking to.”
I’m still quite comfortable with my decision in that moment, but it was enlightening to consider it from the perspective of: if I say no to one behavior, what behavior or action am I doing instead? What are the implications here? By saying no to one thing, I might be agreeing to a status quo (at least for a time), or agreeing to continue an unhealthy behavior, or even agreeing to let a problem continue to exist even though it’s, well, a problem.
This idea of “what did I implicitly agree to” is something that will change how I drive the meetings and decision making in the groups I work with. I see this kind of thinking as a way to make people really consider the ramifications of their actions (or their lack of actions). Even a simple question in the last ten minutes of a call — “Are we all ok with letting this issue persist for another two weeks until our next call, or do we want to schedule some time to work on it sooner?” — has the potential to make a big difference in getting work done.
Maybe the no, or the delay, is the right thing to do in the moment, but it’s always, ALWAYS better to make mindful decisions with an understanding of the consequences, than it is to just say “no” or “let’s discuss later” because it’s the easier path.
And now for my next question in life: if I say ‘no’ to eating my vegetables, what did I implicitly agree to?
“Many ideas grow better when transplanted into another mind than the one where they sprang up.”Oliver Wendell Holmes
My experience of working with globally distributed, multistakeholder, volunteer communities to make things happen.
The short, short version:
- Time zones suck. There’s no way around that. Plan for duplication of information so that you can respect time zones.
- Give up on the idea of doing things quickly but always remember that the work is important. It needs to happen. Be patient (but not too patient).
- If it isn’t written down somewhere that stakeholders can get to it, it didn’t happen. Even if it is written down, if it’s not well indexed, it still didn’t happen.
The somewhat longer version…
At the moment, I work with about five (maybe seven) different collaborations. Those collaborations have a few things in common. They exist across several countries, time zones, and organizations. They are trying to do something that they can give (not sell) back to the world and they all take a really long time to get there from here.
My role differs in the details from one contract to the next, but in all cases: I am responsible for some (sometimes more, sometimes less) level of coordination. I get to interact with many of the stakeholders and help define the processes that will allow them to get their work done. ‘Done’ might mean published or “go-live” with software. It doesn’t actually matter what ‘done’ is, as long as the authors, developers, or stakeholders know they have had the opportunity to be involved.
The coordination aspects are always a challenge for a variety of reasons. First, time zones might seem like an odd thing to put at the top of the list; but time zones are the very devil to work around. It took me a year or two, but now anytime someone suggests a conference call, my first question is “what time zones are the participants in?” Sometimes that means we actually need to play the telephone game because it’s not reasonable to get the people from Malaysia to Amsterdam on a call at the same time.
Second, the more people are involved, the longer the work will take and the better a chance the work has to be broadly adopted. In fact, it will take longer than anyone expects it to. Contract holders do not want to hear that a project they think will take a year will likely take two, or that a software rollout will never actually complete (clients always want one more feature). Sometimes a best practice or technical specification, once set in front of the organizations that would need to follow it to make it “real”, will take a life of its own as it evolves to meet the reality outside the minds of the people that created it.
Third, you can coordinate the heck out of something, but if the decisions weren’t written down AND indexed so that someone could easily find them later, then it didn’t happen. You might well have to do it all over again. Meeting notes, especially ones made public, are great. But let’s say the project extends from two to five years or more. How easy will it be to find the decisions made at the beginning of the project? Everyone will likely have their own indexing method (I’m still working on what will serve my groups most efficiently) , but if you do nothing else; (even if you expect the project to last only six months) make sure that the decisions made and the policies developed are easy to locate.
And that’s the core for herding global, multistakeholder collaborations. The work is definitely worth it. The quality of minds and perspectives you can engage with at this scale are amazing. But, seriously, write it down. And index it.
On May 9, 2019, I participated in my first “Tweet Jam“. What glorious chaos! The topic was the upcoming Identiverse conference, and the goal was to get people thinking about the topics that will be touched on during the week of the conference itself.
The concept of a structured and yet free-flowing conversation with all responses scrolling by at different times meant you never actually knew what response was going to pop up on your screen at any given moment. Each response had the potential to spin off into a random direction (we ended with zombies) or dive deeper into the technical details. It was a glorious chaos that, fortunately, anyone can go back and review to find some gems in the conversation. Just search “#identiverse” on Twitter and head back to May 9.
One of the themes I particularly interested in included considering identity-related technologies in a fully global context. How do people access services online in Africa? In Asia? It’s a very different paradigm, and any technology that’s going to be truly successful needs to take those different use cases into account. Case in point: my colleagues in Africa tell me that it is most common to access the Internet via mobile phones. Mobile phones, however, are often turned off (to conserve power in an unreliable power grid situation) and shared among families. A student may well use his parent’s phone to do research for school, while the parent uses it to pay bills or purchase services. Will self-sovereign identity models take that scenario into account? What about biometrics? WebAuthn?
Question 5 has become fascinating to me, if only in retrospect. (My answer at the time was ‘No. And, “I’m from the government and I’m here to help.”‘),
I’ll be going back to study this thread, and see if what the identity people said matches the logic behind San Francisco‘s move to ban facial recognition technology by the police and other government agencies. Maybe that government, at least, is here to help.
The Tweet Jam was thought provoking, fun, and definitely an interesting tool to get people thinking about the topics for a conference. This is a technique worth applying to other conferences where the expected attendees have a strong presence on Twitter. I wonder if one could do something similar on Instagram…
People often ask me what it is I actually do for a living. What do I do that lets me travel the world for 35-40% of the year, and otherwise work from a rural island in Puget Sound? It’s a fun question, but not easy to answer.
What I do is: whatever IT engineers, open source developers, or Internet standards writers need me to do so that they can get their jobs done. Sometimes, I’m an executive editor, developing, evolving, and overseeing publication processes. In other roles, I’m a technical editor helping clarify reports and writing up style material so the writers have a template from which to start. And more often than not, I’m a facilitator for disparate groups made up of volunteers from organizations around the world who are all trying to make the Internet better.
What I love most about what I do is the fact that I don’t work for any one organization. I did that for quite a while, working for a few years as Director of Systems in central IT at Stanford University, Senior Manager for the same kind of group at Duke University, and as a sys admin for various companies before that. In all those roles, even when I was participating in some kind of inter-institutional collaboration, I had to keep the concept of “what’s best for my organization” central to everything I did. Today, I work from the concept of “what is best for everyone involved in this project, regardless of where they work or where they are in the world.” And that’s a glorious place to be.
Multi-stakeholder collaborations, especially when they consist of volunteers, are always challenging and almost as always rewarding. The collaborations often bring out the best and brightest minds the world has to offer. It is a privilege to get to learn from them and enable their efforts to make the digital world a better place.