Backstage - How I Pair with Teams
The Subtle Art of Enabling Productivity
I work remotely with many tech leads and their teams. I tried many different things on how to be helpful and enable their growth journey. But it’s challenging. There are many approaches cause me to be in the way. Or steal their problems. Or take off or create undue pressure.
I found a system that works fairly well. I’m sharing it with you in hopes that it would make your remote collaboration easier and inspire you to try it.
Push, don’t Pull
Announce that you’re available to pair for the next X hours and check who needs help. Avoid the back-and-forth of binary questions like Does anyone need help?
We’re building products, there will always be someone who could use some help. The same applies for when you need help. Simply announce “Hey, I’m working on this for the next X hours. Any help or shadowing is appreciating on a huddle.”
I call this a push approach because rather than dragging people onto your problem, you are announcing that you are available to help or be helped. It also communicates that you will do something productive even if no one comes to help you.
Schedule and Time Box
Pairing counters procrastination and sets you up with an immediate accountability buddy. Make sure it doesn’t backfire and dissolve into casual chatter— therefore it’s important to have a clear goal:
Set an intention. Agree what it is you are doing and what you’re definitely not doing. Set a clear focus “I have <amount of time> for one increment. What are we trying to learn / do?”
Time box the pairing. Put a 1-2 hour “Focus time with Denis” meeting on the calendar if you’re scheduling it
Make one or several commits something at the end of the session. Ensure work is “done”
Aim to deploy or at least merge. Pairing ensures immediate review. Take advantage of this and avoid the unnecessary PR. If you are required to by procedure, try to change it for pairing or at least merge it live on the session
Separate Assistance from Driving
There are many combinations of activities:
Classic navigate & type pairing, change frequently
The person typing listens and tries to understand. The navigator explains his or her thought process so the driver can succinctly put it in writing. It’s the misunderstanding that often reveal unknowns or expose gaps in our design.One person explores options, the other person assists with documentation
My personal favorite. This is often useful when exploring new technologies and SDKs. The main driver focuses on what’s being created and prototyped. In parallel, the assistant is one step ahead: Need a snippet from the docs? Got it ready. Need to find some obscure reference or constant, can look it up while typing.Work backwards. Prepare for a deploy or empty PR.
Similar to press-release planning from Amazon, start with your finished deployment artefact. Empty at first, write down the release changelog and work backwards together providing the minimum implementation and testing for both. This is best for mentoring and coaching activities where experience and domain knowledge differ greatly.
What helped me avoid the remote micromanagement is to detach from the process and keep accountability separate from shared responsibility. Even though there’s two of us working on it— one person is more accountable. That person will continue working on this after the pairing.
Avoid conflicts where you have to interrupt the pairing for whatever reason (ie. lunch) and then no further progress is made until you can synchronise.