Archive for the ‘Productive Collaboration’ Category

Why Can’t We Just Get Along

Thursday, April 12th, 2007

Is it that the Iraq War has made Europeans dislike North Americans, or is it that North Americans feel that they only have the right answers? I am not quite sure, and recently I have been involved in a Battle Royale. I am talking about a large software company where both sides have acted like school children on the playground. In this corner, North American sales team. And in this corner the Rest of World sales team. Let’s come out fighting fair.

But they aren’t fighting fair. Both teams have lied, cheated, and stolen opportunities from the other. Can this go on? What is the cause? Is it just about the wallet or is it about power? Is it that the compensation model is broken, or is that there is a lack of leadership or not enough negative consequences to change behavior?

The history between senior executives is literally hostile, and brokering an agreement can’t currently be done with both of them in the room. Getting to the VP’s and Directors has been difficult because of time constraints and the pressure being put on each team at the top.

Being the facilitator is exciting because our rule is simple – brutal, and I mean brutal honesty!! Defining the rules of engagement will take hard work and deep understanding of emotional intelligence and defining the social complexity and mastering collaborative communication (if it even exists).

We have now had two meetings where no punches have been thrown and we discussed the social complexity that exists and the organizational constraints that limit collaborative interaction. Getting everyone to talk about the obstacles is progress. 

I would be very interested in hearing what others have done in similar situations.

Crucial Conversations

Monday, April 2nd, 2007

I was reviewing the February 8, 2007 Silence Fails data today. Over 80% of people are engaged in at least one significant organization wide initiative they know will fail to achieve the advertised results. Let me say that again.

Over 80% of people are engaged in at least one significant organization wide initiative they know will fail to achieve the advertised results.

60% of the people don’t believe the important issues have been discussed.

On projects that have failed, 60% knew it would fail right away or shortly into the project and 90% of the people new half-way into the project.

In over 80% of the cases, the project could have been gotten back on track if changes had been made. In 70% of the cases people tried to get to the person that could make the change but were unsuccessful.

We know from reviewing past research that most projects fail to deliver the promised results. The thing is, the people on your projects know before it happens, and in most cases while there is still something to be done about it. Why aren’t we having these conversations in our organizations.

For the most part, because no one is asking. And if someone tries to bring it up, no one is listening. We punish people for bringing bad news or being nay-sayers. We think they don’t understand the problem.

We need to learn to listen. How should we listen. As usual, Hal Macomber is out ahead of this issue in Revisiting Two Great Wastes.

Here’s one thing to remember. Adopt an unconditionally positive stance when speaking (and listening). Operate from a concern for keeping the promise of the project. When you take care of the client and the promise(s) you made to the client you can’t go wrong. Don’t attack people. Instead, express your concern or worry that continuing on the current path might lead to failure. And if you get chastised for speaking up, then you know you are on the wrong project.

Organizations, the initiatives to create change, are getting more complex. At the same time, the rate of necessary change is increasing. Isn’t it time we learn how to listen in our organizations?

What will you be doing in 10 years?

Friday, March 30th, 2007

Once again, Tom Peters provides inspiration for what we are trying to do at Synaptus. In his post yesterday Now Don’t You Worry Your Little Self…,  he raises the alarm about 40 million jobs moving out of the US in the next 10 years.

40 million jobs, is that a lot? According to the Bureau of Labor Statistics there are about 150 million Americans in the work force. 40 million jobs moving overseas is over 25% of the jobs in the US. What could cause this to happen?

China has 798 million people in their labor force. India has 509 million workers available in their labor force. Their real wages are far below the US and Europoe. As education rises in these countries and communication technology improves, businesses will move work to where it can be performed well-enough at the best cost.

Stop and think about what this means. The way companies do work is going to change.  We are just entering the knowledge-based, or project-based, or information-based world. My kids will be entering the job force as this world becomes predominant. It took 50-100 years to get really good at managing industrial based organizations. The businesses and individuals that figure out how to thrive in this new world of work are the ones that will survive and grow.

Aligning a dynamic organization with strategy, understanding and improving processes across your business (regardless of your organizations boundaries), productive collaboration, talent management, and project management become key skills to build and manage organizations that will thrive now and survive in future.

The ability to gain competive advantage from these shifts, both for you and your organization, is there today. On the other hand, 10 years is a long way away. You can wait for someone else to figure out how to run businesses profitably and manage the new workforce. I chose not to wait. What will you be doing in 10 years?

Business Architecture, isn’t that technical

Thursday, March 29th, 2007

