Enterprise Humility

Photo by Eric Ziegler

Enterprise humility is extremely important. But enterprise humility in many companies is very difficult. Think about it. How many people are truly humble? I know that I can show humility and be humble. But I know that I am not humble or show humility in all situations. I can think of many situations where people have come up to me and pumped me full of stuff that made my head 10x's bigger. While I might not be humble as often as I would want to be, I do embrace humility and the humility that I show has served me well, allowing me to listen to others, respect others, which has turned into others listening to me and respecting me. If individuals struggle with humility, what is the likelihood that enterprise show humility?

As an organization, enterprise humility is about respecting the employees, accepting that your employees will make mistakes and encouraging them to learn from the mistakes. Enterprise humility is about encouraging employees to share, work out loud (#WOL) and try "things" that are risky but within some defined set of rules. If an employee is able to make mistakes, it enables them to push the limits of what is possible. They will learn more. The will grow faster. The company will be more effective and be more successful. While there might be a step backwards when a mistake is made, think about how much faster they will go when things don't go wrong. And if that happens, think about the impact it will have on the company.

Leaders play a huge part in humility in the organization. Leader humility is about enabling others to learn, grow, and be independent. If a leader is humble enough to let others build on their ideas and to step in to fill in gaps they all will grow. Leaders must be open to allowing their employees to make mistakes and if a mistake is made, not put a new process in to ensure that mistake never occurs again.

An organization needs to embrace humility and encourage people to be humble. Humility in the enterprise is important to ensure diversity of thought and the refining of ideas by all employees. Humility is important for innovation. Humility is important for engaged employees. Humility is important for driving business value.

To put it bluntly, an organization that does not embrace humility, is an organization that is not as effective as it could be and has a higher chance of failure.

Declare Victory!

Photo by Eric Ziegler

How successful are your enterprise social software implementations? If you are like me, I believe that the success of an implementation is never actually complete until well after the initial implementation and roll out. Why? Let me ask the question, do you believe that if you build it they will come? If you do, you will most certainly #fail.

While there is some truth to the idea that if you build it, they will come, I really question how many "they" actually is. Your early adopters will show up, but what about the quick followers? Or the lagging followers? Quick and lagging followers only come when you build it in the rare occasion. The issue is that they often can't see the business value that the social software provides. They don't see how it could improve the way they do their job. They don't realize that sharing openly, working out loud and collaborating in a social manner are ways to build a career that is much bigger and longer lasting than the age old ways of working.

Since success can't be declared immediately, how and when can you determine success and when can you declare "VICTORY"? I believe that some of the best ways of determining success with social software is based on the great stories of individuals, departments, groups, and divisions. How has the social software impacted them individually? How has the social software impacted their department and provided business value? How has a group used the social software to resolve an issue or implemented a new idea? How has the social software changed how the sub-division or the division communicates (e.g. is the communication two way vs. the traditional one-way communication)?

While each story gathered will be unique, the stories are great ways of getting across to anyone that asks why the software is a success and then also gives them ideas on how to use the social implementation for their own success.

How about sharing some of your stories of success?

Rewarded for Good Behavior

Photo by Eric Ziegler

In my last post, I talked about removing an expert from a team to make the team more effective. Obviously, the wrong behavior from an expert can be bad for a team. But not all experts are bad for a team and not all experts exhibit bad behaviors. In addition experts are definitely not bad for organizations as a whole. And that is what this blog post is about - experts rewarded the right way can be invaluable in an organization.

Employees are often rewarded for being the expert at something - Java development, financial analysis, trader, vendor product integration, sales person, etc. The question is, how are these "experts" rewarded. Does the reward influence behaviors and make the individual better, the team better, or the company better? Ideally the reward is influencing to have a positive impact on the individual, the team and the company. But more often than not, the reward is not given as a reward that enhances the team or the company directly and is directed at the individual. In some cases, these rewards could have a negative effect to the team or the company.

Rewards are often given to the expert for some type of heroics. Saving the day when the system blows up or bringing in the big dollars at the end of the quarter, or delivering functionality after spending 20 hours one day implementing or delivering on a major project. It is easy to find reasons to give rewards under these circumstances. But experts are much more valuable to an organization than heroics and rewarding employees and experts for the material things we see everyday.

Experts and employees can provide much more value in an organization by sharing their knowledge and information about their expertise. They are much more valuable when they help others, educate others, and coach others. And experts should be rewarded for these good behaviors. Experts and employees should be rewarded for sharing their knowledge to their team and rewarded even more for sharing their knowledge to other parts of the organization.

Enterprises typically do not have reward systems in place that account for the team sharing or the organization sharing. In addition, there are little to no expectations set by organizations for employees to share. While rewards and expectations are great, there is another issue. Employees are not provided any guidelines on what, how, when, where, and why to share. Employees are also not given any guidelines or expectations on who to share information with. Even if an organization has rewards for this type of behavior, without help, the employees will flounder and in some cases share in ways that are not as effective as possible.

As organizations change and start thinking about how their employees can share information more freely, they will need to not only setup expectations they will need to tell the employees what sharing looks like so the employees can mimic these good behaviors. Lastly, to reinforce these good behaviors, a little reward does not hurt.

Who moved the expert?

Photo by Eric Ziegler

You are the manager of a team. Your team is good at what they do but you believe they could do even more. They are just not clicking and getting as much as you would have expected. As you review how the team is doing you also notice that some of the employees on the team are not learning the material / topic / technology / etc. as well as they could. If you were to characterize the team, you could almost say that they have stagnated their knowledge grows slowly, and they appear to just walking aimlessly through each work week.

As you start to observe the team closer, you realize that one person is viewed as "The Expert" on the team and everyone on the team goes to this one person for support and direction. While this does not happen in every situation, it happens in so many situations that you realize that "The Expert" is considered by the team as indispensable. "The Expert" is invaluable and the team raves about the person. The Expert is the go to person and answers all questions, helping the team get to a solution quicker.

But how invaluable is "The Expert" really? How indispensable is "The Expert" really?

If you remove "The Expert" from team, what happens? Do new people step up and become an expert? What are the short and long term implications to doing something like this? Short term things slow down, no doubt. But long term, do people start to step up, do they start to lead and does the expertise that was with one person start to be dispersed into the team? Does the team get smarter and the team starts to click like a well oiled machine, getting more done than when "The Expert" was part of the team?

Is removing the expert from a team a risk? Absolutely. But, remember, it is a risk to not make a change also. The risk is that the team is not growing, learning, and being as effective as they could be as a team.

Working Out Loud Requires being Vulnerable

Photo by Eric Ziegler

I love listening to Podcasts. I listen to podcasts when I drive to and from work. I listen to podcasts when I am on a long drive - 6+ hours. I listen to a broad spectrum of podcasts: Football (soccer), Finance, Economics, News, Public Radio, Social business, etc. This weeks blog is prompted by a one episode I listened to recently from the podcast Shift, by +Megan Murray and +Euan Semple.

The podcast I am referring to is episode 21, about Vulnerability. As I listened to the podcast the first thing that popped into my head was that Working Out Loud (#WOL) requires you to put yourself out there and to be willing to be vulnerable. When I think of working out loud, I think of people sharing what they are working on, asking questions, asking for input on a project, takling about an issue you are trying to resolve. In each of these situations you are risking that someone will think less of you. You need to be vulnerable to do any of those things.

People are scared of putting themselves out there and working out loud. They are fearful that there will be negative repercussions when they make a mistake out in the open. They are fearful that people will think less of them. They are not willing to risk sharing because there is no benefit or that other people will not find what they are sharing as interesting or informative.

The opposite is true. Working out loud has so many benefits and everyone should be doing it within an organization. People will learn and grow quicker and faster by working out loud. Organizations are more effective when people share and are open with each other. The likelihood of finding a piece of information increases as more and more people work out loud. People learn from each other only when information is shared. People improve and innovate on ideas only when ideas are discussed openly. By working out loud, your chances of getting the best information, in timely manner goes up tremendously. Even if a conversation happened out loud months ago, finding that piece of information increases because it was stored for others to discover, read and learn from.

So be brave, take the challenge, work out loud and be vulnerable.

Working Out Loud can not be Automated

Photo by Eric ziegler

Not sure how I ended reading an old post by +Bertrand Duperrin but I did.  Maybe something was calling to me.  Maybe it is just purely coincidence that I re-read his blog post. Either way, it has triggered me to write a blog post for the first time in several months. Let's dig in.  

Bertrand Duperrin, posted a blog post back in August of 2012 called Employees don't have time to waste narrating their work. What caught my eye originally was the title. First reaction, huh? You have to be kidding me. Bertand might be just trying to be sensationalistic with his title, I am not sure.  But it did catch my eye and cause me to read his blog post. While the title is interesting, I have to say that the blog post hits a nerve. Bertrand starts his blog post with a concept that I agree with ...

It’s impossible to think about emergent collaboration and self-organized structures without visibility on others’ work. 

This first sentence makes me think of +Change Agents Worldwide (@chagww, #CAWW). Why?  #CAWW is a self organized emergent collaboration organization that is about helping individuals, teams, companies, employees, etc. be more effective.  #CAWW works as a network of individuals that interact, share, and cooperate and collaborate on different topics and ideas, always trying to improve upon ideas that will help organizations be more effective. It is almost like he wrote this sentence with the concept of #CAWW in mind. 

In Bertrand's 3rd paragraph he continues down the same path by stating ....

collaboration, cooperation, problem solving and even innovation requires something to be shared so trigger the dynamic. Moreover, people often don’t realize they can be helped : sometimes we believe we’re doing right while we’re doing wrong, we’re doing right while we could do better, differently.

While the first sentence could be interrupted several ways, this statement does not align with the title at all. Only after you get more than half way through the blog post do you start to see where the title becomes relevant.  I believe this statement best summarizes the rest of the blog ... 

if people’s work’s worth being narrated, people should not always be the narrator. Their time is too precious to ask them to play the role of transponders. 

So now I get it.  People's time are too important to waste on working out loud (#WOL).  Bertrand continues and discusses the idea of having systems do the narrating by automatically creating activities in an activity stream - weekly reports, updates to profiles, etc.    I understand where he is going, but I think this concept misses the importance of working out loud (#WOL).

What do I believe? The idea of working out loud is not about the automated interactions? There is some value, but the biggest value is sharing information in a way a system can never do. Sharing information includes asking questions or putting a thought out that could trigger a thought by someone else. Automatic system updates are too prescribed to cause an emotional reaction by the receiver and bacause of that, the value it just not as high.  

I will say though, I do agree with his concept of having people jump out of their every day work systems to work out loud is not effective. To get people to be most effective, the system to work out loud needs to be integrated into the systems they work in every day.

Automatic system updates are the antithesis of what social networks are about. While an automatic update might provide value, they do not deliver come anywhere close to providing the same amount of value as working out loud.

Incent to Share

Photo by Eric Ziegler

Your company doesn't share information.

There are silos in your organization.

Each silo is not interested in helping the other silos.

Enterprise Social tools are integrated into business tools

Enterprise Social tools are still not being used.

Why is it not working?

Culture culture culture.

Technology is not what wins the battle, change and culture, that's what's needed .

Find the incentives for people to share.

Classifying a Community

Photo by Eric Ziegler

Defining categories of communities can be done in many many different ways: e.g. by size (small, medium, large, humongous), types of people in the community (internal employees vs. external clients vs both), etc.

There are so many different types of communities that to be honest, it can scare away even the hardiest of requester for a new community. Last week I talked about the first step that must happen with requesting community managers, setting expectations. Inside that post, I mentioned that some well intended requests come without knowing much about what a community could do for them. So to help them understand what is available, I have often used the following examples to help the types of communities they could build

1. Pushy Community - Not much of a community, but still there is the need for them in enterprises (hopefully rarely). Success is defined as people reading the information) 
2. Interactive Pushy Community - This is the first real level of a community, where the push of information is accompanied with the ability to like, rate, and comment with the posts. The community can't post new messages, but they can interact with what is posted, allowing them to engage with the content and the content creators. Success is defined as people read the information and interact and engage with the content. 
3. Interactive Community - The community is built so that the community members interact with each other, collaborating on documents, asking questions, getting answers, and sharing information with each other. Sometimes email is used to get the community re-engaged or to get the word out on the most important of information. The success of the community is defined by people almost fully interacting and engaging in the community and occasionally relying on tools outside the community to interact with each other. 
4. Collaborative Community - The community is built so that the community members interact solely using the collaborative tools available, collaborating interacting, engaging with each other within the community. Success for this community is when the community members use the tools available to exclusively collaborate with each other and do not use external tools to collaborate. (e.g. no email).
5. Inter Collaborative Community - The community is built much the same way as the collaborative community, but instead of just collaborating within the community, the community members collaborate inside the community and with other communities and groups. This community knows they are successful when each of the community members are always using collaborative tools in their day to day interactions. 

You can classify communities how ever you would like. In the above examples, I have laid out some examples of types of communities and how the communities would work, with the hope that when I describe these to an unknowing new community manager, they can pick a type and drive their community to success. 

How would you classify communities to a new community manager?  Would you use the same descriptions or would you describe them differently?  If you used the above example, would you add or subtract from the list?  For each of the above types of communities, what would you say make these communities successful? 

Setting Expectations

Photo by Sarah Ziegler

A friend and I were recently talking about adoption. Specifically we were talking about the adoption of tools that help build enterprise communities. One idea we discussed that I haven't read that much about is:

        Setting expectations.

While I know this idea is not new, I have not heard much about the use of setting expectations for Enterprise 2.0 or Social Business or adopting enterprise social networks. For example, as a people manager, if you have read it once, you have read a million times. To help guide your employees to ensure they know what to do, you need to set expectations with your employees. If you don't the manager is at a higher risk of not getting the best performance out of each employee.  This is an oldie but goody. But why don't we use this same idea in the enterprise for adopting enterprise social tools?

I find that for some people, they just want to create a community because their peer has one (the me too syndrome).  Others have good intentions but don't know where to even start to build a vibrant community. In both situations, neither have defined what expectations they have for their community. In both situations, instead of just allowing them to create the community and have it fail, the requester needs to clearly understand their goals so they can use the technology to meet their goals.

So, step 1: get the requester to define their hopes and dreams for the community they want to build.  Have them define how do they see the community working. Have them, articulate what their goals are for the community.  Work with them to design how the community will work. The key to the success, is to get them to set their own expectations for the community and then have them work to have their community meet that expectation.  

While setting expectations are great for the community, one of the keys to ensuring the community is as vibrant as desired, the community manager must communicate what expectations they have for the community to the community. In addition, as the community grows, the community manager must influence the community to meet those expectations, while being willing to reset their expectations and adapt to how the community grows.  

Setting expectations are crucial, being influential and flexible is equally important.  But then again, isn't that the recipe for success in almost all situations?

New Dogs, New Tricks

Photo by Eric Ziegler

I read a quote recently in Harold Jarche's post, "Old dog, new tricks"t .  What caught my eye first was the quote from Euan Semple's blog post, "Old folks and shiny things". Euan states: 

Senior folks have seen technology hucksterism too many times before to fall for hard sell, but equally more and more of them are becoming aware that, partly thanks to the internet, things are changing as never before. They know that they need to get their heads around what is happening – even if they decide that active engagement in it isn’t right for them or their organisations. – Euan Semple

Of course I kept on reading, intrigued on where Harold was going. Harold follows up the quote from Euan with his own example.

After a presentation to the Conference Board of Canada’s HR Executives Forum, a senior VP told me that there was no way some kid was going to advise him on social media. However, he was was willing to listen to me, as I was in my fifties, seemed to understand his situation, and didn’t make him feel uncomfortable. I think there is a great need to teach old dogs new tricks, especially senior managers and executives – my generation.

What I find so interesting is that in some recent experiences, I have found that the 30 and younger crowd is sometimes equally hesitant to use some of the latest tools, especially within the enterprise. In addition, I have found that the 40's and older group is quickly picking up these tools and using them effectively.  

As I encounter these reverse stereotypes, the question that I continue to ask is, no matter who the person is, where they come from, what their position is in the company, and what type of job they do, how do we help them turn the corner to realizing the power of social in the enterprise?