12 KiB
Why working openly is hard when you just want to get stuff done
Learn how to create a book using the Open Decision Framework.
Image by : opensource.com
Three letters guide the way I work: GSD—get stuff done. Over the years, I've managed to blend concepts like feedback loops (from lean methodologies) and iterative improvement (from Agile) into my everyday work habits so I can better GSD (if I can use that as a verb). This means being extremely efficient with my time: outlining clear, discrete goals; checking completed items off a master list; and advancing projects forward iteratively and constantly. But can someone still GSD while defaulting to open? Or is this when getting stuff done comes to a grinding halt? Most would assume the worst, but I found that's not necessarily the case.
Working in the open and using guidance from the Open Decision Framework can get projects off to a slower start. But during a recent project, we made the decision—right at the beginning—to work openly and collaborate with our community.
Open Organization resources
It was the best decision we could have made.
Let's take a look at a few unexpected consequences from this experience and see how we can incorporate a GSD mentality into the Open Decision Framework.
Building community
In November 2014, I undertook a new project: build a community around the concepts in The Open Organization , a forthcoming (at the time) book by Red Hat CEO Jim Whitehurst. I thought, "Cool, that sounds like a challenge—I'm in!" Then impostor syndrome set in. I started thinking: "What in the world are we going to do, and what would success look like?"
Spoiler alert . At the end of the book, Jim recommends that readers visit Opensource.com to continue the conversation about openness and management in the 21st century. So, in May 2015, my team launched a new section of the site dedicated to those ideas. We planned to engage in some storytelling, just like we always do at Opensource.com—this time around the ideas and concepts in the book. Since then, we've published new articles every week, hosted an online book club complete with Twitter chats, and turned The Open Organization into a book series.
We produced the first three installments of our book series in-house, releasing one every six months. When we finished one, we'd announce it to the community. Then we'd get to work on the next one, and the cycle would continue.
Working this way, we saw great success. Nearly 3,000 people have registered to receive the latest book in the series, The Open Organization Leaders Manual . And we've maintained our six-month cadence, which means the next book would coincide with the second anniversary of the book.
Behind the scenes, our process for creating the books is fairly straightforward: We collect our best-of-best stories about particular aspects of working openly, organize them into a compelling narrative, recruit writers to fill some gaps, typeset everything with open tools, collaborate with designers on a cover, and release. Working like this allows us to stay on our own timeline—GSD, full steam ahead. By the third book, we seemed to have perfected the process.
That all changed when we began planning the latest volume in Open Organization series, one focused on the intersection of open organizations and IT culture. I proposed using the Open Decision Framework because I wanted this book to be proof that working openly produced better results, even though I knew it would completely change our approach to the work. In spite of a fairly aggressive timeline (about two-and-a-half months), we decided to try it.
Creating a book with the Open Decision Framework
The Open Decision Framework lists four phases that constitute the open decision-making process. Here's what we did during each (and how it worked out).
1. Ideation
First, we drafted a document outlining a tentative vision for the project. We needed something we could begin sharing with potential "customers" (in our case, potential stakeholders and authors). Then we scheduled interviews with source matter experts we thought would be interested in the project—people who would give us raw, honest feedback about it. Enthusiasm and guidance from those experts validated our idea and gave us the feedback we needed to move forward. If we hadn't gotten that validation, we'd have gone back to our proposal and made a decision on where to pivot and start over.
2. Planning and research
With validation after several interviews, we prepared to announce the project publically on Opensource.com. At the same time, we launched the project on GitHub, offering a description, prospective timeline, and set of constraints. The project announcement was so well-received that all remaining holes in our proposed table of contents were filled within 72 hours. In addition (and more importantly), readers proposed ideas for chapters that _weren't _ already in the table of contents—things they thought might enhance the vision we'd initially sketched.
We experienced Linus' Law firsthand: "With more eyes, all typos are shallow."
Looking back, I get the sense that working openly on Phases 1 and 2 really didn't negatively impacted our ability to GSD. In fact, working this way had a huge upside: identifying and filling content gaps. We didn't just fill them; we filled them rapidly and with chapter ideas, we never would have considered on our own. This didn't necessarily involve more work—just work of a different type. We found ourselves asking people in our limited network to write chapters, then managing incoming requests, setting context, and pointing people in the right direction.
3. Design, development, and testing
This point in the project was all about project management, cat herding, and maintaining expectations. We were on a deadline, and we communicated that early and often. We also used a tactic of creating a list of contributors and stakeholders and keeping them updated and informed along the entire journey, particularly at milestones we'd identified on GitHub.
Eventually, our book needed a title. We gathered lots of feedback on what the title should be, and more importantly what it shouldn't be. We opened an issue as one way of gathering feedback, then openly shared that my team would be making the final decision. When we were ready to announce the final title, my colleague Bryan Behrenshausen did a great job sharing the context for the decision. People seemed to be happy with it—even if they didn't agree with where we landed with the final title.
Book "testing" involved extensive proofreading. The community really stepped up to answer this "help wanted" request. We received approximately 80 comments on the GitHub issue outlining the proofing process (not to mention numerous additional interactions from others via email and other feedback channels).
With respect to getting things done: In this phase, we experienced Linus' Law firsthand: "With more eyes, all typos are shallow." Had we used the internalized method we'd used for our three previous book projects, the entire burden of proofing would have fallen on our shoulders (as it did for those books!). Instead, community members graciously helped us carry the burden of proofing, and our work shifted from proofing itself (though we still did plenty of that) to managing all the change requests coming in. This was a much-welcomed change for our team and a chance for the community to participate. We certainly would have finished the proofing faster if we'd done it ourselves, but working on this in the open undeniably allowed us to catch a greater number of errors in advance of our deadline.
4. Launch
And here we are, on the cusp of launching the final (or is it just the first?) version of the book.
Following the Open Decision Framework was key to the success of the Guide to IT Culture Change.
Our approach to launch consists of two phases. First, in keeping with our public project timeline, we quietly soft-launched the book days ago so our community of contributors could help us test the download form. The second phase begins right now, with the final, formal announcement of the book's general availability. Of course, we'll continue accepting additional feedback post-launch, as is the open source way.
Achievement unlocked
Following the Open Decision Framework was key to the success of the Guide to IT Culture Change . By working with our customers and stakeholders, sharing our constraints, and being transparent with the work, we exceeded even our own expectations for the book project.
I was definitely pleased with the collaboration, feedback, and activity we experienced throughout the entire project. And although the feeling of anxiety about not getting stuff done as quickly as I'd liked loomed over me for a time, I soon realized that opening up the process actually allowed us to get more done than we would have otherwise. That should be evident based on some of the outcomes I outlined above.
So perhaps I should reconsider my GSD mentality and expand it to GMD: Get more done—and, in this case, with better results.
作者简介：
Jason Hibbets - Jason Hibbets is a senior community evangelist in Corporate Marketing at Red Hat where he is a community manager for Opensource.com. He has been with Red Hat since 2003 and is the author of The foundation for an open source city. Prior roles include senior marketing specialist, project manager, Red Hat Knowledgebase maintainer, and support engineer. Follow him on Twitter:
via: https://opensource.com/open-organization/17/6/working-open-and-gsd
作者：Jason Hibbets 译者：译者ID 校对：校对者ID