I've been managing people for quite sometime now. Its somehow unfortunate that I may not be a software engineer for an extensibly longer time than I wanted to because at some point, managing people better would mean putting more good people in a working team.
Over time, I have been able to solve problems of who can I get on board my team to have it function cohesively as one moving unit; which also, allows me to expand them in areas that need some improvement. Here are some of the important things I've learned and experienced along the way:
- Hire your people according to the skills you require.
Sometimes, its tempting to hire people who seem to be overqualified from the standpoint of their resumes. College degree, Masters' degree, worked in big companies, etc. At the end of the day, its about determining if this person suits your requirements. Does this person actually work well in your required skill? How much time can you offer to train and mentor?
Watch out also for those who play along buzzwords. They'll pull off your leg by using these terms very frequently, its almost too hard not to notice. Occasionally, conversation would have to be a bit longer to try and extract the essence of this facade. I've experienced a skilled coder telling me how much she hates CMS; and that she wouldn't want to develop CMSes. I've also heard of one applicant describing LAMP architecture as "Linux, Apache Macromedia and PHP". Well, someone also told me he was using Mysql 9 way back in 2006 (well, not that we already have Mysql 9 right now.. but you get the point).
- Hire people according to the size and impact of the problem you are solving.
Graph your problems. What is the biggest issue that you want to address? If you are understaffed for junior developer duties, then hire junior ones. Seniors might be a good option, but would you want more carving from the company budget?
Don't attempt to hire people for their future responsibility or your greater expectations. Remember that these assets will become their best if you are the right manager. So, instead of addressing problems that hasn't happened yet, fix the ones that you can resolve for the NOW.
- Hire people who have the right kind of attitude.
Skilled people are quite hard to find. Given. However, there is a difference between a DHH rockstar kind of developer who can't take "no" for an answer or one who would quit at the slightest diversion from Agile practice. There is no such word as "perfect" candidate.
Know that your candidate should have the mindset to adjust, adapt and grow. With the right kind of manager, all of these can be achieved gradually by satisfying both ends of the equation (company goals and individual goals).
One of the key experiences I've had in hiring is putting out a requirement that the candidate can take orders from a female superior without issues. Believe it or not, if you are like me, a female manager, there will always be cases of insubordination from male candidates. At some point, I had learned to include that question if my applicant is male (and/or older than me). IMHO, there is no greater conflict than having a team member question your authority because of gender bias.
Also, if you are going to open your doors to international team members, one key question to ask is their flexibility. Are they willing to join a group of inter racial composition? What would be their limitation in these parameters?
- Hire the people who think that your company is a place they can stay in for a long time.
The problem with most applicants is, your company is always a stepping stone. I like to listen to applicants expressing their desire to be part of a longer term plan. To grow with you. When I look at resumes, and see short periods of engagement with previous work, I always ask for the reason. One thing to watch out for is the rockstar applicant who bursts into flames and desires to be reincarnated in another company.
Your goal is to identify phoenixes. First, you check for their passion level. One who quickly bursts into flames on epiphanies wouldn't last long with you. Before you know it, you're crying over ashes. You don't want people who exhausts their own energies and then move on. Although a phoenix may not be the best animal to compare this kind of person with (because of its lifetime before combustion), still, you get my drift. May it be someone who will burnout after 2 or 3 years is not a good option for your team.
These people usually exhibit a very accelerated velocity in terms of learning, and could sometimes drive your team mad. Instead of worrying in the future how you would salvage this Phoenix (along with your burning team), don't hire this person now.
- Hire a window cleaner to clean your windows; not your roof.
This final note is almost similar to #2. Don't hire people according to their potential. More often than not, these people are pleasers, not helpers. This kind of attitude is also not sustainable.
Imagine hiring this person for the set of responsibilities you designate. However, instead of focusing on this, your candidate found a whole in your roof and volunteers to fix it. At first glance, you'd be impressed and say: "Why the hell did my roof guy not notice this at all??" Don't be fooled to let your window cleaner fix this. Thank the window cleaner and ask your roof guy to fix it. If there isn't any roof guy around, then circumvent to tip #2.
There is a reason and purpose for each skill that you gather in your team, and of course, that is for them as well to function efficiently and cost effectively. Delegating tasks to one of undeserving skill might cause your potential fire. You are moving people from their post and leaving a slot open. Moreover, you put confidence in someone who can only do the other job half efficiently. If there would be frequent problems on the roof, as a manager, it would be smarter for you to hire a roof guy or add more roof guys than allow your window cleaner to fix the roof (just because the window cleaner saw the hole on the roof).
Sometimes, by following these set of rules for hiring causes me more delay, but in the end, I'm always sure that I will be able to make them function optimally. But then again, the people who work for you is just one part of your equation to solve. You also need to solve the problems from your stakeholder side.
And then the balancing act begins all over.