Estimated reading time: 9 minutes
Hung Lee invited me to talk on the Brainfood recruitment show on “how to build social capital with programmers”. The show airs today here, and will be available on replay at the same link. While gathering my thoughts, I wrote this article.
What is social capital? Wikipedia says: “the networks of relationships among people who live and work in a particular society,”
Offline vs. Online
Back in the days before the internet, the only social capital you could really build was offline and in person. Well, building relationships face-to-face is the quickest way; you can touch, hear, smell and see the person directly with your senses. Even if you don’t realize it consciously, your subconscious registers and remembers a personal meeting stronger than a video call because all your senses are involved.
If you meet in person, you likely live close to each other, which keeps a stronger perceived bond. Your subconscious tells you: If you betray one another, you might bump into each other when shopping in the supermarket or while walking around in town. So, behave! All this makes it easier to build social bonds and capital.
Yet, personal meetings carry huge costs; you have to travel and “really be there”. You have to chit-chat and engage in a depth that is inadequate for business. James Osborne said on the Brainfood show: “all the bullshit from business disappeared over the last 12 months.”
All the networking events, the constant “who knows who” and the noise was removed once we switched to a 100% online life.
When you hop on a (video) call now, you want to resolve an issue and move on — no time or desire for chit chat. So, how to bond?
Don’t bond with idiots
Here is some maybe surprising news about relationships: The best is to be picky, don’t build social capital with anyone, only with people who aren’t idiots. In the book “The Basic Laws of Human Stupidity” the author points out that 5–10% of any population, be it simple workers or CEOs of Fortune 500 companies, are idiots; the definition is someone who causes damage to others without benefit to themselves. This is clearly distinct from bandits who harm others with benefit to themselves or martyrs who suffer so others can benefit. While bandits and martyrs cause issues, idiots are the only group that causes a net negative to society.
Don’t waste time on idiots: Once, a candidate told me in an interview they would like to work with Java, Python or Node. I asked them why, as these programming languages have little to do with each other; Java runs on the JVM, Python is often used for scripting Node is more for frontend people who want to implement some backend logic. The person told me: “I don’t have time to waste on you to explain to a recruiter why I prefer one programming language over another.” I ended the meeting politely and archived his profile. If you can’t build rapport with a programmer on a technical topic, you will have a hard time working with them.
Avoiding idiots certainly is easier said than done. Unfortunately, there is no algorithm for spotting idiots, you have to just meet enough of them to develop a gut feeling which will help you to avoid them in the future: “You can’t make a good contract with a bad person” — W. Buffett said in a recent interview (I saw this video an hour after I wrote this paragraph — a fun coincidence)
How to build relationships with non-idiotic tech people
Now, that we know that we should avoid idiots, let’s think how to do this. The most profound rapport you can have with someone is shared experiences. Sometimes having immigrated from the same country is enough, at other times you need more things in common, like having studied in the same exotic city.
I once bonded with a candidate because we both a semester in Tomsk, Siberia, as exchange students. He was there during Perestrojka, the though transition from the Soviet system to a new one. So, it was quite interesting for us to exchange different views of the same place at different times in history.
If you don’t have such concrete commonalities, you have to focus on other topics.
If you want to build rapport with developers, you need to understand that your personality, as a recruiter, and theirs, as developer, likely is very different.
As a recruiter, you’re likely a “people person”, someone who bonds quickly and also over “trivial” things. Many technical people don’t function in this way. I read recommendations online that cold approaches should start with a comment about a hobby that you saw on their LinkedIn. Albeit some personalization is better than none, talking about deep technical topics from the start works best in recruitment cold emails.
Engineers need “substance” to build rapport, but how can you — as a non-technical person — have “things” to talk about?
You won’t get around getting some functional knowledge. The fastest way is to read certain news sources. For instance, read Hackernews, a site where most Silicon Valley people hang out, is a good start, or at least the tech section of Google News.
By reading the headlines regularly, you learn stuff where you don’t need to be able to program to understand it. For instance, that Java8+ has lambda expressions, a convenient language feature, or that Angular2+ is much more modern than Angular 1. Such “news” are several years old but don’t get stale.
How this helps with bonding: Some systems still run on legacy systems (old Java or Angular 1) and many developers are happy to switch from old versions to newer ones to stay more relevant. If you can mention things in a call such as “I see why you want to switch from Java 6 to Java 11, I get why, lambda expressions make your life as a programmer simpler”, you’ll stand out.
Alternatively, you can learn to talk briefly about technical principles that never change. These are more complicated topics and they will take you longer to grasp but showing knowledge in these areas is impressive. You can reference, for instance, the following things when discussing if places are good to work at or not:
- Firms should use source code version control, which is a basic prerequisite to be a software company to track any code changes
- Software testing is important; it makes sure that the code can be changed (refactored) and doesn’t “break” existing functionality
- Good firms follow principles like KISS (keep it simple), DRY (don’t repeat yourself), YAGNI (you aren’t going to need it, don’t program stuff that has no use now); these concepts can be beneficial to you in your daily life outside tech, as well.
- Try to understand Joel Spolsky's 12 point list about what makes a good technical team; he wrote it over 20 years ago and it didn’t lose relevance; do the companies you represent fulfil at least some of these 12 points?
Offer Career Coaching
Maybe this point is most accessible to (good) recruiters and gives the biggest benefit to candidates: Developers are strong at technical topics, but they are almost always weak when it comes to most career-related topics. I don’t remember even one meeting where I couldn’t offer at least one or two tips that engineering candidates found useful. Typical topics on which a recruiter can give advice are:
- How to make a CV that is easy to read
- How to ask for a raise/How to negotiate a salary offer
- Share knowledge of current market rates
- Share knowledge of local labour laws, what are employers allowed to do?
- Give tips on general “good” behaviour in an interview
See these two tweets as examples:
I even wrote a guide that covers mostly career topics: “Coderfit: All you need to know for your programming career”. Some readers even come to me for paid coaching sessions on these topics, so there must be a need. (And for me, it’s a nice change from the daily agency grunt work)
What is the goal of all this
Developers tend to be very extreme; they can be either very pleasant, likeable and be a charm to work with or they can be the most annoying humans you meet in your entire life (and the bad interactions will stay with you forever). I wrote about the problem of having to deal with difficult people in a blogpost about recruitment and depression.
Rapport isn’t part of the job of most developers. They think of themselves as masters over machines, not great communicators with humans. The way most companies treat developers, that is, in a “non Sillicon Valley” style, strengthens this problem. Software engineers in most places are shielded from the business and never get the chance to properly learn how to communicate or what matters outside of technical problems.
We operate in the most crowded market out there. In five years of recruitment, I have always been “on the candidate site” if there is a dispute, a lowball offer or other mistreatments. In the last six months I had it regularly that candidates were mistreating the companies. Now, I was on the company’s site; some candidate requests were just insane, and unreasonable (and yet still, the companies caved in to some demands). Pro tip: If you can build rapport, you’ll likely be able to avoid situations where you’ll need to meet crazy demands.
We have to do more than just introduce developers to companies; we need to focus on building stronger relationships by digging deep during the interview (e.g., resulting in stellar candidate notes) and staying in touch “forever” (your ATS should have a snooze function; our klang.so ATS has that).
Recruiting is fundamentally about doing placements in the short-term, but also about building relationships in the long run. If you fail to do placements, you’ll go bankrupt; if you fail to build relationships, you’ll burn out.
If you can show a little bit of willingness to understand what the programming profession is about, you‘ll do fine. 👍
If you like my writing style, you might also enjoy:
We have built klang.so to make recruitment suck less for small recruitment firms, book a demo to hear more (iwan@klang.so, +1 (551) 261-5955), or leave your contact details below:
By Iwan Gulenko
By Iwan Gulenko
