Leadership for a tester - part 3 (people)

Let's talk about the last one. People leadership.

Let me mention this first. If someone asks me to recommend one book that explains pretty well about software development/testing leadership, I would pick "Notes to a Software Team Leader" by Roy Osherove. I really appreciate every point he made in his book, and I totally agree with him. Awesome book. You should read it. He is one of my favorite guys of software development speaker. Like uncle Bob, Martin Fowler and Scott Hanselman. I've really enjoyed watching all his "Unit testing, TDD, team leader manifesto, and etc." YouTube videos. His talk is not as exciting as uncle Bob or Martin Fowler, but I respect his talk because I can feel the pains, thought process, lesson learned, experiment, and effort he went through from his own software development experience. OK. Enough for the guy. Let's start

I always wanted to mention this first when I blog about people leadership. Here goes. I'm sure you've seen lots of articles like '10 common thing that amazing leaders do', '5 habits of great leaders, 10 signs of a great leader and so on. (seems like leadership article should have some sort of list). Leadership is not some attributes added to who you are. It is actually who you become. It requires genuine effort to motivate people and to convince people with what you believe. People are not stupid. Don't believe that everyone in your organization is practical. More money and higher position may keep some practical people. But that does not keep genuine and professional people. You have to be genuine.


Don't be an assh**e because you're smarter than others. You may become a leader because you stand out. You're smart and you do your work more efficiently and fast. Being an assh**e is different from being charismatic. Charismatic leader scolds at people when the value or vision gets disturbed. Ass**e scolds at people when his/her own expectation is not met. Don't think people will respect you because you're simply smarter than them. I like the quote of Jeff Bezos (Amazon) at Princeton Univ. "Cleverness is a gift, but kindness is a choice. Would you bluff it off when you're wrong or would you apologize?"


People leader knows and understand her people individually. She understands the strength and weakness of her people. Some people needs coaching. And some people needs freedom. If she goes up, she understands each team's strength and weakness. She focuses on progress and think about how to help the progress rather than seeing the result and judge. Hitting the milestone is easy to check, but understand what kind of problem gets solved and know what kind of barrier there is are hard.

Well.. I might update this post later. I've got some more to write but I'm a little tired. :)

Leadership for a tester - part 2

Operational leadership

You can easily imagine that great strategy with poor execution cannot lead to a good result. However, great execution in software testing is somewhat hard to define.  We can do all sort of things as part of testing but we cannot clearly know all the effort actually 100% contributed to achieve this big ambiguous goal, 'excellent quality of software.'

To give you some idea, let me give you a question. Which tester do you think is more productive or effective? One who finds lots of good bugs or the one who can prevent from bugs being created? The one has in depth coding knowledge of the application or the one who deeply understands and knows users/customers usage and expectation? One who uses test process/methodology that has been working successfully or one who wants to try unproven new process/methodology that possibly benefit testing effort? One who found 20 pri2 bugs or the one who found 2 critical/pri1 bugs?

What do we do to measure the testing effectiveness? I've seen many times that test managers seriously going through irregular bug burn-down chart categorized by priority/severity or test story points fluctuation to get some sort of meaning out of it. I know data will not lie. But do those data actually represent the effectiveness of testing? I would say no.

Operational leader executes and delivers based on testing strategy. 

I like to emphasize one more time on "simultaneousness" Poor strategy ruins excellent execution. This is like building an excellent ship to go over a mountain. Poor execution makes excellent strategy a day dream. It's like a innovative and passionate person leading a team of complainers "that does not work in this company. you just want to do this to get visibility from senior management....."

Operation leader understands the strategy clearly and execute towards that. And operational leader helps to form excellent strategy.

Based on assessing the context of product/team/timeline/etc, if the testing strategy for current product is more towards CI and pyramid(ton of unit tests,  many integration tests, a few UI/E2E tests),  she will generate code coverage data from unit tests, come up with gated check-in strategy, gather feedback cycle and trends of integration tests and UI tests. She will continue to monitor the progress and tries to optimize the testing effort. Staffing will be leaning towards to the strategy as well. She will clearly deliver the importance of the strategy and ask her team to be best at those areas.  If the testing strategy is more towards exploratory execution and user-centric, she will discuss with the team to come up with session-based exploratory testing plan, ad-hoc testing plan, think outside of box exercise, crowd sourcing, dog fooding and etc. She will generate data relevant to exploratory testing area, buggy feature, or qualitative confidence. She will also categorize the user based on sex, demographic, educational level, and etc to demonstrate the exploratory nature of the testing effort.


Operational leader respects professionalism.

Operational leader put her heart on everything she is doing. As a professional test engineer, she will do her best to accomplish any task. Brainstorming on test cases. Writing bug report. Writing single line of automation code. Discussion during test plan/strategy meeting. Discussion with Dev team and PM team. Solid execution and delivery. No BS. That's an operational leader.  She is also looking to improve the process or methodology continuously. Just set herself to be the best in the industry, just a pure professionalism.

Often times, operational leader loves the work. Sometimes she dreams about work. This might sounds crazy but actually that happens. It's not like getting stress from work. Imagine, you are fall in love with video game and playing all day. And you're stuck at level 12 and you need to go home. Would you think about it? Dream about it? Do you want to be the best tester? then you should love the testing work. In any occupation, one that loves work always out perform one that works hard.  Furthermore, testing is a special occupation. If you don't value your work or don't find interest, your life is hell in the company.

So far, we talked about strategic leadership and operational leadership. I'm a little tired. Will do the people leadership on the next blog.

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.