Michael Hunter 

Hello!

Welcome to the Uncommon Leadership interview series.

I’m Michael Hunter with Uncommon Teams.

Today I’m talking with Linda M Cook about her journey to seeing people as people and learning to leverage the unique gifts that each person brings.

Linda is a recovering waterfallaholic and practicing Agile F undamentalist with significant experience in coaching and training agile ways of working to all levels of an organization.

She enjoys watching people experience learning and applying new and different ways of working.

Her purpose in doing this work is to reduce unnecessary suffering in the workplace.

Welcome, Linda!

Linda M Cook 0:52

Thank you, Michael. I appreciate you inviting me to join you for this conversation today.

Michael 0:59

You’re very welcome. I’m excited to have you here.

As you reflect back over your journey, when did you first recognize that seeing people as people and leveraging the unique gifts they each bring might be a valuable approach?

Linda 1:17

It’s a very good question.

To apply that to the workplace, my first step into management from being a developer, I picked up a team.

We were known as the General Services team.

We serve all-up technology, which was a large group, about 1200 people.

The team wasn’t that large, of course, but I inherited quite an interesting group of talent very diverse in the skill sets that they had, and also people very strong in their conviction for the type of work they wanted to do and didn’t want to do, that sort of thing.

The team had a bit of a struggle, I guess, with their reputation overall. Which I found pretty early on was unfounded. Some folks thought they were difficult to work with and didn’t have all of the “right skills”, whatever that was supposed to be.

It took me a while to figure out that in this team that I was now a part of, I had some people who really only could work in some areas and yet, if you put them in the area they were strong in for.

For example, there was one gentleman who was doing PC-based work. Desktop applications. This was a long time ago. And if he got a mainframe project he struggled big time.

I had another person who was emphatic about how much testing needed to be done before he could consider himself done.

What I found over time was that they were both right in the way they worked.

I was able to convince my leadership that they were actually both quite good at their job. The only problem they had was that people were expecting them to be a peach when they were actually pears.

That really gave me an appreciation for the fact that, appreciate people for the skills they bring.

Yes, as a leader, it’s your job to help them grow those skills.

But you’ve got to start with an appreciation for who the individual is and what their desires are.

I have carried that with me ever since.

I think of both individuals, see them clear as day as we’re talking, because of the amount of engagement that we had over various conversations of what was right and what wasn’t right for them to do.

Michael 4:00

When you were convincing the management, leadership, letting them focus on what worked well, and not to do the things that didn’t work well for them, how did you persuade your bosses and their management that this was the right approach?

Linda 4:24

That’s a very good question.

One of the things I did was to actually show the value the individual who was spending, what management would say they were too slow at getting their job done, I was able to point out this individual’s record, and just how well his work performed once it got to production.

That simply was nearly flawless.

Very seldom was there any sort of a problem once his code was released.

Yes, it was a little slow. It wasn’t horribly slow, but slower than others.

But when you look at his effectiveness, and get them to see, using real data, to say “This guy is on purpose, and has good results. And the only thing you need is to have a little bit of patience with that individual.”

In the case where I had people with such diverse skills, my challenge was really getting management to agree to a set of priorities that let us utilize the team best instead of just randomly staging the work that would come in.

That was really the bigger leadership challenge I had: getting them to understand that if we would align work in a certain way, the team overall would be more productive, our internal customers would be happier with the outcomes, and it would simply be a better situation for everyone involved.

Michael 6:01

How did you overcome that challenge?

Linda 6:06

I’m pretty persistent.

I’m known to be honest and truthful.

I’m more than happy to admit failings and shortcomings.

Overall, I just always accepted responsibility for the outcome of the team.

This was back at a time when it wasn’t unusual for senior leaders to go down and they’d literally stand over the shoulder of someone as they’re coding.

I made it quite clear that the team was my responsibility.

If they had a problem, they had to just come stand over my shoulders.

You want to question something? If there’s an event, it was mine, because I was responsible for the outcome of the team.

That bought me, I think, a lot of leeway, if you will, managing the team, and leading them in a way that I thought would be better for everyone.

