Coaching & Leadership
A Test Lead builds capability, not just executes tests. Learn how to grow your team through skills matrices, coaching techniques, and leadership that creates a quality culture.
1 The Hook — Why This Matters
In 2022, an Auckland fintech team of five testers lost two senior members within three months. The remaining team was overwhelmed, regression suites were slipping, and morale was cratered. The Test Lead did what many do: she picked up the testing herself, working late to cover the gaps.
It worked for two sprints. Then she burned out. The team, deprived of mentorship, kept making the same mistakes: poorly written bug reports, missed edge cases, duplicated effort. Six months later, the company had to hire external contractors at twice the cost to rebuild the test practice.
The lesson: A Test Lead who only executes is an expensive senior tester. A Test Lead who builds capability creates a team that outlasts any individual. Your job is to make yourself less necessary over time, not more.
2 The Rule — The One-Sentence Version
Build the team's capability faster than you build the product's quality, and the product will take care of itself.
Leadership is not a title. It is a set of behaviours: setting direction, removing blockers, giving feedback, creating safety, and investing in growth. The best Test Leads spend as much time on 1-on-1s and skills development as they do on test plans.
3 The Analogy — Think Of It Like...
A rowing coach, not the strongest rower.
The best rowing coaches do not win races by pulling harder. They win by studying technique, identifying who needs strength training versus who needs endurance work, adjusting the crew seating, and building trust so the team rows as one. If the coach jumps in the boat every time it slows down, the crew never learns to handle choppy water. Your job is to make the boat go fast without you in it.
4 Watch Me Do It — Step by Step
Here is a real NZ example: a team of five testers in a Wellington SaaS company. Follow these steps to build a development plan for any team.
- Map the team's skills with a skills matrix List skills across the top: test design, automation, performance, security, domain knowledge, API testing, mobile. Rate each person 1–5. Identify gaps and concentrations.
- Analyse the matrix and identify risks The Wellington team's matrix showed: automation strong (4/5 average), security weak (2/5), mobile testing weak (2/5). One person carried most of the automation knowledge. That is a bus-factor risk.
- Create individual development plans For each gap, define a concrete action. Security weak? Send one person to OWASP training and have them run a lunch-and-learn on return. Mobile weak? Pair the automation expert with a mobile specialist for one sprint.
- Use pairing and rotation deliberately Pair junior testers with seniors on complex features. Rotate testers across teams or domains to broaden domain knowledge. Cross-pollination reduces single points of failure.
- Run effective 1-on-1s every week Use a simple framework: What went well? What was challenging? What support do you need? What are your goals? Document the answers. Follow up on commitments. A 1-on-1 without notes is a chat, not a development tool.
-
Understand Tuckman's stages and adapt your style
Forming → Storming → Norming → Performing (→ Adjourning). In Forming, be directive. In Storming, mediate and clarify roles. In Norming, step back and let the team self-organise. In Performing, remove blockers and protect focus. In Adjourning, celebrate and capture lessons.
| Skill | Aroha | Ben | Chen | Dana | Eli | Avg |
|---|---|---|---|---|---|---|
| Test design | 4 | 3 | 4 | 3 | 2 | 3.2 |
| Automation | 5 | 2 | 3 | 2 | 2 | 2.8 |
| Performance | 2 | 2 | 3 | 2 | 1 | 2.0 |
| Security | 2 | 2 | 2 | 2 | 1 | 1.8 🚨 |
| Domain knowledge | 4 | 3 | 3 | 4 | 2 | 3.2 |
| API testing | 4 | 3 | 3 | 2 | 2 | 2.8 |
| Mobile | 2 | 2 | 2 | 2 | 1 | 1.8 🚨 |
Plan: Aroha trains the team on automation (reduce bus factor). Chen attends OWASP NZ training. Ben pairs with a mobile specialist for one sprint. Eli gets a structured onboarding plan with weekly goals.
Scenario: A team of four at an Auckland insurance firm. The Test Lead creates a skills matrix, identifies gaps in API testing, and assigns the junior tester to pair with an external specialist. The plan is solid. But:
- No follow-up: The pairing happens once, then slips into backlog.
- No psychological safety: The junior is afraid to ask questions, so they nod along but learn nothing.
- No accountability: In the next 1-on-1, the lead forgets to ask: "How did the pairing go? What did you learn?"
- Result: The junior still cannot write API tests. The lead blames the junior ("not committed to growth") instead of recognising the failure was structural.
The fix: Coaching requires follow-through. After you identify a gap and create a plan, book a recurring check-in: "How is the pairing going? What blockers do you face? What have you learned?" Celebrate small wins publicly. Hold both yourself and your people accountable to the plan.
Senior engineer insight
The shift that changed everything for me was realising coaching is fundamentally an information problem: your team cannot improve on what they cannot see. Once I started making quality visible — sharing bug escape rates, running defect retrospectives, posting skills matrix scores openly — junior testers started self-directing their growth instead of waiting to be told what to learn. The skills matrix turned a vague "you need to get better at API testing" into "your current score is 2, here is what a 4 looks like, and here is a pairing plan to get there."
Most common mistake: Test Leads invest in the willing and ignore the resistant, then wonder why the team ceiling never rises.
From the field
On a Wellington insurtech programme, we had a junior tester who was producing shallow test cases — happy-path only, no edge conditions, no negative paths. The assumption was he lacked drive. What we discovered in his 1-on-1 was something different: he had never seen a good test case written from scratch, only inherited a legacy suite he was expected to extend. We ran three paired sessions where I wrote a test case in real time, narrated my thinking aloud, then had him critique it. Within six weeks his coverage had transformed, and he was running his own mini-workshops for the two testers who joined after him. The lesson: most junior testers are not lazy — they are working from a mental model of "good" that nobody ever made explicit.
5 When to Use It / When NOT to Use It
✅ Invest in coaching when...
- You have juniors who need structured growth
- The team has a single point of failure in a skill area
- You are adopting new tools or practices
- Retention is dropping and exit interviews cite "no growth"
- You want to build a quality culture, not just find bugs
- You are preparing someone for promotion or leadership
❌ Avoid coaching when...
- The team is in crisis mode and needs direction, not development
- The individual is not open to feedback (coaching requires consent)
- You are using coaching to avoid a performance conversation
- You have not modelled the behaviour you are coaching
- The organisation punishes failure, making safe-to-fail impossible
Before you invest in coaching, ask:
- Do the people you want to coach actually want to grow, or are they content in their current role?
- Do you have time to run 1-on-1s consistently, or will they become sporadic?
- Is there psychological safety in your team to discuss struggles and mistakes openly?
- Can you model the behaviour you are asking others to develop?
6 Common Mistakes — Don't Do This
🚫 Micromanaging instead of mentoring
I used to think: If I review every test case, quality will be higher.
Actually: Micromanagement creates dependency. The team stops thinking and starts waiting for your approval. Instead, review a sample, give structured feedback, and let them apply it independently. Check back in a week. That is mentoring.
🚫 One-size-fits-all coaching
I used to think: Everyone should learn automation first.
Actually: A tester with strong domain knowledge and weak automation may be more valuable writing exploratory charters than Selenium scripts. Match coaching to career goals and team gaps. Ask each person: "What do you want to be great at in two years?"
🚫 Keeping stars on grunt work
I used to think: My best tester should do the most testing.
Actually: Your best tester should be teaching, reviewing, and raising the floor for everyone else. If your star is still doing regression test execution every sprint, you are wasting leadership potential. Delegate execution. Elevate impact.
When this technique fails
Coaching without clarity or follow-through demoralises teams. If someone receives feedback and nothing changes, or if development plans are made but ignored, the team loses trust. Coaching also fails in crisis situations where the organisation is in shutdown mode—people need direction and safety first, growth later. Finally, if the lead is not willing to get their hands dirty or admit gaps, coaching becomes performative and loses all credibility.
7 Now You Try — Leadership Dilemma
Scenario: You are leading a team of four. Your strongest automation engineer, Sarah, tells you in a 1-on-1 that she wants to move to development within 12 months. Your manager says: "We cannot afford to lose her from testing. Can you talk her out of it?"
What do you do? Write your approach before revealing the answer.
👍 Support the transition.
Trying to talk her out of it destroys trust and guarantees she will leave anyway — possibly to a competitor. Instead:
- Set a timeline with milestones (e.g., start shadowing dev team in 3 months).
- Document knowledge transfer: what only Sarah knows, and who will learn it.
- Keep her engaged with automation architecture work that uses both skill sets.
- Celebrate her growth publicly. A lead who grows people attracts more talent.
Key insight: Your job is to grow careers, not hoard talent. A team member who leaves testing better than they found it is a leadership win, not a loss.
Why teams fail here
- Development plans exist on paper but have no calendar time blocked, so they evaporate by sprint three when delivery pressure returns.
- Psychological safety is absent — testers who raise concerns or admit skill gaps are seen as weak, so the skills matrix gets gamed with inflated self-ratings and real gaps stay hidden.
- The Test Lead coaches the wrong thing: they focus on technical skills (automation, tooling) while ignoring the critical-thinking and communication gaps that actually explain why bugs are written poorly or missed in review.
- Feedback is delayed until performance reviews instead of being delivered in the moment, so the junior tester has repeated the mistake thirty times before anyone names it.
Key takeaway
Your job as a Test Lead is not to be the best tester in the room — it is to build a room full of testers who no longer need you to be.
8 Self-Check — Can You Actually Do This?
Click each question to reveal the answer. If you got all three, you are ready to practice.
Q1. What are Tuckman's five stages of team development?
Forming (orientation, dependence on leader), Storming (conflict, competition), Norming (cohesion, agreement on processes), Performing (self-direction, high output), and Adjourning (closure, celebration). Your leadership style should adapt at each stage.
Q2. What is the purpose of a skills matrix?
A skills matrix maps team capabilities against proficiency levels, revealing gaps, concentrations, and bus-factor risks. It turns vague feelings like "we are weak on security" into actionable data: "Three people rate 2/5 on security; we need training or hiring."
Q3. Why should a Test Lead do the hard tests themselves?
Leading by testing earns credibility, sets the quality bar, and creates teachable moments. When the team sees how you approach a complex security test or a subtle race condition, they learn what "good" looks like. Then you debrief so the learning spreads.
9 Interview Prep — What They Will Ask
Q1. How do you handle a high-performer who wants to move to development?
I support the transition. I set a timeline with clear milestones, document knowledge transfer so the team is not left with a gap, keep them engaged with automation architecture work that bridges both worlds, and celebrate their growth publicly. Trying to block them destroys trust and guarantees they leave anyway. A lead who grows people attracts more talent.
Q2. Describe how you would run a 1-on-1 with a struggling junior tester.
I use a structured framework: What went well this week? What was challenging? What support do you need? What are your goals? I listen more than I talk. I avoid jumping to solutions. Instead, I ask: "What have you tried?" and "What would you do differently next time?" I document commitments and follow up. Consistency builds safety. Safety builds growth.
Q3. How do you build a quality culture in a team that sees testing as a bottleneck?
I start by making quality visible: show escaped defects and their cost in customer impact and rework hours. I shift left by pairing with developers during design and code review. I celebrate early bug finds, not just late ones. And I involve the whole team in defining "done" so quality is a shared goal, not a testing burden.
Q4. A team member is resistant to automation. How do you coach them?
I first understand the resistance: is it skill anxiety, past bad experience, or a belief that manual testing is superior? Then I match the approach. For skill anxiety, I pair them with a patient mentor on a small, low-risk script. For bad experience, I show them a well-maintained suite with fast feedback. For philosophical resistance, I run a time-boxed experiment comparing manual and automated regression on the same feature, then debrief the data together.