Unicorn Factory
Are you hiring for capacity or knowledge? Do you ensure your staff have time given to them for training, learning and development? How about certifications?
Throughout the IT industry I often see job advertisements for unicorns; those amazing developers who are able to work on frontend, backend, cloud services and security, maybe they even know how to interact with customers. Most of the time when I see these ads I wonder why the company is wanting a unicorn, and usually I end up thinking they must not be willing to train their own staff to perform the required tasks and to grow.
Especially in a start-up, scale-up or smaller company, hiring people based on a specific skill or set of skills will create a silo effect where an individual (or a team) can become a bottleneck.
If we take a small development team at a start-up as an example, and we assume the team is comprised of the founding CTO, a frontend developer and a backend developer. The CTO realises that the number of bug reports is increasing and after some investigation discovers that it is likely caused by a lack of testing. At this point the CTO has a choice, invest in some training for the existing developers or hire a QA specialist.
If the QA specialist is hired, then the existing untested code remains, the QA specialist may become bottleneck and overall output potentially reduces. If the CTO instead invested in some training for the staff, then a short term productivity decrease is observed, the developers start implementing tests and as they work on code additional tests are added; although there is a slight drop in output due to the overhead of writing tests no additional bottlenecks exist and quality will increase.
Additionally, if a QA specialist were hired this would be an on-going cost to the business; but training is a one-off cost. Once the cost of the training has been absorbed, the business will be able to hire for capacity, not for knowledge. If the new hire is chosen wisely, the business will be able to find someone who is skilled at development but can also bring additional QA skills to the organisation. This person can then be given the mandate of improving the testing skills of the other developers and also be given the opportunity to suggest further training or development to help all of the developers increase their testing ability.
Although I’ve used an example of a QA specialist, the situation I most often see this occur in is the hiring of a DevOps engineer. As an organisation begins moving to a cloud-based architecture, many will hire a DevOps engineer. As soon as this person starts work, they have become a silo and a significant bottleneck. Instead of hiring someone for this role, the organisation could instead have provided the existing employees with time and training to gain these skills, and this would mean each developer would have the ability to create the infrastructure required for their portfolio.
In my opinion, companies should be striving to become unicorn factories. Employ people with a base skillset that matches the organisation’s requirements, but provide them with time, education and training to allow them to develop their skillset to help the business improve. If this is done well, then the company will only need to hire due to capacity and a desire to deliver more in a shorter timeframe, the employees will have increased job satisfaction and the number of potential bottlenecks or single points of failure will be reduced.
So, how do you become a unicorn factory? It’s really quite simple. Get to know your employees; find out their reason for coming to work, find out their perceived weaknesses, find out their goals and aspirations, and find out what they want to learn more about. Once you’ve got this information, then help them to achieve their goals, remove their weaknesses and learn the topics that interest them. As each employee becomes happier in their job, they will become more invested in making the product succeed. They will start to observe other aspects of the development process that they lack knowledge of, they will want to learn about topics that will help them to deliver the best possible product.
Of course, there’s an exception to this ideal; and that’s when no one in the team has an interest in the required knowledge, or they simply lack the experience to perform the required tasks. In cases like this you may need to hire for knowledge, but a key part of identifying who to hire is to find someone who will enable the rest of the team to learn to perform the required tasks. Hire a DevOps person who can also code with your chosen tech stack; hire a QA specialist who knows more than just testing; then use their knowledge to educate the rest of the team.
Encourage your staff to go to conferences and meetups; but ask that they report back to the team about what they learnt. I’m not talking about getting them to run a brownbag or a lunch ‘n’ learn; I’m meaning schedule a meeting during work hours for them to share their knowledge; give them the time to implement a proof of concept so other staff can learn from it.
Encourage your staff to undertake training and certification; but ask them to take the lead on implementing what they’ve learnt; don’t ask them to just implement it ask them to lead the others in implementing it, so the knowledge is shared across the entire team.
Encourage your staff to research, experiment and try new things; but ask them to share their findings with the team and find ways for the results to be used.
If you give your staff the space to improve and encourage them to improve in ways that are beneficial to both themselves and the business, then you’ll have a team of unicorns before you know it. The only difference between your tech team and a unicorn factory is that the unicorns won’t be getting shipped out the door, they’ll be wanting to stay.