Michael 7:01

How big was your entire team?

Linda 7:05

At that time, the team varied between 10 and 12 people.

Michael 7:11

And were you the only group supporting the larger 1200-person group?

Linda 7:18

Yes, we were. With lots and lots of customers. And they were in the same building so you couldn’t run away from them.

Michael 7:35

How did you manage supporting so many people with so few people?

Linda 7:41

It really just got down to having conversations with folks.

Laying out the choices before them and saying, “Here’s how much we can handle. You tell me: what’s the real priority of the work? What’s more valuable?”

Understanding when things truly had critical timelines.

Because most of the work was internal, we didn’t have externally-focused commitments made. That made it, in some ways, a little bit easier.

Of course, it was always a situation where the demand clearly would exceed any capacity we might have.

That’s just a typical problem.

It is probably a good problem in IT. It’s one that we had throughout the time that I work with that team.

Michael 8:34

With that amount of demand, I imagine there were times where there’s work you needed to do that wasn’t ideally suited to the people you had to do that work. How did you work with your people to accomplish the work you needed to do knowing that it wasn’t how they would work best?

Linda 9:00

I started out with gaining their trust. For them to understand that I really did have their back and to give them as much choice as I had possible.

There was certainly a span of influence that I had in the organization and with the upper management, and with that there was only so much that I could really control.

For the most part, I gave most of that control over to the team, saying, “Here’s the challenge we have as a team. We need to get this thing done. It’s going to take that type of a skill set. Who’s willing to take this on?”

Michael 9:44

Did you find that they were always then excited to take things on? Or were there times where you needed to coach them through seeing how this work that maybe wasn’t so interesting to them could actually be really interesting, if they viewed it in a certain way?

Linda 10:05

No, they weren’t always excited to do the work.

We asked them to do something they didn’t like to do, they still didn’t like to do it.

That was just through them understanding the importance of the work and the value that it brings.

Getting them, sometimes it would be a tradeoff. If you’re working on this thing, then you can pick the next of this batch of things that we have to choose from.

I always tried to reward my teams in small ways.

There were never really big things that we could do.

But just having an occasional Thank You lunch at work.

It was a very large insurance company. We had a huge cafeteria that it was possible to have special lunches prepared. And I could do that on occasion. Just to show that I appreciated the work.

I also made sure that senior management knew who did the work and when it was time for them to step up and pop in someplace and give an attagirl, attaboy to somebody.

I’d literally write them a script, saying “John Schmo did this really awesome thing. We should thank him for it.”

They were appreciative of that and generally willing to do it. The teams were getting good feedback from leaders.

I think that really helped quite a bit.

Michael 11:45

It sounds like you really stood up for the team and really empowered them.

Linda 11:55

Yes.

As a developer, I learned I was hardly ever the smartest person in the room.

I’ve had good experiences working with others to get some really complex things done.

I know there are things that I’m really good at. When I get to do things, I’m really good at, I tend to do them well, and pretty quickly.

As opposed to, if you give me something I’m not nearly as good at, I’ll probably get it done. But chances are it’ll take me longer than it may have taken someone else who was really just strong in that skill set.

So, I applied that to the team.

They titled us as managers, and I’ve always felt that these roles that they call managers and organizations, it was a different role I had. Okay, it has this title. You call it manager.

It just means I’m the one that’s going to put up with nonsense, if you will, around the organization.

I’m going to make sure plans are done, and status reports are done, and people are rewarded for the good work that they do, and that sort of stuff.

But I’ve always felt that that was simply a different role on the team.

Not a different level of the team.

If that makes sense?

Michael 13:16

It does make sense.

As you’re talking, it makes sense to me why you are such a well-regarded leader in the Agile world these days: you were doing all the things that Agile talks about now, way back then.

Empowering the team.

Protecting them.

Doing what they needed to be unblocked and then leaving the rest up to them.

Linda 13:46

I’ve been fortunate enough to have just enough technical skill that if someone’s stuck on a problem and wants someone to just sit down and talk through with it, I’m usually pretty good at that kind of listening.

