Monday, October 7, 2013

Leadership for a tester - part 1

Today, I like to write about leadership.

For those genius techie testers, leadership might not be very attractive topic. You already getting respect for your technical skills and delivery so you don't have to worry about being a manager.

But seriously, do you only need a leadership skill when you become a manager? I've seen lots of leaders who don't have manager or senior title. Wether you're planning to go managerial route or individual contributor route, you need leadership skill. Leaders are influential. And good companies know that and use if for measure of promotion.

There are tons of books and articles about leadership. And those are mostly written by business people (e.g. MBAs) and for the business people (e.g. MBAs). Lots of them are the same concept with a little different flavors. I found a good one yesterday. And I've been thinking about it all day to relate to my lovely work, software testing.

Here is the simple quote that explains.

"A good leader has three kinds of leadership, and he/she should be excellent at all of them simultaneously. Those are Strategic leadership, Operation leadership and People leadership."

Let's relate this to our testing world. And I want to point out one more time, good at all those three simultaneously. 
  

Strategic leadership

It's about the decision on how you're going to test your software. It requires a good understanding of what you have, what you can control and what you can do. And you make decision and execute on that. This applies to the one who is responsible for entire test organization of the company, the one who is responsible for one testing department, or the one who is responsible for a story testing. And you can guess that the decision will impact based on what you're responsible for.

I really think context-driven testing make sense in this leadership because what you have, what you can control and what you can do differ from companies to companies. Even if two companies producing similar software product, testing strategy cannot be similar. Your company/organization will have people who has different skill set. Company/development culture can be different. Process adoption and maturity are different. You might or might not be able to work with offshore. Testing strategy the company has been using might be different. And so on and on..

However, there are things we can do to make sure testing strategy works.
First, you need to communicate your testing strategy. If you're a test director or manager, you need to communicate your strategy to all of your subordinates and make them understand. Why we're doing this way and what we're expect to get out of our current strategy. If you're an individual contributor tester, you need to communicate your testing strategy with your scrum/project team. "This is how I'm going to test this story and this is why." By doing so, you are informing your plan and open  for feedback. A great strategic leader make sure others understand what're he/she is trying to do and why. And provide a way to get feedback. If you as an IC and feel that your test manager/director just care about numbers and graph, you need to challenge them to provide strategy.

Second, you need to have a mechanism that shows progress or results of your decision. This happens naturally if you open your feedback channel. For test directors and test managers, you need to check with your direct reports to understand how the strategy is working. Often times, you'll see issues, overhead or redundancy in your strategy. And for ICs, you can see how your strategy is working by going through several iteration of work(sprints/milestone). I know measuring testing progress or success is hard. (I'm planning on writing one post about this) Sometimes it's not about numbers or graph, people notice the benefits and drawbacks. You need to check your strategy progress/result and make adjustments to make perfect fit for your situation.

Third, you need to study, research and experiment a lot on strategy. Innovation does not come out of nowhere. Hear other companies stories, your subordinate's experiences, and feedback. Have a meeting with your directs to make better. Work with PMs and developers to understand their views and progress. Continuous improvement is part of strategy effort. And make sure you're doing the right thing, not doing things right.

And lastly, once you're clear on strategy, you should believe in it and execute the hell out it.    

I'll write operational and people leadership in following post.

No comments: