Earlier posts in this series: “Introduction“, “Hiring“, “Orientation“, “Training“, “Planning“, “Production“, and “Shadowing“.
At the end of shadowing, the trainee has been with us for 10-12 weeks, has received intensive classroom-style training, has planned and developed a small project from start to finish, and has worked on real commercial projects in parallel with a few of our most senior developers. Throughout this, we have been assessing and providing feedback on their productivity, code quality, communication skills, time management, and problem solving ability.
At this point we know for certain (hopefully) if they are going to be a great addition to the team.
As the 3 month mark approaches, we schedule a meeting with all of the senior staff who worked with the trainees. We compare notes, and discuss the strengths, weaknesses, and growth of the trainee, citing specific examples wherever possible. I take a lot of notes, and bring them into the review.
I like to keep reviews informal, usually over lunch or a beer. I talk to the trainee about what they are doing well, and how they could improve. Again, I try to use concrete examples where possible, so they can relate the input to real experiences. I give them lots of opportunity to ask questions or provide their own feedback on their performance and the training they’ve received.
If things didn’t work out, I make a point to provide them with honest feedback on what I think they need to work on if they want to continue in the industry, and where they could go next. I ask them how they’d be most comfortable with me announcing their departure to the team, and we generally have beers as a group to see them off amicably.
If things went well, I welcome them to the team, ask them a bit about their goals for the future, and start talking through possible projects we could put them on. From this point on we work aggressively to keep them busy on real projects, under the watchful eye of more senior staff who can ensure the quality of their output, and help to continue their growth in the company.
Of course, this whole process requires a large up-front investment which is wasted if we can’t retain our staff. I try my best to make gskinner.com a great place to work. We keep regular office hours, encourage our team to have a life outside work, pay fairly, have a good bonus model, offer praise and appreciation for accomplishments, foster continuous learning, promote a fun work environment, try to book interesting projects, and protect our staff from abusive clients. I would much rather lose a bad client than a good developer.
I have an amazingly fun and talented team that I love working with, and one of the things I’m most proud in my professional life of has been keeping them together over the years.
This concludes the Creating Great Developers series. Hopefully it helps inspire other dev groups to mould a new generation of creative, competent developers, and treat them with the respect they deserve. Interactive development is a creative pursuit, and I’m a strong believer that you can’t get exceptional results by treating developers as a commodity.
Note: I’m planning to revisit this series to do some editing (I’m not completely happy with the quality of writing), flesh out some details based on feedback, and add a persistent index.