Esther Derby on Coaching Upwards and Still No Silver Bullet

1. Good day this is Shane Hastie with InfoQ and I’m here at Agile 2014 and we are sitting with Esther Derby. Esther you are from Esther Derby Associates and an expert in organizational dynamics. Welcome, thank for taking the time, it’s lovely to see you again.

It’s a pleasure to see you again, we served on the Agile Alliance Board together and I used to get to see you on a regular bases and I miss that, so it’s nice to be chatting with you today.

Shane: It’s great to see you. You’ve done a couple of talks here and are deeply engaged in the conference, but a couple really jumped out of me when we chatting, the talk about Coaching Beyond the Team.

Yes, well I’m doing, my colleague Don Grey and I are, doing a workshop tomorrow morning and it’s a snipped of a longer workshop we do. So, the premise of this workshop in the reason we designed it, was we both works both a lot of clients who have teams and coaches, and our observation is that many coaches are good at coaching individuals, they have some skills there, and they do pretty well coaching the team, getting the team to work more effectively together, but as we all know many of the problems that teams face are from beyond the team.

So this workshop that we are doing on Friday is a snipped of a longer workshop as I said, that really addresses how do you begin to effect the environment that is supporting the team and enhance that environment so the team can do much better. Because you really can’t just go up to a manager and say: “Here is your impediments list”, well you could but it doesn’t work very well and very often if you have been brought in to coach the team, you did not have the same permission to coach the manager, because that’s really done on a basis of a relationship and an agreement, so it takes some skill to build report and to create the opening for a relationship where you can effectively work with the managers around the team to enhance the environment. So we talk about different roles a coach can take based on the relationship they have and the work that needs to be done, and give them some explicit frameworks to talk about that, with the hope of moving into a relationship where they can work more effectively.

2. But isn’t Agile about getting rid of all of these managers?

Not necessarily, I mean I think many teams do quite well when they are self-managed, when they don’t have a manager giving them day to day direction, but in my experience, particularly in larger organizations, there is a role for managers to play working on the system, so not so much looking down and directing the team on a day to day basis, but being aware of the environment that the team is in and supporting the team by creating the environment which can include material resources, creating feedback loops; it can be looking at systemic effects that are much broader than that one team, and I think that’s a very critical role for managers to take, is to have that broad view of the system and work to enhance the system. So that we are not just optimizing on the team level, we are actually looking at what are the various things that are affecting the team, is it policies, is it other structures, those are things that a team can’t necessarily fix. So I think there is a role for people to do that, it doesn’t look like traditional management does.

3. How do you take somebody from that traditional manager to the new style manager?

Well you start by valuing what they’ve been doing all along, because they have, they are in a role where their job is to maintain stability and now we are telling them that that’s not so valued, you supposed to maintain stability and now you supposed to change, if you don’t change the way we want you to, you are the “clay layer”, I’ve heard people use that term. So I really want to reframe it as a more strategic where they are having a broader effect on the organization and it’s still a very valued role, so I think about it as a shift of focus from looking down to looking across and I’ve found that helps people in general, and it doesn’t different set of skills, but there are skills that people can learn.

4. And when you are working with coaches, how do you coach them or teach them to be able to coach people through this change?

Well that’s part of what we do in the workshop and we start with rapport, entering groups and rapport, we look at different roles for coaching and how that various depending on what your responsibility is for results versus growth, and we look at various ways to talk to managers in a way that helps them, helps engage them in systemic problems solving without blaming them. I had a really interesting chat over lunch yesterday with a guy who was in one of our classes and he was explaining to me how he had applied some of those ideas to really unravel a really thorny problem in one of his plan organizations and presented to the managers not as I’m telling you what to do or I’m telling you what you’ve been doing wrong, but rather here is a problem and lets sketch this out and let’s look at the parts of it and see where we can find to interact with this. So I find that engaging in problem solving with managers in a way that isn’t you know, I’m telling you but we are working together on this thing outside of us, is much more effective than coming in and saying: “Would you like some coaching from me?“ Which I’ve heard people do and generally doesn’t work because it’s one up, one down, there is always this thing about excepting help is a one down position managers, most people don’t like to be in that, particularly ones that haven’t given permission for it.

