Salesforce, Talent Sourcing and the Future of Enterprise Search

The increasing overlap, and potentially inextricable intertwining of recruitment and marketing has been a central theme in the HR industry, the subject of a prodigal amount of product marketing, ‘thought leadership’ content and corporate copy.

The confluence of recruiting and marketing has, in fact, become a central focus in competing for top talent, with concepts like employer branding, SEO, segmented “talent networks” and e-mail campaigns moving from the margins of recruiting to the mainstream of how companies find, attract and engage candidates.

Not so, says Andrew McKay, CTO & Co-Founder of KonaSearch, which provides a “single, universal search application within Salesforce that searches all Salesforce data along with content from external sources,” including an integration with Jobscience, its primary foray into the recruiting technology market. In fact, McKay said in a recent interview with Recruiting Tools, recruiting actually has little in common with marketing from a strategic or systems perspective, instead aligning much more closely with customer service and support as a reactive, highly tactical and performance-based function.

RecruitingTools recently spoke with McKay, a technology industry veteran widely considered one of the world’s top experts in enterprise search (and, coincidentally, author of the Wiley book Enterprise Search for Dummies) about KonaSearch, the future of enterprise search, systems and sourcing, and some big ideas about big data and why Boolean continues to survive – and thrive – in the new world of search.

We’re also hearing a lot about Big Data.  From your point of view, what, exactly, does big data mean and what is KonaSearch’s approach to tackling the massive amount of information available to businesses today?

Andrew McKay, CTO & Co-Founder – KonaSearch:  I’m going to be truly lazy here and simply quote Wikipedia: “Big data is the term for a collection of data sets so large and complex that it becomes difficult to process using on-hand database management tools or traditional data processing applications.” This is actually a fairly accurate definition. I would add to the definition the presence of both structured data (database records) and unstructured content (documents), both derived from sources that are internal (operational data, ERP, CRM, KM, etc.) and external (social data, public information, etc.). I would also include an indication of what the data is used for, i.e. discovery, analysis, prediction, etc.: quantitative data mining and analysis for structured data and qualitative content mining and analysis for unstructured data.

The key distinguisher, however, is that it is BIG – too big for conventional (read: traditional) technologies. Big means 10s or 100s of terabytes and even petabytes, and it is disrupting the most stalwart technologies: the SQL database and data warehouse, even storage media. Our conversation here (for Kona), though, is about retrieval and analysis.

Some vendors emphasize that added insight derives from the interaction of data and content technologies, insight that leads to true predictive analytics. The argument goes like this: data analytics answers “who, what, where and when”; content analytics answers “why”. Together you get “active intelligence”, or “actionable information”, two common terms from the Big Data lexicon. There is truth to this, if for no other reason that for the first time, analysis is covering ALL information from the organization, not just the structured or unstructured skew from BI/data mining or search services deployed separately. An aside: I’m always trying to explain what I do to my mother. I hit on this analogy: search is the left eye view, BI is the right eye view. Only when they’re used together do you get depth perception. Lame, but it works.

Anyway, we at Kona share this view, although we are less about analytics and more about simply finding what the user thinks they’re looking for. Salesforce, like any CRM, suffers from being squarely between the data and content worlds. Although a highly relationally structured construct, its data is predominantly text. Analytics are qualitative as much as quantitative. Kona is designed to integrate the two. Yes, it’s a search engine underneath (search technology is better at embracing data analytics than BI is at embracing content analytics, search indexing also handles larger volumes than relational indexing), but it is highly enhanced with the ability to understand relational cardinality and structured, field-oriented records.

