Open workplace research

Introduction

GSD guides the way I work. Over the years, I have integrated various methodologies into my daily work habits, including the feedback loop of lean methods, and the iterative optimization of agile development, as a way to better GSD. This means I have to use my time very efficiently: list clear, discrete goals; mark completed projects; and continue to advance project progress in an iterative manner. But can we still GSD when we base it on openness? Or maybe GSD’s approach simply doesn’t work?

Working in an open environment and following the guidance in the Open Decision Framework will make the project start slower. But on a recent project, we made a decision that was the right one from the beginning: to work in an open way and in partnership with our community.

This is the best decision we can make.

Let’s take a look at the unexpected consequences of this experience and see how we can incorporate GSD ideas into an open organizational framework.

Build a community

In October 2014, I took over a new project: Jim Whitehurst, the CEO of Red Hat at the time, was about to launch a new book "The Open Organization", and I wanted to build a community based on the concepts proposed in the book. "Great, this sounds like a challenge, I'm in!" I thought. But soon imposter syndrome set in, and I started thinking, “What on earth are we going to do? What does it take to be successful?”

Let me give you a spoiler, at the end of the book, Jim encourages readers to visit Opensource.com to continue the conversation about openness and management in the 21st century. So, in May 2015, our team created a new section on the website to discuss these ideas. We plan to tell some stories, like we often do on Opensource.com, but this time around ideas and concepts from the book. Since then, we’ve published new articles every week, hosted an online book club on Twitter, and turned Open Organization into a book series.

We wrote the first three issues of the book series in-house, publishing one issue every six months. As each issue is completed, we release it to the community. Then we move on to the next issue, and the cycle continues.

This way of working has allowed us to see great success. Nearly 3,000 people have subscribed to the new book in the series: The Leader's Handbook for Open Organizations. We worked on the project in a six-month cycle so that the new book's release date would be the second anniversary of the previous book.

Against this background, the way we completed this book was simple and straightforward: on the topic of open work, we collected the best stories and organized them into articles, recruiting authors to fill in some content Blank, adjust font styles using open source tools, work with designers to finalize the cover, and finally publish the book. This way of working allows us to move forward at full speed according to our own timeline (GSD). By the third book, our workflow was mostly complete.

This all changed, however, when we planned to start the final book of The Open Organization, which will focus on the intersection of open organizations and IT culture. I proposed using the open decision-making framework for this book because I wanted to demonstrate that an open approach to work leads to better results, even though I knew it might completely change the way we work. The time frame was very tight (only two and a half months), but we decided to give it a try.

Complete a book using an open decision-making framework

The Open Decision Making Framework outlines the 4 stages that make up the open decision making process. Here’s how we work in each phase (and how being open helps get the job done).

1. Concept

We started by writing a draft outlining our vision for the project. We need to take something out and share it with potential “customers” (in this case, potential stakeholders and authors). We then set up interviews with experts in the field who could give us direct, honest opinions. The enthusiasm shown by these experts and the guidance they provided validated our ideas while providing feedback that kept us moving forward. If we don’t get these validations, we fall back on our original idea and decide where to start over.

2. Planning and Research

After several interviews, we are ready to announce the project on Opensource.com. At the same time, we also launched the project on Github, providing a project description, estimated timeline, and clarifying our constraints. The announcement was well received, with some items missing from our originally planned catalog being completed within 72 hours of the project being announced. Additionally (and more importantly), readers have suggested ideas for some chapters that were not part of our plans, but which they felt would complement the version we originally envisioned.

Looking back, I feel that in the first and second phases of the project, opening up the project did not affect our ability to complete the project. In fact, working this way has a big benefit: discovering and filling content gaps. We didn't just fill the gaps, we filled them quickly and with ideas we would never have considered ourselves. This doesn’t necessarily require us to do more work, it just changes how we work. We draw on our limited connections, invite others to write, and then organize the content we receive, setting context and guiding people in the right direction.

3. Design, development and testing

This phase of the project is all about project management, managing some cat-like mavericks, and dealing with the expectations of the project. We have clear deadlines, we communicate in advance and we communicate frequently. We also used a strategy of making a list of contributors and stakeholders and keeping them informed of the project's progress throughout its lifespan, especially the milestones we mapped out on Github.

Finally, our book needs a name. We collected a lot of feedback about what the title should be and, more importantly, what the title shouldn't be. We collect feedback via tickets on Github and make it public that our team will make the final decision. As we prepared to announce the final titles, my colleague Bryan Behrenshausen did a great job sharing the process that led to our decision. People seemed happy about it—even if they disagreed with our final title.

The "beta" phase of a book requires a lot of proofreading. Community members really got involved in answering this "ask for help" post. We received approximately 80 comments on the GitHub ticket reporting on the progress of the proofreading work (not to mention the many additional feedback received via email and other feedback channels).

About completing the task: At this stage, we have personally experienced Linus's law: "With more eyes, all typos are shallow." If we are independent like the first three books, done, then the entire burden of proofreading falls on our shoulders (just like these books)! Instead, community members generously shouldered the burden of proofreading for us, and our job shifted from proofreading ourselves (although we still did a lot of that) to managing all the change requests. This is a welcome change for our team and an opportunity for the community to get involved. We definitely could have finished proofreading faster if we had done it ourselves, but with the open we found more errors before the deadline, that's for sure.

4. Release

Well, we now have the final version of this book out. (Or just the first edition?)

We divide the release into two stages. First, according to our public project timeline, we quietly launched the book a few days before the final date to allow our community contributors to help us test the download form. The second stage is now, the official announcement of the general version of this book. Of course, we still accept feedback after release, as is the open source approach.

content

Achievements Unlocked
Following an open decision-making framework is key to the success of the Guide to IT Culture Change. By collaborating with clients and stakeholders, sharing our constraints, and being transparent about our work, we exceeded even our own expectations for the book project.

I am very pleased with the collaboration, feedback and activity throughout the project. While there was a period of anxiety about not getting things done as quickly as I wanted to, I quickly realized that opening up the process actually allowed us to get more done. This is obvious based on my overview above.

So maybe I should rethink my GSD mentality and extend it to GMD: Get More Done, get more done, and in this case, get better results.

(title picture: opensource.com)

About the Author:

Jason Hibbets - Jason Hibbets is a Senior Community Evangelist in Red Hat Enterprise Marketing and a Community Manager at Opensource.com. He has been with Red Hat since 2003 and is the founder of the Open Source Cities Foundation. Previous positions include Senior Marketing Specialist, Project Manager, Red Hat Knowledge Base Maintainer, and Support Engineer.

The above is the detailed content of Open workplace research. For more information, please follow other related articles on the PHP Chinese website!