“Don’t hire the person you don’t trust, and trust the person you’ve hired.”
Who I am, what I am sharing and why you might be interested is indicated in the first post.
Disclaimer: I do not tell you how to make games correctly, but I tell you how I experimented, learned and continue to develop in this direction.
In the previous parts, I have already shared my opinion “why people might want to join an indie team” and wrote about where you can look for such people. Now I want to dwell a little more on how to accept them into the team, how to live with them, how to share development and what features of “free development” we have identified for ourselves.
ACCENT: I am describing only the experience that I received as part of the work on the current project. In other companies, I hired people for money, but at S.O.S. we all work on enthusiasm – for free. We have our own non-material motivation. In this case, onboarding priorities differ from those that are present when working for money. Further – the scheme of the “free team”.
The bored HR of our team.
In my opinion, working with personnel is like sex: everyone has heard about it, everyone in theory understands how it is. But until you try to hire and fire yourself, you won’t understand how it works. Advice for those who are going to hire staff: start as soon as you feel the need for personnel. And be sure to do it yourself, with your own hands. You have to determine in advance for yourself:
The criteria by which the primary screening will occur
what can you promise the person as a reward or other benefit they will get from working with you (in the short and long term)
how to explain to a person why he should come to you
how will you check the candidate
how to evaluate the result of a test task and form primary long-term agreements
how to carry out onboarding (integration into the team) of candidates
But hiring a team is half the battle. Until you “fire” two or three people, it will be difficult for you to understand how effective your item # 1 from the above list is. With each “exit” point # 1 will be corrected. You will understand how the first interview affects this: with each new dump (and there will be many), you will be able to more accurately predict whether a candidate is suitable for you or not.
After you go through the “hiring and firing” 3-4 times, you will be able to set up the first option of the onboarding procedure. The goal of onboarding is to minimize the amount of effort and time it takes to enter and leave a team. Automate the process as much as possible.
Currently, at the time of initial acquaintance, we ask:
Motive: Why does a person go to gamedev? If he answers “I want to try,” then it won’t work with him. This is not the one who will benefit you. He will try endlessly, and then leave, since the gamedev turned out to be not quite what he expected.
Does the candidate play games? 100% of those who DO NOT play games at least a couple of times a week for fun, but really want to get into the team / want to play game dev, fall off without even completing the test task. If a person is not a player, I advise you not to waste time on him, and not to hammer his head. You and him simply do not have the same views on fan. You are rushing from the game dev and the creation process, but he does not even understand this fan.
What other projects does the candidate have, what is he involved in? If a person is already a member of some indie team, works, got a dog, went to study, plays in the theater, loves auto racing, draws, a volunteer and generally a super active person, and for complete happiness he lacks only participation in your team, then don’t take it. He won’t give the project enough time. The optimal formula for a candidate’s loading: “I work, I want to do my dream in my free time, I’m free for 20 hours a week”.
In our practice, people left the project when they only had a second child. In the classic situation with two parents, this is not a sentence. So do your research beforehand.
What kind of experience? Obviously, free of charge is critically difficult to find a professional to do half of the project for you. It is also clear that those who cannot do anything should not be accepted. The candidate must have minimal knowledge. Examples: the developer must be familiar with the engine and programming language, the animator must be familiar with a set of programs, the level designer must be familiar with architecture or design. Here, the very certificates of online courses that are now coming out of every advertising banner will be very useful. They are not critical for hiring, but for an indie team, yes.
It is especially great if the candidate tried to do at least something himself and he has something to show. Even if it is from the category of “stick, stick, cucumber”.
We estimate “by eye” the level of enthusiasm. This is a very biased indicator. It can be just a feeling of communication or a subjective assessment of the degree of adequacy. Vkusovschina, if I may say so. Rather, it complements the portrait of the candidate. Helps when you hesitate to take / not take. Can help lean in one direction or another. But, of course, one cannot rely on this alone.
If you follow at least these rules when onboarding, then with a high degree of probability you will select good guys for your team.
And then you need to give the candidate a test task. I would recommend giving a task that really exists and is useful for the project. Not some already closed case, not a question to which you already know the answer, but something new. This will test motivation, initiative, engagement, and self-reliance. If you start looking for the answer to the question yourself – wonderful, you are on the way. If he starts to “mumble” and asks what to do, how and in what program – look for a new one, this one will take your time. You need a person who will offer solutions, even if they are wrong at first, but for indie in the beginning, initiative and desire to develop are more important. Well, make sure not to give overwhelming tasks. Unless you want to fail the candidate at the start.
At some point, there are a lot of people, and there are more and more materials in the project with which everyone needs to be introduced. Therefore, the leader will need a deputy / assistant / new PM to take over these responsibilities. This moment can be easily identified by the fact that you do not have time to create a product and increase its value.
When we outgrew the threshold of 14 people, I stopped having time to do management, onboarding newcomers, overseeing build production, discussing game design solutions, marketing and everything else that required my attention. At that moment, the producer brought Masha to our team. In almost six months, she managed to debug onboarding processes, created a Velcomtask in our tasktracker, created a personnel folder on Confluence, and more. We can say that thanks to the emergence of a separate PM, by the spring of 2020 we were able to grow to almost 30 people.
Masha in our team has already been replaced by Zhora, who has successfully integrated into the current system and continues to develop it.
Look for a PM for yourself when you feel that you are drowning in administration.
Finally, a small life hack from the Rummy Games team. Empirically, we have found that it is easier for people to work in pairs. It is necessary to exchange ideas, experience, mastered technologies, opinions. It is very difficult to do this alone, with yourself. And when a partner appears, it is easier and more interesting for both of you to do your magic. The involvement and interest in what is happening increases, the emergence of results on the current tasks of the project, the general set of experience and level-up, accelerates.
before increasing the team, develop procedures for entering, escorting and exiting people;
after there are more than 10 of you, think about finding a person who will take over all cross-functional interaction in the team, personnel issues, administration;
trust newbies, give them work. You will not be able to drag everything yourself, functions and tasks must be delegated;
cultivate a work environment. You do the project together, respect each other and support. If the person needs rest, let them go for a few days. This will ultimately benefit the project;
trust but verify. No one, no matter how much you trust him, should not be left floating freely. Constantly you need to adjust the course and focus. Otherwise, you will be making different games, not just one.
The atmosphere of mutual trust, respect and regulation of the basic processes will lead you to the very feeling of a common cause, something big and common. To something that can develop and grow. This is one of the foundations of intangible motivation.
P.S. I could easily make a full-fledged longread out of this post, since I did not write a third part on this issue. But we still have many topics ahead, as well as the launch of a live show on our development, so I will share with you something from this area more than once.