High Performance Teams
There is nothing as fun as working on a high performance team. Going to work is fun and challenging. Getting the work done is a blast and time just breezes past. Often you go home and discover how tired you are, something you hadn't noticed before.
OTI was my first experience with a high performance team. I was just learning about how to develop programs (I'd just hacked them before that) and stumbled across OTI. I'd taken a course from Big Dave Thomas (now running Bedarra), which made the interview easier. I was wowed by how much OTI accomplished, and as a junior, a little overwhelmed. I didn't contribute much but they taught me what it meant to be a professional developer. As my first development job, it set the bar really high.
My subsequent jobs are the ones where I learned what a high performance environment OTI really was. Mostly, I was amazed at how most development projects worked. I used the lessons learned at OTI to make changes at subsequent jobs I worked in.
With Mark Roseman, Fred Yee, Brad Johnson, Raymond Yip at Teamwave, I got to help manage my second high performance team. Using Mark's GroupKit platform we were able to build many stunning applications in a short amount of time. We had fun. Our product still appears to be used by Sonexis, whom we were sold to.
With Alan Covington, Shaun Smith, Jane Robarts, Darrel Hull, Greg Cook, Nathalie Veerwal, and Ralph Bohnet we were able to build a really high performance team that showed EFA how to build software in an Agile way. It was really fun and intense as the six of us challenged the way EFA built software.
How do you create them?
I really don't know.
There is no magic formula, but there are a few key ingredients:
- Enthusiasm. The people on your team need to do it because they love it. It is not just a job, it is what they do.
- Learning. Learning is part of the process, not something you do occasionally when the technology changes
- Desire to get better. Being better means you're always thinking, and driving yourself.
- Care. Care about the code, the product, the quality, the features.
- Reality Based Management. Management reflects reality rather than a schedule or a hope.
- Listen. Listen to others. Build on their ideas. Build a cooperative environment.
- Ego. Ego exists to let you get stuff done. Ego is a double edged sword, it can help you get stuff done, but also tear apart your team.
- Boldness. Being bold and taking on stuff you don't know how to do, lets you learn and amaze not only others but yourself.
- Mistakes. Mistakes are the lifeblood of the high performance team, they mean you are learning and not afraid. They keep your ego in check.
- Quality. Quality is what drives these teams. Building crap gets you ostracized.
- Judgemental. High performance teams are in many ways judgmental, they will not accept mediocre. They work to make everything great.
Very good teams
Very good teams are nothing to be ashamed of. They still develop excellent software. They still build successful products. I have been part of many of these and enjoy them, but I miss the exponential quality, speed and fun of the high performance teams. I miss the people pushing my abilities to the limit and expanding my horizons.
Interestingly, I find many projects are estimated as if they are a high performance team, but are actually a very good team, which leads to lots of difficulty when the estimates are finally done.
At PAS we have a very good team, there are a few key ingredients missing and we can't quite achieve those exponential returns in effectiveness, but PAS has done extremely well. I worked with two great leaders, Joseph King and Colin Jones, to create the best team we could. We hired great passionate people. We tried to be as non political as possible. We tried to share our passion for development and modeling. We tried to encouraged our members and teams to contribute new ideas, listen, and grow. We leveraged all that to build a great application that seems to be appreciated by our customers.
Over the last four years, I have watched many people I hired, trained, and/or mentored blossom in their abilities. I sneak moments of self pride when I look at them and think I might have contributed in some small way to what amazing developers and leaders they have become today. If you ever interview someone with PAS on their resume, you'll probably hire them.
