Give Them A Chance: Jobsity CTO Mauricio Lopez on the Power and Potential of Remote Work

Mauricio Lopez, Jobsity’s CTO, has been with the company since the beginning but not always in a leadership role.

When he started, he was based in the southern Ecuadorian city of Guayaquil, 250 miles from Quito (where most of Jobsity’s staff was then based), and worked with a client based on New York and Chicago. That project eventually grew to include 15 developers, and in managing that team, he learned firsthand the challenges--and benefits--of leading a group of remote workers, and early on, he began to see the potential power of a distributed nearshore team.

When the opportunity arose to take the reins as the CTO, he leaped at it. Today, he oversees over 160 developers spread throughout Latin America and manages Jobsity’s internal IT staff.

We sat down with Mauricio to find out more about how he stays on top of such a broad dispersed workforce, what advice he has for others wading into remote work for the first (or fifteenth) time, and what he feels is the most important opportunity to come out of the worldwide changes in work over the last six months. (Hint: it involves giving more people a chance to shine!).

Here’s what Mauricio had to say:

Let’s start with the big question: how do you manage such a big team? What processes do you use? What tricks? What methodology? Do share!

Jobsity started in Colombia and Ecuador, and now we have developers all over Latin America. There are small things you can do; people don’t realize how important they are. People are used to seeing each other in an office, but the dynamics of remote work are very very different. You have to make changes to a team for it to adapt and thrive in a remote context.

Sometimes team leads believe you can just start a sprint and then say: “See you in two weeks!” It won't work. You need points of control during the day, during the spring, and throughout every other day as well. Especially if you’re dealing with different time zones.

For this reason, it’s best to negotiate with developers about time zones. If a developer starts on the East Coast at a certain time and your client works at a different time, you need to work out so there’s the most overlapping time possible for the job. Some developers love starting at 11 am; or they’re like me: I don’t mind starting at 7am and ending early. So negotiating overlapping hours with team members is important; you’ll find solutions to problems easier.

Another thing everyone uses but the importance of which can often be overlooked is Slack. The problem when dealing with timezones and trying to rely on Scrum Boards, Trello, etc, is that sometimes things become too asynchronous. Sometimes you need synchronous communications, and that's when Slack comes in. People come in in the morning and say “Hi, Good Morning” or “I’m going to lunch” or are available for questions. It creates normality, and it creates immediate contact so as to not delay projects. You need a good mix between synchronous and asynchronous communication.

What type of activities does the tech team do to keep all the devs, QAs, etc motivated and feel part of the company while working remotely.

When you’re working remotely you lose the face-to-face connections. So, first, besides work, you need spaces where people can share things with the team. For example, today we have a sci-fi fantasy meeting at 5:30. For 30 minutes we are going to discuss the new Dune movie, talk about the second season of The Mandalorian, and play Among us! These are small things, but they go a long way to motivate people. In Slack you can create channels, make clubs, and discuss other things that aren’t their jobs.

Another thing I advise managers to do to create strong morale is to provide deadlines. The whole thing about scrum is that you're iterating every two weeks, but you don’t have a sense of where you’re going. So you can need to create milestones. Developers need to know where they are in relation to the finished product, and they need to know what they’re contributing too in order to feel invested in it. Even if a company has OKRs, everyone needs to be involved. Developers need to understand which OKRs they are impacting; they need a bigger goal, more than just when their part is due.

Third: Feedback. Giving feedback is complex. Everyone hates doing performance reviews, annual reviews, etc. But I don’t mean that I mean here I have 1-on-1s. I do them weekly with my second in command, for instance, and then he has 1-on-1s with the developers he manages every week. Not just to talk about work, but also “how are you,” what's your living situation like, do you need time off, etc. It’s very time demanding, and it can feel like it hurts the button line. But it pays off because you can be proactive, you can get in front of problems before they happen.

I’ll give you an example. Recently, we had a team in El Salvador working in a very complex time-sensitive project in the middle of COVID. At one point, we realized they were living alone and because of the national lockdown, they couldn’t go out for a month. They were prisoners! And no one knew that. They had a very challenging time and we didn’t discover it for too long. If we would have known earlier, we could have spoken to them and done something. For this reason, 1-on-1s and other build-in feedback cycles would have been important to discover things.

How do you measure the success of the developers inside Jobsity and with their clients?

Let me tell you a story. This is how we measure success.

We have a client that has backend and front end developers. We had a developer who joined their team--a good guy but very opinionated. He liked to fight back. This guy had a problem with the tech lead, who happened to be one of our people. After 2-3 weeks, the manager met with the new developer and said: “This guy has been here a few years; he’s been here for almost every important decision of the last few years. He’s essential to this company. And if you want to work with us you have to find a way to work with this guy.” That's how I measure success: when a manager says “this guy is a key component of my company.” And that’s one of our guys.

We want our developers to be irreplaceable; to have shown their professionalism, skill, and ability over a long period of time, so that they are as much part of the client's company as the client themselves.

What is your philosophy of team management?

I don’t do micro-management. I’ve had micro-managers and it’s painful if you're a guy like me who is committed and knows what he’s doing. So my ethos is to avoid this. I am careful about the people I select for my teams. If I'm careful, I trust them I don't have to micromanage.

Another big value for me is trust. How to gain trust? A developer has to prove themself. For instance, if a dev wants to change the company after only being on the team for 2-3 weeks, I don’t listen to that. They have to do what they’re assigned first so I can see if they can manage more, and then when they’ve proven themselves and we have trust, then I’m open to listening to their suggestions, for them to lead change.

I believe in feedback and working together with the people under my command. I like to get involved -- as much as I can depending on time -- and I try to really understand what my people are doing. I get deep into what everyone is doing, not as a manager, to correct or check on them, but as a peer, as a participant.

What recommendation can you give other CTOs that might be looking to make their teams remote, or hire remote workers going forward?

Some CTOs, especially if they have been involved with live teams in offices, they don’t trust remote workers. And they do as much as they can to find people who can work near them. The talent pool of developers they can get is very limited because they narrow their search to their city. My recommendation is: look broadly--not just because I work for Jobsity, but because it’s real: there are plenty of people who are remote who just need an opportunity. Perhaps they don’t have the best English. Perhaps they don’t have complete cultural fluency (they don't know about baseball or something), but they deserve a chance. COVID is changing the rules. People need a chance.

A client told me he found a dev in a little town in Russia -- in Siberia. And the work ethic this guy had was amazing. Always committed, no problems, never failed, always reporting, excellent soft and hard skills. He didn’t want to leave his home; he wanted to stay in that town. So why hold that against him? And why exclude him from your search?

So that’s my advice: there are really good people out there. Give them a chance and you won’t be sorry.

--

If you want to stay up to date with all the new content we publish on our blog, share your email and hit the subscribe button.

Also, feel free to browse through the other sections of the blog where you can find many other amazing articles on: Programming, IT, Outsourcing, and even Management.