How to identify what makes your team happy, and what doesn’t?

April 24, 2007

Jochen is at it again. This time, he describes a simple, two-part exercise known as the Happiness Reality Check.

Part 1

In the first part, the team identifies the multiple sources of their happiness at work. Jochen’s team’s list included such things as challenging tasks, like-minded colleagues, and an open atmosphere – things that might show up on the lists of many teams – as well as a few items that are more team-specific.

This part of the exercise is valuable for two reasons:

  1. By naming what team members like about the work and work environment, it helps the team to recognize what is working; what is going right! Too often, the “squeaky wheels” (problems) get all the attention while the well-functioning, joyful aspects of daily activities get overshadowed. Naming the good stuff reminds us of what we like.
  2. Naming what makes us happy also provides an opportunity to find ways to spend more time and energy on those “happiness” activities, and to spread the environmental factors that lead to happiness. For most people, greater happiness brings greater productivity and energy, so it makes sense to maximize happiness.

Part 2

The second part of the exercise is to identify those things that make team members unhappy. I was pleasantly surprised to see the team’s list shorter for this aspect than in part 1. It included such items as office noise, repetitive task and interruptions. (The last may be on everyone’s list!)

The critical aspect of Part 2 is for the team to also develop a strategy for minimizing the “unhappiness” factors. For example, to reduce the negative effect of repetitive tasks, the team resolved to better “use technology to automate them as much as possible.”

I have not yet conducted the exercise with any of my teams, but I hope to soon. Take a look at Jochen’s post and give the Happiness Reality Check a whirl. It might just make you happy!

TechnoratiTechnorati: , ,


Recognizing the two types of knowledge workers on your team

March 12, 2007

Interesting discussion over at Future of Work that provides some insight for teams. In an effort to better define and understand “knowledge workers,” authors Jim Ware and Charlie Grantham explore two types:

Knowledge Executors and Knowledge Generators

Knowledge Executors are those workers who apply existing knowledge by manipulating information through processes created or invented by others. Knowledge Generators, on the other hand, create new knowledge by manipulating information to develop new solutions to a given problem, or to create new concepts or products.

Following these definitions, my take is that Knowledge Generators produce new knowledge by manipulating or combining existing knowledge, whereas Knowledge Executors put knowledge to use for tangible applications.

I suspect that most knowledge workers engage both as Executors and as Generators in their daily activities. However, each team member will likely lean toward one or the other end of the spectrum based on their job description and individual propensities.

Knowledge Generators cultivate networks

A key difference regarding the two types of knowledge workers was added by a commenter, Larry West, and reprinted here.

Successful Knowledge Generators on the other hand, seem to naturally be excellent networkers. As Daniel Goleman points out in his book, Emotional Intelligence, star performers are often people who cultivate a network of fellow Knowledge Generators who they can tap into for quick solutions or ideas. As active contributors to such networks, they tend to quickly respond to those in their inner circle and earn the privilege of quick response in return. Knowledge Generators also have networks of trusted colleagues that they can use to test new products, services or concepts before disseminating them. The key for me is membership in multiple groups or networks is very typical of Knowledge Generators whereas Knowledge Executors are less likely to be members of diverse groups.

The notion that Knowledge Generators build and rely on networks seems accurate. In order to create new knowledge, we typically need input from multiple sources. New and diverse knowledge serves as a sort of incubator for nurturing new thoughts, ideas and perspectives.

That’s why it is often true that the team members who come up with the creative solutions to tough problems are those who also read constantly, blog, talk to others across the organization, and have many outside contacts.

These same team members may not be the best at implementing their ideas. Thus teams also need Knowledge Executors to dig in and make sure that the creative solutions get applied properly and achieve their purpose.

TechnoratiTechnorati: , , , ,

Strong teams clarify objectives and desired outcomes before strategies

March 2, 2007

Have you been here before?

  • The team has a project to provide some uncertain deliverable(s) to meet specific internal needs or the needs of a client.
  • The team meets for the first time.
  • Item #1 on the agenda is to clarify the objectives and desirable outcomes.
  • Five minutes into the meeting, without ever exploring where the project needs to go, the team is weighing pros and cons of alternatives for how to get there.

