One of the ways I lead the team of testers in my project is through delegation of power from my own role…
1) A test manager in my group asks guidance. The members in the project team does not reply the requests or give them the information they need. As a test manager in the project they don’t have the theoretic power, but not the practical power… I send them back with all my powers – to tell them that because I said so, they should be respectfull. I don’t mind taking “stars” of my shoulders and giving the power of my role and position to someone junior to me.
2) A tester on my project team approaches me to ask for permission to create tasks on our task board. I immediately grant them a “do every thing you need to do, without asking“-permission. By all means take the initiative and ownership. I probably fail to manage everything, so we need to work together on this. By all means go ask the developer, create test cases, find things we didn’t know – think.. and test.
Sometimes I think, this is perhaps a Danish “equality” culture – but then I realize it is a collaborate approach for the modern knowledge worker. It works equally well with people from both India, Denmark, Philippines and China.
My style is not to CONTROL – but to facilitate KNOWLEDGE. In my team the team is the star…
Complexity is a Matter of Perspective 
I see this a little differently, I think. I’m a big fan of the Manager Tools podcast (http://www.manager-tools.com). One of their recurring topics is that there’s 3 kinds of power we each have: Role power, expertise power, and relationship power. That is, the power our company grants us as a function of our position (role power, or “Andy is the practice lead, so we have to do what he says”), the influence we have due to being recognized as an expert (expertise power, or “Andy is our resident expert on testing, he knows what he’s talking about, so we should do what he says”) and influence based on our relationships with others (relationship power, or “Andy’s a good guy. I like him, and thus will do what he says”).
I think there’s things we can do with team leadership to help all 3 types of power. Your example #1 is a good example of pure delegation of role power.
For the other 2 types, though, and for example 2, it’s less clear. I think example 2 is less delegating your role power and more granting the team member their own role power. It’s also getting into expertise power and probably some relationship power too. There’s an element of recognizing the person has expertise – “do what you need to do to accomplish your job” and an element of the relationship between you and the team member – “I trust you to not make more problems than you solve”.
In general, I see getting team members to an increased state of expertise power to be a mix of training (giving them more expertise) and providing opportunities for them to more broadly demonstrate their expertise to the broader organization (raising the visibility).
Increasing relationship power is also a mix – for some people, there may be elements of coaching on interpersonal skills. There also is an element of encouraging people to create those relationships and perhaps, facilitating opportunities for the team to do so. I think this is where a lot of the benefits of the concept of one team (instead of a dev team, a test team, etc.) or embedded testers come in (though there are often elements of expertise power there too, I think).
This is getting a little long and rambling – I’m not sure where I’m going with it. I think the concept you describe is spot on – it just made me think there’s even more to the topic. Thanks for getting me thinking!
LikeLiked by 1 person
Great reply Andy – got me thinking as well 🙂
LikeLike
[…] The team worked political with back channels, we worked open and power-lifting […]
LikeLike