The rest of the team develop software, using the typist as a smart voice-controlled input device. This is how to communicate and act towards the typist.
Communicate the intent. Be clear about the why to the typist. A smart typist with system knowledge might already start implementing just with the why.
Communicate location accurately using absolutes like file names, class names, or line numbers. Avoid relative location like “move a little bit more up; no, that was too far, go down a little bit more, …”.
It’s not what you say, but how you say it. So say “Can you go to line 45, please?”.
Be patient when giving the typist commands. You are responsible that the typist feels comfortable. Give the typist time to think and fix their own mistakes like missing semi colons, too many parentheses, or simple typos.
Accept the freedom of the typist. Before giving advice, make sure the typist is open for it. A typical example is when the typist is doing a refactoring manually and you know how to do this with IDE functions only. Tell the typist you have a suggestion on doing this differently, and ask them if they would like to know it - but be prepared to accept a no as an answer. The best case would be that you never give advice unsolicited, but the typist has an inkling that IDE refactorings might help here and asks you to guide them.
Speak with one voice. Don’t send conflicting commands. Normally, a temporary spokesperson emerges naturally. If this doesn’t work, you can agree upon a temporary spokesperson - and they might even rotate alongside the typist.
Make sure that you don’t dominate the rest of the team. If you realize you’re talking too much, you might be leading by giving command over command. Think about switching to lead with questions instead. Asking questions will automatically reduce your talking time and opens space for others to join in and share their solution approaches.
Make sure everybody in video call is okay.
We’re just sharing what works for us. It might help you as well.