Every now and then I might just have something valuable to offer.

I may not know the exact structure, the language that they’re using or whatever.

But I’m usually pretty good at helping out with a discussion around problem solving.

Michael 14:20

This team, you were really successful in applying this approach. Have there been other times where applying this approach wasn’t so successful?

Linda 14:41

I think the most challenging time I had with that, I was in as a coach in an organization. It was relatively small.

The CTO at the time was rolling with a pretty firm hand.

There was a lot of fear in the group that their leader was looking for who could he lay off next.

It was kind of understood that it was his way or the highway.

I had to walk a very thin line, coaching the teams and providing him with the kind of information he needed to run his organization.

And also, not for people to say, “This was Georgiana, got to look out for that one.” That sort of thing.

Strong fear-based organization.

It took longer for them to understand that I really did have their back.

I think that there was also some fear that I was going to come, after this leader cleared house, if you will, that I’d be coming in with a whole new group of developers and DBAs and all that good stuff.

“I’m an independent, this is just me. I’m not here for any of your jobs.”

I made that quite clear.

There seemed to be a moment where people started to relax and just say, “No, we don’t have anything to fear from that perspective” from me.

It was a lot easier to get them to see how some of the things I was suggesting they try really might help them.

This was a team that had some really strong struggles when I went in.

They hadn’t delivered anything in over three months.

I mean, zero.

There were a lot of eyes on them.

That’s why I think the technology leader was also under a lot of pressure.

Teams weren’t delivering. Weren’t performing.

At the end of the day, most of it were just communication challenges between the business and the technology folks.

That’s one of the things I think I’ve been fairly successful with, is actually keeping a foot in both camps.

I seem to be able to translate business into tech and tech back into business.

That helped me along in my career for sure.

Michael 17:21

Are there specific signals you’ve identified that tell you this situation is primarily a communication mismatch between the two groups? Versus, this is a technology issue, that we’re not applying the right technology, or we don’t know how to apply the technology we’re trying to use? Versus the other sort of categories of problems that you typically see.

Linda 17:55

The “Is it a communication issue and a people problem” versus “Is it a technology issue”: by and large, the problems are with communication and with people issues.

Whether it’s people in the wrong job, people not understanding the domain that they’re working in, or even how to actually get work done.

If you’re in a regulated environment, there could be a lot of rules and things that you have to follow as you’re developing software, and some folks just take some while to catch on to that.

The technology problems are almost more obvious. In some ways, they can be easier to fix. Because we pretty much have all the technology we need in the business system solution space. Whether or not you’re using that technology or using it to its optimal is another question.

Typically, those, if you want to call them technology problems, often have as the root communication.

Communication being the business simply expects more than their team is capable of delivering. We’ve got just such a high excess of demand.

Typically, those organizations don’t have the best methods on how to make good decisions around whose work gets done first.

Michael 19:30

When you recognize that you’re faced with a people problem, how do you typically get started on identifying what’s specifically is at the root of that?

Linda 19:43

It really starts with getting to know the people.

Early on in an engagement, I’ll spend most of my time in observation. In building relationships. Trying to understand where each individual’s coming from in their work and what they’re asking for.

And sometimes to get to know, are there other stresses going on?

There are generally reasons for people’s behavior.

Especially if that behavior’s not particularly healthy.

There’s a lot of talk these days about toxic work environments. And there’s just no shortage of that.

Having been in many different organizations, you begin to see the patterns. The problems that are coming up.

With that, you can look for what are the patterns you could apply to help solve those.

Michael 20:46

Are there particular patterns for helping us solve this, that you find are useful more often than not?

Linda 20:57

Not necessarily patterns as much as techniques.

Some of that is to turn down the volume of all the noise that’s going on around things.

Very oftentimes, I might first play intermediary in the communication.

That comes to a point where it feels like the individuals that are involved here are best left to solve these things on their own.

Once they realize I’m pretty much playing the middleman and they could just eliminate me if they could simply communicate well with one another, that’ll usually happen.

