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:
Remote Work
How long have you been working remotely?
I have reported to remote leaders for around six years now. It is not traditional remote work because I get to go to an office, but all the OKRs are set and reviewed by people in different locations.
Nevertheless, I have hired, onboard, and managed team members remotely because we work with teams in Guadalajara, Tijuana, Mexico City, and even Vietnam.
Why do you think we’ve evolved into remote work?
I think there are a lot of factors involved here:
- Economics – Being able to bring people to the team without the additional cost of relocation.
- Family – Some good, hard-working people have other responsibilities (usually family) that prevents them from move to another location (even in the same city)
- Technology – We can now communicate more efficiently and effectively electronically.
- Tools – There are a huge amount of tools that allow us to be a consistent contributor remotely.
- Career – Most companies have invested time and money to build flexible career paths for the vast majority of the team.
- Talent – It doesn’t matter where you built your current skill set.
What advantages do you see when working remotely?
- Opportunities – Access to different projects or industries that otherwise we would not have access to.
- Diversity – We can have a better, more diverse group of people working in the same project.
Economics – There are real savings. No commute, no transportation, no office, no lunch. - Personal Time – All the time saved in coming and going to the office, can be better used for enjoying other important aspects of life.
What are your expectations about remote work? Where do you see it going?
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.
Are there some positions in tech that are better suited for remote work than others? Can you list some examples?
DevOps (AWS), SW Developers, Data Engineers, Automations Engineers. QA can be done, but in person has benefits.
General Management Practices
In your eyes what’s the role of a manager?
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.
What’s your approach to management? Do you have a set of principles you follow?
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.
How is managing remote teams different from in-person teams?
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.
How do you manage performance?
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.
How do you engage with remote teams?
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.
How do you hold remote team members accountable? Do you use any kind of monitoring?
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.
Building an engineering team best practices
How do you start building an engineering team from zero?
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.
What things are important to define from the get-go?
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.
Who is involved in the decision-making process when hiring the team?
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.
- Manager should be reviewing the motivators and cultural fitness.
- Lead/Architect should review the level of knowledge (or lack of it).
- Peers need to see if that person is coachable and has the proper amount of energy and will power for the environment they know exists.
What are some specific growth milestones you look at before hiring more folks or restructuring the team’s organizational hierarchy?
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?
What is a typical timeline for growing a small team – 10-15 people?
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.
What are some onboarding best practices you’ve seen pay off big dividends?
- 30/60/90 days Reviews.
- Buddy System.
- Pair Programming.
- Leader Code Review.
- QA SitDown.
- Non-Engineer Managers.
Download this guide for a closer look and the steps to implement these onboarding best practices.
Do you have any specific processes or frameworks (besides agile) that you use to manage your engineering team?
- Hardening (agile). Tech debt has to be paid.
- Demo.
- Brown bags.
- Recognitions. Thankyou Notes, ShoutOuts.
- Excentricities. One afternoon off.
- Social gatherings.
Are there any specific software tools or else you use that you recommend?
- Jira.
- StackOverflow.
- Intranet/FAQ/Postmortem Docs.
- Slack.
- ToDoIst
Hiring and Firing
How is hiring remotely different from hiring in person?
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).
What traits or skills are more important in a developer when hiring remotely?
- Right motivators. The Developer’s reasons for wanting to change their current work and join in specific this project.
- Great Communicator. A person that can express his/her concerns, doubts or discomforts and raise their hands when they don’t feel fully functional.
- Proactive. A person that doesn’t need someone to tell them what they can or cannot do.
- Confident. Needs to be sure of what he/she knows.
Are there any onboarding challenges when hiring a remote developer? How do you get them to fully understand your workflow?
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.
Bonus questions
How do you empower your team?
- Allowing them to take on bigger, yet reasonable commitments, that are risky or outside the scope of the story.
- Having them present their work, research, or implementation of certain technology to the team.
- Having their backs, showing them that any decision well made was taken as a team. Focus on the learning and then moving on.
- Listening to their needs and Delivering.
- Allowing them to say NO.
How do you maintain the human factor?
- Open Doors.
- Conducting real 1-1 is crucial.
- Finding support from the extended team.
- Social gatherings. After-hours clubs tailored to all demographics.
Last Word
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