Here’s a simple but perfect example: searching for a Contact named Andy – can’t remember his last name – but he works for ABC. The search query is, “Andy ABC Inc”. This is actually hard because Andy is the contact’s first name, and ABC is the name of the account. The Contact record does not contain “ABC” anywhere in its record; instead it contains a Lookup field (foreign key) to the Account record. Now suppose the contact is actually “Andrew McKay” and the account, “ABC Corp”. Kona still finds the Contact record. Our friendly name thesaurus/dictionary matches “Andy” with “Andrew” and “Corp” with “Inc”, and Kona finds the Kona account because it automatically searches through foreign keys. This is one example of several technologies we have added to our search service that pairs the ability to traverse SQL relationships with natural-language, Google-like, relevancy-based content searching.

And finally, the right to play: any retrieval technology, search or otherwise, must be scalable, that is, it must be able to traverse 100s of millions of records with the same level of performance, response and simplicity as a few thousand – without compromising functionality. Kona does this, and we think the only search engine for Salesforce that does (a key technology that we are looking to patent: how we handle Salesforce permissioning is central to this ability and discussed later).

Taking a look at the HR or recruiting technology marketplace right now, vendors are increasingly offering CRM capabilities as part of their current ATS or HCM system or as a point solution.  What advantages do you think marketing automation has for HR & Recruiting? What are some of the major trends or themes you’re seeing out there?

CRM capabilities I see, but marketing automation? Maybe it’s my understanding of marketing automation. CRM capabilities are to some degree universal. They manage people and track them through a weeding process for some purpose; in the case of Sales, selling them stuff. But it could be connecting them to jobs or solving their problems or whatever. I’m not so clear about MA. MA in my experience (Eloqua, Marketo, Pardot, etc.) is about managing the same people, like CRM, but further up the food chain – and I can see where that applies. Prospects become leads or opportunities when their activity score reaches some level. But, a lot of MA focuses on SEO, landing pages, drip campaigns, email blasts, etc. Perhaps this is used to fill up the job order pipeline rather than the candidate pipeline?

In any event, our experience finds Recruiting to be operationally much closer to the typical service call center.

As for trends, we see:

• Demand for more sophisticated matching engines and better profiling of both jobs and candidates through better, more relevant metadata;
• Leveraging social data to enhance reputation scoring, influence scoring, and investigate accuracy (is their resume identical to their LinkedIn profile?);
• A more seamless and consistent integration of pre and post-assignment of candidates. Once the candidate takes the job, what do we know about them? How successful were they? How long did they stay? How should these factors be used to modify the profile of the candidate should they re-enter the market?

Tell us a little bit more about KonaSearch and its capabilities.  What does it do, exactly?  Why should HR or recruiting care about something designed for Salesforce, since they have separate systems?  

KonaSearch (our sole product) is an integrated, enterprise-class, AppExchange-certified search application for the Salesforce community, that searches not only Salesforce data but also other data sources relevant to the Salesforce user (e.g. SharePoint), serving up results from a single, consistent relevancy-based index to the Salesforce desktop. Here is a bullet list highlighting our capabilities:

• Search of every field of every object in Sales Cloud, Service Cloud, Content Manager, custom objects, and Chatter, including full text search of Attachments, Documents and Files of any size and format;
• A template-based, customizable search UI with customizable filters, columns and dynamic facets, and a programmable search API;
• Boolean logic-based search language, with wildcards, spell correction, lemmatization and stemming, range filtering, customizable dictionary, field-specific search, geo/range-search, and concept extraction;
• A scalable environment where searches are returned in less than 5 seconds on indexes with over a 100 million records while respecting the full set of permissioning capabilities Salesforce offers (more on this later);
• Connectors for SharePoint, Box.com, directory trees, and JDBC with the ability to index the content into the same index as the Salesforce data for an integrated (not federated) set of results based on a common relevancy model;
• Ability to search in every language Salesforce supports.

In general, all our customers buy Kona for one or more of the following reasons:

• Scaling at any size without compromising performance;
• Searching all Salesforce fields and objects and deploying results to the standard platform, portal, and Chatter communities;
• Customizing the search experience and integrating it with their application (matching engine, ability to select results and forward them to Apex job).

