Over the past few years, backend teams have been working in completely new environments: remote working has become the norm, and AI has radically changed the way we solve problems. This has increased productivity, but at the same time exposed a problem that we previously underestimated — the loss of team dynamics.
Over the past few years, backend teams have been working in completely new environments: remote working has become the norm, and AI has radically changed the way we solve problems. This has increased productivity, but at the same time exposed a problem that we previously underestimated — the loss of team dynamics.
Offline organically creates a sense of team: joint activities, jokes, live communication. In remote, there is less of this, and this especially affects newcomers. Add to this AI, which many now go to for answers instead of consulting with colleagues, and the distance of live contact increases even more.
C# Team Lead UPSTARS Timur Karanda sees this for himself, as AI has become his #1 tool for quickly finding information. The solution is to additionally consult with the team so as not to lose human interaction and a healthy exchange of experience.
In such a reality, code culture, quality processes, and structured backend team development become critically important. In this article, he has collected the rules and principles that work in my team and will allow it to remain strong, autonomous, and cohesive even at a distance.
Code culture is how a team thinks and coordinates processes. Working in a common, universally accepted logic helps avoid chaos, speeds up the onboarding of new specialists, and makes the project predictable for everyone. Here are four rules that underpin our engineering culture.
I was a developer who tried to use all possible patterns, to add all the best practices to the code. But at one point I was faced with a question from more experienced people: «what for?» It turned out that the complexity of the architecture for the sake of the complexity of the architecture is a trap. Simple code is easier to read, easier to maintain and much harder to break, because you don’t create unnecessary places for errors. I always test myself with the question: can I do the same thing, but simpler? If the answer is «yes», then the code needs to be simplified.
A single style saves time and effort. When the folder structure, variable names, approach to logic, and organization are the same everywhere, it optimizes development by making the code easier to read and understand. This helps the team work more efficiently, and newcomers adapt faster. This is a fundamental requirement for a unified and understandable project. And, in my opinion, one of the strongest catalysts for productivity.
Sooner or later, the code «just in case» gradually turns into technical fog. Nobody checks it, nobody maintains it, but everyone is afraid to touch it. My rule is very simple: if the code is not used, it should disappear. It is better to rewrite it once than to spend years bypassing something that has no function, but interferes with the development of the product.
For us, code reviews are a tool for improving the quality and maturity of the team. It is important that not only the leads participate in it, because when one person does the review, everything can quickly become automatic. We use the review as a point for early detection of errors, maintaining a single code style, and sharing knowledge within the team so that everyone has a basic understanding of what is happening in the product, where, and why. It is this collective attention to this process that allows us to maintain the quality and consistency of solutions.
Technical onboarding of new teammates is an important step in the life of any technical team. Its role is especially acute during a period of active company growth. Remote work also creates an additional problem: a newcomer loses the opportunity to simply clarify something with someone nearby. To maintain a clear and working code culture when hiring new people, everyone needs support and understanding. Successful adaptation of new teammates, structured transfer of information, principles, approaches and code style creates a holistic understanding of the product, architecture and processes from the first days of work. Below is my vision of successful technical onboarding of a backend engineer in several steps.
I am against the classic approach, which consists in gradually diving into small tasks. This stretches the adaptation for months and does not allow to understand the product as a whole. Our first task is a complex, voluminous task that covers as many parts of the system as possible. This forces a person to go through all the key modules, understand the architecture, relationships and principles of the system.
As a guide, we try to provide examples of similar tasks that have been done before so that the newbie can see what changes were made and can consult with the person who made them. This builds a sense of the team’s style and saves hours of searching for answers.
In UPSTARS, there is such a role for teammates as Onboarding Buddy. This is a person who helps a newcomer adapt to the company faster and more calmly and integrate into work processes. In my team, this is a teammate to whom a new engineer can turn with any question from the first day, without thinking about who is better not to distract. In remote conditions, this critically reduces uncertainty and allows you to integrate into the team and processes much faster and more painlessly.
The Onboarding Buddy becomes the first reviewer and mentor during the probationary period: the code goes to the general review after it has been approved and adapted to the team’s agreements and style. As a result, the newcomer learns faster, the team spends less time on reviews, and everyone else can focus on their tasks without being distracted by dozens of small questions.
Once a week, I conduct a short sync with the newcomer: is everything clear about the tasks and processes, how is the interaction with the team, and are there any ideas or difficulties that should be discussed directly.
These regular 1:1s give the new engineer a sense of support and a safe space to talk through anything from technical nuances to team dynamics. For me as a lead, it’s also a constant feedback loop: I can see how the person is progressing, if there are any performance or work-related issues, and I can make adjustments immediately without building up tension or uncertainty.
It is important to me that a newcomer completes their first big task: testing, reviewing, deploying, supporting. This builds ownership from the first weeks. Psychologically, it is important to feel that you have already done something big that really works.
In our team, mentoring is integrated into daily work. I can highlight the following key qualities for team development and career growth:
After particularly large tasks, such as large refactorings, the developer demonstrates the code to the team, explains how they solved the problems and why they chose certain solutions. This way, the team can absorb the experience and apply it in future work — programmers will be better able to navigate the new code thanks to explanations of what, where, and why it was done that way.
All programmers participate in the code review process, everyone can review the tasks that interest them, offer their ideas. This ensures uniform technical development and involvement of all participants, as well as uniform distribution of knowledge. One of our principles is not to create knowledge keepers, and if this has already happened, then to involve other developers as much as possible in working on these modules.
I encourage initiative and suggestions for improvements, but not chaotic independent solutions without coordination. It is important for me that there is a single model for making technical decisions in the team and clear responsibility — from the technical lead or architect, who validates the approaches and monitors the integrity of the system. This allows you to avoid situations where quick local solutions eventually turn the code base into a Big Ball of Mud.
At the same time, I support ideas, suggestions, and initiative from engineers as much as possible. When a person can influence a product and sees that their ideas are discussed and implemented, the feeling of responsibility and involvement increases. This, together with practice, a desire to develop, and strong soft skills, creates the basis for professional growth and the formation of leadership potential, but only when the person himself seeks it.
For convenience, I have highlighted several key principles for successful backend team development in a convenient checklist:
