Testing skills I use in management – pair-blog # 1
A while back I asked on Twitter for people who would be up for pair-blogging. The idea was that we agree on a topic and a date and then we each write a post about that topic. We publish on the same date and promote each other’s posts.
My reason behind this was both to get to see different views on things, learn some writing skills to improve my own writing and perhaps above all: To train myself in writing on demand instead of “just” when I felt like it.
You see, while writing my series of card blog posts, I noticed that it was quite possible to produce good quality content on a schedule, as long as I had the topic to write about. Previously, my writing had been very sporadic and only happened when something triggered me to write. I also noticed that I found it easier and easier to produce posts when I got into the motion so to speak.
Enough about that, this is the first one!
James Thomas was brave enough to take me up on the offer and he gave me the topic: “Testing skills I use in management”.
You can read James’ take on this on his blog, which is amazing so you should follow it!
Testing skills I use in management
To start: Let’s look at testing skills. What does that even mean? I often talk about how almost any skill or experience you have from outside of software testing can be translated into testing. But that seems like too broad of a definition for this topic so let’s try to find a smaller scope.
If I really have to pick a few skills that I think made me successful as a tester I would pick:
- A good understanding of technical matters (code, hardware, network, databases etc)
- A good understanding of people (group dynamics, user-computer interaction, basic psychology, history etc)
- Asking questions
- Problem solving
- Social skills
Hm. Looking at those: don’t they look like something that would be useful for basically any job in tech? They still seem like too broad of a scope but I will have to go with those.
Do they translate into management? Well, definitely.
Asking questions was my main weapon as a tester. Note that I do not write questioning, I write asking questions. Questioning can, for a lot of people, sound too much like critique.
Asking questions are friendlier, sprung more out of curiosity than animosity. Something that I think is really important, both in testing and in management. Because in the end it all comes down to people and relationships.
It builds trust, it builds common models and understanding, it builds relationships. It is like a magic superpower!
Questioning on the other hand is a dual-edged weapon. It could work, if the other person trusts you enough and is open enough to not take it as an attack to protect against.
How challenging the questions can be depends on the level of relationship you have with the other person. Knowing how to find that balance – that is another superpower.
Asking questions is my main weapon as a manager as well. One that I believe makes me a way better manager than I would have been without all of the experience I have gotten from asking at least a million questions since I started as a tester.
What I have found is that I seem to be able to create more trust, better relationships faster than people who have a less question asking-focused management style.
In testing and programming, problem solving is a crucial skill. I often break things down into small lego bricks and I have a good sense of how those connect with other lego bricks and how moving one will affect others. This allowed me to do “on the fly” risk assessment and othen pretty quickly see how/what to test depending on different features and/or changes. Applying that with ability to connect what I hear other people and/or teams talk about with how their lego bricks could be used by us, or how they could benefit from our lego bricks (or the opposite) gave me a reputation for being able to bring people and solutions together and find weird connections that no one else had considered.
In management, it is basically the same. The difference being that the problems are less often directly related to soft-/hardware and more often about building teams, individuals and/or organizations.
Second most important “skill” I think I had as a tester was a theoretical knowledge about human behaviour. I had a pretty broad education with courses in human computer interaction, interface design and group dynamics and this was extremely valuable when I moved from programming into testing. Well, it was useful in coding as well but even more in testing.
It allowed me to understand how to approach people to get the result I wanted. It allowed me to find bugs I had not found otherwise. It allowed me to put some solid arguments into why certain things were problems and not just my personal point of view.
I am sure it is no surprise to anyone that understanding people is even more valuable as a manager. Understanding people is invaluable in any leadership role. Knowing how people react to change, basic communication theory, how group dynamics work and other things is, to me, things a manager needs to know in order to do a good job. At least when it comes to modern leadership and not traditional, micro-managing, ordering people around-management.
Well. I am sure this would be less useful if I was in a non-tech management role. In the roles I have had, all relating to testing and/or engineering, it has been a big strength. Again, that my reports can talk with me about their daily challenges, in a language they are comfortable with, has been something many of them have mentioned as important to them. Again: it seems to build trust and trust is my main currency as manager. Trust between me and my reports, trust in my skills from my management and other people who I, or my reports, interact with.
In testing, my technical understanding allowed me to do testing on a very different level to the testers I’ve worked with without that background. (They often had other areas they excelled in of course!). It also allowed me to talk to developers, product owners and business representatives with an authority I would not have had without that background. Used correctly, it gave me the power to actually influence how we built things and, again: made people trust me.
Combine them all with social skills and you get a very solid ground for any role where your main responsibility is to influence the choices of others. And both testing and management are very much reliant on your power of influence.
To wrap up and really drive down that I think both testing and managing are team sports where you are part of the team, I’d like to end with a quote from Kobe Bryant:
The important thing is that your teammates have to know you’re pulling for them and you really want them to be successful.
I was interested to hear Lena’s view on this question and I like it, but perhaps I shouldn’t be surprised that our analyses are similar?
I’ve only known Lena for a short time but in our conversations, the talks of hers that I’ve seen, and the recent series of blog posts around her Would Heu-risk it? cards I’ve quickly come to see that she thinks carefully about her work and the way she goes about it. I like to think that I do too.
The fact that we’re both on the board of the Association for Software Testing shows that we have overlapping sets of values, a deep passion for testing, and are concerned about the people and ethics in software production.
There’s overlap in our backgrounds too: each of us have moved through a variety of roles including development and testing at individual contributor and management levels.
So I shouldn’t be surprised that we’ve approached the problem in similar ways and drawn similar conclusions? Maybe, but as a tester and as a manager I’ve learned not to beat myself up with apparent 20-20 hindsight and instead remember that until I asked the question, and got the data, I actually didn’t know.
Again: Don’t miss James’ take on the topic, here