In our e-zine this week, we published an interview with Ric Merrifield at Microsoft. The subject was Business Architecture. It wasn’t well received by some of our subscribers.

Microsoft! Business Architecture! Heck, if I wanted to read technical stuff I’d subscribe to Joel Sposky. I had three people unsubscribe to the e-zine over straying away from business and into this technical area.

But business architecture isn’t technical — and Microsoft is very interested in the business models of their clients. It helps them provide better solutions than just pushing software out the door. But when you hear the words Microsoft and Architecture together, you mind jumps to technology. You bring a specific background of obviousness to how you listen to everything after that.

Ted Walls and David Walden discuss the problem of different backgrounds of obviousness in Understanding Unclear Situations and Each Other Using the Language Processing Method

"Unfortunately, however, when two or more people are trying to understand, discuss, and act on a complex business situation, the fact that each person has a different background of obviousness and therefore reasons differently can lead to confusion and unproductive effort. We talk past each other."

We participate in different conversations in different ways. Based on how we participate, we may we decide to listen and interpret the information differently. The situation, certain words, how someone looks, the location, and our prior experience can all trigger the way we participate. I am participating differently with my 11-year-old daughter than I am with a senior executive.

Based on the trigger of Microsoft and Architecture, the subscribers came to the conversation with a preconception that we were talking about something technical. We were talking about a way to develop a common understanding of an organization’s business model. This is important when you are trying to align people, process, and technology improvements with the strategy of the organization.

This break down happens between different functional areas all the time. People stop listening to things they could understand because they choose to participate in a way that keeps them from understanding. It is the responsibility of both parties to get past this problem.

Are there words, or situations, or people that trigger a specific way of participating in conversations with them? Does your ability to comprehend someone break down based on different backgrounds of understanding? Pay attention to those situations where you are participating in a way that is unproductive. See if you can shift to a more productive way of listening.

What are the new key skills for IT

Friday, March 16th, 2007 points to an article on that talks about the rise of relationship management skills over technical skills in IT organizations. This is driven by the automation and outsourcing of IT capabilities. The IT employee of the near future will be more likely to be handing customer service requests and managing vendor relationships than plugging in hardware, installing or configuring software, or writing code.

“Morello said IT organizations will become increasingly automated and outsourced. As a result, IT employees will be asked to fill multiple roles, rather than just focus on a single job. And one of their most important roles will be managing "points of interface" with other parts of the business. “

“IT employees will need to speak the same language as business stakeholders. This means less demand for specialists (IT employees with a deep understanding of specific technology) and generalists (IT employees who have a broad set of relatively shallow technology skills). IT will still need technical skills, but the most valuable technical employees will know how they can apply those skills to different situations in different parts of the business.“

So project management, collaboration, and customer service will be the key capabilities of IT. And new capabilities to create a common business framework to focus and align a distributed organization will be necessary. How many of your key employees are being hired or developed with these skills in mind? What framework are you putting in place today to create a common understanding of what the business actually does?

Agile Management

Wednesday, March 14th, 2007

David Anderson over at Agile Management has a series of posts about HR Myths. David blogs on software development, management, constraints, and agility. I come from a technology development and implementation background so I may be biased. But, I believe that the software industry is one where the impact of knowledge-based work, the transitional worker, outsourcing, speed, and unique customer requirements have all coincided over the last 10 years. Since many other jobs will begin to fall into this space over the next decade, I think it is critical to learn from what has worked in the software industry. Here are some HR policies that David has identified that make working in software development more difficult.

In HR Myths #1: Merit Based Pay, David discusses why it doesn’t make sense not to hire top quartile performers, something pay bands make difficult.

"We don’t care about productivity look at our cost control"

Top performers may be 10-20 time more productive than mediocre performers. Yet "companies which claim to be meritocracies, in fact, are not. They pay people in a very narrow band. In my example, you can be sure that everyone on that Level 56 grade is being paid between $27,000 and $28,500 despite the fact that some of them will be 10 times more productive than others."

Focus on "productivity first, investment second and cost last. Cost first generates mediocrity and mediocrity results in very poor performance from a software engineering organization"

In HR Myths #2: Divide and Conquer, David discusses how HR departments practice of negotiating pay down at hiring time, restricting the ability to reward performance after hire, and then hiding how much everyone makes to avoid conflict, may be counter productive.

"In almost all companies it is directly against company rules to discuss what you – the knowledge worker – are paid with your colleagues. Why? Simply put, it is a divide and conquer strategy by Human Resources. They believe that by enforcing silence with a threat of summary dismissal, they will save the company money and reduce complaints from disgruntled employees. In a few companies, it is also illegal to discuss your pay scale grade with other employees. This is the ultimate in Big Brother style control because it theoretically prevents employees from learning that someone doing the same work is on a higher grade than them. HR believes that this enforced silence reduces complaints, saves the business money and makes employees happier."

