Asking Out Loud #wolweek

During the countdown leading up to #wolweek, I wrote this post about some additional Work Out Loud behaviors to recognize and practice. Let’s dive deeper into one of them.

Asking Out Loud = Reuse Awareness + Expertise Discovery

asking for help

Many moons ago as we were trying to increase adoption within our ESN, it didn’t take long for a trend to emerge. We didn’t limit what types of communities people could create. We wanted creativity and need to be easily met with a low barrier to entry, and that helped us to identify the greatest areas of opportunity in the organization where “social collaboration” could improve work outcomes.

The most common early trend was that communities were popping up for the sole purpose of collecting a critical mass of experts on a given process, practice or technology…that other people could then use as a place to post questions and get fast answers. Created as an alternative to sending email blasts, battling search engines, calling a help desk, screaming over cube walls, or desperately walking around department floors holding a sign that asks for help.

People started to realize that using these Q&A communities to ask their questions resulted in new outcomes vs. more traditional work methods:

  • Shotgunning the request into a community instead of targeting it to a bottleneck process usually resulted in a faster answer. It removes the problem of being stopped in your tracks by “Busy” or “Not Available” experts.
  • Those looking for help could keep working on other stuff while waiting for the answer to arrive because it is an asynchronous interaction. Whereas many other methods (aside from email) are synchronous and kept them from making progress on other work while they problem solved.
  • For the benefit of the experts, capturing what they know IN THE OPEN makes the outcome of the interaction reusable for others via search or references. And could potentially deflect future requests that come their way…so they can be more productive later! Not to mention the potential recognition and open tracking of what they’ve contributed to the organization (personal reputation management, performance management, etc).

But for this to really work, congregating experts into the proper communities wasn’t even half the battle. There’s a behavior to instill in everyone else within an organization that’s even more important to making it successful.

Asking Out Loud.

The key was teaching people to change their behaviors to recognize an opportunity for Asking for help Out Loud vs traditional hunt and seek methods. Let’s dive into the formula of key Asking Out Loud behaviors:

  • Reuse Awareness: The ability to identify an opportunity, when searching for something or troubleshooting a problem you are experiencing, where the answer / solution has value beyond yourself. Because it’s the people that identify this opportunity, shift their behavior from the old way, and initiate the open interactions that will lead to newly captured knowledge that make this behavior click. Where Working Out Loud as a concept recognized the sharers of knowledge, Asking Out Loud recognizes the value of the people that admit they don’t know something and make the decision to initiate their request for help in a way that will result in shared and reusable knowledge.
  • Expertise Discovery: There are really two parts to this. First being the skill to identify the right context and/or community to leverage for “Search Then Ask” activities. Specifically when asking a new question, understanding which online audience to target to maximize the chances of reaching engaged experts that can either answer the question or lead you to someone that can. The other is knowing how to effectively search, filter and browse existing knowledge stores of openly shared information before asking a new question which may have already been answered.

So while recognizing those that are Working Out Loud and show up as prolific sharers in your online communities, make sure to give just as much praise (if not more) to those that realize the value of asking for help through open and “social” communities. Because in many cases…if they’d never asked…the knowledge would never have been captured.

Advertisements

Working Out Loud Behaviors to Develop during #WOLWeek

#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

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!

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!