On the last day of the Monospace conference, one of the open space sessions was Miguel de Icaza from Novell discussing his jazz band management style. It was an interesting look into the way the Mono project team works and learn more of the personal history
The Mono team had several members at the conference and watching them interact and hearing about the work, it sounds like a great environment to work in. I've been thinking about Miguel's talk since then and what lessons could be taken to help other teams be as tight knit and effective as his team.
First, why were we discussing jazz? Miguel compares his team to a really good jazz band. They are really sharp and can take the lead in an area that interests them, just as different members of a good jazz band can take the lead in a song and everyone else can support and play off their lead. Sure, there are times he sets a direction or throws out a big goal, but then the folks on the team can run with it, bring in things that interest them or help support the people taking the lead.
What troubles me though, is how unique is their situation? The people on the Mono team are really sharp and super passionate about Mono. It is rare to find teams that are so good at what they do and so committed to their cause. No wonder they excel and Miguel can have such a loose style and they have such fun together. Sure it would be great if we could all pick a team of all-stars to work with and have everyone jamming to the same tune, but how many times have you been in that situation?
One lesson that I think is generally applicable is the way they recruit for the Mono. Since they work with Open Source, they get to see people contribute, interact with them in a distributed environment, see their passion for the project and get to know them before they ever bring them on board their team.
Great for Open Source related projects, but how does this apply to non-open source projects? How can you see how well people fit and what their knowledge and skills really are? One day of interviewing usually isn't enough especially since we are often "testing" skills like "writing pseudo code on a white board" that aren't really part of what we expect people to do in their daily work. Plus, we don't gauge how well they interact with the team day to day, so we don't have a sense how they'd fit into the team game that is building great software. Most companies have a 3 or 6 month probationary period for new hires when they can be let go for whatever reason, but this seems to only be used in cases of gross incompetence. Psychologically, the team and hiring manager already committed to hiring this person, so they don't want to admit to a mistake and let them go.
A good alternative would be to hire the candidate as a contractor for a short specified period of time. For agile teams that have defined iterations, a couple of iterations or sprints would be enough. The team would have enough time to get to know the candidate, the candidate could show off their skills in a real environment and everyone would know up front the length of time and that this is an experiment.
What do you think are the best ways to add a new player to your band?
PS- Gary Sherman had a great post summarizing the Mono conference and Innotech.
