In the world of tech, there are very few people that have the experience of building, scaling, and running high-performing tech teams. It’s usually seen in startups or in multinational companies expanding to other countries, but the recurrence of a single person doing it multiple times is usually null. Enter Javier Coca, who’s not only done all of the abovementioned, but he’s done it well over 5 times with different companies across different countries.
We sat down with Javier to talk about his engineering management journey and what he’s learned from growing complete tech teams of more than 50 people from the ground up.
He’s also a former Software Engineer who not only understands the complexities of managing folks but also its technical implications. Over the last ten years, he’s transitioned from Engineering Manager to Operations Manager, all the way to General Manager.
He currently manages a “perfect team size” of 7 people as a General Manager, a combination of direct reports from the operations team, marketing team, and indirect reports from 4 software engineering managers. He’s managed up to 40 people in the past, but in his own words:
“A manager shouldn’t have more than 12 people. Twelve people are the right amount of people you can invest time in paying attention to everyone’s needs.”
We talk in-depth about several topics from remote work, general management, engineering management, and hiring talent. His pragmatic, agile approach to management and his servant-leader leadership style is both refreshing and on-point to the needs of today’s modern managers.
You can hear the podcast episode here:
Nevertheless, I have hired, onboard, and managed team members remotely because we work with teams in Guadalajara, Tijuana, Mexico City, and even Vietnam.
I think there are a lot of factors involved here:
Between the pandemic we are currently facing, that has shown many disbelievers that remote work is possible and effective, plus the cost savings associated with it will have a positive impact on remote work. I see that all companies, especially tech companies will have between 20% to 50% of their workforce working remotely in the near future.
DevOps (AWS), SW Developers, Data Engineers, Automations Engineers. QA can be done, but in person has benefits.
For me, a manager is an enabler; that’s the word that describes what a manager should be. A manager knows the team’s strengths and weaknesses and is the team’s power sponsor that can help remove blockers and resolve impediments. A manager is also a shield that isolates people from situations and distractions that might affect their performance, from simple company-related hurdles to personal problems.
I am a firm believer that a manager needs to walk the talk with the team, shoulder to shoulder. Being a leader, a person that pushes the team forward from within. Getting things done by doing and executing things. Sometimes is just being there as support (not everyone can code the same function). Some other times its doing what only a manager can do like escalating things, getting budget, or enabling education. In other words, teamwork.
When you manage a team in person, you can see how much someone struggles or how much someone works to get something done.When you do it remotely, it is complicated to realize how much effort someone is actually putting into getting things done.
With a remote team, you have to strengthen your communication to adequately address issues that can impact the team’s motivation and energy. It is more challenging to motivate people and foster a culture when you don’t see them daily.
Besides, if the company was not created with remote working in mind, a lot of changes need to happen, and some companies don’t realize that.
I’ve been successful in incorporating the teams to an Agile methodology. Most Engineers have experience in developing in this environment. The challenge for them really becomes getting the hang out of the specific tracking software to be used.
Non-engineering teams need to be persuaded to employ an agile approach, but it is an easy sale as they can immediately see the rewards of using it There are some teams that can’t work a 2-week cadence, but the same basic principles apply to all teams: quarterly goals, monthly goals, weekly to-dos.
Some roles are very unpredictable when it comes to everyday work. For example, operations folks are reactive people who solve problems that are not foreseen a week or two before. So, what we do is to define weekly to-dos priorities and leave some open space so they can incorporate other unforeseen tasks.
Through communication and transparency:
Communication – All managers need to be extremely available, even during off-hours. People working remotely do not follow the usual 9 to 5 schedule or are in different time zones. Biweekly 1-1s are crucial and team meetings need to be more frequent than in-person.
Transparency – Everyone needs to know how and why a decision was made. It is not a democracy, but all opinions should be not only welcome but encouraged. There also needs to be a clear escalation path for any sort of problem.
Same as any other team. There must be a clear communication of the KPIs. In the case of teams following agile methodology, you can easily see any individual’s completion rate and follow up with them.
First, start by really understanding and learning about the product and technologies used or looking to be used. Put together a short presentation or technical demo and invite a small group of known tech leaders in the area to talk about both the product and the technology aspect
Second, while hosting these more controlled, smaller meetings, start putting together bigger events, where all types of tech enthusiasts are welcome and you can start getting interested from engineers at all levels
Third. Reach out. Significant impact emails usually come from C-Level positions. When you get people interested in working with you, it will be easier to recruit A-Players that deliver and add value to the team.
The Goal – The product, module, library or feature the team will be helping with. Given that info, then the level of expertise of the Engineers can be established. With that in mind, the structure of the team, engagement strategy, salaries, career path, onboarding, and way to approach them will be defined.
The way that I have found to be more effective is that all the team is involved, but the manager is the one that finally has the responsibility to make this person successful.
Completion Ratio. Stories took vs stories completed and history.
Story Complexity. Do we have the right people or should other skill sets need to be brought to the team?
Mentoring. Can the team share knowledge or need external help?
Around a year (from 9 to 12 months), it all depends on the team’s structure and the product the team is building. One of the metrics you have to consider building a team is that people tend to be productive until the sixth month; senior engineers can cut that time in half. But to add more engineers to the team (especially junior members), you need to wait for the first hirees to mature their understanding of the product.
After those 12 months, you can start making better decisions on what other engineers to bring, knowing that you have a reliable engineering team that can support newcomers.
There shouldn’t be any significant differences. Only the onsite, which is usually better in person, but can be done remotely.
Be more thorough in reviewing references (Online or in-person).
I feel the biggest challenge is culture. New hires tend to imitate what they see and that is difficult to replicate remotely. A 2-4 week onSite onboarding is recommended. Post-COVID, the buddy system could work but needs to be honed.
Building a successful remote engineering team takes time and a lot of communication. You have to be patient and really focus on strengthening your first hires; they should be flexible and capable of changing gears as the project progresses. Once you have a solid foundation, it is easier to bring in more specialized engineers to the company as needs arise.
Find more insights into our tactical guide “Managing Remote Software Engineers”. Get it here!
Full Video Interview