Notes on enginering leadership and software development.

Remote Team Health Check

I've been away from my team for almost a month and a half. No checking-in on Slack, no reading weekly posts on Basecamp. I didn't know what was happening, and of course, I was anxious about it.

We're a fully remote company, and every time I get back from time off, I scan for how the team is feeling. You can usually scan your team's communication channels in just a few minutes to get a picture of whether the team is happy, motivated, and productive, or stressed, burned out, and confused.

Here's the list of things I look for to get that picture. Your list may vary: each team has their own culture, so their "happy place" will be different. But the principle stays the same — quick scan to see where your attention is needed most.

Are people working in the open?

Do you see folks talking about their day-to-day work in the open Slack channels (or Discord, or whatever else you use)? Asking for a review, syncing up between platform and product, frontend and backend engineers, quick asks about different pieces of your system, or product or design questions — do you see them in the open?

Working in the open channels is essential (to me) in remote environments: it lets others chime in, understand how things work, see the progress, or search for that topic in the future, or support the work if the team needs help, or if someone has a few days off, and someone else is picking up their work.

If you don't see open chatter — it's either because no one is talking about day-to-day work at all (unlikely, but that's a different problem), or because everyone is siloed in their DMs.

If you've seen the chatter before you left, but it died out without you — think about why nobody else sees talking in the open as beneficial, or why are they afraid to or shy to post in the open. Do you see judgement, "well, actually", or other form of lack of support when people did talk in the open previously?

Are people asking for help?

Do you see people asking for help and advice? Sharing their in-progress work? Admitting they're struggling with a task, or admitting mistakes?

Some teams prefer a more open and direct culture than others. But in all teams where people respect and care for each other, they would support their teammates when they need help. But to share a work-in-progress, or admit a mistake, people on the team need a pretty high level of trust with each other, and with their organization leadership. Nobody would share their mistakes if they thought that doing so would affect their next performance review in a bad way.

So if you don't see any of the vulnerability and camaraderie in the team, it could be that no one needs help, or makes mistakes, or gets blocked ever (lol no, they do). However, it's much more likely that people are afraid to talk about their mistakes in the open because they don't trust that other people on the team, or you, will not use that against them.

In my experience, that kind of trust starts with leadership. Believe it or not, nobody expects you to always be right. And when you tell your team that you need help, or ask for help for help, or tell them that you made a mistake — it empowers your team to do the same. Of course, that only works if you don't punish people for making honest mistakes.

Are people debating ideas?

Do you see any new RFCs, or just discussions about how to build a feature, or what architecture would work best? Do you see respectful disagreements and debates? Strong arguments and spikes to support ideas?

RFCs, Disagreements, and debates are all critical to building a resilient, open, serene organization that sources ideas from all the talented people on the team. But it's pretty hard to get right.

Discussions take time to think and prepare through a problem at hand. Articulating engineering opinion is both a communication task (writing and presenting), and an engineering task (research, proof of concept or a spike). It's your job as a leader to balance your team's backlog in a way that gives them enough slack-time.

Disagreeing in public and taking time for research work can feel scary for the people on your team. If that work is not recognized, or if the discussions are routinely shut down and discarded because of a pressing deadline — no one will risk taking the time to articulate and post their opinion anymore. Which is pretty bad for your team's culture, and for the company as a whole, as it limits where you get new ideas. Why hire the smartest people you could find, and then shut them down?

So, if you don't see any back-and-forth on ideas on how to implement features, and close to zero feedback on pull requests overall — you should absolutely dive deeper.

Do people have a shared goal, a path forward, and a clear indication of their progress?

To stay engaged (with the company) and energized, people really need a plan that makes sense to them, an explanation of why that plan is important, a picture of what everyone else in the company is doing, and an indication of how they're doing as a team and as a company.

In the first few 1:1 conversations, ask about what goal do they think their team is working towards, and what are the next steps for them. Is there a consistent picture of the team's goals? Do people know what they're working towards, how it contributes to the company, and where they are on the path to that goal?

For people to stay engaged with the company strategy, someone has to connect them to it, and consistently relay any changes in strategy, and broadcast the current state, and the path forward.

It's your job as a leader to communicate the strategic goals, and the tactical goals to your team. If you put the right systems and communication channels in place, then your team should at the very least be informed and well-connected internally. However, your time away puts those communications systems to a serious stress test — you were not there to course correct if they didn't work.

The same goes for understanding where the company, the organization, and the team is now in their path towards the goal.

Are people cheerful?

Do you see folks recognize each other's work, and support each other?

  • If your team has daily written check-ins, do you see people reacting to each other's check-ins? Congratulating each other on work well done? Do people check-in at all? If you see any outliers that dropped the habit, can you figure out why?
  • If you have regular sync calls to check in — do people gladly share their work in progress with each other, and ask questions, or do you have to call out each team member one by one and inquire about their progress?

Engaged teams work together. The recognition and energy helps push the project forward. If you have to pull the progress out of people on your team, and the morale seems down — it's likely a combination of factors described above. Lack of clarity, lack of autonomy, lack of recognition, lack of support, or an otherwise toxic environment.

If your team culture does decay, it usually starts slow, but then snowballs. Lost trust is very difficult to rebuild, so hopefully you catch the first signs of problems in just one area before it's too late, and immediately make time and a plan to improve on it.

More on leading and supporting fully remote teams:

⌘ ⌘ ⌘
Originally published on Jun 25th 2023.
Last update on Jul 3rd 2023.