I’ve decided to dig back into my roots of IT Requirements Management practices to contribute to the public conversation and understanding of the concept of Working Out Loud. For more on my personal history contributing to this idea, read here: Working Out Loud: What Happened to Then? We’re at Now, Now!
The below is a flow of an idea of something I’d like to get rolling on, with some help. Certainly not a finished product. And the target benefactor is an individual worker…or someone coaching individual workers about adopting “working out loud” work behaviors into their daily practices.
Capture the “behaviors” of someone that is effective at Working Out Loud into a modular use case format, organized around typical work behaviors and how each of those can be shifted to the “new way” of working instead of how most people in today’s work environment might go about that activity. And organize those use cases / behaviors / activities using John Stepper’s Five Elements of Working Out Loud.
- Organize it and build it in a process similar to how I used to capture and organize IT system requirements packages.
- Work Out Loud while defining Working Out Loud🙂 So what does that really mean? A few things that will be critical to this working:
- It’s an ongoing work in progress, not a finished product. But I’m publishing it in progress, not waiting until it’s done.
- It’s public. You know I actually started this as in internal blog post for my company only? Bad Bryce, Bad! (Sorry. We have a new puppy in the house…habit.)
- Many Will Contribute. That way, it will get better as it goes and hopefully people much smarter than me will contribute to it! As a result, this post will be a living and crowdsourced table of contents that gets updated to reference new use cases / behaviors / activities are developed and shared by myself or others. As a result it must be…
- Modular. This is the parent post that will define the patterns and then link to the real meat of the topic. Whether those are blog posts I write for a given use case, or one that someone else decides to contribute within their own respective blog (or elsewhere).
- Open to Suggestions. These rules. The structure of the use cases. The use cases listed below. They are all open to improvement and change. Let me have it. Let’s make it better together.
- This Should be a Wiki. I know. I know. But I didn’t have a good one set up in the public domain to start from. And I didn’t want to lose the concept before my son’s basketball game today🙂 I can see this evolving and moving to something more like a wiki format that takes me out of the role of “curator”. Once I get more time I’ll shift it to some place where we can all work on it in that form or fashion.
Writing a Use Case:
Each detailed use case should contain the following:
- Work Activity Description
- The typical / default behavior of today’s worker
- The “Working Out Loud” behavior of tomorrow’s worker
- Benefits of shifting the behavior
- Risk Considerations / Mitigation
- Real Life Stories / Examples of this “new” behavior in action. What was the outcome?
Use this definition created by John Stepper and captured on the Working Out Loud wikipedia page as a guide to brainstorming the application of the behavior to daily work activities:
“Working Out Loud is working in an open, generous, connected way so you can build a purposeful network, become more effective, and access more opportunities.”
The Use Cases:
Each use case is meant to represent a typical daily work activity.
If you have some that you think I’ve missed that you’d like added, please comment or contact me directly and I can get them added. This is a work in progress and merely a suggested starting point, including the topic groupings. As we identify and write new use cases, we can regroup and come back here and link to each individual one. Or eventually move this structure into a more wiki like structure in the not too distant future:
- Making Your Work Visible (Observable Work / In The Flow)
- Seeking an answer to a question / problem
- Answering a question directed to you about your area of expertise
- Answering a question directed to you unrelated to your area of expertise
- Creating a presentation for a team / committee / department / town hall
- Collecting team input prior to starting a work deliverable
- Creating content for a work deliverable (WIP)
- Collecting feedback on an in-progress work deliverable
- Creating content for a work deliverable (Finished Product)
- Making Your Work Visible (Narrating Your Work / Above The Flow)
- Writing your objectives
- Writing a project status update to management / customers
- Taking meeting notes
- Capturing brainstormed ideas about a project / process / opportunity
- Sharing progress / status on an assigned task
- Making Work Better / Creating Shared Value by Default / Leading With Generosity
- Achieving awareness of work outside your direct responsibilities
- Coaching people outside of your team / department
- Discovering external resources about your role / area of expertise
- Leading / Participating in corporate responsibility projects
- Contributing to the Corporate Conversation (Engagement, Activities, Facilities, Corporate Policies, etc.)
- Building a Social Network / Making It All Purposeful
- Forming and collecting a community of experts on a topic
- Connecting with fellow employees on personal interests
*Initial groupings could change or break apart. This is just a first shot at it. And we may find some use cases fit within multiple top-level categories.
I’ve spent as much time as I can spare on this this morning…but as I promised…this is a work in progress. And I was hoping to have completed at least one real use case example. But that will have to come in another day or two.
More to come! Comments for improvement welcome. And a format / structure more suitable to content crowdsourcing as well.