Effective Strategies for Managing Remote Frontend Teams

Hello, everyone. I'm so excited to be here. How many of you had a CSS bug that took three days to fix because the person who wrote it is six times longer and already asleep? Yeah, that's why I'm here. My name is Martin Mordanov. And for more than seven years, I manage international front-end teams and create scalable solutions.

My topic today will be effective strategies for managing remote front-end teams. In our way to create successful remote front-end team, we need to pass three different rules. First of all is cooperation sync. Cooperation is everything. Many of you know the pain when you create something and QA engineer returns it to import this again. This can be avoided very easy with communication, control versions and browser connection. So I will give an example from my experience.

My team member creates, for example, box which have border radius six pixels. But when he commit, create pull requests, the QA open and review it. In Safari browser, it's four pixels instead of six. And the task is returned back. To avoid this, you need to have conversations with them between teams. For example, in my teams, we have discussion threads, we have documentation system, we have storybook, we have readme files inside components, inside different part of the projects. It's very important to pass every rule to create successful project and to pass all rules. Next is performance issues.

We can't create a project without performance issues, I think. Performance issues in front-end development teams, most of them are based on not testing APIs on the local host and using mock-up APIs. To avoid everything and these problems, the front-end developer needs to have a local instance of back-end development and to test the things how many times loading, response time, core web details, very important for SEO optimization. So it's very important for the front-end developer to have a local configuration for the back-end, not only dev environment, which in this hour, 10 or more developers make requests on it. It needs to be separated for each task. And for the end, but not for priority in the end, alignment struggles. Knowledge is everything. When a new team member comes to my projects, I share documentation and onboard like a week ago. So it's very important to have documentation on everything. It's not like a book, don't miss that, but we need to write everything important to make sure every developer will know that, will search that and in this way we will have a project documented, successfully project and the product will be fine.

So don't miss these three rules and I promise you will have a very big chance to create something amazing without returning to the basics.

We continue with trust-driven leadership. This part of the project needs to be measured and have results, focusing on team member quality improvement.

In my early career, I used my seniority to conduct numerous daily meetings to track task statuses and progress, realizing I was a bottleneck. I shifted decision rights to senior engineers for code review quality and merge, allowing junior and mid-engineers to focus on documentation and learning. Empowering team members with decision rights significantly boosts motivation and productivity.

Eliminating misunderstandings is crucial. Developers must read tasks thoroughly before starting work, identifying and addressing code problems proactively to prevent downstream issues. Ensuring developers understand tasks upfront minimizes delays, prevents bottlenecks, and maintains project momentum and business continuity.

The junior and mid-engineers make the documentations and learn the new things about the tasks. I provided creativity for them. So which things I learned very fast? I learned very fast when the team member have decision rights for something in the project. Everything is changed in his head and motivation is increased and a lot of productivity is being used in the project. So I recommend use this thing. I promise it will work.

Every team member needs to be an unreplaceable part of the project and the results will be going on. Eliminate misunderstanding. How to be sure when you have tasks and give to developer? The developer will read it, starting working, describing code problems before that and the task will be done right. Yeah, that's the hard part.

Developers in our days start the task, start the code. And after an hour or days, they realize they have a problem, which is a general and they can ship the task without fixing it. But this problem is allocated to another team, for example, backend, and backend needs to have a resolution for it. This takes time. Developer gets stuck. Time gets stuck. Sprint gets stuck. Product almost gets stuck. And business gets stuck. So this is the very big problem.

Developer needs to read the task before starting doing it and to think about it, to describe the problems which they have or they think they have to talk with another developer and after that, start doing task. Before that, everything is just passing time and it's not okay. If this task has a problem, start another task. Talk with your product owner to give you something. Talk with backend. But it's very important all team members to know this process and to train this process. This is not easy to integrate into your team. This needs time, needs consistent checks. I check my team, for example, from two to four months, every of them, what they know for the process. And it's just a friendly conversation, which I will be more good for them. So this is very important part of our projects and synchronization between teams.

Automated quality gates, but not only pipelines, continuous integration, continuous deployment. We'll talk about front-end developer local configuration, local commit processes and deployment operations. It's very important to know every developer use same local configuration. What I mean for local configuration? I mean, pre-tier version, pre-tier configuration, dependable updates, security processes, which they run for every commit. So I implement .settings folder in every project which I made. And there I create setting JSON and another JSON, which are needed for the extensions installed on the IDE. Extensions are very flexible when you use it. I use pre-tier updates. I use ESLint and with Husky, with every Git commit, I run again and again. Linting of the code and checks of the rules. So this is very important and integration of it is required for every projects.

