Good Coaching vs. Coaching Anti-Patterns

Is unit based: saying what could be done better in this particular unit. If you could paste any IC unit in this coaching, then it's not unit based for sure
Clear description of the problem, what IC made wrong, understandable for IC & reviewer
Root cause of the problem correctly identified, preferably using n-why technique
Actions defined
1. Tell What & HOW IC should do sth better
2. Write in 1st person, IC will receive this coaching via email and he should understand whole picture from it
3. Cover several actions if possible:
  1. Quick - how to unblock IC
  2. Quick - how to solve problem within this particular ticket
  3. Longer - how to avoid this happening in the future (process, tools, documentation, IQBs etc)
  4. Any other sub-problems that appeared in RCA
Clear expected result - what will/will not happen in the future after your coaching is applied, e.g. IC will not fail QB4 in X kind of tickets (has to be short, no coaching/actions here). It should have relation to the Problem described.
Is technical. Touches core of IC work (code, content of RCA/E2E etc)

Problem not clearly described
Directive, not answering HOW: eg. 'Reach your target of X units !'
Action not clear - what IC should exactly do?
Not based on real work units. Even sometimes there is link, but not really related to coaching
Not getting to root cause of the problem, or just calling symptoms as root cause
"Plan to have a plan" anti-pattern: example: "Find QBs which can be automated and build a tool for that", "I will propose new QB", "I will update playbook" - this all should be proposed within coaching/insight
Problem described, then "Create ticket to another team" as only action
Not clear, what IC did VS what help did you provide him.
1. Sometimes it's just ticket description with problem & solution, not clear where exact coaching is
2. Coaching is just repeating, what was the error reported by QE
Just unblocking IC is good action, but it's not enough for good coaching
WSPro time issues - they are general, ok to talk about it, but not fit as unit based coaching
No long-term action. If nothing apply because you have mechanisms in place, write it explicitly
Focus on additional tickets just for metrics. Additional ticket is not improving real productivity!
Arguing QE to not fail a ticket is not Quality improvement. It increases metrics, not unit quality
Defining new functionality/automation for IC to do as coaching - but he didn't do anything wrong about it as he will just start working on it. It's usually automation idea, it’s better to commit it as an Insight

Last updated 5 years ago

Was this helpful?

Is unit based: saying what could be done better in this particular unit. If you could paste any IC unit in this coaching, then it's not unit based for sure
Clear description of the problem, what IC made wrong, understandable for IC & reviewer
Root cause of the problem correctly identified, preferably using n-why technique
Actions defined
1. Tell What & HOW IC should do sth better
2. Write in 1st person, IC will receive this coaching via email and he should understand whole picture from it
3. Cover several actions if possible:
  1. Quick - how to unblock IC
  2. Quick - how to solve problem within this particular ticket
  3. Longer - how to avoid this happening in the future (process, tools, documentation, IQBs etc)
  4. Any other sub-problems that appeared in RCA
Clear expected result - what will/will not happen in the future after your coaching is applied, e.g. IC will not fail QB4 in X kind of tickets (has to be short, no coaching/actions here). It should have relation to the Problem described.
Is technical. Touches core of IC work (code, content of RCA/E2E etc)

Problem not clearly described
Directive, not answering HOW: eg. 'Reach your target of X units !'
Action not clear - what IC should exactly do?
Not based on real work units. Even sometimes there is link, but not really related to coaching
Not getting to root cause of the problem, or just calling symptoms as root cause
"Plan to have a plan" anti-pattern: example: "Find QBs which can be automated and build a tool for that", "I will propose new QB", "I will update playbook" - this all should be proposed within coaching/insight
Problem described, then "Create ticket to another team" as only action
Not clear, what IC did VS what help did you provide him.
1. Sometimes it's just ticket description with problem & solution, not clear where exact coaching is
2. Coaching is just repeating, what was the error reported by QE
Just unblocking IC is good action, but it's not enough for good coaching
WSPro time issues - they are general, ok to talk about it, but not fit as unit based coaching
No long-term action. If nothing apply because you have mechanisms in place, write it explicitly
Focus on additional tickets just for metrics. Additional ticket is not improving real productivity!
Arguing QE to not fail a ticket is not Quality improvement. It increases metrics, not unit quality
Defining new functionality/automation for IC to do as coaching - but he didn't do anything wrong about it as he will just start working on it. It's usually automation idea, it’s better to commit it as an Insight

Last updated 5 years ago

Was this helpful?