Split typist and rest of the team

Author: simonharrer

restoftheteam.md

@@ -0,0 +1,35 @@
+## How to act in the rest of the team
+
+
+### Be intentional.
+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.
+
+### Be concise of location.
+Communicate location 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, ...".
+
+### Be polite.
+It's not what you say, but how you say it.
+So say "Can you go to line 45, please?".
+
+### Be patient.
+Be patient when giving the typist commands.
+*You* are responsible that the typist feels comfortable.
+
+### Be unobtrusive.
+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.
+
+### Be inclusive.
+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.
+
+### Be emphatic.
+Make sure everybody in video call is okay.
+

typist.md

@@ -49,39 +49,3 @@ Rotation is key to the success of working together.
 Make sure to hand over to the next typist on time.
 Don't go for the famous last words of "let me finish this real quick".
 
-
-## How to act in the rest of the team
-
-
-### Be intentional.
-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.
-
-### Be concise of location.
-Communicate location 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, ...".
-
-### Be polite.
-It's not what you say, but how you say it.
-So say "Can you go to line 45, please?".
-
-### Be patient.
-Be patient when giving the typist commands.
-*You* are responsible that the typist feels comfortable.
-
-### Be unobtrusive.
-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.
-
-### Be inclusive.
-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.
-
-### Be emphatic.
-Make sure everybody in video call is okay.
-