How to Build a Dream Team Using Recruiting Antipatterns

In general, the world is not unipolar and pattern does not mean good in the absolute. Moreover, the world is not bipolar, and most often template solutions work with minimal benefit in the format “and so it will do.” Hiring a team is one of the burning topics among those who do not know how to hire, among those who think they can, and among those who are disappointed and think that anyone can manage, if there is a process and money, it will go there.

Quality+Speed+Price

Everyone’s favorite Euler-Went diagram with an almost scientific justification for the “long/expensive/bad” reasons. In fact, it should look different: responsibility plus competence. Responsibility without competence – gives only nerves and a blind game. Competence without responsibility – requires justification of the results. The presence of both – gives results within the promises. Just what you need.

During a technical interview, in addition to banal technical questions (where it is already clear that a person gets out or understands how everything works), I often use questions that are poorly answered by irresponsible people.

A responsible person is always able to recognize the limit of his ignorance and incompetence, to yield the task to a colleague who knows how to do what is required in it.

An irresponsible person follows a simple path – delaying a decision, overestimating the price of a decision in the eyes of a leader, denying the possibility of a decision, changing the topic of conversation, and other ways of avoiding a real goal. Model “neither to himself nor to people”

A responsible person can delegate work to a professional and is able to respect those who understand any topic better than him, so I can quite entrust the development to a contractor, and instruct an internal specialist to control them to the right extent, accept the result of the work and adapt it to our realities. The combination is excellent – the term is minimal, the quality of the internal specialist reaches the proper level, the price is average market.

Appropriateness vs Cunning vs Technical Skills

In general, it is not correct to put “vs” here, but if you do not understand what softskill and hadrskill are, then it turns out that at least one of them “vs” remains 🙂 Let’s try to get around this problem as well.

In general, what do we expect from an “adequate person” in the team? Minimal: compliance with the surrounding team, keeping promises. Someone has other requirements, but I know little about them, so I can’t speak.

At the stage of the interview and even the first 2-3 months of communication and work, cunning can be mistaken for adequacy and the presence of softskill. If the leader does not know how to cut it off at the very initial stage, then then the cunning and completely stupid team will have to be dispersed. It’s understandable that the manager will feel internal guilt for the dismissal and will begin to choose between solving the situation in the bud and whether to become cunning himself (the second happens 4 times more often than the first, at least – this is the rating that I saw from the outside.).

More and more often, the ability to brazenly lie is called “softskill”. It can’t be cut in one technical interview. Most often, trying to catch a lie in a single technical interview discards truly broad-based and experienced specialists and hires only those who can do one thing.

Technical skills – can also be different. For example, many team leaders are quite capable of writing something simple in the linux console, like:

sudo docker ps -a | grep Exit | xargs docker rm -f 

But this does not mean that a person can design and build a failover cluster under docker. Technical skills in writing commands, writing code, using frameworks are almost nothing compared to the skill of systems thinking and understanding how it really works and what can be done with it to achieve the goal.

The best questions on the topic will have the format of finding several solutions to this problem. An example can be simple: “We need to process a post request with json, write data to the database as quickly as possible, the response is always static 200 OK. We need 3 solutions.” In general, there are a lot of options here, depending on the technology stack used and on the environment.

let us suppose

Suppose we have found responsible people who are competent. Those. their promises match their results. Almost a dream team if people behave adequately (no offense, no fears, and so on). The method is as simple as possible: provocative questions. This is where anti-patterns come in:

  • Let’s talk about religion, shall we?

  • Let’s talk about politics, shall we?

  • And if I pretend to be an idiot, will he understand that I’m testing him? Will he take it as a joke or spread paranoia?

What’s funny is that several CEOs with whom I had to work did not pass the last point for 2022. And the first two points are extremely afraid to discuss almost any leaders who do not have experience in communicating in a company of mutually respectful people.

The result of hiring a team

Will we quickly find a team like this? No, not fast. But the advantages are obvious – a stable team, which can handle everything they say “yes, we’ll do it.” Opportunities to scale the business by transferring microservices to contractors (it is important to find responsible ones too).

How to manage such a team is probably the easiest question. In short, no way. It is enough to prioritize and no additional management or complex process that needs to be managed by the sweat of your brow is required. The manager can safely engage in solving his immediate tasks – ensuring the work of the department for internal and external relations, accepting new goals, expanding the team, and so on.

The most difficult question is perspective. Personally, I had the following objections and the following answers to them turned out:

  • People will leave, it is not known whether the rate of hiring and the rate of leaving will converge. Answer: it makes sense to create such a team only when there is internal growth in the company, then a person will go through several steps in the company and the speed of hiring and leaving will converge with good reserves in favor of hiring.

  • With the rapid growth in the number of tasks, you will need to quickly hire a few people and this will not grow together. Answer: it will not be required, since the growth of tasks will not occur in terrible quantities. The thing is that a result-focused team generates very little technical debt, highly coupled code, and other sudden bug generators. The number of bugs in working with the existing service is around 1-2%. In working with a new, from scratch, written service, sent for various tests (loads, functional, test implementations, first real implementations) – 10-15% with a decrease to 1-2% for the initial period of active bug control.

  • Salaries and promotions – for long-term collaboration, you need to index the salary, sometimes indexing is perceived as a freebie and reduces the level of responsibility. Answer: give the initial salary above the market, so that it is enough for 1.5-2 years without increases. Do not index the salary for a person who does not grow in the company. For us, the growth of the money we receive is always associated with the growth of the zone of direct responsibility. For a good specialist who has studied all the systems and services with which his work is connected in 1.5-2 years, who has worked with contractors, who has gone through 2-3 successful product implementations, there is always growth, simply because it is profitable for the business.

Too rosy

I understand how this article sounds to most. Actually, that’s why I write, because there is no point in writing about everyday life. To understand why I needed all this, I will describe our environment (what we are doing, why and why):

We create highly reliable technical solutions for the needs of infrastructure, data transmission, data processing. A number of projects have a requirement in the form of “0 bugs per year on combat systems” (of course there are hundreds of test systems for this with the same load, but less requirements).

The basis of our processes: test base, i.e. nothing can get into production “tomorrow” or “in a month”. Everything must go through a sieve of test implementations, bugs must be found, corrected, and only then it will go to the end user.

Technology stack:

  • Debian Linux 9/10/11, Raspberry Pi OS

  • Core code in C, C++, Part of Golang services

  • Web interfaces: PHP 7.4, Yii2, vue.js, jQuery (don’t laugh, but sometimes it’s optimal for us to just have one jQuery on the front)

  • PostgreSQL database

  • RabbitMQ

Similar Posts

Leave a Reply