The story of human achievement is almost always one of teamwork. While we celebrate individual accomplishments, like Neil Armstrong stepping foot on the moon, it is always the team that makes or breaks the effort. I have always been interested in why teams succeed; it is easy to figure out why teams fail. A lot of time we think that we need a team of “Ninjas” in order to succeed, or a superstar team leader. In reality we need neither the Ninja team nor rock star team leader. For better or worse, I have been leading teams for a long time and I maybe a decent team leader now, but I was not early in my career-I have made every mistake in the book! Upon reflection of my past successes and failures I recently turned my attention to the question of why do teams succeed?
The problem with answering that question is that each team is different and even if you measure one team over a period of time, chances are that they worked on different projects or with different users, so it is difficult to get reliable observations. To gain some reliable observations you would have to observe one team working on virtually the same project, with virtually the same users, over a short period of time.
The good news is that I did just that. About 10 years ago during the .COM boom, I was the team leader of a team that was working on a website. (Surprise, surprise back then!) We worked on two short iterations (we did not call them that since this was before “Agile”) that were very similar in scope and requirements and worked for the same users. One iteration failed completely (the second one) and one was a smashing success (the first one). What was the key difference between these iterations? Everything was the same, the users and the developers got along, all key members were engaged, all the requirements were clear. What was different?
During the first and more successful project , I was on the “disabled list”. My ankle and leg were hurt while rock climbing and I had to walk around with a silly cane. (My doctor wanted crutches, but I refused.) It hurt to walk, even to stand, so I tended to stay put in one place at a time. As luck would have it, this company was an aspiring .COM, so they had leased a ridiculous amount of office space since they were going to hire 500 more people overnight. (Remember those days?) Since it hurt to walk, I usually just camped out with the business users at a spare desk.
Sometimes I overheard something the users would say that would affect the system and just butt on in that conversation. Sometimes they wanted to bounce things off my head and since I was right next to them, we had a lot of ad hoc meetings. This produced a better quality of communication. Studies have shown that there are thousands of communication "points" delivered with facial expressions and verbal tones/speech patterns. This gets lost in email, documents, etc.
Besides the close proximity to the business users, the development team would be around a lot too. While email was popular back then, I believed (and still do) that in-person communication is better, so I would not reply often to emails (especially vacation requests), forcing my introverted developers to ask me things face to face. This lead to other mini-meetings with the users and developers; business users would also overhead a team member coming to me lobbying to cut or add a feature and butt into that conversation with their perspective.
When the second project started, I was almost healed, so I tended to hang out in the IT department more often. (I also started to walk around with a baseball bat instead of a cane, that that would frighten people who did not know me.) As I said before the second project was a big failure and we later figured out that my leg was the only variable that had changed. For the next project iteration, we made it a rule to have a technology person sitting with the business team. (The guy who suggested this won the first shift with the users.) The collaboration between the business team and the technical team was the deciding factor and I have stressed team collaboration ever since, and my career has been the better for it.
You may be thinking that this is impossible in today’s day and age with distributed teams and rapidly changing requirements. The company I co-founded a few years back, Corzen, employed this strategy, even though we had a distributed team with both remote employees and overseas contractors. At our Corzen headquarters in New York City, we had our seating arrangements in an “open” style where the business team and the technology teams all sat together at desks right on top of each other alongside the sales team. While it at times did suck (like when my girlfriend would call and everyone could overhear our conversation), it paid many dividends. When the salesperson obviously lost a sale because of a lack of a feature that you lobbied against, it is far more powerful to hear the play by play in real time than getting an angry email from him later on.
Corzen had remote employees as well as overseas contractors, and we collaborated and communicated well with them. Of course we could not have them sit with us in the “bullpen” as we called it, but we did involve them on very frequent calls and webinars with our business team. The business team would make all of their documents available on a share or Google documents and over-share information instead of under-share. During the design phases the team would always communicate well and keep that communication going almost daily. New team members were inserted all the time and would come up to speed very rapidly. Of course the technical team held daily scrums using Skype and reported both ways (to the tech team and the business team) what was going on. This process was so successful that it lead to a great deal of success and Corzen was acquired by a larger entity based in another country and it still operates this way.
So if I have to sum it all up and answer the question why do teams succeed, the answer is pretty easy: communication, collaboration, and being “in the flow” of the emerging process. I have always known this, but my experiences described above enabled me to re-discover it. The best teams can finish each other sentences. Successful projects that I worked on had high bandwidth communication and extremely small feedback cycles. Success projects communicate and work "the way humans" should work - more face to face, more verbal. They also didn't rely up documentation to collaborate/communicate need/specification. Users don’t have all the answers, the requirements and features need to be discovered jointly by having a technical team member embedded with the users, or tools that mimic the fluidity of being together. Toyota perfected this process twenty years ago; the agile movement that started ten years ago was a recognition of this, so we have the knowledge of what works and what doesn’t work on projects. Embrace collaboration, communication, and work “the way humans” work (or mimic that fluidity if your team is remote) and you will have successful projects all the time.