It’s very rare that I have to be anything more than just honest.

Talk to people about asking them how they could do things better. What is it they don’t like about what they’re doing today? That sort of thing.

Michael 22:01

It sounds like you are really skilled at observing a situation, identifying two or three points that, if they’re amplified, help the root causes become really evident and more able to be attacked. And then stand back and let your amplification of those issues speak for itself until everyone else in the situation recognizes that, “Oh, these are the key things.” Then, at that point, you take a step back and they do a great job of solving things themselves.

Linda 22:53

That’s a pretty fair characterization, Michael, with a small adjustment.

That adjustment is: sitting in the background.

I’m planting seeds of thought in various minds to get people to consider before they walk into a situation, so that they’ve had a chance to consider the problem that they’re trying to address.

Consider what options might be.

And also look for ways to build community around the options.

That’s another thing that is very important: It’s rarely just two people involved. It’s usually two or more groups involved.

I work more one-on-one with individuals. Once I understand whatever their really strong point is, maybe I can, in a way that they don’t see challenging, get them to see what others might think and ask them what other possibilities are happening in the situation.

Michael 23:54

Thank you for the adjustment that community turns out to be involved. When we get into the meat of the problem does that usually turn out to be much larger or broader than the people initially thought that community was?

Linda 24:18

Very often, what we find is that there are at least two different aspects of the problem.

There’s one set are problems that simply cannot be solved within the team. They’ve got to be escalated.

But with that, there’s generally always a part that’s within the group’s control to either take direct action on or to make a very specific recommendation on how they want to experiment to do it better.

I am a huge proponent, on not trying to jump too much into the conclusion of “Oh, we know what the fix is.”

As much as finding out we think we know what the fix is, let’s create some experiment and have test criteria. So we’ll know when we’re done with the experiment. Did it work or not? You take it from that viewpoint.

Michael 25:16

Those tiny, tiny experiments are key to my approach as well.

Linda 25:28

I especially like those when there’s a technology challenge that’s come up and someone to argue for technology “A and someone else is going to argue for technology “B.”

Great. Sounds like two good experiments.

Who wants to run an experiment? How long is it going to take? How soon can we know? To have good information so you guys make an informed choice.

Because chances are both things could work.

Michael 25:57

Right.

Then it’s a question of which trade-offs are we willing to make and which ones are we not?

That’s what ultimately will drive the decision.

I imagine you find the same thing that I often find: that the scope of what’s within the team’s control is much larger than the team realizes or believes initially.

Linda 26:26

Yes.

We’re back to communication problems again.

A request is taken too literally, oftentimes, around a piece of work that’s been asked to be done.

Especially if that request is not done face to face. Where we’re sharing paper, back and forth.

A request comes in, someone interprets that request to be a really big thing.

Without an opportunity to discuss that, find out that, guess what, there were three or four different trade-offs we could have made that would either save time or money or just help amplify the outcome differently.

That’s the bigger thing that most teams don’t realize: to not take everything at face value.

Question it all.

Get to the point where you’re building a trusting relationship with the people you’re working with.

So that when you ask for space and grace on a particular item, it’s granted because the trust is there. They know you’re not just off playing games or something like that.

This is really an important part of the work.

Michael 27:47

That trust between the members of the team and out from the team, to the other people they’re dependent on, interacting with, accountable to, is super key.

Linda 28:06

That there again, that’s an important part of the leader’s role: to make sure that there is plenty of communication about the goodness that’s happening within the team.

Even among things that you might deem a failure.

The learnings that have happened can be rich and really make a better result when all is said and done.

I just can’t let things be perceived as “Oh well, this didn’t work.” Okay, that didn’t work. But the next thing might. Let’s try something else.

Keeping people from getting too vested in a particular solution can be a challenge.

But again, that’s all part of building trust.

Michael 28:55

Even the most dire outcome, there are always things to celebrate.

Linda 29:03

Absolutely.

I have built a reputation: I can find the smallest thing, the tiniest seed, and have a celebration.

Every now and then, you just have to celebrate, “We all got out of this alive to do another project.”