Shane: And one of the key things about coaching is permission.

We actually spend a lot of time on “permissioning” as a verb in this class and anytime you want to go more into a topic more deeply or ask more personal questions or shift the focus to something that’s a little more personal, you really have to get permission, because if you don’t, you will get a defensive response and it may not be really visible externally but it will impact the relationship, so it’s really important to do that.

Shane: Great. The other talk ”still no silver bullet”

It’s so sad, I know I hate to be the one that break the news.

Shane: I mean Agile didn’t solve all the problems.

Not so much as I’ve noticed, I think there are still some problems out there. Part of the premise of that talk is that, very often when we do benchmark or when we adopt some practice, we are looking at something that is the end state of something that has evolved within a specific context to solve a specific problem and they arrive at something that works really well for them in their place, but it may not work for you, because you may have a different problem, you definitely have a different context, and so we need to be continuously looking at how can we adapt our environment so this practice will work, if it indeed addresses the problem we have, how can we evolve the practice being clear on the fundamental principles behind the practice, so that it suit us better, which is harder than reading a recipe block, it’s much harder, but it works better. All of these processes were things that evolved through experimentation and learning, and I had an interesting chat with Ron Jeffries saying that when they came up with XP, they were hoping that people would continue exploring and learning and expanding, but somehow when we have a tendency, it is something that we have grown into over a long period of time, of looking for one right answer, and so we had looked to Agile for one right answer.

Shane: When we think of the Agile Manifesto, one of the preamble, right at the very beginning, we say we are uncovering.

Yes, it’s uncovering not we have uncovered, so yes, it is still an action and I find a lot of people focus on practices without looking deeply at the principles or without looking at what problem was this practice intended to solve. For example, this wasn’t one of my clients but it was someone I was talking to, that they were having a lot of trouble delivering anything and they were still working in component groups so progress was quite a herky-jerky affair. But they decided that everybody in their technical teams had to start doing TDD, Test Driven Development. That wasn’t the problem they had, so it wasn’t going to help them. I mean it is a very useful practice but it was absolutely not directed at the problem they had, so and I see that happen a lot, you look at what are other people doing, so we should keep up with them. Which sometimes if that’s the only motivation again people to start looking at doing things, keeping up with what other companies are doing, that can be useful, but it’s still really important to understand the thinking behind the practice, not just the practice.

5. How do you get people, how do you coach, train, help people to actually do that deep examination?

Well when I work with my clients, I start with doing an assessment; of going in and looking at how are things working, how are their structures, their organization, the way they organize people, the way their policies are set up, how are those supporting people to carry out the mission of the company and to serve their customers, because very often those are, there is a big gap and anytime there is a gap that fills is with cynicism and fear. So I look for those contradictions, I look at how those are affecting their functional dynamics, so their management practices, how decision are made, morale, there’s a whole range of things that I look at, and then we look at, what does this tell us about the problems and where do you really want to be, what needs to be in place for you to get there. So we start from what is, what problem there are, where do you want to be, what will help you to get there, and let’s look then at the principles underneath the practices to enable you to achieve what you want to achieve, to achieve the aspiration. So I start from understanding what’s going on and when I’m talking to people I ask them a lot of questions, what is the problem we are trying to solve here, what have you seen, because very often people’s initial statement of the problem comes from their current thinking and if they could state it accurately, they could solve it. So sometimes we have to rework that problem statement, bit I start by saying that, what is the problem we are trying to solve here and we work back from there, we ask lots of questions, we gather information, we develop some hypothesis and we do some experiments, see if we can get something to move us in the right direction.

Shane: Learning?

Yes, that is what it is, simply stated, we try to do some learning, we start with observation and we look for possible answers and hypothesis about what’s going on.

Shane: The Agile mantra inspect and adapt.

Yes, that is what I do, adopting Agile in an Agile way, keep the concept.

Shane: Esther thanks so much for taking the time to talk to us, and enjoy the rest of the conference!

It’s an absolute pleasure.