Tag Archives: social collaboration

Working Out Loud Behaviors to Develop during #WOLWeek

Posted on by

#wolweek

This week is going to be fun. Nov 17th through Nov 24th. WOLWeek 2014 People from all over the world coming together via the inter-webs to develop and practice the art of Working Out Loud…to improve their productivity…make connections…spark ideas…and further a movement. What a thrill it is to see the expansion of such a simple concept (When Will We Work Out Loud? Soon!) into the transition to a larger movement. Thanks to the likes of Jonathan Anthony, Austen Hunter and Simon Terry. You know that original post I wrote was posted on Nov 29th, 2010? So this version of #wolweek culminates within days of the four year anniversary of my first post on the topic. I’m moved myself reading some of the previews and set up for #wolweek:

As a precursor into this week’s activities, I would like to introduce some new classifications of behaviors that you may want to try and spread to others around you to help with the adoption and effectiveness of your own local #wol movement. I’ve taken the behaviors that I have observed in our own Enterprise Social Network (ESN) that drive the greatest success stories, and organized them in to “behaviors” that you can take and apply to your own application of bringing “social” and “sharing” into your work environment.

From Working Out Loud -> The xOL Light Bulb

Working Out Loud = Narrating Your Work + Observable Work

In the early days of trying to grasp the hows and the whys of this “enterprise social” thing, I focused very hard on the coaching behaviors of the individual, encouraging them to shift how they worked to make their knowledge, conclusions, activities and deliverables more open and visible to  others. Change you. Dare to share. Put yourself and your knowledge out there for more people to see, consume and contribute. I can even share from my own experience this past week, as I decided to put a lot of “future considerations” I was working on (but hadn’t prioritized yet) out in the open within my own organization (via blog posts, wiki pages, video demos). Via my own fears or reservations I’d been holding what I was considering close to the vest. And the return I received from sharing was immediate:

  • It provided incredible ease of educating multiple people about possibilities because I’d already captured the concepts openly (shared with people that wanted to leverage what I was working on, or people I’d need to get approval from before I could proceed with the work).
  • It helped identify new opportunities from corners of the organization I hadn’t considered…triggering their own ideas of how to leverage what I was thinking about, at a time when I didn’t know if any interest would exist at all.
  • And people openly responding with new ideas on how to apply that work that I hadn’t yet considered.

And that’s all great. Those behaviors and realization of the benefits has resonated…with some. But after a certain amount of time, I began to realize that there were other key “Out Loud” behaviors emerging by knowledge workers in our network that contributed just as much if not more to the cause than what we’ve described as “Working Out Loud”. Maybe we can call them sub-behaviors of WOL. And some of those behaviors seem to be even more natural for people to pick up as they look to leverage “social” technology to get work done and connect with others. Behaviors that seem to reduce the hurdles of being a contributor to communities & networks…more than just trying to narrate work via a blog, or create observable work by storing it in open locations that generate activity streams to interested communities. Let’s boil these down into the concept of “xOL” behaviors. At least those that I’ve observed and found to be most effective to date in my own experiences.

Are these acronyms going to get me into trouble? Hmmmm… In the interest of keeping everyone engaged the entire week, and not starting off with a 3,000 word manifesto, my plan during #wolweek will be to share a new post each day that further defines and explores each of the xOL concepts above with examples and descriptions of how they may help you personally and your organization. And maybe Friday we’ll save for a new xOL I haven’t identified yet that emerges from the sharing and conversation that takes place during the week. And we’ll see if, for fun, I can throw in a few related Spaceballs references as well just to keep the theme alive :). Stay tuned! I’m looking forward to being inspired while learning from all those that will be sharing and participating in #wolweek! *Open Leadership – Credit: Charlene Li **Open Innovation – Credit: Henry Chesbrough ***Learning Out Loud – Credit: Harold Jarche

Working Out Loud: The Use Cases

Posted on by

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.

The Idea:

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:
      1. It’s an ongoing work in progress, not a finished product. But I’m publishing it in progress, not waiting until it’s done.
      2. 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.)
      3. 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…
      4. 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).
      5. 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.
      6. 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:

  1. Making Your Work Visible (Observable Work / In The Flow)
    1. Seeking an answer to a question / problem
    2. Answering a question directed to you about your area of expertise
    3. Answering a question directed to you unrelated to your area of expertise
    4. Creating a presentation for a team / committee / department / town hall
    5. Collecting team input prior to starting a work deliverable
    6. Creating content for a work deliverable (WIP)
    7. Collecting feedback on an in-progress work deliverable
    8. Creating content for a work deliverable (Finished Product)
  2. Making Your Work Visible (Narrating Your Work / Above The Flow)
    1. Writing your objectives
    2. Writing a project status update to management / customers
    3. Taking meeting notes
    4. Capturing brainstormed ideas about a project / process / opportunity
    5. Sharing progress / status on an assigned task
  3. Making Work Better / Creating Shared Value by Default / Leading With Generosity
    1. Achieving awareness of work outside your direct responsibilities
    2. Coaching people outside of your team / department
    3. Discovering external resources about your role / area of expertise
    4. Leading / Participating in corporate responsibility projects
    5. Contributing to the Corporate Conversation (Engagement, Activities, Facilities, Corporate Policies, etc.)
  4. Building a Social Network / Making It All Purposeful
    1. Forming and collecting a community of experts on a topic
    2. 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.