Let’s go out and celebrate that if that’s what we have to celebrate.

Michael 29:29

Absolutely. There’s always something.

What else should I ask you, Linda?

Linda 29:40

Perhaps you might ask me, what could we be doing? We being the Agile community. To better provide the experience that our customers want, whether our customers are internal, fellow teammates, or people out in the marketplace?

Michael 30:05

What could we be doing to better provide the outcome our customers are looking for?

Linda 30:12

If we were focusing just a bit more on the values that Agile represents and less on the tools and frameworks and all these things that are trying to solve problems for us.

If we work off a set of values that we can all share and say “Here’s really the things that we prioritize that would make our work better.”

Michael 30:44

Focus on the principles that are guiding us, not on the particular implementation we’re using this time.

Linda 30:52

Yes.

Even just back to, Number One: individuals and interactions over processes and tools.

If you always value the person you’re engaging with more than the process that you might be debating or struggling to utilize, that will generally lead you to a much better result than if you sit and struggle with the process and tool side.

Michael 31:24

For sure.

You may have just answered this question: what would you like to leave our listeners with today?

Linda 31:34

One of the things I’d like to leave the listeners with is that no matter where you are in your organization today, whether or not you’re Agile, it’s really not a consequence.

What’s most important is that we’re generally working towards a better place, a better position with the people that we work with, a better product that we’re delivering to our customers.

Taking tiny steps can often be the best way to get there.

To be willing to learn from their mistakes.

I’d like to be able to take the word failure out of our vocabulary, and always replace it with learning.

We can remove some of the fear element in what we do, and just look at what tiny, small improvement we could make.

I’m wanting to tell teams that are working in these two-week sprints: you’ve got 26 opportunities every year to do something differently. If you only took advantage of half of those opportunities, just think how much better the work will be a year from now.

Michael 32:54

Absolutely.

One of the reasons I talk about things in terms of experiments is because an experiment can’t fail.

We always get information out of it.

It may not be the information we hoped for or expected.

We always get information.

So, it succeeded.

Linda 33:14

Yes.

I found it easier to find, use that right word.

In some companies, experiments is not the right word.

You have to use pilot. We can do a trial. We can do a test.

Find the language that will give you that space to try something differently and test the outcome.

Michael 33:39

You’ve generously offered to give our listeners a free coaching session on the lessons they can get from your modified Agile Penny Game. Tell us about that, please.

Linda 33:57

The Penny Game’s been around probably since the early 2000s.

And mostly, what people are learning in playing the Penny Game is the value of small batches.

I’ve adapted that game quite a bit to where I call it the Coin Game now. No longer the Penny Game. Because it’s not just pennies.

I use those coins to help people apply many different lessons.

Yes, flow is important.

But it also gives me an opportunity to bring in a much bigger conversation around value.

When all coins aren’t created equal, there are lots of other kinds of decisions that can be made.

Recently, working through the Agile Alliance and a session they call Game On they hold monthly, we just held a virtual coin game. And within the next couple of weeks, all that information will be published.

I’ve offered people a free half-hour coaching session to ask me questions about how I facilitate it. How do you adapt as the game changes? The different things I use in coins. Things like that.

Michael 35:13

That sounds amazing.

For your listeners, when they’d like to take you up on that offer, where can they find you? What’s the best way to connect with you?

Linda 35:23

They should be able to find some of the instructions around the coin game itself on my website. Which is: www dot project cooks with an s.com and I can be reached at linda@projectcooks.com.

Michael 35:43

Thank you for a great conversation today, Linda!

Linda 35:47

Oh, thank you for the invite Michael. It was my pleasure.

Michael 35:51

And for all of our viewers and listeners and readers, thank you for being here and have an edifying day.

Thanks for joining us on Uncommon Leadership today.

If you found these stories interesting, inspiring, and illuminating, sign up for my newsletter.

Use the form at the top of this page.

You’ll be the first to know about every new episode of Uncommon Leadership.

You’ll also discover how you can build uncommon teams.

Thanks so much!