Cliche time: The cart is before the horse. If you don’t know where you are going, it really doesn’t matter which road you take.

Read on as Elton Billings at Extractable shares his team’s experience with this phenomenon.

Conducting the Conductors
Do you have any idea how difficult it is to sit in a room of people who spend their lives proposing solutions and ask that they state only the desired outcomes? Every idea about what should happen was accompanied by a method for making it happen.

But to me, one very interesting side effect of the meeting was getting an amplified example of one of the major traps of web strategy: getting to the solution before fully stating the goals of the site.

There is a very strong desire to quickly get to the solution phase. Having a defined solution is much more comfortable than not having one. The issue is that defining a solution too quickly can miss the mark by not allowing time to explore all possible outcomes and really get important details about the goals of the site.

Action-oriented, smart people are often eager to develop and implement strategies to accomplish objectives. Folks like these are wonderful for teams and it is critical to steer their energies toward the right objectives.

I find it more valuable to have the team members actually identify the key objectives, as opposed to some else handing the team pre-defined outcomes. As I discuss here, when teams go through the process of thinking about what outcomes are desired, it helps ensure that the doing that follows is most effective.

TechnoratiTechnorati: , ,

8 essential elements for trusting teams

February 25, 2007

When a gifted team dedicates itself to unselfish trust and combines instinct with boldness and effort, it is ready to climb.” Patanjali

trust_fall.gifOne of the most telling predictors of a team’s success is the extent to which it builds trust among team members. Whether teams are large or small, virtual or under the same roof, trusting teams have inherent advantages not found in teams with a low level of trust.

What makes a trusting team? Following are 8 essential elements that set apart teams that possess a strong trust factor.

Social Exchanges

Social exchanges are critical in the early stages of team building, and continue to be important throughout the team’s existence. Discussions of family, weekend activities, and personal interests help team members understand the values and priorities of one another and build strong personal bonds. Team members who have worked together before make a point to included newer team mates in social exchanges to avoid the chance of creating cliques of socially-familiar members within the team. While bonding socially, trusting teams are careful to not allow social cohesion to be a substitute for progress on the team’s objectives.

Showing Enthusiasm

Trusting teams demonstrate enthusiasm about their projects and members make a point to overtly encourage team mates. Teams may refer to themselves as “family,” “posse,” or other nicknames used to signify the uniqueness and unity of the group. Language of enthusiasm might include phrases such as, “this is getting exciting!” or “I’m really pumped about our progress.” A favorite phrased I hear team members use is, “You rock!” By using somewhat informal vocabulary, team members reinforce that their enthusiasm for team mates includes a personal aspect as well as professions. Trusting teams “keep it real.” At the same time, trusting teams are keen to channel their enthusiasm toward accomplishing the team’s tasks.

Using Technology

Trusting teams use technology to enhance communication and solve problems, and do not allow technology to become an impediment to teamwork. Technology is a huge topic, so let’s touch on three of the more important aspects of using technology for teamwork: e-mail communication; scheduling; and file management. Read the rest of this entry »

Collaborative knowledge workers use ad hoc and changing work processes

February 9, 2007

A fascinating ethnographic study sponsored by IBM examines the collaborative processes used by knowledge workers to conduct their work. I’m intrigued by a key finding that many of these processes are ad hoc, created uniquely for the task at hand, rather than routinized procedures.

Knowledge workers make decisions and perform their work by drawing on a particular set of skills, knowledge, experiences, and intuitions. Although the work is dependent on the individual, process plays a major role. The work processes we observed differ from the enterprise-level processes in several ways:

  • These processes are rarely duplicated; some are ad hoc, some are semistructured, and all are in a state of change.
  • They are defined and owned by the knowledge worker.
  • The process cannot be codified; decisions are made by people and cannot be automated.

So often, large organizations try to standardized work processes so that workers are expected to perform a particular task in a certain manner. Command and control style managers tend to want to dictate how tasks are performed.

What this study finds is that knowledge work does not lend itself to standardization or micro-management. Instead, knowledge workers adopt processes that best allow them to produce the needed outcome or deliverable given their own work style.

