During our (now finalised - more on this shortly) interview process, one of my questions to the candidate was: "What makes a good development team ?". Although we had discussed this with Christophe, and that I had my own take on it, I realised the answer was everything but simple. I also remembered a tweet exchange about the differences of culture between languages communities (java and ruby/rails in this case). Those two led me to ask myself: what is a development team culture? What it is made of? What is a good one, and why?

It is about people


Volley vannes 2006 n1m

It is the easiest and best answer, so I won't spend precious e-paper on it (save the electrons! Write short posts!): of course, you foremost make gr

eat teams with great people. But this is not the end of it (some great people can make awful teams, and all good teams are not the same).

It is about people dynamics

What level of heterogeneity do you want/have: from genre (it may be a surprise for some, but there is female programmers, I’ve worked with several) to age to experience (junior to senior) passing by speciality (is everyone a specialist in the same domain? in different ones? or more generic engineers?).

It is about values

This is a term I learned to despise, when I read about it in companies where the values are defined on top then pushed back to every person - preferably in the form of a non-removable (kidding) wallpaper.

And yet, it is an important part of the question: what are your team key values? Out of my head: expertise, effort, solidarity, product orientation, customer orientation, efficiency, learning, humility, honesty, humour... There is many to choose from, but as with priorities, if you pick them all, then they are no more values.

It is about the code

All the previous points are important in a development team. But probably also in any “project” team, whatever the project (a building, a dance exhibition, a store). What makes us specific is not only that we produce code, but that code is actually the way we express ourselves. For the machine (as this is the way we choose to communicate with it), but also with other humans (notably our future selves, but also our colleagues). As often (but never enough) quoted : we write code first and foremost for humans.

A software product or project should reflect its development team culture, as any language does for the group using it, and particularly in sub groups in close interaction. For example, I may speak the same french than 200 millions other people, but the locutions, expressions and puns I use would probably not be recognized outside of my close circle (even if they will be understood).

It is the same when we write Ruby or Java or others. It may be the same Java (there is a specification, after all) as used by thousands of programmers around the world, but we have our own set of usages. It can come in the forms of libraries, idioms or patterns. Even if every developer arrives with his own set of practices, it’s important that they do not stay apart : you do not want a codebase where each part is written in the author specific way, but something that emerges from the group interaction.

Haka of the All Blacks before the match agains...

It is about the small things

Even if you have great people agreeing on a core set of values, my personal experience is that the key factor could be the day to day little things, from humour (none, some, lots of, kind, sarcastic, ironic, other), cultural references (having a soft spot for historical quotes around geeks make an effect), noise level (none, each person that needs to speak leave the work zone, pair discussing admitted, full bazaar), desk organization (one room, several room, desk with face-to-face or not). All those “little things” will influence the way your team organizes.

It goes the other way, also

The good part in all the previous point is that this is not a one way relationship: your culture will impact your team, but your team will impact the culture. They will move desks around, exchange knowledges, regulate themselves (or try to regulate the others).

As far as this go, it’s the position we decided to take with Christophe: we do have (strong) opinions about the kind of team we want to build, but there is lots of space in them for people to bring their own vision.

How does it work in your team? What are you trying to bring on the table?

Enhanced by Zemanta