SEO won't fix a site that sucks

Photo by Eric ziegler

As I stated in my last post, my plan is to regularly post short little notes I created as I read books. My expectation is that the posts will come in spurts, based on my ability to find time to read the book I am reading. As you will find, my notes are typically caused by the book and are not notes directly of or from the book. 

A couple of ground rules. I will always reference which book I was reading which caused the thought. If I can, I will reference where in the book I was when I wrote my comment, but there are times where it just does not make sense and the only reference you will see is to the book.  The notes I am posting could be as short as sentence or they could be longer. I will not be posting more than one note a day, but there could be many days between posts.

This comment was inspired by  +David Amerland 's book, Google Semantic Search

Remember, if people find the site through search or other means and the site sucks, you are going to do more harm than good. 

Collisions of Change

Photo by Sarah Ziegler

I have been in the midst of several small changes recently. I have a new position at work with new responsibilities, I have realized the beauty of using a task oriented system to keep me organized, and I have gotten back to reading both for pleasure and for growing my mind.

These last two items are colliding in a great and spectacular way. Well maybe that is a little bit of an exaggeration....  What I mean is that with my reading, I have found that taking notes has done me wonders in helping me think through the thoughts that come up while I read them. And my method of taking these notes have caused them to start showing up in my task management system. My intention is to share these notes on my blog as a form of #workingoutloud (ala +Bryce Williams and +John Stepper of +Change Agents Worldwide ).  

The goal is that if I share these out loud, others might learn from what I see within the text and what I see beyond the text.  Hope you enjoy the series.

-eric

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?