Our recruiting clients like us for the above plus our ability to search an attached resume (attached to the Candidate record) and include it as part of the Candidate’s total relevancy score. Our Jobscience clients like us for the above plus our ability to incorporate skills and skill ratings as part of our matching and relevancy scoring.

HR should care about Salesforce and its partner applications when their current applications (recruiting or otherwise) are built on force.com. They should still care about Salesforce if they are using an on-prem HR system because it’s time to move to the cloud and Salesforce is the best way to get there. This is true in fact for any application built on force.com.

Search (and therefore Kona) is particularly important to Recruiting because the ability to find relevant matches between job orders and candidates is a measurable competitive differentiator.

Your product information talks about upcoming integrations with partners like Workday and Jobscience.  Can you speak a little bit more to the nature of these integrations and what advantages being a KonaSearch user would have for talent acquisition and management?  

Our mention of Workday is more aspirational – we are working on a relationship as a channel. However, we have several Jobscience clients running live. At the most basic level, our integration with the Jobscience app is no different, frankly, then it is with any other custom app built on force.com: we index the content right out of the box. But, there are areas we have enhanced in response to the demands of the Jobscience community (who from our perspective are all recruiting companies):

• Search performance uncompromised by the demands of scale, as in, several 100 thousand candidate records with attached resumes (our largest recruiting system floats 2.3 million candidates);
• Ability to produce custom search UIs that integrate with the application in a matter of days (despite all being Jobscience clients, they all have very different, personalized search UIs);
• Matching engine that works in both directions: job order to candidate, candidate to job order
• Using skills and skill ratings as part of the relevancy scoring and filtering.

KonaSearch is obviously a search company.  What do you see as being some of the major trends in search, specifically the larger trend of federated or universal search that we’re seeing from products like Dice Open Web, Entelo, Gild and TalentBin?

I have to qualify your definition of “search” as an industry by separating web, or public, search (Google, Bing, Yahoo, etc.) from enterprise search, a market that has been around since the 1980s and 1990s with Thunderstone, Fulcrum, Alta-Vista, etc.

Enterprise search went through a consolidation phase some years ago when all the largest players sold to major concerns (e.g. Fast Search & Transfer to Microsoft, Autonomy to HP, Endeca to Oracle). In this time, we saw the rise of Lucene and Solr (and later Elasticsearch) in the Open Source community and a new generation of search engines built around them (e.g. Attivio: full disclosure, I’m a co-founder).

What made them different than previous engines? They were tackling Big Data before “Big Data” was a phrase, essentially the problem of bridging structured data (databases) and unstructured content (documents) in extreme volumes. Graph processing (e.g. MapReduce) was a key factor in opening up analytics and soon became part of the mix (by the way, before Facebook introduced its graph search release). Earlier, Enterprise search had started specializing (e.g. legal discovery, Q&A systems for call centers, voice of the customer, social media and sentiment analysis) and this accelerated.

Key trends today are:

• Simplicity – Ease of implementation, tuning, and management. Enterprise search has suffered from ignoring “mere mortals”. No longer. Organizations today have much less tolerance for months of configuration and tuning by highly paid search experts. Thank Google (rightly) for “it just works”.
• Centralization – One logically integrated search engine for the entire organization across multiple, heterogeneous structured and unstructured sources. “Logically” means that while it appears as one index, it is physically distributed to where the data is. This is not a new concept of course, but perhaps the first time it is more than a holy grail. Recall the similarity to the original goals of the data warehouse.
• Real-time analytics – Analytics on demand and in real time. Also, embraces integration of both data mining and text mining capabilities. BI and search together. The term “360-degree view” is returning (although it was way over-used the first time).
• And of course, search in the cloud as a service – New vendors are appearing rapidly. Amazon provides a search service as part of their EC2 suite, for instance.

