In my last post I described our squad as a bunch of full stack domain-experts, but the main focus was on team dynamics and team-issues. This time I would like to highlight the advantages and disadvantages of working on separated domains, as, in my opinion this is the way recruitment agencies can differentiate their service, and brake the common preconception about dummy recruiters who believes libraries are only for borrowing books.

Our model

I like buzzwords, so I named our model ‘Domain Driven Recruitment’. In a nutshell, we are a small recruitment agency with IT focus, and all our consultants are working on different domains, like low-level languages, Frontend, UX, Testing or Product. If you are not familiar with recruitment agency practices: it’s kinda different from the ‘common’ model, where the domains are separated to activities, like seeking people, interviewing them, consulting with partner companies, developing the business and so on…
I think if you would like to keep your recruiters’ enthusiasm and your quality on a high level, training domain experts and building up a domain driven recruitment agency is a good way, with a few pitfalls. So let’s check my reasons to love and hate our model so much!

Why is it powerful?

Firstly, I would like to emphasize, that although I can point out numerous issues around our model, I think the benefits are more important as they have more influence on the quality of the service. Here are my main pros to implement our model:

• Match recruiter’s interest to the domain

It’s the first step when you hire a new recruiter, and it’s much more important than you think. For example, I have a teammate, who loves embedded devices, playing with raspberry and linux modifications in his free time. When he joined our team, we had no embedded specialist, so it was obvious to give him the openings of this domain. He was (and still is) impressed by the candidates, everybody could feel his true interest behind his questions, and because of this he is able to get some really good and personal stories beyond ‘I like new challenges and solving problems’.
I think if you are a recruiter (or doing anything else), having some interest for your domain is necessary, and this leads us to our next and most painful point: the deep ocean of domain knowledge.

• Time for building domain knowledge

Earlier I read some brainstorming about the necessity of recruiters’ understanding of software development, but it shouldn’t be a question. Understanding is a must, but if you love your profession, you should be curious about it anyway. If a recruiter is working only on 2-3 domains, s/he has time and energy to dig deep and understand the processes, explore the differences between languages and/or frameworks, participate on meetups or conferences and so on. It’s a bit similar to software development: if you are dealing only with frontend, you can follow the trends and news, but if you are a ‘full stack’ developer, rapid prototyper or anybody, who deals with various technologies at the same time, it’s really hard to keep your knowledge up-to-date.

• Building a meaningful network

You can find some “open networkers” and random recruiters on linkedin with 10.000+ connections, and to be honest, it’s a bit sad and funny for me. I think taking care of 500 people in your network is still a big deal, but after a few thousand, a ‘personal’ network is getting meaningless, impersonal and losing its substance. If a recruiter has to work on just a few domains, it’s easier to keep her/his network alive.
About meaningful networks you can check out this one; it’s pretty long but worth a read: http://firstround.com/review/dont-just-network-build-your-meaningful-network-to-maximize-your-impact/

• Joint effort for the partners

We have many partners, where we are looking for quite different guys, like PHP dev, Data scientist, UX researcher and Product owner for the same company. For a partner like this it’s faster to discuss the different roles with a domain expert, than a general key account manager, and finding the right people is easier because of the live networks and the aggregated effort of more recruiters.

• Effective business development

Earlier, when I worked on the enterprise side we had many discussions with sales people of recruitment agencies. These discussions were mostly awkward: we talked about literally everything, I mean bad things as well, and there were no questions, only nods. When we are talking with a possible partner, we are able to ask truly meaningful questions for the first time, regarding tech stack, product strategy, team structures and so on. This understanding enables us to shorten our discovery process and start the work earlier.
So basically that’s it: if you are building up a team, which leans on the individual’s personal interest, you provide them time to dig deeper into a domain and spread the different tasks/roles, everyone will be happy and productive as hell.

Issues which need attention

These issues can cause many troubles, and you have to pay a lot of attention and effort to solve them, but they are still inside problems, and if you are well prepared, none of your partners will feel your pain.

• Somebody quits, network and knowledge also quits

There is no company without churn, but hand-over and knowledge transfer are highly challenging when a team member has his own well supervised territory for years. I have no silver bullet for this problem, I think with fair documentation of candidates’ processes could help a bit, but building a network is not equal to have resumes, phone numbers or mail addresses. A smart onboarding for newcomers is also useful, but getting the domain and market knowledge takes time, no matter the level of enthusiasm or interest. I think this is the biggest issue with domain separation, but at least your recruiters will feel their value (:

• You need people who are interested in IT

I think there is no need for further explanation, it’s simply hard to find people, who are interested in software development and recruitment also. The real magic is to recognize the talent of a junior fellow, who is not aware of her/his interest because s/he has literally zero knowledge about IT or recruitment.

• Building T-shaped knowledge for newcomers

All of our consultants have a T-shaped knowledge: some general understanding about software development, from product management and agile practices through infra and backend development to frontend and UX, and a dedicated domain, such as mobile development, embedded devs or product owners/managers.
One trick is to recognize the depth of the general knowledge and the way to ‘teach’ it. The other is to help to dig deep into a domain, which is not covered by any of the current team members.
A good start for the general understanding is some videos, like ‘something’ (put here a Docker, AWS, backend, frontend, mobile development or any tool or language) explained, there are plenty of quality channels on youtube as well. My other favorite is the conference talks, like GoTo, TNW, Google I/O, XP days or any big happening, there are amazing speakers with really interesting topics. Of course personal mentoring is essential as well.

• The limited number of different domains

Hitting a developer with the same position, especially from the recruiters of the same company is pretty amateurish. As an agency is growing, more partners and more positions are coming, it’s unavoidable to have more recruiters on the same domain. Building the knowledge is much easier in this case, but amateurish moments like the one above can also happen more often. Radical transparency and smooth communication is the key to solve (or at least to reduce) this issue.

• Only agencies can apply

If you see the potential in this domain driven model, and you are working in the enterprise world: I have bad news. Applying this model on the enterprise side is a huge pain in the ass, as not all the companies have enough domains for every team members, and the priority of the roles are changing quite often. However building up an inhouse agency model is not impossible, but I only met bad implementations so far, so I guess it’s not easy :)

That’s all folks; the domain driven model is really powerful if you are working for a small but quality focused agency. It enables you to understand companies fast, reach developers’ respect and match their interest to the perfect opportunity, and to get better than your competitors. Prepare for the difficulties, beat them, eat healthy and sleep well.

Next time I will explain where we failed in practice, and what we changed in our model.