Home > Uncategorized > Inviting people onto projects – and giving them an exit strategy

Inviting people onto projects – and giving them an exit strategy

August 29th, 2008 Leave a comment Go to comments

In my work life, I’ve been running a couple of projects lately where I had choices about who to include on the project team. Historically, I have been unhappy with the approach used by my company. People are essentially an interchangeable resource although each resource should have the right set of skills. Individuals are in fact asked whether or not she/he is interested in the project and willing to join. This all works well enough when there is a match between projects and people. But it assumes that the resource really knows about a project and vice versa that the project knows the skills (and attitudes) of the worker. But what happens when there is a “lack of fit”. Often both of us are stuck with each other. In some cases, you do get to get off the project – often quietly, and in my experience is often undermining. At best you get to get off an ongoing project when you go on extended leave. Thankfully, I go on leave often! Therefore, I want to think about ways which build in inviting people into a project that allows for an exit.

Luckily, I have friends who think about group processes. One friend is a clinical psychologist working with dialectical behaviour therapy (DBT). He’s been having a similar issue. He works in a small group of 6-8 people. It is a stable team but still requires new people at times. The success of that team is each person’s fit into the team and not just their skills – and they tend not to be able know in advance how well the new person will work out. His approach is to give someone 4-6 weeks on the project before reviewing suitability. Within that period it is outlined that the person needs to:
  • read certain materials
  • observe and participate in meetings
  • raise concerns
Central to this approach is to allow both sides to gather knowledge about each other and the environment. They are really looking for the new person to make a commitment to using particular skills and methods. Because, it is the actual using them that is essential. Sound familiar? We need well-functioning, small teams. Here’s what I have been attempting to do over the last couple of projects. This is the basic process I use once we have decided that a person is going to join the team (so this isn’t a recruitment strategy):
  1. Have an initial meeting outlining that I would like to invite them into the team and that I feel it is important that they get a chance to work out whether or not the project is for them.
  2. I outline that once they join that we will have a review at the end of two weeks.
  3. I outline the three points above.
  4. I outline that what we are looking for are people who can contribute to the project (and to me that is contributing to the code as a measure of success)
  5. I outline that these types of projects are not for everyone and that wanting to leave is okay – being stuck is not. I also outline the sorts of struggle that I have had in the past and why I think what we are doing is going to try and work against those problems.
How well does it go? To tell the truth, I haven’t used with enough people to really know. I have noticed that with the people who have been inducted through this process, they tended to contribute well and early. The others that were really given to me and just started have tended to be more of a struggle.

What could I be doing better? I think that I could do the review better. The review isn’t as formal as the initial meeting. It is more of a touching base. I check out with other team members how it is all going. I haven’t had anyone leave yet either – but then again those that I gave the induction approach to tended to well out better!

I’m not surprised that it might work well. It is akin to setting ground rules for small groups. My problem though is that I tend to set the ground rules rather than make them shared and in practice that doesn’t give much of a chance to the new person.

A final point my friend made after I was explaining the agile principles and trying to draw some parallels in our work. He agreed with the agile principles. He could see that a focus on individuals and interactions over processes and tools would be important; or customer collaboration to get working software. But he pointed out that DBT for him helps him think about how to do personal relationships. Now that’s an important point that I don’t think we are addressing in software development models. We might say that people are important and that they interact but we aren’t talking too loudly about its qualities. I’m not reading a lot around what happens when there is difference, such as gender and race, within interactions – is this will become more apparent if outsourcing across national borders increases. At best the discussion is relegated to the level of psychological-based soft-skills – for example, the pragmatic programmers series, such as, retrospectives, project management or management books.

Categories: Uncategorized Tags:
  1. No comments yet.
  1. No trackbacks yet.