This is something I wanted to write for some months now, especially after my relocation to a new country and a new market.
It is about team bonding and performance, in the context of software development teams. A lot of stuff have been written in books around management or team leading, things like the role of the ‘organization’ aka company, the ‘managers’ aka leaders etc.
All of the above contribute on a higher level around the formation and sustainability of a development team, but from my experience there are some other things that eventually are overlooked sometimes, or no text book eventually addresses them.
After all, we talk about teams of software developers and some restrictions or special cases apply.
Some of these points should be evaluated by Human Resources departments, aim to form or empower teams.
- A successful development team needs to have a common level of understanding and principles around their job / profession . Our job is to provide solutions to problems and then create software that materializes this solution. This process involves a lot of different phases and requires several technical and non technical skills. The members need to have a common vision and understanding on how to perform this demanding ‘dance’. The members need to share the same qualities on professionalism and ‘execution’. In teams where all the members are on the same level (or close to the same), then the team operates similar to a well configured ‘engine’ it is then the responsibility of the driver to use his skills and the power the ‘engine’ provides to steer the car (aka project).
- I really believe on that kind of team formation. One potential way on eventually improving or leveling the team is to empower it with people that eventually will provide and set the core values where new or inexperienced members will follow. In this point ‘leadership’ becomes very important, meaning picking leaders to establish the common ground, but this is not the ultimate goal. Leaders need to establish the configuration of a team but the end result is to have a well configured engine and not just some of it’s parts.
- A lot things have been written about stereotypes regarding the ‘developer’ personality. Nurds, geeks, loners or whatever. I am not going to elaborate if all these things are correct (personally I think they are nonsense), but as a developer I have to admit that during 9 to 5 I really don’t care about the personal traits of my colleagues. Meaning I am mostly interested, if we share the same values and interests for our common goal, so that we form a well configured team and not if we potentially share the same views about music or personal matters. This might become a reality but it might not, it is really OK!!! During our work hours we are ‘first’ professionals and then potential friends. If we become it is really great, if it is not that is ok again. So let’s skip the emotional wars.
- A successful development team, in terms of team bonding and environment, will be formed only after certain and clear goals have been set. Ideally the best teams I have ever been member of, were those that eventually fully embraced the goal – believed in it. In plain words, actual team building is not only accomplished with nice offices, plain of coffee breaks or shared lunches. Team building is eventually materialized when all these people try to achieve the same goals and through hard work. Developers bond when they develop together, not by having breaks together. After all we are all persons individuals, sometimes you do not ‘fit’ as individual with people from work, we have friends for this, but there is a very good case where friendship will bloom in the corporate space, when we work together, fail or succeed together on something we believe. This is how developers bond.
| Reference: | Regarding team building and bonding – on developer teams from our JCG partner Paris Apostolopoulos at the Papo’s log blog. |