Working Out Loud: What Happened to Then? We’re at Now, Now!

Posted on by

What Happened to Then? There’s a story about how I ended up in my enterprise role of change agent for Enterprise 2.0 / Social Business / Social Collaboration…whatever you want to call it.

For the first 10 years of my career at Lilly, I worked on various IT projects within the Regulatory department. And the role I typically performed best was known as “Business Integrator” or “Business Consultant.” And the biggest responsibility of that role for each and every project was to collect, synthesize and document the requirements of the ultimate business customers. We wrote these for four primary purposes:

        1. To reflect back to the business representatives that you understood what they were telling you…and had captured it completely and accurately.
        2. Requirements were the “contract” for defining how the ultimate capabilities would perform once delivered.
        3. They were intended to be THE source for the IT implementation team to scope, design, develop and test the deliverables against business expectations. Or locate and evaluate a third-party software vendor solution to get as close to the requirements as possible.
        4. And they were continually updated as a work in progress representation of the software development process as experimentation and iteration influenced changes to those requirements.

Over the years of doing this over and over, I developed my own art to being a “requirements manager,” particularly for fairly large IT systems, and eventually for projects that were evaluating and implementing third-party software packages. My “go to” method of organizing requirements into manageable chunks was using use cases.

To make a short story long, my methods began to draw some attention across other departments within the IT organization. People from other programs were wanting to my ideas and mentoring to replicate what we had done for their large scale IT programs. They wanted their people to learn what I was doing and how I was doing it. I was swamped.

We Just Passed Then! This was taking place in about 2007 / 2008, coinciding nicely with the time that our IT organization had just implemented a new “large scale enterprise collaboration suite.” As I explored what the new collaboration suite could do, I saw something that could help me better scale my knowledge sharing. Profiles, blogs and wiki libraries…oh my! It just clicked…

So I started blogging as I worked on projects. My thought processes, my tips and tricks, sources that I used for inspiration. I started using wiki pages to capture and get feedback on requirements instead of monolithic Word files. And occasionally instead of replying to an email request for someone, I would write a blog post and reply to that person with a link to my new blog post. And I set the security on all of that to be wide open across the entire company so others could see it and learn from it. I helped organize a “community” of business consultants that met once a month, brought in teams to share their stories and regularly presented to the members myself. But I also taught them how to follow along with and interact with my blog to keep the learning going between the meetings.

Then more and more requests for my time started coming in. New opportunities to consult for and lead larger IT-wide initiatives. Getting to present in front of the entire IT org at town halls or in senior leader committee meetings about updating our long standing software development lifecycle standards and implementing new requirements management training programs. Phone calls and e-mails and blog comments from people I’d never met asking me for help or thanking me for what I had shared. People asking me how to set up their blogs and wikis to look and operate like what I had done with mine.

I realized that there was a new way to work…and my mission was no longer to help my IT peers with requirements management. It was to be a Change Agent that would help all of my Lilly peers learn how to Work Out Loud on any topic of expertise. It had amplified my own reach and productivity, why couldn’t it do that for everyone?

When Will Then Be Now? By the middle of 2009, I had accepted a new role to take availability and adoption of our enterprise social capabilities to another level and begin teaching people all over the company the behaviors of “social collaboration”, aka Working Out Loud. And it’s about that time the practice starting becoming clearer to me and led to blog posts such as this one: When Will We Work Out Loud? Soon! 

Soon! I’m writing this story because this morning I had an idea. I’m going back to my requirements management roots (use cases) to help further the understanding and practice of Work Out Loud behaviors, in concert with and to complement the amazing work that John Stepper has shared of late: The 5 Elements of Working Out Loud.

I’m going to dig deep into my old methods of requirements use case modularization and topic hierarchy to capture the key behaviors of someone that works out loud effectively, including what one would need to shift from traditional behaviors to these new behaviors. And I’m going to build it in the true nature of Working Out Loud.

We’re At Now, Now! Click here to see my next blog post putting that idea into action…and to contribute and participate if you wish!