Aleksandar Bradic, CTO Supplyframe
“The battle for talent has been a permanent fixture of the tech world since the very beginning. However, we have seen it accelerate dramatically over the last decade.
Newly funded companies are springing up every day. The established players are getting more and more aggressive. More and more competition is mounting around an increasingly shrinking pool of exceptional engineering talent. PaaS companies and Coding bootcamps are emerging as alternatives ways of solving the issue of “competency gap.” Yet, everyone’s still struggling to fill out all the positions with the right talent.
Such setting presents a modern CTO with a problem. We all like to think we’re hiring only the best talent, but if this is indeed the case, where do all the unexceptional performers end up?
If you’re a CTO of a young startup, the answer to this question might well be “on your team,” unless you consciously make an effort to stack odds in your favor. Existing companies have worked hard at creating pipelines and processes ensuring they recruit and retain top-notch engineers.
It’s an “efficient market” for great, and even just good enough talent, regardless of technology or geographical domain. So you’ll have to work hard to identify what’s the thing about your team which will make it stand out.
An approach which has worked quite well for me in this regard is fostering a culture of challenging conventional wisdom and cargo-cult thinking when it comes to new technology adoption.
These days, among other things, teams are easy to adopt frameworks and platforms based on reasoning such as “a company which I admire is using it.” While this might be a valid point, it often leads to the sense of inferiority on the team, and being a follower rather than a leader. Not to mention it can end up turning the engineering discourse to religious wars and entrenching of existing worldviews instead of broadening one’s horizons.
Instead, my approach has always been reframing the same conversation as “let’s spend one hour looking and discussing the project’s implementation details and understanding trade-offs” So much of what we’re using is Open Source anyway, so why not take advantage of this? I have found this approach to result not only in more intelligent conversations but also in the team feeling like they have acquired the type of knowledge and insight which not everyone has, making them feel more like a leader in the field.
To this point, I often refer to the following quote: “First you get your Bachelor’s degree, and you think you know everything. Then, you get your Master’s, and you realize you don’t know anything. Then you get your Doctorate, and you find out that nobody knows anything.”
Making an effort to scratch the surface of implementation details serves precisely the purpose of facilitating such a learning process. By demystifying the tools which the team uses, they’re leading themselves to the realization they too can be as good, if not better, than their role models. It removes egos from the equation and turns the process into a collaborative effort.
Cultivating the culture which encourages such intellectual curiosity in the team context can be intoxicating. And, most importantly, it can go a long way in attracting and developing unique talent in a way which only a few other places can match.