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
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
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.
Stephen Forte sits on the board of several start-ups including Triton Works. Stephen is also the Microsoft Regional Director for the NY Metro region and speaks regularly at industry conferences around the world. He has written several books on application and database development including Programming SQL Server 2008 (MS Press).
Copyright © 2016, Progress Software Corporation and/or its subsidiaries or affiliates. All Rights Reserved.
Progress, Telerik, and certain product names used herein are trademarks or registered trademarks of Progress Software Corporation and/or one of its subsidiaries or affiliates in the U.S. and/or other countries. See Trademarks or appropriate markings.