This post is a continuation of the series on how to build a talented and capable technology team. See Part 1 on Internal vs External teams here.
When hiring anyone to do technology work for your company, whether it is an external development shop, contractor or internal hire, many of the evaluation criteria are the same:
Could you grab a beer with this person and have easy, non-work conversation?
Evaluate on culture fit first. Does this person / team mesh with you or your company’s culture? Could you go have a beer with them, not talk about work or the project at hand, and still get along? The more relaxed and easy the conversation and understanding is, the easier future communications will be. You don’t actually have to grab a beer or coffee together, just think about whether you would want to.
How easy is it for this person to think on their feet and adapt to change? Often in technology production, you’ll have a plan for the day and something will come up to change it all. Maybe it’s a critical bug, or an opportunity to change the task plan and kill two birds with one stone. If this person can think on their feet, the benefit to the overall project can be exponential.
communication, responsibility, initiative
The combination of communication, responsibility, and initiative separate the adequate from the exceptional.
Some people focus on communication as a positive asset when hiring, but I like to extend that to include responsibility and initiative. The combination of these 3 traits will differentiate the adequate from the exceptional. Technical skills are something that can be taught, but similar to culture fit, this characteristic is more about who the person is. Any time you encounter someone who possesses these traits, it is worth thinking about how and where you could use them, because they’ll drive your cause forward.
You on Monday morning:
I’d like you to procure a cake for the party I’m planning on Friday, nothing fancy, just use your judgement. Can you give me a status update on Thursday at noon?
Your employee on Tuesday afternoon:
I got the cake lined up to be delivered an hour before the party on Friday like you asked. I also noticed that we’d need some more tables and chairs, drinks, music and some additional lighting. I’ve sourced and priced options for all those items and can coordinate them as well, just let me know if you’d like to approve and I can get them delivered.
While the example might seem contrived, this type of initiative is real. When you find it, snap it up – the change to your project and organization will be substantial.
Skills on a Resume
While skills and experience are important, it is equally important to know that skills can be trained. There is some overhead associated with training people, and it requires materials and having someone to do the training and judge progress. That said, if the trainee has responsibility and initiative, it shouldn’t be terribly difficult.
I find that it is often difficult to find someone that has the exact skill set that I’m looking for, especially in the software engineering world. So instead of looking for someone who can program in ABC Language or Framework, I look for someone who understands the language agnostic concepts of good software engineering. Once someone reaches a certain level of software engineering mastery, the language is just syntax. Typically the person can pick up a new tool, technique or language quickly and be proficient in no time.
Show me what you’ve done, because this will tell me what you can do for me. A degree or certification on a resume isn’t enough.
A college degree only tells you that a person is capable of being educated.
Look for work samples from previous projects – this could be designs, code, architecture, open source work, etc. Looking at what someone has done in the past will give you an idea of what they can do for your project and organization. Anyone can list skills and work experience on a resume. Even if the previous experience sounds enticing, how do you know what that person’s contributions actually were?
A good portfolio of work will tell volumes about the individual; ask them questions about the work to find out more about their contributions and validate what’s been presented.
You get what you pay for
Underpaying your employees is an ideal recipe for turnover and overall talent decay.
Many organizations approach hiring from the perspective of getting the most qualified talent for the least possible cost. This strategy is an ideal recipe for employee turnover. What’s worse is your organization will get a negative workplace reputation amongst the available talent pool. When someone is underpaid for their position, they will quickly realize it and begin thinking about where they could move for better compensation.
If you pay a fair wage and hire capable, responsible people, they will enjoy their job. They will strive to demonstrate good work that is worthy of the compensation you’ve provided.
Know what you’re looking at
Whether it is you, someone else in your organization, or a consultant, someone needs to know what they are looking at. With software this could be a CTO, senior engineer, Consulting CTO, etc. In the world of design and UI, it needs to be someone that is a designer themselves – not just someone who can recognize good design, but someone who understands the foundation.
If you don’t know what you’re looking at, you are reduced to simply checking off skills on a resume. It’s essential to have someone who can make a judgment call on the quality of work.
Understand how a candidate learns
Technology (and software development in particular) is a constantly changing field. Foundational best practices seem to remain somewhat constant, but changes in languages, frameworks, tools, techniques, and strategy move at an incredibly fast pace. The hot technology today may be a thing of the past two years from now. A candidate’s ability to learn new skills and tools and apply them in an efficient timeframe is critical to that person’s long-term career success. Likewise, it is critical to their impact on your organization.