I’m a curious person by nature. I’m not generally satisfied with what’s on the back flap of the book – I want to know what’s inside. I’ve also lost more than one laptop to this curiosity. I, like many sourcers, was one of those kids who broke their toys as a kid to see if they could figure out how to put them back together. About half the time, the answer was “yes”, I could put them back together. The other half resulted in my mother asking things like “why is there a half melted G.I. Joe figure on the light bulb?” As you’d assume, I gave a plethora of answers to these questions, but no answer I’d give would ever suffice. This carried into my professional life, and as a sourcer, this innate curiosity has served me well.
As sourcers, we’re researchers at heart when you think about it. We can come up with a thousand ways to dissect profiles, absorb trends, siphon copious amounts of data off of public (and some not-so-public) websites and apps. But many of us seem to falter in an area that, while a little left of center of our core duties, is essential to our success. We can’t speak to technology as adeptly as we should be able to. We fail frequently to glean ample insight into the technology being used by those candidates we so covet.
The argument here for some may be that they don’t interact with candidates often, or at all. And while a firm grasp of specific technology talking points may be slightly more beneficial to those who are talking with candidates each day, those of us doing pure research can also benefit as well. By understanding the landscape of the technology we’re searching for, we are able to find similar, translatable skill sets that can meet the needs of the teams you are supporting.
If we’re sourcing engineers, no one (presumably) is expecting us to be coders ourselves. But sure, it helps if you have a grasp of core concepts. Understanding what version a widely-used tool is on (say, Java perhaps), or how new technology works can be extremely beneficial in aiding you to understand what else you can be looking for in addition to the standard 10 buzzwords on the job description.
A few years ago, I was working for an organization that was transitioning to Kubernetes and a CI/CD framework for releases and container management. I had barely heard of Kubernetes, let alone some of the other things thrown at me in this intake meeting. I knew I had some work ahead of me. I leveled with the VP, and said I needed him to walk me through some high level of how to describe some of these skills and tools. There was zero sense in pretending I knew exactly what he needed, when I didn’t and just start sending him crappy candidates. So, he white-boarded a few scenarios for me, and it was slightly less foggy at the end of an hour-long session. I knew I still had some work to do when I left his office, and that I’d have to figure the rest out on my own.
After about 10 minutes of deliberating how to figure out what I was going to have to figure out, I googled “Kubernetes for idiots” and what I found changed everything, in the most unexpected way. The below video popped up in one of the first results, and despite my slight cynicism associated with trusting this at first, I casually peeked over my shoulders to make sure no one was looking and began to watch:
Article Continues Below
In just over 8 minutes, I had a fundamentally-sound, non-engineer, understanding of what containerization and Kubernetes were all about. I even had some good ideas about other things to include in search strings I’d be using. While I knew I could find profiles, I now knew how to read for what I was looking for. One semantic google search of what I was really thinking led me to my answer. I thought about what I was looking for, and decided to start with three very basic searches:
- What is Kubernetes?
- What is Containerization?
- Kubernetes for Dummies
The last one was the one that yielded the video. Sometimes it’s the simplest solution.
We’re researchers. We research, people daily to assess their fit. Understanding the technology and being able to leverage that understanding in either our conversations or research is an extremely versatile tool to have as a sourcer. We have to keep learning to stay viable. We have to stay curious to keep learning. We have to leverage our best sourcing tool, our brain, in order to find those little nuggets that make us better and more credible.
Go be curious.