Having remote tech team still seems to freak out CEOs and founders.

We are so used to 9 to 5 and having meetings that we have a hard time imagining not having the team on site and being available immediately.

But tech teams are the perfect example of what should work remotely.

I don’t care where my team works from. Or when. Here’s how I make it work.

Make tasks asynchronous

My team’s value is production. I must let them focus. I can hardly think of a task that would require an immediate answer.

Remember that interrupting your tech team can have a drastic effect on their focus and, thus, their productivity.

It’s easy to think that “it will be faster” to come and ask, and that” it will only take 2 minutes”
On-site, we tend to schedule too many meetings, gathering too many people.

These 2 minutes could have been an email.
This meeting probably did not need the devs presence.

It’s crucial to make an intellectual effort beforehand to assess if what takes “2 minutes” requires an immediate answer. If not, I formulate my need or question, write it, and make it an asynchronous task, sending an email or using our workflow tools.

If my team presence is not mandatory for that meeting’s decisions (which is almost always the case), I let them work.

If I need them to be aware of anything when we’re done, I let them know at a relevant time, through the relevant canal.

Be Agile

I only lead tech projects using Agile / Lean methodologies. My opinion is that waterfall project management just can’t work with IT projects.

So I make sure to split tasks, prioritize them with the team, and document them enough for the team to be autonomous during our iteration. If they need any precision, they know they can reach me, when it fits their organization.

I also make sure not to add tasks or ask them to brainstorm on something that’s not in the sprint. The “mental load” is big enough during sprints.

Plus, they know where we’re heading to. Which leads to my next point.

Common goals and shared vision

I never treat my tech team like they’re just here to execute orders.

Letting a team work in the blind, on small tasks, without having the big picture and the business implications in mind is a recipe for disaster.

Because that’s utterly demotivating. Devs don’t want to churn out code. They want, and need, to have an impact.

I don’t necessarily bring them into decision meetings (see point 1), but I make sure to tell them where we’re going, and why.

That way, it’s easy to deal with changes and pivots, which WILL happen during the product’s development and scale.

I also take the time to celebrate the deployments, share client’s feedback, and the business impact their work had.

Involve your team

Showing the direction is not enough to keep a team motivated.

I also involve them a lot in tech decisions.

Sure, if there are doubts and disagreements, that’s my role to decide. But let’s be honest. As CTOs, we don’t have as much time as before to do technical watch.

And things go FAST.

Being a tech leader or a CTO is a humbling job.

I have absolutely no problem if someone in my team gives his/her opinion on the stack, and explains why choice A would be better than choice B, to achieve our goals (which they’re aware of, see point 3)

So most of the time, we decide together.

I also use checklists a lot (and add them to my deliverables for clients, but that’s another story) to make sure that the product is functional and documented, and that nothing is missing.

I don’t create them alone. I used my fullstack / lead developer experiences, to lay the foundations. But then, front-end, back-end, design teams are responsible for adding relevant attention points.

They know their jobs well. I trust them.

Let them work

I trust my team. Of course, it’s easier when you hire people yourself.

But even if I arrive in an existing team, I try to inspire trust. We have a common vision, and we built this sprint’s to-do list altogether. We have deadlines, tasks, and checklists.

You can work from where you want.

You can work when you want.

You’re free to work at night if you want to enjoy your evening with your kids or take a nap in the afternoon because you started working at 6 today.

I want my team to be efficient and productive, and they know better when they work best.

Takeaways For a Successful Remote Team

This isn’t some magic bullet for every company. It takes time and effort and depends on your team’s experience.

Of course, I’ll step in if a deadline’s about to crash and burn, but that should rarely happen with the tools and processes we use to keep us on the same page.

I really think we should tend to this tech leadership. Give your team the trust and freedom they deserve, and watch them grow.

Everyone wins: they’re happier, more productive, and the results are undeniable.