There’s a tremendous amount that’s been written about high performance teams. I’ve studied high performance teams as part of my graduate work, read about them as part of my professional career, and had several experiences with high performance teams in the workplace. Reading and studying about high performance teams has the unfortunate effect of making them seem quite complicated, when in reality, there are just a few practices that go a long way towards creating a high performance team.

My experiences have been in the realm of software development, but these practices should apply to other areas as well.

1. End the day with a debrief meeting: At the end of your workday, take the time to meet and recap what’s happened. Who has accomplished what? Who ran into problems? What were those problems and what can be done with them? The end of the day is typically a time when everyone’s brain is tired, so it usually isn’t a time of great creativity. But it is a time of getting it all out of the table. Part of getting it out on the table is to share problems and successes to that people can sleep on those ideas.
2. Start the day with a planning meeting: After a good night’s sleep, and with a clear understanding of where everyone is, the morning planning meeting serves to plan out the events of the day. Who will work on what? What coordination will be needed? Who will pair program together? What novel solutions to current problems came to people while they were in the shower? What are the critical few objectives that should be accomplished today? The morning planning meeting is typically upbeat, high energy, and quick: 20 minutes to 40 minutes (max) will serve to plan out the day in great detail.
3. Start the week with a high level planning meeting, and end the week with a high level debrief: Just as the daily meetings serve to highlight the critical objectives for the day and develop a plan to meet those objectives, the weekly meeting serves the same function, but at a macro level. What are the business objectives to work on this week? What is the plan to accomplish those objectives? What problems meeting business objectives did you run into? This can take as little as an hour on Monday morning if objectives and a path forward are very clear, and as much as four hours if they are not. (But this is time well spent, as it ensures that the rest of the week is highly productive.)
4. Have a simple, shared system of documentation: It might be a wiki, a Google group, a whiteboard, or a Sharepoint (make sign to ward off evil empire), but almost every high performance team will have a simple system of documentation that ensures the most important information is easily accessible and up to date. This will typically encompass at least the business objectives, the daily plan, the build environment, the architecture plan, and integration points documentation. Too much documentation is overwhelming and a time sink, too little documentation and people are repeatedly searching for the same stuff or wandering aimlessly. Personally, I highly favor wikis if you can get one in your environment. Tips for wiki adoption.
   
5. Create a culture of personal responsibility: In a high performance team, everyone should feel comfortable doing whatever is necessary for the success of the team regardless of what the official scope of their job is. In fact, they should feel not only empowered to do whatever is necessary, but ethically compelled to do whatever is necessary. One day, the most helpful thing I might do is stay heads down developing my code. Another day, the most helpful thing I might do is go get lunch or coffee so that someone else can stay heads their developing their code. One day I might be developing a high level architecture, and another day I might be hand-editing every row of a 3,000 row Excel spreadsheet. (Yes, I did that.) The point is that regardless of skills, code ownership, or perceived importance, what is important on any given day and on any given part of the project varies, and flexibly adapting to this is critically important.
6. Be social: The team that laughs together and plays together shares a bond that goes beyond mere workplace acquaintance. Those weekly and daily meetings are a time for people to bring all of who they are to the table. Getting lunch together is a great way to be social and create pockets of more innovation: what work lunch doesn’t at some point come back around to work topics? One of my teams had a practice of taking off every other Friday during the winter to go snowboarding. It was our motivation to kick butt Monday through Thursday so that we could go enjoy a day of snowboarding with a clear conscience. (Oh, and what did we spend hours talking about while snowboarding? Work, of course.) An actual conversation with our manager when we decided to do this:
   Us to Manager: “We’re all going to take Fridays off to go snowboarding.”
   Manager to Us: “You can’t all go snowboarding on Fridays, there will be nobody here to handle things.”
   Us To Manager: “You’ll be here to handle things.”
7. Optimize decisions for fun: Obviously snowboarding, team lunches, and coffee together are both social and fun. But other decisions that take place can also incorporate fun into them. Silly as it may seem, but choosing the operating system, programming language, development environment, build tools, database engine are all technical decisions that have implications for how interesting and fun team members find their work to be. Sadly, in large companies these are decisions that are most often made either on the basis of perceived technical merit, or more often, based on existing corporate strategic alliances. A team that is excited to use a new language or development tool can, as a function of that excitement and passion, be ten times more productive than they would otherwise. Whereas, the technical differences in productivity are often quite small. So optimize those decisions for fun and interest, and you’ll get more productive and passionate teams.
8. Avoid negativity: Few things can be more destructive to a team than negativity. Complaining and trying to place blame are huge time and energy sinks. If there is an issue, then the focus should be on fixing the issue. Not detailing the issue out, not trying to figure out who caused the issue, not belabouring the pain that it has caused. Only on trying to figure out what to about it. In fact, if you have a chronic complainer on your team, one of the best things to stop the complaining is simply to ask the person, when they bring a complaint to you, “What are you going to do about it?”
9. Have at least one person who likes to work nights and weekends: Every high performance team I’ve been a part of has had one person who works nights and weekends. They just can’t seem to help themselves from staying up half the night to work. This isn’t a choice I would make myself, and I wouldn’t ask people to make that kind of a sacrifice. But if you just happen to end up with one person like this on your team, it will make all the difference. While everyone else is resting and getting their creative juices refilled, that one night person will have: fixed that build problem, solved the defect no one could find, figured out how to use the new GUI library, optimized the performance of the database, found a cool new IDE, and brought the build documentation up to date. And the next day everyone will “oooh” and “aaah” over what they accomplished. Be very nice to this person and buy them lots of coffee and chocolate.