Because developers can install, for example, extension which can format the code different than another developers. And when pull request is being created, merge conflicts are guaranteed. You need to avoid this. So local essentials pipeline integrated successfully. After that, you review this and you have pipeline. When you merge, you run these things again and again. And after that, you verify the build. PR lifetime is being reduced because you don't have meetings with the developer.

Why you use this pre-format factor. You just read the code and you are sure your rules are acceptable and confirmed and you're ready for deploy. So we continue with preview environments. And to be honest, we talked about the corporations. We talked about the process. Now how developers will share their process on the task to another team. Yeah. The word is sandbox environment or preview environment. It doesn't matter if you use AWS, Vercel or self-hosted server. You can create in every branch to have sandbox URL created automatically when something is merged into dev area environment. So very important part of it is this to be provided, this URL to be provided to create team, to design team. Design team members needs to verify this interaction, which is, for example, in Figma, Sketch or XD provided file is correct in sandbox environment.

When everything is confirmed, we're ready for deploy and we're sure every team member corporations are accepted and passed and the thing is shipped successfully. Time zone registration or how to identity and protect core overall powers between teams with different time zones and different countries. You need to catch these hours and to make meetings, requiring meetings for them. All hands meetings, sprint plannings, cooperation plannings. So, yeah, you know what I mean. To use these hours and the team to talk and to cooperate with another teams. These teams, which are in different times, they need to feel in the team, in-house team without this hour problem. Because they feel isolated if you don't invite to required meetings. So it's very important to identity these hours to create recurring meetings and to make them very important part of the whole team. Not isolated.

In my experience, I measure this with different metrics because the different countries, they have no working days. We have working days in other country. They overlap. I think the things in the start of every year, to be sure, in this year, I created all things and team is happy. The team is a very important part of our project and I think the team is the real value, not the project. We need to make sure our team will not burn out, right? So let's talk about this. This is very important part of our presentation and of our work, of course, because we need to make sure our team members get enough work for the sprint. They will not pressure, will not have blockers and they will feel good.

I have a lot of blockers. I don't do my job very well. So this is a very important part, the people. The burnout is the process in which people think and overstep some metrics. The time needed for a task and the end date create pressure and discomfort. As a leader, it's crucial to ensure tasks are initiated and address any questions promptly. Regular communication, like bi-weekly check-ins, helps developers feel supported without unnecessary meeting overhead.

Developers should be empowered to make decisions autonomously. Guiding them on the how, not dictating, fosters self-reliance and growth. Implementing no-meeting Fridays allows focused time for skill development. Transitioning from daily to bi-weekly updates streamlines communication, leveraging documentation for clarity. Allocating time for task completion enhances team comfort and boosts project outcomes.

Efficient task allocation and self-driven decision-making lead to improved productivity and morale. Maintaining well-structured documentation is key to keeping the team informed and aligned. Balancing communication frequency optimizes time for individual tasks and skill improvement. Prioritizing team collaboration and empowerment results in a more efficient and content work environment, yielding better project outcomes.

I'm fine for this. The company is fine for this. Everybody's happy. In our dailies, which previously was every day, now we replaced it with two times a week. Why two times? Because we have written updates in all documentations, in all discussion panels in Teams. We don't need every day to talk about our daily activities, because the team knows what to do. This is a lot of time which they can use for their own.

Last, but not in last, of course, cooperation between them. When you allocate time for each task, they feel good. They feel comfortable, and this increase productivity and deliverables of your project. Let's summarize all things which we talk in this presentation. First, documentation, of course. Be sure you have well-maintained documentation. Your team updated it. You are fine for this, and the team is well-being contributing for this.

Make sure you have automated code quality, not only on the pipeline for the point. Be sure developers have local essentials installed. Linkedin processes, prettier dependencies, rules for each of them. And one big thing, every developer uses one same front-end configuration, and you can update it remotely. Only just push the branch. And last, team well-being. Think about team cultures, team activities, team solutions, team commitments, and how to make the more happier area in your team, and what are the problems in your team. Identify it, talk with your developers. Don't be shy because, you know, time is being checked every day, and you need to be more creative and creative, because with this creativity and solutions, your remote front-end team will be happy, and the results will be good for the business and good for all people.