HR Myths #3: Performance Buckets

"The first fallacy is the concept of an equal distribution of performance across a team – someone has to get a 1 and someone has to get a 5. The idea is based on the statistical bell curve normal distribution. However, when your statistical sample is (for example) less than 20 then any statistician will tell you – you do not have a basis for a normal distribution.

The second fallacy is that all teams perform equally and that someone from every team deserves a 1 and that equally someone from every team deserves 5."

In HR Myths #4: Tribal Markings, David discusses how companies make temporary workers feel inferior and how it can impact group performance.

"Why do HR departments insist on issuing different colored badges to contingent contract labor and vendors on long term contracts? It’s clearly tribal. It clearly marks the individual as somehow less worthy. Why? The assumption is that temporary staff are less trustworthy. Hmmm. This feels that it belongs in medieval Japan’s early Edo period where Samurai without a master – ronin – were treated with suspicion."

In HR Myths #5: Pay for Performance, where David discusses the issues associated with pay for performance that can lead to reduced organizational performance.

"Pay for Performance can lead to dysfunctional behavior encouraging individuals to look out for themselves and discouraging team working that enables higher productivity from the whole team."

Read all the entries if you have the time. The issues facing technology development are people issues, not technical issues. Equitable compensation, temporary workers, and uniquely skilled workers are issues increasingly faced outside of the technology sector. It sure makes sense to learn from the really smart people in an industry that has begun to figure this out. It isn’t true that life is different in technology so those lessons don’t apply to us. We can apply the lessons throughout most organizations. Which of these myths are impacting the performance of your organization?

Talking about what we’re talking about

Tuesday, March 13th, 2007

I think the conversation theory post may have been a little dry. It all sounds so theoretical. It’s so far out there you may be wondering how can it be applied in business. So here’s a a couple specific examples.

We had a client that had five IT departments, one to support each line of business. Each group believed that their business was so unique that they had to have their own support groups. The CIO of the company thought that there was probably a lot in common between them, he was just struggling to get everyone on the same page. Everytime they tried it would break down in a defensive battle. With some of the executives from the operations group, we helped facilitate the development of a common semantic model of the businesses. We started with some clearly common concepts and worked our way through the business. At the end of the effort, management reached an agreement that about 80% of the business models were the same. Working towards developing a common background of understanding, instead of defending a previously established set of concepts, led to a breakthrough for the business. We talked about what we talked about, and common understanding became explicit, rather than each person defending how their view of the world was correct. Combining common technology and functions saved the company millions of dollars a year. The added organizational agility and synergy probably contributed to the massive growth the company experienced over the next two years.

A software development group was struggling to get what product management was promising to the customer in a timely fashion. There was a lot of conflict and frustration. Customer commitments were consistently missed. Working with key people in development and product management, we worked our way through how work was coordinated, how commitments were made, and how understanding was established between the customer, product management, and development. We identified the key points that were leading to waste, quality problems, and rework. Then we talked about the conversations that were leading to those breakdowns. The rate of work through the organization doubled in just over four weeks. We didn’t change any people or technology, we didn’t cut any scope. We spent time talking about what they talked about to make the conversations more productive.

These are not isolated circumstances. This is how people interact. When people from different backgrounds or with different roles get together, they participate in a way to justify their groups norms. When these norms get in the way of successfully moving work through the organization, these problems tend to go unexplored. Because talking about what we talk about is considered threatening, too touchy-feely or too theoretical. I believe there are huge returns for addressing this situation. Look around your organization, do you think the returns are there if there was a way to address it? What would it take for you to start talking about the conversations in your organization?

Conversation Theory

Monday, March 12th, 2007

Gordon Pask (1928-1996) was a psychologist who contributed an important theory in the area of instructional psychology. So why do we care? The theory is called Conversation Theory and the fundamental idea is learning occurs through conversations about a subject matter which serve to make knowledge explicit. Due to the pace of change and the high level of service demanded by customers, learning in organizations is becoming more and more important. So, there are three interesting concepts I want to discuss about Conversation Theory that apply to how businesses works today.

