How I Run a Remote Team

Processes:

• Daily 123 in slack: 1 – what definitely will happen today, 2 – what will hopefully happen, 3 – what I’m filling in the gaps with.
• Daily standup: this is separate from 123, which I find is a better way to share?what. Standup is a little more about?how.
• Pairing: this just means “working together on something”*. Talking about the plan before writing code, explaining some piece of non-code work. Screenshare liberally, and often.
• Weekly build to QA. This is the best way I know to measure concrete progress – what’s in the release notes? What’s better than last week? It’s easy to have a performance of progress, where a lot of code is written but few features are completed and few bugs are fixed. Pushing something out every week mitigates this.

SLAs:

• PR-review. My desired SLA is that I look at every PR once. In practise, I fall short of this goal.
• Every engineer submits a PR every day. It doesn’t have to be big, but if days go by with no PRs it can be a sign that someone is overwhelmed or has a task that should be broken down.
• Speak to every engineer on the team 1:1, every day. This can be the equivalent of “hi” as you pass each other by in an open office. Or it can lead to a longer conversation.

Warm and Fuzzy and Hard to Measure

• Engineers who report to me will give me feedback. On PRs, on planning, on processes.
• Engineers who report to me will tell me things. This is a sign of trust that they think things will be better for me knowing about them.
• I can tell if someone is bothered by something and ask the right questions to draw them out.

As in all things I write about management, there is very little evidence I have any idea what I’m doing. As in all things I write about processes, this is what I aim to live up to.

* My initial reaction to “let’s pair” was “is this where you watch me code and judge me?” Much gratitude to the engineer on my team who taught me that is not the case.