This text is a translation of an article originally published on DOU.ua.
Hello! I'm Igor Stepanov, a Senior Team Lead at Plarium. I’m currently managing a group of other team leads and technical leads, and I’m responsible for all things technical on the client-side of the company’s flagship title RAID: Shadow Legends.
At the start of my career, I wasn’t fully aware of all the options that I had to grow as a Unity developer. The first projects I worked on were small, and the theoretical knowledge I had didn’t provide me with an understanding of what’s needed to solve more complex problems.
Back then, it seemed that the only way to build a career was to lead a team of other developers as a team leader. But in fact there are many options. You just need to understand the different types of career growth that are out there, figure out which one is closer to you, and start acting.
Using the RAID: Shadow Legends client development team as an example, I’ll describe the career growth options for a Unity Developer. Let's go!
When you start building a career, it’s not immediately clear how to evaluate your development. Some developers can work in one position for three years, deepen their expertise, and make improvements to the code they work on, but still feel like they’re standing still because of a lack of vertical development or a promotion.
Career growth can be horizontal or vertical. Horizontal growth means studying new technologies and approaches, and deepening knowledge you’ve already mastered. Vertical growth is about expanding your obligations and responsibilities within a new role. This development can be both with an emphasis on management or technical skills.
Let's say we have developers Bob, Joe, and Larry. At point “0”, the start of their careers, each of them is at a base horizontal and vertical level. Bob was only interested in vertical development, Joe only in horizontal, and Larry wanted optimal career development. By his third year on the job, Bob hit the vertical ceiling for his technical level, and Joe hit the horizontal ceiling for his position.
Meanwhile, Larry continued to actively grow horizontally, taking on more and more responsibilities. Even if, over time, Bob and Joe want to move in a different direction, Larry will have more freedom of choice and his career will continue to develop actively. The area of the resulting figure can be seen as an indicator of successful career development.
It’s better to start with active horizontal growth, regardless of your plans for the future. A high level of technical expertise is a powerful argument for development in any direction.
Think of horizontal development as working with the foundation of your career: the stronger it is, the more prospects you have. You don't have to move exclusively vertically to increase your value. Horizontal development is no less effective.
It’s a mistake to think that the path to building a career is universal. On a small project, a complex hierarchy isn’t required, so there will be less opportunity for vertical growth. But horizontal development will be a necessity: there are few people and everyone will have many responsibilities.
On a large project, there will be more opportunities for vertical growth, and horizontal development will require you to show more initiative.
Always keep in mind that you’re building a career not only in a global world, but also on the basis of a specific company on a specific project. Consider the needs of the market, the company, and the product you’re working on. Your big-picture plans do not have to be tied to any specific place of work, but each individual step you take at any given moment will take place within a specific environment.
All the appointments I made of people to positions like team lead, tech lead, and architect were predictable and did not come as a surprise to anyone from the teams I worked with. This was down to the fact that the people I appointed had actively developed horizontally, showed initiative, and took responsibility. Therefore, giving them a new position was a logical step for which both they, and the whole team, were ready.
Horizontal development happens when you perform a certain set of tasks within a specialist area such as payment systems, metagame features, or plugin integration.
Choose one or two priority areas for yourself. Bear in mind though that it’s not worth changing areas of responsibility and trying to expand your experience into new areas more frequently than every six months. If you don’t spend enough time working in one area, you may not gain the experience you need to confidently perform the tasks you’re responsible for at a high level.
Monitor your own situation, and ask yourself often the following questions:
Regularly ask for feedback from your manager and from the people whose technical opinions you respect. In addition, 360-degree feedback will help “calibrate” the assessment of your work. In the RAID team we try to conduct 360-degree feedback every six months in order to see the results in a comparative perspective over time.
If you are already fluently performing your tasks — regardless of their level of complexity — you should not be tempted to stop at your current level. Ask your manager what other technologies and techniques might be useful for your team.
For our team, we outline development options in the format of specializations. This allows for objective, transparent tracking of each developer’s growth process.
Specialization, the context of the RAID team, means a specific area of knowledge within which a developer can perform planned tasks, solve problems, and prevent issues from occurring in the future. Our areas of specialization include metagame features, battle mechanics, payment systems, integration of third-party libraries and plugins, and game audio.
At Plarium, developers begin their journey by specializing in the metagame features of the game they work on. This allows them to learn all the key information about the game, including its modules and the principles of their interaction. As the employee progresses, we discuss what other specializations they’re interested in and how those specializations relate to the needs of the project. As such, we build for that employee an optimal horizontal development strategy.
When we have a developer adapting to a new specialization, we assign them a personal mentor who is experienced in that area of work. As a first step, the developer receives introductory instructions, and gets acquainted with video materials and documentation on the topic. They then perform some typical tasks in a test environment, after which they proceed to performing tasks in a live environment.
We have at least two to three developers covering each of our areas of specialization. This allows us to plan our workload so that in the event of vacation, sickness, or force majeure situations, we do not have gaps that no one can fill.
We always encourage our employees to develop themselves, given our belief that implementing non-standard solutions leads to worthwhile individual growth. By giving our specialists this room to experiment, they have the opportunity to find a route to achieving any goal they want faster and more easily in the future. It’s a win-win situation not only for the person who comes up with something new, but also for the whole team, which is exposed to new expertise based on solutions that have been implemented.
Here is a simplified visualization of my recommendations for setting up a horizontal growth strategy:
For vertical development to take place, certain conditions must be met. These include that an employee must have the opportunity and aspiration for vertical development, and that the company and the project have a need for it. When we compare it to horizontal development, we see that vertical development should be planned as far in advance as possible.
When a specialist is preparing for vertical development, we offer them additional responsibilities. If, having taken on those responsibilities, the specialist shows consistently good results and a desire to grow, we then offer suitable vertical development options.
To determine what vertical development strategy is best for you, look at the two options below and decide which of them you have a stronger preference for:
Neither option precludes development in the other. Having chosen, for example, to become a team lead, you will not stop developing your technical skills. Equally, having chosen to become a technical lead, you will still develop administrative skills.
If you are worried that in a managerial position you will not have time for coding, consider these time breakdowns of the members in our team:
Thus as a team lead, you still have time to continue programming.
To decide which kind of vertical development is right for you, ask yourself: are you more interested in the individual development of employees or are you more interested in designing technical solutions and working with project architecture?
Regardless of which option you prefer, you need to consider both – the development of the team and the development of the project. After all, one cannot function without the other.
Here is a visualization of how to set up a vertical growth strategy:
If in the future you want to become a tech lead or a team lead, then working now to mentor new employees or helping developers adapt to a new specialization will act as the perfect test run.
Mentoring is a great opportunity to take your administrative and technical skills to the next level. While explaining something, you will yourself learn to structure knowledge. What’s more, taking responsibility for the results of the work of your mentee will help assess your readiness for vertical growth, and make you better prepared for it.
On the RAID team, mentoring is considered a fully-fledged task in itself. Our approach is to partially lighten a developer’s workload to allow them room to provide mentorship to others. Often, a beginner mentor will be assisted by a more experienced one. Together, they’ll come up with a strategy on how to communicate information, they’ll set up a schedule for feedback to flow in both directions, discuss problems and difficulties, and summarize their findings.
Another way to develop in terms of administrative skills is to perform tasks as a feature lead.
Feature lead is a role we introduced to prepare an employee for potential vertical growth, to give them the opportunity to take on more responsibilities, and gain the necessary experience on real tasks. Within this role, an employee is assigned responsibility for a particular task, as well as for the timing and quality of work of other developers assigned to work on it.
Within this structure, the team lead responsible for the release delegates part of their authority, but still remains responsible for the quality of the release overall, and for getting it out on time. They do not micromanage the work of the feature lead and do not go into the details of implementation of that work, or monitor that it is completed on time.
Feature Lead responsibilities include:
In taking on these new responsibilities, the feature lead will learn skills of organization, time management, and prioritization. As the project progresses and tasks become more complex, the number of developers working on features increases. This can be thought of as a single micro-release within a larger one.
The feature lead manages everything and gives everyone feedback on their progress. At first, they will likely consult a team lead on questions of management, or a technical lead on the specifics of technical implementation. But as a result they will gain enough skills to eventually solve problems of any complexity on their own. In the long-run, the Feature Lead can even take responsibility for the entire release.
On the RAID team we really like this approach, and find that its results greatly influence our decisions on assigning developers to new positions.
The position of team lead involves the management of a development team. The team lead takes responsibility for dedicated releases, team development, and process improvement.
As part of mastering the team lead role, a developer will have to largely rebuild their habits and approaches to work. In my last article, “7 Misconceptions of a Beginner Team Lead,” I shared my personal experience of such a restructuring.
You need always to see the bigger picture as it pertains to individual tasks and the project overall. This skill you can already learn when you are a developer. The practice is as follows: when you receive a task, analyze why you need to complete it, but also look at what problem you are currently solving, and ask whether it can be done more quickly or easily.
To give an example: while a developer has the responsibility of finding the optimal solution to a problem, their manager’s job is to answer for why the particular task being undertaken by the developer is the best way to solve the problem. In turn, the manager’s manager needs in the first place to correctly prioritize which problems need to be solved.
The higher your position in the vertical, the bigger will be your responsibility, and the further away from low-level tasks will be your focus. We move from tasks to problems and from problems to goals. Goals are determined by the existence of a strategy we all hold in common. As a team lead, you need to shift to team-wide thinking.
Your responsibilities will include building a development strategy for each employee. One of the most important indicators of the quality of your work will be the state and progress of your team.
To move in this direction, you need to take on more responsibility, and ensure you do not remain indifferent to the problems of others, but rather help them find solutions. If you have well-developed soft skills and the team enjoys interacting with you, this will be a strong argument in your favor when it comes to discussing your wish to become a team lead with your manager.
The tech lead position includes solving complex technical challenges within one or more specializations, and building a strategy to support and further develop those specializations.
In order for your technical expertise to fully influence a project, you will have to hold training lectures and delegate the solving of problems to those who have the most to gain from taking on such challenges. At the same time, you’ll need to organize reviews and provide support so that results meet your quality standards.
As a tech lead, you need to think in terms of the technical requirements of your chosen area, rather than in terms of the development of individual employees. You will not have direct reports, but you will have to decide with team leaders how many people you need and how much time you need to achieve your goals.
You also need to solve the problem, while the team leader needs to effectively engage and develop the team. Together, by discussing the needs and priorities of the team and the project, you’ll be able to build an optimal plan for the effective work of the department and the projects to which you’re assigned.
In our team, we offer to deal with complex tasks that require more research and creativity. We also share experience through reports, consultations to assess and decompose tasks, pull request reviews, and feature lead results reviews.
In addition to a high technical level, the tech lead needs to have a certain authority in the team. This is because they will make key technical decisions on the project, and be required not only to explain those decisions to others, but also help others understand the causes and consequences of those decisions.
To become a tech lead, you have to take on more complex technical challenges, research new approaches, and find ways to improve different project areas. You also need to share expertise and make reports on completed work in order to structure your knowledge better. This will help you earn the credibility of a strong technical specialist.
If you’ve already tried everything within a project that appeals to you, you can still explore the idea of rotations. The main thing is to make sure that it isn’t just that you are having a hard time at the moment mastering something new. If that is the case, it’s better to work through it so you can reach the level at which you can begin to enjoy the skills you’ve honed.
However, switching to an adjacent field is a valid option when you realize that you would be more interested in a different specialization and different tasks. There can be many options in this regard such as joining a server team or a different department or project in your same position, working on technical art, or even just looking at moving in a completely new direction.
In our company, there have been successful cases of rotations from Technical Artists, QAs and Localization Engineers to developers, as well as vice versa – from developers to Technical Artists or just to other departments. Some Unity developers switched to the server side or even radically changed the scope of their activities.
However, if there are no relevant and interesting positions in your team, project, department, or company as a whole, you can of course change to a different company.
But if you like your current working conditions, project, and team, take the time to look around first before making any sudden moves. Make sure you really don't have any options at your current job, and only then consider something more drastic. But you shouldn’t be afraid of that either because, after all, all companies are different, and if you’re sure that you’ve reached the limit of your capabilities at your current company, feel free to look further.
Every company and every project is different. Nevertheless, I hope that what I’ve told you here about growth options for Unity developers in our team will help you learn something useful.
Building a career is also part of your job. You can do it consciously, or it can happen by itself. Sometimes you take a position that comes free or is allocated to you.
But even then, your manager will take into account your interest and commitment in the implementation of new responsibilities. Look at the needs of the project, map your career out, and feel free to talk about this topic with your manager.
Share your thoughts about a career as a game developer in the comments, and I’d be more than happy to discuss the subject with you. I wish you all great success and happiness on your career paths!