Peformance Goals – The Wisdom of Teams

Learn more about transforming people, process and culture with the Real Agility Program

As I continue my enthralled read through “The Wisdom of Teams: Creating the High-Performance Organization” I am moved to share another core concept that deserves to be considered essential for Agile Work:

The Performance Goal


This concept and practice is an essential condition for a team to become a high performance team. The Performance Goal is a specific, measurable, challenging goal that is given to and/or adopted by the team. It is a statement or description of a goal that answers “why?” and “what?” questions, but specifically avoids answering “how?”. It is not a description of activities, it is a statement of desired results. The team is left with the full authority to answer “how?” and implement it.

This concept is essential for setting the initial boundaries of self-organization. By defining “what” and “why”, the team is left free to be creative about the solution. The Performance Goal is also essential to building team accountability (as opposed to individual or externalized accountability). Every action, plan, mistake and success are oriented around the Performance Goal.

From the book:

The hunger for performance is far more important to team success than team-building exercises, special incentives, or team leaders with ideal profiles. In fact, teams often form around such challenges without any help or support from management. Conversely, potential teams without such challenges usually fail to become teams.

I would also like to point out a great blog entry I found that shows some of the other side of dealing with teams and present some cautionary words about the potential pitfalls of working in teams.

Teams as a Double-Edged Sword


In an Agile Work environment, the starting point for a performance goal is simply the delivery of valuable work at the end of their very first iteration. This is often a substantial challenge to a team and an organization. For some teams that have worked for a long time in a “waterfall” or phase-based project environment, it can be almost unthinkable that valuable results could be delivered in one tenth or one twentieth of the “normal” amount of time.

However, simply delivering value at the end of each iteration is probably not going to sustain the development of a high performance team for very long. Rather, the overall objective or goal of the project has to be important and compelling. Much work these days is _not_ important and compelling. In fact, many people become cynical about work because they are stuck doing a high proportion of work that is bureaucratic or due to chaotic circumstances.

As a reminder, the books “Good to Great” and “Built to Last” both discuss the importance of challenging, important goals. The wording is different, but the concepts all map to the idea of a Performance Goal. In “Good to Great” it is the “Hedgehog Concept”. In “Built to Last” it is the “Big Hairy Audacious Goals” (no kidding!). I imagine this concept comes up in many other good books about team and organizational effectiveness. I would love suggestions on other good books to read about this! Please write them in the comments.


I frequently work with organizations where a team has been formed up, told to use agile methods, and then also told how to do their work. Really great examples of this are things like: “we want you to self-organize, but you have to build this huge system using J2EE.” The the problem with this is simply that it may in fact be ten times less expensive to build the system with Ruby. However, someone has decided (possibly for defensible reasons) that J2EE is the technology platform that must be used. In this circumstance, someone external to the team has stepped over the boundary of “why” and “what” and also included some “how” in the team’s goals. The team is not even allowed to consider the possibility that something might work just as well and be much less expensive. Not only that, but the stakeholders haven’t even really stated “why” the system is being built and so the team can’t evaluate technology choices. There is no standard around which to self-organize. I admit that I am using a simplistic example here, but the pattern is something that I have seen over and over again.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Leave a Reply

Your email address will not be published. Required fields are marked *