Note the absence of “federated search”. It really depends on what you mean by it. The formal definition, courtesy of the search industry, is posting a search query to the search engine of a foreign system, getting its results as a simple ordered list (no relevancy scores, facets, metadata, etc.), and listing the results separately along with results from other sources. You can’t integrate the results of course because whose #1 result is really #1? And there are no facets or other advanced search features.

By this definition federated search has been around since the 90s and was generally considered the lowest common denominator of search – a quick fix solution for responding to the need for heterogeneous environments. In fact, federated search used to be a separate sub-market of enterprise search, but it disappeared due to lack of demand.

Now, if your definition of federated search is more about true search integration (“integrated search”), where data from all the sources is indexed in one location so that results can be returned with one relevancy context, then it has much more relevance to our discussion. However, even this is not what I would call a major trend as it has been a tenet of enterprise search for a long time. The trend, if any, is properly including structured data into the mix.

As for Dice, Entelo, Gild and TalentBin (none of which I am familiar to be honest), are clearly squarely focused on Recruiting. Our observation entering the recruiting market is that it appears slightly behind the latest capabilities of the broader search market. Expectations have been for more basic capabilities that have been in the industry for years. But then I may be missing something specific that we haven’t hit on yet, and certainly some of the broader capabilities of Search may simply not have much value in Recruiting. By the way, the only vendor we have come across is Daxtra.

This is a big one.  Is Boolean search dead?  With tools like Konasearch, do you think that sourcing has a future as a dedicated function?

No. Autonomy said this 15 years ago (Autonomy is based on Bayesian logic), and it was wrong then as well. It still forms the basis of pragmatic search logic. And its close proximity to SQL means that it can embrace structured data easier without compromising the cardinal relationship of the RDBMS. But, this does not mean users should be entering Boolean searches, despite the fact that we see Boolean searches entered all the time by our recruiting customers.

The ubiquitous search bar today may be fine for web search but the enterprise demands more context from the user and data. Think of the search bar as the search UI of last resort. As search becomes more integrated into the fabric of the application, information appears in context from the search engine because the context at the time can generate the search query automatically. Example: matching candidates to job orders and job orders to candidates. The search uses the profile of the context record as the basis for the search query. The search query, however, is still Boolean.

Can other machine-learning technologies be included, like Bayesian logic? Sure, but carefully. We find interesting the continued resistance to auto-improvement of search results, where the same search can return different results. It’s generally viewed as chaos – rightly or wrongly, people equate consistency with accuracy and trust.

For all the sourcing gurus out there, tell us a little bit about how your search results are generated and displayed.  How can it be used for sourcing, if at all?  And why is recruiting so bad at lead generation when marketing is often so effective at it?

We present a highly automated, template-based search UI to our customers. The ability for us to generate a full search page in 1 or 2 days is part of our attraction. A good search page for our recruiting customers is made up of 4 components:

• General search bar for searching all fields;
• Filters (text boxes, drop downs, check boxes, radius search, etc.) for searching on specific fields;
• Search results in a tabular format focused on one specific object (e.g. Candidate, Job Order), although the searched objects may be several – Note: there is a bias here for our clients – the familiarity of the Salesforce report;
• Dynamic facets as a more intelligent and efficient way of filtering, or refining, the search (more than filters).

A lot of the more general Intranet-based enterprise search solutions embrace reputation engines, recommendation engines, sentiment analysis, visual trending, etc. as a way to introduce more predictive analytics. The theory is, if you have a 360-degree view of all the data and content, and you leverage search qualitative analytics to answer “why” something happens, you can introduce prediction. There is an important distinction here: this is search used primarily for exploration in contrast to just plain finding stuff. Both are valid, but in recruiting, it is essentially about finding stuff.

As for lead generation, you are making a statement I don’t disagree with (Recruiting is bad at it), but we’re not seeing a strong desire to fix it. Our clients do not appear to suffer from lack of Candidates or Job Orders, more the ability to be first and best at matching them up.