10 typesetters for 30 teams. Are you crazy?
Hello! My name is Kostya, and I head the layout department at Wrike .
There are 10 people working in our department now, and all these guys came to the company at different times, they have different experience and tasks in separate teams. At the same time, all employees are excellent specialists, who together with ten manage to cover the layout needs of the entire product.
In this article I want to talk about what practices help us align the overall technical level of the team, adhering to the same approaches in work, and give the guys development opportunities so that they themselves can be better and improve the interface of our product.
For those who have a lot of letters, there is a video .
And now a little context. We are a Wrike product company dedicated to developing a single product. This is a Single Page Application (SPA) for collaborating on tasks and projects. In total, the company has more than 700 people, and more than 300 engineers are working on the development. All employees are divided into 30 product teams - each of them works according to the Scrum methodology and consists of different specialists: back-end, front-end, testers, layout designers, UX-designers, etc. Each team works on its own piece of product. All these pieces are then assembled into one large product, which is used by more than 16 thousand companies around the world.
The product is so large and complex that it is important for us to clearly distinguish between Frontend developers who create business logic on the client and UI developers, in essence, coders who deal only with the layout of interfaces, but do it with maximum immersion and, accordingly , with maximum quality.
At the same time, we do not believe that the layout designer is an intermediate stage of development in the Frontend developer. For us, this is a separate branch of development with its own stack of technologies and its own complexities. Not every layout designer should be able to program, but not every Frontend developer should be able to typeset.
Despite the fact that only 30 teams work in Wrike, coders of ten cover the needs of only 20. The fact is that not all teams work on tasks to change the interface, so only 20 of them are “armed” with their permanent layout designer.
Wrike's team is distributed, we have several offices around the world: from San Diego to Voronezh. The main development center is located in St. Petersburg, part of the development is in Voronezh, and now an office is opened in Prague, where some of the product teams will move.
When such a large number of people work on a product in different teams, cities and countries, it can be difficult to maintain a uniform approach, engineers have the same level and, consequently, consistency and equally high quality of the code. If you do not pay special attention to this, a variety of troubles can arise.
Imagine that you are a typesetter and work in your product team. One fine May day, guys from another team come to you and urgently ask for help: their layout designer fell ill a few days before the important release and he needs to be quickly replaced, having completed everything that he didn’t have on the way. You are not very busy right now and agree to help: it only takes a couple of days. Next, you download the repository your colleague worked on and ... drown in it for a week, just to figure out what is going on there. Sleepless nights, torn deadlines and a nervous tick are given to you as a bonus.
Or even worse - you are the same sick coder. And, leaving the sick-list, you update your repository and get 28 commits from your colleague, which completely destroy the slender architecture laid from the very beginning. Why is that? Because your colleague worked hard at night without knowing your ideas and the ability to synchronize with the author. And, it seems, the current task is somehow done, but developing this code further will be a nightmare. Everything needs to be redone, and it’s good if you can explain it to the team and lay another week of work on what seems to have been done.
I have been in web development for quite some time: I worked as a developer and manager. He worked in web studios, agency, outsourcing production, and now I work in a product team. I have seen everything, I have seen similar situations with the rush and in much smaller companies than Wrike. And therefore, I am very glad that in Wrike, at least in terms of UI development, there are no such situations and cannot be, and I am ready to share practices that help us avoid this.
In general, if you think about it, it’s clear that the whole thing is in people and processes. It is people who write code, it is they who build processes and somehow interact. People are both a source of solutions and a source of problems. And if we are talking about engineers, then everything seems to be simple. In order not to have problems, some conditions must be observed:
And if somehow all this is implemented in one engineer, then calling it a “layout designer” is somehow wrong, and a title like “universal layout designer in a vacuum” is better.
It seems that it is impossible to fulfill all these points, especially the last two. But we, in the layout department at Wrike, are close to that. And now I will tell you about 7 practices that help us to be as close as possible to the ideal to which we strive.
If we know what tasks to be solved, we must understand what competencies are needed to solve them. Of course, it would be good for everyone to know everything in the world, but objectively this is impossible and it is worth highlighting the minimum list of knowledge that at least someone in the department should have, and better for everyone.
What does it give? Clear requirements for candidates - the closer his knowledge corresponds to the list of required competencies, the better.
How to make it up? At some point, we gathered in the entire department and in a few meetings wrote out on paper all the technologies that we are already using or would like to study and start using in the future. And with the help of facilitation we came to a list of competencies with which absolutely everyone agrees.
As a result, our list of competencies contains both very abstract things, for example, the ability to quickly find information, and very specific technologies, up to the specific commands of the console utility git, which we think should be able to use.
At the same time, it is completely normal that at one point only one or two people in a department have one of the competencies - at this stage, the main thing is that at least someone possesses this knowledge, otherwise it turns out that the department faces tasks that nobody at all not able to solve.
Having finished with the full list of competencies, we have conveniently grouped them into 13 directions. Here they are:
And if the same HTML / CSS are common industry standards, and we can expect the candidates to be familiar with them, then there were quite specific things. For example, our internal UI Kit library. Or our internal specific tools, features of the environment, features of approaches for solving particular problems, etc. The same Dart Angular (the front end of the product we write on Dart) is a rather rare thing, few people worked with it and expecting at least one of these standards to be familiar to a potential candidate is at least naive. It turns out that even if we hire an experienced specialist, he still will not know a good half of what we consider necessary for the successful completion of our tasks. It turns out that hiring and adapting a new person to a team is always a bit of training. And the more knowledge accumulated,
It turns out that it is simply impossible to find a person who 100% meets our requirements for technical expertise, and we will need to learn him. So, a beginner must have certain learning skills. And these are personal features, the so-called Soft Skills.
When the department and product are small, and the accumulated knowledge is small, it is advantageous to hire people with high expertise to share it in a team. And here already Hard Skills come out on top.
When the department grows, and at the same time the amount of accumulated knowledge about the product increases, it becomes unprofitable to hire children with extensive experience, because it will be more difficult for them to adapt to new realities that are difficult to quickly change. And here it’s useful to hire guys who, even if they don’t have much technical expertise, but who can quickly adapt and learn the necessary technologies. And Soft Skills come to the fore - namely, high learning ability, good communication skills. And it is important that a person shares already established values and strengthens the team, and does not begin to fight with it. It's about the so-called Cultural Fit.
It is important that, having joined a team, a person as soon as possible has an understanding of technologies and processes and begins to bring benefits. And this brings us to a second important practice:
We have already decided that simply hiring experienced guys is not enough and we, immediately after a person goes to work, need to quickly and effectively teach him what he does not currently know. And it doesn’t matter if this is something mundane, such as flex or grid, or some specific tool that it was simply impossible to meet with outside of Wrike.
To do this, we use Onboarding - from the English “on-board” - the process of adapting a new person to a team. But at Wrike, this is not just a story about where a newcomer has a job, and where to look at his tasks. We realized that for us onboarding is like continuing education courses - a kind of training for several months: with an assessment of the current level, a training plan, a mentor-mentor, several trainings about the product, technologies and processes. According to the results of onboarding, we expect that a person will learn everything that is necessary to complete their tasks and become as close as possible in their skills to even the most experienced guys from the department.
In general, the process of our onboarding is a topic for a separate article, but for now I want to dwell on one key thing: the rose of competencies.
Based on the competency groups that we have formulated earlier, we can evaluate any employee or even a candidate in each direction and build such a radial diagram:
Each ray is a certain group of skills. The point on it is the percentage of mastered technologies and approaches inherent in this group. The more a person knows and knows how, the closer his diagram to the ideal circle. The one who has absolutely all the skills from our list of competencies is the very spherical layout designer in a vacuum that we need.
It is important to understand that such a chart (aka the rose of competencies) is not used for performance review, that is, we do not use it to understand who is a good layout designer and who is bad. There is no minimum level in each of the areas below which it is impossible to fall. This chart gives an understanding of where a person has strengths and where are points for growth. We are prepared for the fact that everyone in the department does not know something, especially if it is a beginner. But, looking at the rose of competencies, it is easy enough to understand what things should be pulled up in the first place.
When a newcomer comes to us, such a rose is built for him, and they, together with their mentor, draw up a training plan for 2-3 months, moving along which a person is pumped and approaches the desired ideal.
And, according to the results, after going through this training, the rose is being rebuilt, and progress is becoming evident.
We do not expect 100% result in each direction, it is important for us that there be significant progress. And, in fact, this diagram can be used even after the completion of onboarding, so as not to stand still and develop further. Someone can pump their own directions of interest up to 100% and even further, and someone can add a new direction and develop from a typesetter into some adjacent area. We also have such examples and practices.
What does it give? A clear development plan for beginners. Thus, we all bring to a single level, minimizing the gap between the “oldies” and “newcomers”.
Plus, this reduces the requirements for candidates: if you still train, isn’t it all the same to what? As a result, we do not have really mandatory requirements for Hard Skills for candidates. It is clear that we cannot hire people without basic knowledge at all, but much can be learned at the onboarding stage. The main thing is that a person is capable, and the rest is a business.
So, we know who we are looking for, what skills are needed and how to train them, but this knowledge is relevant today. And the front-end train rushes at full speed, smearing all who stumbled and keep up with the rails. And we need some kind of process of introducing new knowledge so that the whole department does not lag behind modern requirements. And that brings us to a third good practice:
In order to keep up with the modern world, it is important to monitor what is happening in it. Go to conferences, read specialized articles, try new technologies and implement them in your work.
It would be strange to drag everyone to all available conferences and courses, this is not effective. But one of the guys, one way or another, is studying something on his own or with the support of Wrike - we send to conferences, pay for specialized courses and generally support in every way those who want to pump. And if in the whole flow of information it is possible to fish out something useful for itself, then it would be nice to bring it to the department and share knowledge with everyone. For this, regular internal training events help us. But how to understand who and what the whole department could teach? The same rose of competencies helps us in this. But not in the context of each employee, but in the context of the entire department.
Looking at such a chart, it is easy to single out an expert in some area and ask to share your knowledge with everyone else.
You can also see that, despite the fact that we ourselves have determined a certain level of knowledge in one of the areas, no one in the department has 100% knowledge. And this is an occasion to attract an external expert who will hold a workshop or lecture for us and raise the general level of knowledge throughout the department. For example, because of the need to learn the basics of the Dart language, we found a mentor in the company - a strong developer who conducted a course of lectures on Dart for the entire layout department. This did not make us developers, because there was no such task, but at least we now better understand the front-end. Or maybe someone, having felt the new technology, will think about how to retrain in FE, which is also good.
All that remains for us is to regularly review the list of our competencies, supplementing with new relevant technologies. Then the rose will be rebuilt, and we will see the general level of the department, we will be able to manage it and we will never lag behind the front-end engine.
So, we have a set of cool specialists who are approximately equal in strength and do not lag behind current trends. And we even know how to replenish their ranks. How now to synchronize their work? The fourth important practice helps us with this:
Let me remind you that all of our work is carried out in product teams. And each team whose tasks are associated with changing the interface has its own permanent typesetter. A typesetter can have several commands, but only if one does not load it at 100%. And if you leave the specialist alone with himself, then, sooner or later, he devises his own way of typesetting, which the rest will never know.
So that this does not happen and the same tasks are solved by all approximately the same, each task and Merge Request goes through a mandatory review code.
It’s important to look at the code review not so much as the controlling function so that no one puts something bad into the master, but rather at the stage at which two engineers from different teams, with a different background and tasks, agreed on how to solve it one or another problem.
What gives a cross review?
At the review stage, you can get an outside view - how the task can be done better, which reduces the number of errors and makes the code consistent. It’s also a mutual learning process - not only does the author of the code pass the “validation” of the reviewer, but the reviewer can also see how the problem was solved and take it into service. And so, through the cross-review process, common trips are developed and distributed throughout the company.
Having developed common approaches, it would be nice to save them somewhere, so that beginners can get this knowledge not only from colleagues, but also independently. This leads us to the following important practice:
It is important that the code is consistent and consistent with the general rules developed in the department. The most basic thing is Codestyle common to all. It is important that these rules are clearly fixed and publicly available to any person in the company. Because you will never guess in advance who will have to work with your code.
Better yet, make sure that the code matches the given rules automatically checked by the linter: machines should suffer, not people. For example, we have developed and implemented linting for markup templates and linting of less-files.
What does automatic linting give?
Well, firstly, it’s banal to write code - all errors are highlighted directly in the code, while you are still in context. And there is no need to be distracted by checking the code style: this will be done by the plugin for the IDE.
Secondly, it is easier to conduct and pass a code review - in MR there simply are no errors and there can be no code style errors and you can concentrate precisely on the essence of the task.
Thirdly, automatic linting in the process of writing code is also a way to study code style. It doesn’t matter whether you are familiar with the code style or not, already at the time of writing the code, and even more so when you try to commit the code, the linter will display a list of errors and links to the rules that they violate in exactly the amount that you need right here and now . And so, you will inevitably learn the code style by trial and error.
It seems that despite the fact that everyone works in different teams and on different tasks, there are a lot of common ground. And they need to be able to coordinate: who, what, and when to review, who, when, what, what rules to introduce into the code style, and which not, etc. All these activities need to be able to synchronize. Another important practice helps us with this:
The department does not have its own sprints and planning (only product teams that have layout designers work for them), but we nevertheless learned some of the practices from Scrum. Namely, the daily stand-up is a meeting for which we gather and discuss pressing issues: we discuss completed and current tasks, and discuss future ones. This is important if only in the context of the sequence of tasks for the review, and as a bonus you can discuss problems that arise, ask your colleagues for advice, or share news from your teams.
It is important that the stand-up pass quickly, no more than 15 minutes a day. Because even 15 minutes a day, multiplied by 10 people give costs of 40-50 man-hours per month. It’s like a whole week of one person’s work. Therefore, the rally itself should be as short and effective as possible. And only if there are issues that require a separate discussion, they fall outside the framework of the Daily and are discussed separately by interested people, without wasting the time of others.
We use an interactive whiteboard with tasks that any layout designer can work with at any time from any city. At the Daily, everyone who gathers in St. Petersburg in one cabinet at the TV where this board is displayed, and those who work in other cities connect via Zoom. In addition to webcams, this gives the effect of presence and distribution problems we do not experience.
The daily stand-up gives us a certain common information space where any question regarding layout can be resolved - just ask it out loud and the collective mind synthesizes the answer, because someone has already come across this. Or some group of interested guys can help find a solution for a new outlandish task.
So, we know how to hire and train cool specialists, we know how to coordinate their actions to maintain high quality code. But there is one ambush - if a person wants to develop as a specialist and do his job well, then he will do it no matter what. Even if all these processes do not exist. They only help. And if he doesn’t want to, then even ideal processes and super-training will not make a person move. Everyone should be really involved and interested in the future fate of their own, and the company, and the product. And this is the last on the list, but actually the most important practice:
Ideally, each employee should have an understandable plan for the development of himself and the department at least for the next quarter. And it’s good if everyone has it in his head. But the stream of current tasks does not always have time to think about it.
So that no one sticks at the current level and does not “sour” in his team, we have introduced the practice of regular “one on one” meetings with your team leader or leader. These are meetings where you can talk about your development, the development of the team, department and company, and what you can do for this right now. At the meeting, you can get feedback about yourself and coordinate actions, or you can give feedback about your tasks, about the processes in the team or department and, thus, influence them.
In addition to the regular 1: 1, “projects” went well with us. One way or another, the processes and technologies in the department need to be pumped, something new should be introduced, and the old and irrelevant should be disposed of. Everyone in the department has the opportunity to propose such a change, for example, introduce a new technology. Or cut out some Legacy approach that interferes with life.
And, if such a change is really useful, anyone can take on the project for its implementation. This means that you independently conduct some research or work, or gather a project team and manage its activities to achieve the goals of the project. Often this requires in-depth study of new technologies or the search for answers to previously unsolvable questions.
Everyone can choose for themselves the project that interests him. Thus, a person develops himself in an area of interest to him, and pumps the whole department.
And once a month, so that the work on the projects is transparent for everyone, we gather the whole department in retro style and share our successes or offer new projects.
These seven practices allowed us to hire and integrate 6 layout designers into the department and teams in a year. At the moment, this is almost ⅔ of the entire department. Good result.
And what about the flights?
It could not do without magic - all thanks to the magic of automation and our travel fairy Ane.
If for some working reason you need to be in another office, for example, chat with someone in person, then all that is needed is to fill out a special form directly in Wrike, indicate the dates and purpose of the trip. And at the right time in the mail will be plane tickets. All that remains is to grab a laptop, passport and not be late for the flight. So our typesetters fly without problems :)
But what if your company doesn’t have such practices yet?
If you are a team leader or leader, then the advice is very simple: “Here is the checklist, take it and implement it.” I think every leader is interested in the growth of their employees and the quality of the code.
And if you are a simple typesetter or even a freelancer, you don’t have to rely on support “from the air”? Oddly enough, the advice is exactly the same.
The trick is that the implementation of all these practices does not require any huge investments or labor costs, can be promoted “from bottom to top” on the initiative of ordinary employees. The main thing is that there is a desire to pump yourself and improve the world around you.
There are 10 people working in our department now, and all these guys came to the company at different times, they have different experience and tasks in separate teams. At the same time, all employees are excellent specialists, who together with ten manage to cover the layout needs of the entire product.
In this article I want to talk about what practices help us align the overall technical level of the team, adhering to the same approaches in work, and give the guys development opportunities so that they themselves can be better and improve the interface of our product.
For those who have a lot of letters, there is a video .
And now a little context. We are a Wrike product company dedicated to developing a single product. This is a Single Page Application (SPA) for collaborating on tasks and projects. In total, the company has more than 700 people, and more than 300 engineers are working on the development. All employees are divided into 30 product teams - each of them works according to the Scrum methodology and consists of different specialists: back-end, front-end, testers, layout designers, UX-designers, etc. Each team works on its own piece of product. All these pieces are then assembled into one large product, which is used by more than 16 thousand companies around the world.
The product is so large and complex that it is important for us to clearly distinguish between Frontend developers who create business logic on the client and UI developers, in essence, coders who deal only with the layout of interfaces, but do it with maximum immersion and, accordingly , with maximum quality.
At the same time, we do not believe that the layout designer is an intermediate stage of development in the Frontend developer. For us, this is a separate branch of development with its own stack of technologies and its own complexities. Not every layout designer should be able to program, but not every Frontend developer should be able to typeset.
Despite the fact that only 30 teams work in Wrike, coders of ten cover the needs of only 20. The fact is that not all teams work on tasks to change the interface, so only 20 of them are “armed” with their permanent layout designer.
Wrike's team is distributed, we have several offices around the world: from San Diego to Voronezh. The main development center is located in St. Petersburg, part of the development is in Voronezh, and now an office is opened in Prague, where some of the product teams will move.
When such a large number of people work on a product in different teams, cities and countries, it can be difficult to maintain a uniform approach, engineers have the same level and, consequently, consistency and equally high quality of the code. If you do not pay special attention to this, a variety of troubles can arise.
Imagine that you are a typesetter and work in your product team. One fine May day, guys from another team come to you and urgently ask for help: their layout designer fell ill a few days before the important release and he needs to be quickly replaced, having completed everything that he didn’t have on the way. You are not very busy right now and agree to help: it only takes a couple of days. Next, you download the repository your colleague worked on and ... drown in it for a week, just to figure out what is going on there. Sleepless nights, torn deadlines and a nervous tick are given to you as a bonus.
Or even worse - you are the same sick coder. And, leaving the sick-list, you update your repository and get 28 commits from your colleague, which completely destroy the slender architecture laid from the very beginning. Why is that? Because your colleague worked hard at night without knowing your ideas and the ability to synchronize with the author. And, it seems, the current task is somehow done, but developing this code further will be a nightmare. Everything needs to be redone, and it’s good if you can explain it to the team and lay another week of work on what seems to have been done.
I have been in web development for quite some time: I worked as a developer and manager. He worked in web studios, agency, outsourcing production, and now I work in a product team. I have seen everything, I have seen similar situations with the rush and in much smaller companies than Wrike. And therefore, I am very glad that in Wrike, at least in terms of UI development, there are no such situations and cannot be, and I am ready to share practices that help us avoid this.
In general, if you think about it, it’s clear that the whole thing is in people and processes. It is people who write code, it is they who build processes and somehow interact. People are both a source of solutions and a source of problems. And if we are talking about engineers, then everything seems to be simple. In order not to have problems, some conditions must be observed:
- All guys must be equally high level. Everyone uses the whole set of necessary technologies, knows all the strengths and limitations, is well versed in the processes and adheres to the same approaches. Then, indeed, you can give the task to any engineer, and he will solve it as well as any other colleague;
- Everyone writes code equally well. Well, or at least just the same. Then, indeed, when combined with the first paragraph, we will get a consistent, well-maintained code that any team member can work with;
- Everyone knows who does what. This lowers the entry threshold when switching between tasks and then, indeed, even if someone gets sick or “falls out” of the workflow for any other reason, any of the colleagues will be on hand: this reduces the likelihood of the so-called Bus Factor;
- Team members “share budding”. The number of teams is growing, as is the need for engineers. It’s already difficult to hire such people who correspond to the first three points, so it would be nice if existing guys could share budding or cloning, while maintaining current knowledge. Then yes, there will be no problems with scaling;
- Teach everyone to fly. For a company with several offices in different countries, it is necessary to be able to gather people from different offices in one place, because the value of non-verbal communication for establishing communication can hardly be overestimated. And it would be nice if the guys, when they need to synchronize with someone, could just “fly out” to another office, as in comics. Then, perhaps, there will be no problems with the distribution of teams around the globe.
And if somehow all this is implemented in one engineer, then calling it a “layout designer” is somehow wrong, and a title like “universal layout designer in a vacuum” is better.
It seems that it is impossible to fulfill all these points, especially the last two. But we, in the layout department at Wrike, are close to that. And now I will tell you about 7 practices that help us to be as close as possible to the ideal to which we strive.
1. Current list of competencies
If we know what tasks to be solved, we must understand what competencies are needed to solve them. Of course, it would be good for everyone to know everything in the world, but objectively this is impossible and it is worth highlighting the minimum list of knowledge that at least someone in the department should have, and better for everyone.
What does it give? Clear requirements for candidates - the closer his knowledge corresponds to the list of required competencies, the better.
How to make it up? At some point, we gathered in the entire department and in a few meetings wrote out on paper all the technologies that we are already using or would like to study and start using in the future. And with the help of facilitation we came to a list of competencies with which absolutely everyone agrees.
As a result, our list of competencies contains both very abstract things, for example, the ability to quickly find information, and very specific technologies, up to the specific commands of the console utility git, which we think should be able to use.
At the same time, it is completely normal that at one point only one or two people in a department have one of the competencies - at this stage, the main thing is that at least someone possesses this knowledge, otherwise it turns out that the department faces tasks that nobody at all not able to solve.
Having finished with the full list of competencies, we have conveniently grouped them into 13 directions. Here they are:
- The ability to google;
- Environment (tools, git, serve, etc.);
- HTML
- CSS
- General approaches (HTML / CSS);
- UI-kit;
- Scrum;
- Angular + Dart;
- Code review;
- JS;
- Basics of programming;
- UI / Interfaces;
- Hotkeys
And if the same HTML / CSS are common industry standards, and we can expect the candidates to be familiar with them, then there were quite specific things. For example, our internal UI Kit library. Or our internal specific tools, features of the environment, features of approaches for solving particular problems, etc. The same Dart Angular (the front end of the product we write on Dart) is a rather rare thing, few people worked with it and expecting at least one of these standards to be familiar to a potential candidate is at least naive. It turns out that even if we hire an experienced specialist, he still will not know a good half of what we consider necessary for the successful completion of our tasks. It turns out that hiring and adapting a new person to a team is always a bit of training. And the more knowledge accumulated,
It turns out that it is simply impossible to find a person who 100% meets our requirements for technical expertise, and we will need to learn him. So, a beginner must have certain learning skills. And these are personal features, the so-called Soft Skills.
When the department and product are small, and the accumulated knowledge is small, it is advantageous to hire people with high expertise to share it in a team. And here already Hard Skills come out on top.
When the department grows, and at the same time the amount of accumulated knowledge about the product increases, it becomes unprofitable to hire children with extensive experience, because it will be more difficult for them to adapt to new realities that are difficult to quickly change. And here it’s useful to hire guys who, even if they don’t have much technical expertise, but who can quickly adapt and learn the necessary technologies. And Soft Skills come to the fore - namely, high learning ability, good communication skills. And it is important that a person shares already established values and strengthens the team, and does not begin to fight with it. It's about the so-called Cultural Fit.
It is important that, having joined a team, a person as soon as possible has an understanding of technologies and processes and begins to bring benefits. And this brings us to a second important practice:
2. Onboarding with integrated training
We have already decided that simply hiring experienced guys is not enough and we, immediately after a person goes to work, need to quickly and effectively teach him what he does not currently know. And it doesn’t matter if this is something mundane, such as flex or grid, or some specific tool that it was simply impossible to meet with outside of Wrike.
To do this, we use Onboarding - from the English “on-board” - the process of adapting a new person to a team. But at Wrike, this is not just a story about where a newcomer has a job, and where to look at his tasks. We realized that for us onboarding is like continuing education courses - a kind of training for several months: with an assessment of the current level, a training plan, a mentor-mentor, several trainings about the product, technologies and processes. According to the results of onboarding, we expect that a person will learn everything that is necessary to complete their tasks and become as close as possible in their skills to even the most experienced guys from the department.
In general, the process of our onboarding is a topic for a separate article, but for now I want to dwell on one key thing: the rose of competencies.
Based on the competency groups that we have formulated earlier, we can evaluate any employee or even a candidate in each direction and build such a radial diagram:
Each ray is a certain group of skills. The point on it is the percentage of mastered technologies and approaches inherent in this group. The more a person knows and knows how, the closer his diagram to the ideal circle. The one who has absolutely all the skills from our list of competencies is the very spherical layout designer in a vacuum that we need.
It is important to understand that such a chart (aka the rose of competencies) is not used for performance review, that is, we do not use it to understand who is a good layout designer and who is bad. There is no minimum level in each of the areas below which it is impossible to fall. This chart gives an understanding of where a person has strengths and where are points for growth. We are prepared for the fact that everyone in the department does not know something, especially if it is a beginner. But, looking at the rose of competencies, it is easy enough to understand what things should be pulled up in the first place.
When a newcomer comes to us, such a rose is built for him, and they, together with their mentor, draw up a training plan for 2-3 months, moving along which a person is pumped and approaches the desired ideal.
And, according to the results, after going through this training, the rose is being rebuilt, and progress is becoming evident.
We do not expect 100% result in each direction, it is important for us that there be significant progress. And, in fact, this diagram can be used even after the completion of onboarding, so as not to stand still and develop further. Someone can pump their own directions of interest up to 100% and even further, and someone can add a new direction and develop from a typesetter into some adjacent area. We also have such examples and practices.
What does it give? A clear development plan for beginners. Thus, we all bring to a single level, minimizing the gap between the “oldies” and “newcomers”.
Plus, this reduces the requirements for candidates: if you still train, isn’t it all the same to what? As a result, we do not have really mandatory requirements for Hard Skills for candidates. It is clear that we cannot hire people without basic knowledge at all, but much can be learned at the onboarding stage. The main thing is that a person is capable, and the rest is a business.
So, we know who we are looking for, what skills are needed and how to train them, but this knowledge is relevant today. And the front-end train rushes at full speed, smearing all who stumbled and keep up with the rails. And we need some kind of process of introducing new knowledge so that the whole department does not lag behind modern requirements. And that brings us to a third good practice:
3. Regular training activities
In order to keep up with the modern world, it is important to monitor what is happening in it. Go to conferences, read specialized articles, try new technologies and implement them in your work.
It would be strange to drag everyone to all available conferences and courses, this is not effective. But one of the guys, one way or another, is studying something on his own or with the support of Wrike - we send to conferences, pay for specialized courses and generally support in every way those who want to pump. And if in the whole flow of information it is possible to fish out something useful for itself, then it would be nice to bring it to the department and share knowledge with everyone. For this, regular internal training events help us. But how to understand who and what the whole department could teach? The same rose of competencies helps us in this. But not in the context of each employee, but in the context of the entire department.
Looking at such a chart, it is easy to single out an expert in some area and ask to share your knowledge with everyone else.
You can also see that, despite the fact that we ourselves have determined a certain level of knowledge in one of the areas, no one in the department has 100% knowledge. And this is an occasion to attract an external expert who will hold a workshop or lecture for us and raise the general level of knowledge throughout the department. For example, because of the need to learn the basics of the Dart language, we found a mentor in the company - a strong developer who conducted a course of lectures on Dart for the entire layout department. This did not make us developers, because there was no such task, but at least we now better understand the front-end. Or maybe someone, having felt the new technology, will think about how to retrain in FE, which is also good.
All that remains for us is to regularly review the list of our competencies, supplementing with new relevant technologies. Then the rose will be rebuilt, and we will see the general level of the department, we will be able to manage it and we will never lag behind the front-end engine.
So, we have a set of cool specialists who are approximately equal in strength and do not lag behind current trends. And we even know how to replenish their ranks. How now to synchronize their work? The fourth important practice helps us with this:
4. Mandatory cross-review
Let me remind you that all of our work is carried out in product teams. And each team whose tasks are associated with changing the interface has its own permanent typesetter. A typesetter can have several commands, but only if one does not load it at 100%. And if you leave the specialist alone with himself, then, sooner or later, he devises his own way of typesetting, which the rest will never know.
So that this does not happen and the same tasks are solved by all approximately the same, each task and Merge Request goes through a mandatory review code.
It’s important to look at the code review not so much as the controlling function so that no one puts something bad into the master, but rather at the stage at which two engineers from different teams, with a different background and tasks, agreed on how to solve it one or another problem.
What gives a cross review?
At the review stage, you can get an outside view - how the task can be done better, which reduces the number of errors and makes the code consistent. It’s also a mutual learning process - not only does the author of the code pass the “validation” of the reviewer, but the reviewer can also see how the problem was solved and take it into service. And so, through the cross-review process, common trips are developed and distributed throughout the company.
Having developed common approaches, it would be nice to save them somewhere, so that beginners can get this knowledge not only from colleagues, but also independently. This leads us to the following important practice:
5. Code style and automatic linting
It is important that the code is consistent and consistent with the general rules developed in the department. The most basic thing is Codestyle common to all. It is important that these rules are clearly fixed and publicly available to any person in the company. Because you will never guess in advance who will have to work with your code.
Better yet, make sure that the code matches the given rules automatically checked by the linter: machines should suffer, not people. For example, we have developed and implemented linting for markup templates and linting of less-files.
What does automatic linting give?
Well, firstly, it’s banal to write code - all errors are highlighted directly in the code, while you are still in context. And there is no need to be distracted by checking the code style: this will be done by the plugin for the IDE.
Secondly, it is easier to conduct and pass a code review - in MR there simply are no errors and there can be no code style errors and you can concentrate precisely on the essence of the task.
Thirdly, automatic linting in the process of writing code is also a way to study code style. It doesn’t matter whether you are familiar with the code style or not, already at the time of writing the code, and even more so when you try to commit the code, the linter will display a list of errors and links to the rules that they violate in exactly the amount that you need right here and now . And so, you will inevitably learn the code style by trial and error.
It seems that despite the fact that everyone works in different teams and on different tasks, there are a lot of common ground. And they need to be able to coordinate: who, what, and when to review, who, when, what, what rules to introduce into the code style, and which not, etc. All these activities need to be able to synchronize. Another important practice helps us with this:
6. Daily stand-up
The department does not have its own sprints and planning (only product teams that have layout designers work for them), but we nevertheless learned some of the practices from Scrum. Namely, the daily stand-up is a meeting for which we gather and discuss pressing issues: we discuss completed and current tasks, and discuss future ones. This is important if only in the context of the sequence of tasks for the review, and as a bonus you can discuss problems that arise, ask your colleagues for advice, or share news from your teams.
It is important that the stand-up pass quickly, no more than 15 minutes a day. Because even 15 minutes a day, multiplied by 10 people give costs of 40-50 man-hours per month. It’s like a whole week of one person’s work. Therefore, the rally itself should be as short and effective as possible. And only if there are issues that require a separate discussion, they fall outside the framework of the Daily and are discussed separately by interested people, without wasting the time of others.
We use an interactive whiteboard with tasks that any layout designer can work with at any time from any city. At the Daily, everyone who gathers in St. Petersburg in one cabinet at the TV where this board is displayed, and those who work in other cities connect via Zoom. In addition to webcams, this gives the effect of presence and distribution problems we do not experience.
The daily stand-up gives us a certain common information space where any question regarding layout can be resolved - just ask it out loud and the collective mind synthesizes the answer, because someone has already come across this. Or some group of interested guys can help find a solution for a new outlandish task.
So, we know how to hire and train cool specialists, we know how to coordinate their actions to maintain high quality code. But there is one ambush - if a person wants to develop as a specialist and do his job well, then he will do it no matter what. Even if all these processes do not exist. They only help. And if he doesn’t want to, then even ideal processes and super-training will not make a person move. Everyone should be really involved and interested in the future fate of their own, and the company, and the product. And this is the last on the list, but actually the most important practice:
7. Everyone's involvement in department projects
Ideally, each employee should have an understandable plan for the development of himself and the department at least for the next quarter. And it’s good if everyone has it in his head. But the stream of current tasks does not always have time to think about it.
So that no one sticks at the current level and does not “sour” in his team, we have introduced the practice of regular “one on one” meetings with your team leader or leader. These are meetings where you can talk about your development, the development of the team, department and company, and what you can do for this right now. At the meeting, you can get feedback about yourself and coordinate actions, or you can give feedback about your tasks, about the processes in the team or department and, thus, influence them.
In addition to the regular 1: 1, “projects” went well with us. One way or another, the processes and technologies in the department need to be pumped, something new should be introduced, and the old and irrelevant should be disposed of. Everyone in the department has the opportunity to propose such a change, for example, introduce a new technology. Or cut out some Legacy approach that interferes with life.
And, if such a change is really useful, anyone can take on the project for its implementation. This means that you independently conduct some research or work, or gather a project team and manage its activities to achieve the goals of the project. Often this requires in-depth study of new technologies or the search for answers to previously unsolvable questions.
Everyone can choose for themselves the project that interests him. Thus, a person develops himself in an area of interest to him, and pumps the whole department.
And once a month, so that the work on the projects is transparent for everyone, we gather the whole department in retro style and share our successes or offer new projects.
These seven practices allowed us to hire and integrate 6 layout designers into the department and teams in a year. At the moment, this is almost ⅔ of the entire department. Good result.
And what about the flights?
It could not do without magic - all thanks to the magic of automation and our travel fairy Ane.
If for some working reason you need to be in another office, for example, chat with someone in person, then all that is needed is to fill out a special form directly in Wrike, indicate the dates and purpose of the trip. And at the right time in the mail will be plane tickets. All that remains is to grab a laptop, passport and not be late for the flight. So our typesetters fly without problems :)
But what if your company doesn’t have such practices yet?
If you are a team leader or leader, then the advice is very simple: “Here is the checklist, take it and implement it.” I think every leader is interested in the growth of their employees and the quality of the code.
And if you are a simple typesetter or even a freelancer, you don’t have to rely on support “from the air”? Oddly enough, the advice is exactly the same.
The trick is that the implementation of all these practices does not require any huge investments or labor costs, can be promoted “from bottom to top” on the initiative of ordinary employees. The main thing is that there is a desire to pump yourself and improve the world around you.