First, knowledge is not explicit until both people understand it. That sounds circular, but its important to think about this. Whenever two people are talking they come from different backgrounds and experiences. Since everything we learn is informed by what we already know, then if we don’t share a common history,  or common background of understanding, then we won’t have the same understanding of what we are talking about. We call the common background of understanding "group norms". When someone from outside the group tries to participate in a conversation, they might not understand all the implicit concepts that the conversation is built on. You will see this whenever people from different specializations are dealing with each other. Sales doesn’t understand the field. The field doesn’t understand IT. IT doesn’t understand Finance. Instead of forcing the other participant to understand something "obvious", take a moment to understand why it isn’t obvious to the other person.

Second, concepts build on each other. You can’t force the next concept until a dependent concept is understood. When Frank, the best man at my wedding, was trying to get his four year old daughter, Devon, to learn French, he had a teacher walk her around the neighborhood. The teacher walked around saying, "The French word for tree is [whatever the French work for tree is]." "The French word for house is …" She spent about 30 minutes going through this with Devon. When they finished the walk, the teacher asked Devon if she had any questions. Devon responded, "Yes. What is a word?" The lesson was lost because they didn’t share a common context for knowledge to become explicit in. Looking for what is not explicit in the background of understanding is a key step in resolving many conflicts and breakdowns in organizations.

Finally, Pask says we participate in different conversations in different ways. So we participate in conversations differently with our children then we do with our business partners or the rude person in the parking lot. The way we participate has to do with what we have seen or experienced as successful in other conversations. What’s compelling here is that very few people take anytime to understand how they are participating. So while we might choose a way of participating that is in the best interest of the situation, we might not. If I had a dollar for every person who said, I can’t understand this because I’m not technical or I’m not for the field I would have a lot more dollars that I do. They are making a choice to participate in a way that they prevents knowledge from becoming explicit. Understanding how we and others are participating in a conversation has a lot to do with how successful the conversation will be.

As you run into situations where there are breakdowns in communication, problems with understanding, or conflict between individuals, apply these two concepts. Instead of driving the "obvious" point home of assuming the other person is stupid is will never get it. As you work in your job, look for what is not in sync in the common background of understanding, try to understand what concepts are needed and relevant to make the point, and practice participating productively. With the growth of diversity, rapid changes, and the integration of concepts from multiple fields this is an important skill to begin to develop. If both parties can learn to look at these three concepts, tremendous advances can be made in improving collaboration. Do you see any points where these concepts would prove useful?

Are you done yet?

Thursday, March 8th, 2007

Project managers often fall into the percent complete trap when running projects.  Percent complete gives the feeling of making progress, but provides no value to the managing the project. In There is no such thing as percent complete, Johanna Rothman says:

"Percent complete makes no sense. Features are done or not done. You can count done features and see how far along you are. You can’t reliably count any percentage done."

This doesn’t apply to just software development, this is true in an type of project. The only questions about completion that matter to coordinating and managing the project are:

1. Are you done? Done means that the consumer of what you were working on knows you are done and you don’t owe them anything else for them to use it. You should mark the task as 100%.

2. If not, are you working on it and when will you be done? This allows the consumer of whatever you are working on to get ready to work on it.  You should mark these tasks as 50%.

3. If you don’t know, what do I (the project manager) need to do to help you answer #2? Are you short of resources, do you have unclear requirements, are you waiting on someone else’s work, have you even started on it? You should mark these as 0% done. You aren’t working on it until you are have the resources, requirements, prerequisites, and intention to work on it.

If tasks are too long, then the only way to show progress is to update percent complete on tasks. Try to keep tasks to verifiable pieces of work that are relatively short, probably two to three weeks. Reflecting a percent done just to demonstrate progress doesn’t provide any insight into the status of the project, doesn’t help coordinate work through the project, and artifically demonstrates progress. As project managers or executives with projects reporting to you, are you keeping track of percent complete or what is done?

Ram says Organizations are Social Systems

Tuesday, March 6th, 2007

Ram Charon is interviewed by Workforce about the nature of leadership in organizations.

"the work gets done from a meshing of the parts of the organization. When people work together, that is by design a social system. Leaders need to understand these relationships and how people communicate—they need to understand the social systems. If you don’t know how they work, you can’t be successful. That’s new to the 21st century."

It is no longer sufficient to define strategy and map processes. Organizational leaders need to develop effective methods of understanding the social systems that make up their businesses. If this sounds like psycho-babble or Kumbyah to you, then the challenge is in finding pragmatic ways to get a handle on the way people communicate when they work together. Lean, Six Sigma, BPR, and other process improvement efforts unleashed a wave of productivity from organizations between 1950 and 2000. The next wave is in improving the way people innovate, coordinate, learn, and commit.  Does this sound like psycho-babble mumbo jumbo to you? What are you doing to find ways to get a handle on the creating productive collaboration in the social systems that make up your organization?