While working on our Telemedicine in Thailand project, I’ve learned quite a few things about building a team and managing a talented and diverse group of people.
The first lesson that I learned (the hard way) is that it is often very difficult to get computer science students to work on an extra-curricular project, especially when that project is unpaid. Ultimately, it didn’t really matter that I had an interesting problem to solve and a real client to work with. We weren’t just going to build something and hope that someone would implement it – we had an actual value proposition based on testimonials and extensive research from a non-profit that organizes volunteers for a network of rural medical clinics in Thailand.
Computer science students are in high demand, whether they know it or not. Many of them also like to own the projects that they are working on, or in other words, they all want to be recognized as Co-Founders, and they often have an issue being a subordinate member of a development team. At the same time, there are many other computer science students that actually want to be micro-managed. They want to be given specific instructions and deliverables, and they want to know the exact objective of every one of their tasks. These people are not interested in ‘owning’ the project, they don’t want to be creative, they just want to get results.
The approach that I took to recruitment was that I wanted to work with my developers. I explained that we’d be learning details about the clients needs throughout the project, and new information might change our envisioned solution dramatically. Unfortunately, while this idea interested some candidates, the ones that prefer to have an itemized list of deliverables places in front of them were turned off. Understanding a candidate’s personality was difficult when only based on a first impression at an interview.
Recruitment was the longest process of our entire project this year. It took me 4 months to get a final team together, and that was after several developers dropped out or lost interest, and I was forced to start the recruitment process all over. At one point, we had an incredible team of 12 student developers. But as soon as I gave them time to think about joining the team, and explained that we didn’t fully understand how we were going to solve the problem yet, most of them claimed that they were too busy with school to commit their time.
I believe that hiring talented people is as much about selling yourself and your vision as it is about getting them to try and prove their worth. My main recruitment strategy, given the nature of the project, was to reach out as far as possible into the pool of computer science students at my University. This was done by essentially spamming every computer science student, especially the grads whose names and emails are posted on the faculty website, with a plea to consider joining my team. I also tried to get the students that I had recruited to reach within their own networks. I still see no alternative to this lengthy process.
Now that we’re nearly at the end of our development phase, I can safely say that we have prevailed. I learned that I didn’t need a huge team of developers with different specialties. Dividing up work between a large team and also distributing administrative access to our servers and other services proved to be unnecessary and inefficient. Ending up with a lean team of 4 students that could work together on each of the deliverables reduced the potential for disagreements or redundant work.
The most important lesson that I learned, however, was that hiring a person who is committed and anxious to learn is absolutely always better than a person who has a tonne of impressive experience, and as a result, they act like they have nothing to learn from the project or their teammates, and they remain stuck in their own methods. That kind of person can still be very useful though given their expertise, so I put a few of them on an advisory board that is on call to help us in case we get stumped by some feature.
Some of these lessons only apply to the circumstances of this project, but some of these lessons also apply to the important process of recruitment in general.