This suggests to me that managers and team leaders can add value by helping knowledge workers to:

  • accurately assess the needs and constraints of tasks so as to better develop unique processes;
  • think creatively about posssible process alternatives;
  • feel comforatble with adapting and changing processes as needed;
  • know they are trusted to make process decisions.

Additionally, the study suggests that organizations benefit both by the knowledge worker’s productivity and by identifying best practices that can be used by other workers.

As we examined the life cycle of some of these human-centric processes, we observed, for example, that they may start out as ad hoc and informal processes but can quickly grow into best practices. This finding is corroborated by studies of activity-centric computing. Muller et al. found that work that begins as ad hoc and unstructured evolves over time into a semiformal process or a reusable pattern exemplifying best practices.

Take a look at the full report here.

TechnoratiTechnorati: , , ,

Taking time for vacation is a teamwork responsibility

November 16, 2006

The latest Hudson Employment Index was covered on all the mass media news outlets today. The headlines are:

  • 37% of workers will not take all of their vacation time this year
  • 24% of workers will not take any time off all year,
  • most workers who do take time will stay connected with their work via phone calls, email, etc.

From a teamwork perspective, I see taking vacation and time off as a serious responsibility just like any other work assignment. If team members fail to take time to relax away from the workplace, the entire team is likely to suffer the consequences. These consequences can include lost productivity, higher levels of stress, unnecessary tension with co-workers, lack of creativity, and a feeling of entitlement because of so-called “sacrifices.”

Working too much overtime is a similar matter and holds many of the same pitfalls. How many time have you seen great team members burn out and pull down projects because they tried to work nights and weekends without adequate breaks?

Most people do not skip vacations or work overtime to cause their teams to fail. Quite the contrary, most team members will have great intentions and will not recognize the potential negative consequences. Highly productive people may believe they can continue to function well during endless periods of non-stop focus on work. In these situations, it becomes incumbent on managers/team leaders to make workers aware that periodic breaks are not only an option, but are necessary for the employee to maintain productivity and satisfaction.

Consider what another finding from the Hudson study might tell us about those who opt to take vacations:

Only eight percent of workers earning more than $100k per year have not taken off from work this year.

I see two ways to read this. First, it could be that those making $100K can afford to take vacations and, therefore, take them more frequently. An equally plausible explanation is that those who make a habit of taking time away from the workplace are productive enough to earn $100k, and they continue their time-off habits.

This is clearly a chicken-and-egg question with no real solution. My experience, however, suggests that productive people accomplish a lot while at work, then they leave the work behind and enjoy the rest of their lives. This kind of work-life balance is important for the success of the team and the individual.

TechnoratiTechnorati: , , , ,

Transferring AGILE principles to non-development teams

September 19, 2006

Over the last five years, the principles set forth in the Manifesto for Agile Software Development have been the talk of that industry. Now others are beginning to notice, and for good reason. For example, Lisa Haneberg writes this:

I think there are lots of things businesses can learn about how to engage the workforce and put out a good product from Agile philosophies and techniques.

I agree. While much of the Agile approach is focused on developing software, many Agile principles are transferable to almost any business team. Here are four Agile principles I find particularly useful for teams, managers, and team leaders.

  • Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  • Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
  • Simplicity–the art of maximizing the amount of work not done–is essential.
  • At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

I also like the Agile goal to make projects interative by continuously producing short time-frame deliverables for customers. While I have no expertise in software development, I understand that Agile teams attempt to deliver usable code every few weeks, rather than waiting to deliver an omnibus software program at the end of a project.

If it is hard to see how an iterative approach would transfer to your organization, it may not be so far fetched. Effective teams often manage projects by dividing up tasks into smaller, more manageable, chunks. An agile approach might be to identify a “deliverable” from each of these sets of tasks (a marketing piece, a prototype, an interim report) that provides value to internal or external customers.

I have just begun to learn from the pioneers who have been developing and using Agile principles for developong software. The more I learn, the more I believe that business teams can benefit from an Agile approach. If you are not already familiar with Agile principles, give them a look.

TechnoratiTechnorati: , , , , , ,