Roles and titles

In general, I've been opposed to giving people titles on projects, especially titles such as architect, senior designer, or even tester. I've been opposed because I didn't want the titles to lead other people in the team to feel that they didn't have responsibilities in these areas. My preference is that everyone feel responsibility for every aspect of the project - that the team own all the problems.

Of course people who worked with me at IBS are now saying "hang on, there were people with specific titles/reponsibilities", and there were. For each team we identified three different lead roles, each of which required different skills sets. Let's say that they were design-focussed, people-focussed, and process-focussed. The argument was that when everything was working well things were a team responsibility, but if something went pear shaped I, as a manager, wanted to be able to go to one person and say "what's going on?" - I was trying to handle the failure modes. I don't think this worked as well as it should have, mainly because in my time at IBS I spent most of my time working as a recruiter or a fire fighter, and not really much as a manager (and I need to take the blame for that).

So where am I going with this? In the project I'm currently involved with we have titles/relatively strong roles, and I'm enjoying it. We have two people in the BA role, a test manager, an architect, and me (I'm nominally the development lead, but I haven't really figured out what I do that isn't covered by someone else yet, but I'm sure I will eventually). What I'm enjoying is being able to leave certain things to other people - in some sense to be able to flick them over the wall and not think about them at all. Now don't get the impression that we're sitting in bunkers lobbing artillery shells - that's definitely not the case. There's plenty of collaboration, and we definitely help each other out where we can, but we're also willing to trust other people to do their bits, ask questions where they need to, and keep the rest of the team informed (this is helped by all being in a project room and not having cubicles).

Reluctantly, I think I was avoiding titles because I didn't trust everyone on the team. Not in a suspicious, I-have-to-keep-an-eye-on-you kind of way, but at a level I wasn't really aware of. Still, if you're read the first paragraph carefully you can sense the distrust, either towards people's sense of responsibility or towards their technical ability. I think there are certainly times when that's appropriate - if I had a team of grads I don't think I would give them some roles and 'flick things over the wall'. I'd want to assign tasks, monitor them fairly closely and see how things went. I think that my mistake was trying to create a blanket rule, rather than assessing each case individually, which is a manager's job after all.

If I get a chance to do this again, I think I'd prefer to more formally acknowledge roles within the team. If it turns out that one person has all the lead roles, then lets say so openly - it certainly tells us a lot about the current skills mix within the team and how we need to change it. If a team is mature enough to handle having no formal roles, I think they'll be mature enough to handle having formal roles as well.