Ask HN: Difficulties Managing a Remote Team?

Have you tried talking to that underperforming quarter and asking them what’s going on? Perhaps they need more direction or they’re burned out, or personal issues, or maybe they just want to leave and are waiting until something better comes along.

This has nothing to do with remote - this happens all the time in most teams who work in office, for the same reasons.

p.s. 15 people is too many for a single manager. If you haven’t already, define smaller teams and designate a team lead for each. Start managing those team leads.

> Of course firing is an option

Certainly not the first option. You bring it up with them, you modify your process and manage a bit more closely, you agree on some concrete objectives; and if things don't change that much, you make it clear that if things don't improve in a well-defined way within an agreed time window, they could be fired. Firing is the last measure of a series of escalating measures, and each one of those measures should be communicated well. If you fire someone and it comes as a surprise to them, you messed up, not them.

I have similar problems with similar ratios. I suspect core motivation is part of it, their reason for picking software development. People that pick it for money perform poorly. Another observation, people with young kids at home just don't have focus time to get work done.

You should be having regular 1:1's with each person to talk to them about what they've got going on in their lives, problems/barriers, gripes, career planning stuff, general coaching and feedback. Oftentimes it is something outside of work that impacts their work.

Nudging under-performers isn't micromanaging. Your company may also have a process to start documenting the lack of performance in advance of letting them go. If they've proven they aren't completing work on time then it would be appropriate to talk with your manager/HR about letting someone go.

> basically disappear for hours at a time during the day

This isn't a problem - I've been working remotely for over a decade now, and the most productive devs work when they are in a good space to do so, and don't work when they aren't feeling it. Yes, this means they may disappear for a few hours. But the good ones will come back and work those hours while you are not online. From their perspective, you are the one disappearing during their working hours. So just let it go and worry about whether or not their work gets done.

Now, if their work is not getting done, that is a problem - but deal with it directly, not by questioning their hours or working methods. And ultimately, that is my advice overall for managing remote teams - be transparent and direct. If you feel unsure about something, talk directly to them about it and work it out.

I'm in almost the exact same situation -- stepping from mostly IC into a CTO / Tech Lead role at a small startup, trying to create the type of culture that I'd want to work in, etc.

I unfortunately don't have a solution, other than I've noticed the exact same pattern -- most of my reports are awesome and work hard... there are a couple that I wonder if they are legitimately working, and my attempts to establish more transparency into what their day looks like have so far not gone over super well.

So you: - remove the handrail they can use to run down the stairs (very little process) - remove their ability to sync, and agree on work (no daily stand-ups) - remove their ability to understand where they are, and their accountability (no "fiddling" jira) - remove any kind of consistency in the work day (hours are very flexible)

And then wonder why they fail? You set them up for failure. Textbook style.

before spying or firing, why not talk to them openly about your concerns.

In a similar role and have peers in a similar role, a lot to unpack here:

No Micromanagement ≠ No Guidance or Collaboration

There is unfortunately a perception in startup engineering orgs that any meeting is a waste of time and that 100% of time should be spent coding. My personal KPI for eng teams is 85-90% of IC time is coding, 10-15% of the time is spent on standups or spontaneous collaboration sessions to figure out exactly what we are trying to build.

It is unclear how you are running the team (Agile / Waterfall / Agilefall / some other flavor) but it doesn't really matter. At the end of the day, your job as the team lead / CTO is to empower your team to get things done. Guidance around what and how to build it is not the same as micromanagement.

Micromanagement

- Asking an engineering every 30 mins where a given feature or task is at.

- Mandating that you review every line of code prior to pushing to production

Guidance and Technical Leadership

- Holding (optional) office hours at 11am everyday for engineers to hop on with any questions or discussion points

- Asking an IC to work on the solution to a problem for 4 hours then check in with what they have

Lack of Awareness of IC Work ≠ A Problem

You mentioned that you trust 3/4 of the team already - do you feel the need to track those individuals throughout the day or week? If one of them disappears for hours at a time, are you concerned, or do you believe they are working and will check in if they have issues?

Managers that have the concern of "what is someone doing all day" either do not trust that person to complete the tasks assigned to them and ask for help when needed (lack of trust) or believe that they are abusing their remote position and doing less work than they could be doing (bad actor). You may have very legitimate reasons for believing either of these things.

If you don't trust them, what can you do to build that trust? If they are a bad actor, what can you do to confirm that they are a bad actor vs misinterpreting your goals and objectives for them?

The best way I have found is via a 1/1 every two weeks, with the following questions:

- Do you feel as though what is being asked of you is clear?

- Are you currently doing the work you want to be doing?

- What is harder than it should be?

The answers to these questions will likely confirm or deny your level of trust and whether the IC is a bad actor. Then you can figure out the appropriate next step.

Productivity Software ≠ Effectiveness

I would not recommend productivity tracking software or any "monitoring" software. This is your role - to make sure the team spends time on what is worth spending time on. Software will not be able to tell you whether the direction you are heading is the right direction, that is a judgement call.

There is an old communist joke "We pretend to work, they pretend to pay us". The analog here is, "We pretend to log JIRA hours/tickets, they pretend we are productive". You need to decide what level of effectiveness is appropriate for your team and drive towards that, whether that is new features, platform stability, security, etc. Not whether the team is superficially productive.

Team Size

-15 people is way too many people for anyone to effectively manage. You should be looking at 1/2 direct reports to help you manage those folks, but before you do that, you need to be able to tell them what to look for and how to manage the team. So while it may be overwhelming in the short term, I would recommend figuring out your system first, before hiring others to help you run it.