On May 11, 2017 I was fortunate enough to have been invited to share a keynote at the TechWell StarEast Testing Conference in Orlando, FL. There were about 1000 folks in attendance and the talk was entitled: Step Aside - Stop Leading from the Front! I can't tell you how big a privilege it was to share my thoughts on this important topic. Many thanks to Lee Copeland for inviting me.
Here's a link to a video of the keynote.
And here is a synopsis of the talk with a nice sketcthnote: https://developer.s24.com/blog/stareast-virtual.html
I thought I'd also share an interview I gave about the keynote a few months before. Here is that interview...
First, could you tell us a bit about your experience in the industry?
Well, something I’m quite proud of is my affiliation with TechWell. I’ve been speaking at your events since 2000. I started talking about software management and development. Then sharing on testing topics at the Star series. I consider myself a “partner” with TechWell and really have enjoyed the ride.
My experience is relatively broad across testing, development, project management, and leadership. I’ve served in senior leadership positions for over 25 years in development and testing roles. You could say that I’m seasoned and some say that I’m fairly salty ;-)
I think the breadth of my experience, both in the trenches and in leadership, distinguishes me from many consultants. There literally are very few situations and challenges that I haven’t seen and overcome over the years.
As agile unfolded, I’ve was an early adopter and champion of those approaches. Both as an inside leader and as an outside consultant. The people matter focus of the agile approaches is what resonates with me most, as it aligns with my own leadership style.
Your keynote is about leading in a way that promotes the growth of your team and not just yourself. Do you find software testing has been a pretty singular, almost selfish career up to this point? Have testers been taught to be more focused on the tester, rather than the test team?
I think all roles in software teams have been focusing on the role (organization structure, silo) rather than the team, the business, and the results. It’s a side effect of our waterfall approaches, which placed an emphasis on role-by-role or activity-by-activity work planning with hand-offs as the model for delivery.
While you can approach things this way, it didn’t foster teamwork across the silos. Instead it reinforced us vs them behavior all along the delivery pipeline. From that perspective, thank goodness that agile emerged as a different approach.
Nowhere can this be seen more clearly than the divide between “developers – them” versus “testers – us”. And this divide is still alive and well today, even after 20 years of experience with the agile methods. It’s certainly a testament to the resilience of waterfall structure and thinking in our organizations.
So yes, testers have been focus on the tester, then the test team, before thinking of a broader notion of team. Sure, we’re slowly evolving away from that, but far too slowly for my taste. And this keynote is intended to try and nudge us all along this evolutionary path.
Can it be difficult for testers to strengthen both themselves and their teams, since you often can’t take that team with you if you get a better offer at another company or want to create a startup? By focusing on yourself, you’re investing in your own future. By focusing on your team, aren’t you just investing in your current job?
I don’t think so.
There’s an old adage or quote that says: to be a good leader, you have to be a good follower first. And I believe it’s true.
The ability to work well in teams, collaboratively and successfully, has become the new normal for most technical workers. No longer is it the case that you stand out simply on your own skills and merits.
Sure, you count as an individual tester or test leader and you should develop yourself. But, the real differentiator is how you work in groups, in teams, and how you contribute and influence those teams towards excellent delivery. Delivery of results. Not YOUR results, but THEIR results.
Even in a startup mode, it’s not simply about the brilliant founder. Sure, they get the ball rolling. But sooner than later, they have to scale their organizations and they need to start forming highly-performing teams.
Another aside here is that, if you’re a solid team member, often you establish a network of colleagues who respect you. Often, you’ll run into these folks again in new companies, or as referrers for other position.
The reality is: software development and software testing is now a team sport whether you like/accept it or not.
What are some techniques you’ve learned throughout your career to help trust your team? As a leader, can it be difficult to put trust in other people and not just want to do it yourself?
I don’t know if there’s a specific technique or not. I think there’s a fundamental shift that needs to occur in every good leader from: you’re doing things yourself or directing, towards delegating, mentoring, and coaching others to do those things.
Trust needs to be a part of this shift. I honestly think that trust is a choice for each of us. Sure, it’s hard to trust others. We have to show vulnerability. We have to be willing to allow for different approaches. We have to be open to failure. In a word, we have to “let go”.
Using an agile team example, I’ve seen that there are two phrases that are incredibly hard for developers, testers, teams, and leaders to say. They are:
- I don’t know.
- I need help.
Trust is wrapped around the cultural safety that exists for someone to admit to those two statements, and by so doing, activating others to help.
What are the qualities of a good storyteller in the world of testing?
The initial goal is to simply share your experience. Don’t try to copy someone else’s story telling. Find your own style and leverage your own experiences.
I think one of the challenges is “mining” your day-to-day experiences for stories. Often, we’re just going through the motions and not really observing and learning from what is unfolding around us.
Good story tellers are observers who like to share.
The second quality is practice. Essentially, you can improve on anything, so if you want to become a good – great storyteller, then you need to tell your stories. Often!
Next I think is the ability to visualize. You want to paint pictures with your narrative so that your audience can get connected to your story and visualize what you are saying. One great way to do this is to connect the stories to your audiences lives.
For example, if you’re trying to communicate a Severity 1 bug to your Sr. VP of Sales, you might want to describe the bug with a story. Share how the customer can experience the bug. Under what business circumstances. And then describe the impact to them. If the bug is in end of month reporting, and it’s the end of the year, then your CFO customer is exposed organizationally. It’s not just a bug, it’s relates to their credibility within their company. Share that as a way of amplifying priority and lighting a fire under the team to fix it.
How difficult can it be for a leader to adapt to new technologies in the testing world? I’m sure there were some hard transitions when mobile was first coming into prominence.
I don’t think it’s that difficult. Well, it might be. Let me start this way.
I think there are two parts to change, technical learning and then simply being willing to put in the time. One is related to new technologies and may require extra effort by dinosaurs like myself to fully understand and grok the implication to me, my teams, and my organization.
But I sometimes view that as the easy part.
The harder part, at least to me, is viewing yourself as a continuous learner. Making it a part of your DNA to constantly, relentlessly, and curiously learn your craft. I think if you have that mindset, then adapting to change, while hard, is a natural process in your own personal journey.
Can you explain how stepping aside in your own leadership journey is necessary to empower your teams?
Well, first of all, you don’t have to step aside. If you want traditional teams who follow your lead, then don’t change. You’ll get the same results you always have. And you might notice that the capacity of your teams to deliver is directly proportional to the amount of time and energy you have to lead them.
But if you want teams that exhibit: more initiative, empowerment, accountability, engagement, self-direction, and fun; then stepping aside usually allows for this. These are among the attributes of high-performing, self-directed agile teams. And being these attributes, these teams typically deliver more results, far more, than their directed counterparts.
And stepping aside does not mean that you’re not leading. To the contrary, I’ve always felt that this style of leadership requires more of you. It’s situational and subtle. Often you have to decide when to step in and when not to. If you step in too often, then you’re not going to get the self-directed attributes that are so powerful. But if you don’t step in at all, then the results are impacted as well.
It’s this balanced leadership approach that we’ll explore in the keynote.
More than anything, what central message do you want to leave with your keynote audience?
First that leadership isn’t just for folks with “leadership” in their title. I contend that in team environments, we’re ALL leaders. From the most senior of executives, to the individual testers on teams. There are opportunities presented to us every day to provide leadership. So, we all have to make positional choices.
When do we lead from the front, side, and back? How often and in what situations? And the ultimate measure, are our colleagues & team members growing as a result.
You hear the term Servant Leadership used quite often to describe the style of leadership best suited to develop agile teams. Here’s a quick quote that describes it:
“The servant-leader is servant first… It begins with the natural feeling that one wants to serve, to serve first.” -Robert K. Greenleaf
The funny thing is that Bob Greenleaf was a CEO in the 1960’s. We all think of this leadership style as being new. But it’s not. It’s simply hard to do…