Test Leadership Lessons Learnt
By Sunjeet Khokhar
The biggest challenge (and source of learning for me) as a consultant has been to be able to operate and succeed at influencing change without any explicit authority, credibility, or mandate. Especially in organizations that do not have a precedent for effective testing practices. I want to share some of the test leadership lessons that I have learnt and tactics that I have employed to lead through influence.
Testers and those in non-direct leadership positions might find these lessons and tactics useful when exercising leadership in complex environments where the testing craft and its value are not understood or recognized.
Lack Of Maturity In A Testing Practice
Last year I consulted a client who was executing a multi-year, public sector software programme that comprised of 10+ concurrent tech and operational projects.
The complexity of a programme that large was driven by lack of maturity towards a test practice, wherein some of the core elements of a test process were missing. Here are a few of the things I identified as issues which indicated a lack of mature development and testing practices:
- There was confusion and lack of credibility about our test process among stakeholders.
- Stakeholders were not engaged and did not recognize the value of skilful testing.
- The team was not sure of their role, where they were heading, and how would they achieve their objectives.
- Testers were seen as outsiders (as business units had not experienced valuable testing before), resulting in a lack of support to embrace better testing practices.
- There were silos of business units with explicit resistance to share their turf and achieve a common cause.
Lessons Learnt From Leading Through Influence
After 10 months with the client, the testing team had grown to 20 testers. As a team, we were able to turn around the reputation and credibility of testing. Business people were advocates of our work and relied heavily on the information that the team provided to aid business decisions.
Here are four stories on the tactics I used that had an impact on strengthening the test process, structure and credibility of the testing team.
Behaviours & Values: Your Touted Values And Behaviours Need To Align
A month or so into the role, due to a sudden leadership gap, I was asked to lead a multi-week user acceptance testing (UAT) effort for a public facing pre-go live phase of the programme. I had no credibility in the organisation and there was resistance to embracing anything related to a test process and there was no precedent in terms of value that good testing craft can bring to the table.
"Why do we even need a defect management process ? We are not expecting many bugs"
"Why do we want to see all the testing work in a central place?"
"I am not sure what value will testing will provide here"
These were the themes of feedback that I received when I came onboard into the leadership role.
Business units (for whom I was leading the UAT effort) considered UAT to be just a tick box exercise and underestimated the technical complexity of the various system components that were being integrated.
On top of that, the development teams delivering the work were extremely stressed out, siloed away from my team (performing UAT).
And in turn, there was a severe lack of coordination among the development teams themselves, bugs were being ping-ponged around teams which no ownership, visibility and facilitation. This had created a highly emotive environment where the siloed teams were not talking to each other but just trying to stay off the critical path (by taking the minimal amount of action required to make it another team’s problem)
I relied on two core principles to influence my stakeholders and demonstrate the value of testing:
- My behaviours need to be different from the status-quo to beat the status-quo.
- The test process needs to be “lean” and speak the business’ language.
Doing Things Differently From The Status-quo
I needed to get the siloed groups talking to each other and there were 3 key things that I did differently from the status quo:
- Represent work and progress visually.
- Report frequently on testing progress.
- Create a common understanding of dependencies and who is responsible for resolving them.
To report on testing progress, I had to make the work visible in the first place. To achieve that I set up a simple Kanban board capturing all the UAT work that spanned across what the various development teams. The board also visually showed where the inter-team dependencies were, who owned which dependency and what was the next step (to remove that dependency). In addition, I also organized a daily stand up with key business managers to go through the board, reflect on progress, discuss dependencies and agree on the next steps.
Having the business managers/key decision makers in the same place and having all the work/dependencies in the same place, short-circuited the "ping-ponging" of issues that happened earlier.
To top it off, I created a summary of test progress (based on the board) at the end of each day and sent it off the all the involved business units and senior managers.
The visual board, daily stand up and end of day report all put together created a shared understanding of where Testing was at; the scale of complexity/risk that warranted the level of testing that I was advocating.
Keeping It Lean
Keeping the test process “lean” also helped in lending a rudimentary structure to testing. Doing simple things like having a Kanban-esque board to reflect the UAT/Project backlog, creating a simple 1-page dashboard to report progress across the various API integrations of the architecture, and using those dashboards to link the health of the business processes that mattered. This went a long way towards my team’s test outputs being noticed.
Rather than only reporting the health of the technical architecture (e.g. in terms of various API endpoints), I reported progress using the currency that the business used, with the underlying tech details abstracted away. This immediately lead to the business hearing what the test team had to say about progress and quality.
The UAT cycle was 5 weeks in duration and during the course of this period, there were several occasions where one or more of the teams involved dropped the ball either in terms of not supporting the process that I had put in place or resulting in critical bugs that should have been picked up before UAT.
I looked at such events as opportunities, again, to beat the status quo. Rather than indulging in a blame game I took ownership of problems, was humble in calling out that a peer had dropped the ball and facilitated the issue to its conclusion in a transparent manner.
These behaviours enabled me to build my credibility. A testimonial to that, at the end of UAT phase, there was a retro held across all the business units on how the phase went. During that retro, I was provided feedback from multiple stakeholders on how they now saw the value added by the lean test process. They appreciated my leadership not only in terms of what I helped them achieve but how I went about it. One senior manager’s public comment was that I had consistently demonstrated that I don't just pay lip service to the organisation’s values but embody them.
So, to summarize, to build credibility when you are new to an organisation :
- It is not what you say but how you do, matters
- Manage work in progress and dependencies visually
- Demonstrate bias towards taking decisions (at the risk of being proven wrong)
- Communicate with humility (especially when your stakeholders make a mistake)
Be Fearless: Step Forward And Define Your Role
On social media, you might have come across the “what people think I do” meme, which is a sarcastic take on how various cross-sections of society perceive a particular profession. Here is an example about developers:
Source: We Know Memes
Similarly, the role that I was interviewed for, the role that I thought I would end up doing, and the role that I actually ended up doing, were all different. And the reason was, in the midst of fighting day-to-day organisational fires our manager had lost a view of the "why."
Pretty early on, I observed that no-one was asking the following questions:
- Why does the team exist?
- What does the team's success criteria look like?
- What does the team need to achieve those success criteria?
- What role do I play in the team’s success?
- What are our responsibilities and accountabilities as individuals and as a team?
We were all on a ship, and it was moving but everyone had a different version of why it was moving, and where it was going. Even though it was not my role, one of the key things I established through multiple workshops was a shared understanding of the identity, purpose, and the key issues for the testing team.
The key issues were a list of action-points and impediments that the testing team asked the senior leadership team to act on urgently to enable the team to achieve success. This list was circulated to the highest levels in the organisation and became the voice of the testing team through which they exercised reverse-accountability with the senior leaders in the organisation. The key issues also became a reflection tool for team members to measure our conversion rate in terms of how many issues have we ideated verses actually achieved.
As a Leader, you are the north star for your team. A big part of your role is to provide clarity on the team’s purpose and direction, and you don't need to hold a managerial title to be the voice of the team. You have to be fearless to speak up if your team’s role is poorly understood and facilitate answers to “where to/what’s next?” so that clarity on your team’s identity and purpose is achieved.
Give & Take: Don’t Ask For Authority Or Play The Power Struggle Game, Try And Build Personal Bridges
It is 'give and take', not in a 'you scratch my back and I scratch yours' way, but if you want to influence people hiding behind their silos you need to understand what success means to them rather than focussing on your team’s success and how can you help them achieve it.
Resistance to fresh ideas is often a cry for help based on past bad experiences or a sense of insecurity about not achieving one’s work-related goals. People in siloed cultures are less likely to respond to demands coming from your job title but are more receptive if they know you can solve a pain point for them.
The way I approached coaching or creating change, was through closely observing the challenges related to testing which other siloed business teams were struggling with (in terms of guidance and/or expertise).
I would then approach the team members and say:
"Hey you know we have already solved this problem in my team and can help you with a tool that can speed things up for you, would you like to see a demo?"
"This is an upcoming piece of work that falls in the overlap deliverable areas of our teams, even though this is directly assigned to my team, I would still like to hear your inputs and insights, as the work affects both of our business units, would you like to join us for a brainstorm?"
Demonstrating that I could get things done for them and was open and inclusive set the tone for cloistered business units to start collaborating with my team. Playing ping-pong politics is not the answer. To develop true empathy for others I am completely open, transparent, and embracing of perceived threats, scrutiny, or disruptions to my team as long as the role and purpose of the team is not compromised
Don't weight in by your title but your usefulness. Give and take does work, not back scratching but building personal bridges by selflessly offering to help other teams. Embrace disruption and scrutiny (especially in a siloed environment) while also balancing your team’s purpose and direction
Negativity In The Workplace: Work On Building Your Reserves Of Resilience
A common by-product of a complex environment and organisational politics is negativity. It was almost a sub-culture of this organisation and manifested sometimes as the proverbial team doomsayer, who always liked to publicly reflect on why the project would never succeed or publicly demean the quality of work that other teams were delivering. Or the nagger, who would constantly serve you syndicated content from other teams about contention, ego clashes, and conflicts which had no relation whatsoever with the work that the team was delivering.
Initially in the engagement, hardly a day passed by when I did not return home burdened with self doubt and frustration from all the negativity and rejection (of the better test practices that I believed in) that I received. My physical and mental well being started to take a toll and I was not finding myself mindful outside work, especially when I was around my family as I was still hungover from work related issues.
These were the two tactics that I employed to deal with the negativity and to build my resilience:
- Actively dissociate myself from office-jerks. If I could not do anything about them, I made it a strict professional policy to ignore the personas which were destructive. I actively sought to engage with people who demonstrated a track record of getting stuff done. These were the folks worth building personal bridges with. The ability to influence stakeholders is directly proportional to whom you associate yourself within the organisation.
- Do the “it’s not rocket science” stuff with discipline. “Don’t check work emails first thing in the morning.” “Go for a jog every day.” “Meditate for 5 minutes." “Be more mindful.” These are but a few of the well-meaning platitudes have been said to death but are hard to do because it takes a lot of self-discipline. For me, the tactic that worked was to pick two or three of the “not rocket science” stuff that worked for me to unhook myself from work related stress and do them really well.
In my case there are:
- Going for a run every day
- Writing regularly
These two activities have proven to be really effective tools for self-reflection, and for spiritual and physical rejuvenation which helped me bounce back from workplace stress and helped add to my reserves of resilience.
The key to building resilience is to actively stop hanging out with project doomsayers. If you can not influence it, stop engaging in disparaging gossip about other teams’ quality of work. Reflect on past success to reinforce self-belief and take care of yourself before anyone else (both physically and spiritually).
Leading Through Influence Rather Than By Position
Becoming a trusted adviser to a decision maker is the key to influencing positive change in organisations. The lessons above have been applied to subsequent test management engagements I have taken.
My recipe for becoming a trusted adviser is to:
- Before everything else, focus on achieving a shared understanding of the team’s purpose and direction.
- Ensure that actions demonstrate the values which I claim to hold.
- Avoid getting dragged into negativity at the workplace.Instead focus inwards on building resilience.
- Lastly, it is all about building personal bridges by demonstrating a bias towards action and proving worth by being resourceful and a problem solver.
To keep these top tips handy, here are my 4 lessons on how to lead through influence as a graphic. You can download this as a PDF below!
Sunjeet Khokhar is a consulting Test Manager and an experienced Practice Lead, over the past 4 years his key focus has been on solving organisation wide testing problems (primarily in IT Teams within non-Tech companies). Prior to that, he worked in Tech product companies for a decade as a Tester and a Team Lead.