Clayton Lengel-Zigich, Roy van de Water and Scott Dunn discuss:

• StrengthsFinder 2.0
• Playing to your Strengths
• Introducing Strengths to your team
• Strengths and self-organizing teams
• When Strengths go wrong

Transcript

Clayton Lengel‑Zigich:  Welcome to another episode of the Agile Weekly Podcast. I’m Clayton Lengel‑Zigich…

Roy van de Water:  I’m Roy van de Water.

Scott Dunn:  I’m Scott Dunn.

Clayton:  Scott thanks for joining us today. I know that you are interested in the strength finder or the strengths…I don’t know what the generic term for it is, but maybe can you give, I guess, a little bit of a background of what that is and why you find that interesting?

Scott:  Sure. Back when I was a manager for a web development shared systems team, looking for ways to have my team members be engaged and focused. I was at an event called the leadership summit. There, I heard someone named Marcus Buckingham talk about the level of engagement of employees and how low it was. I was definitely listening.

He gave a stat that less than two out of ten of us are engaged, meaning that we care what is happening at work and are doing our best. The company that he worked for at the time was Gallop. They did a survey of a million employees and a hundred thousand men trying to find what makes great management.

They boiled it down to twelve questions called the “Q12”. The biggest lever if you were a manager to get the best out of your employees was do they have a good chance each day to do what they do best?

IE Do they have the chance to play to their strengths? From there they came up with an assessment that you can walk‑through and get your top five strength which is called the strength spine which has been on the best seller list for four or five years now.

Marcus has recently come out with an assessment of the zone, he has recently left Gallop. This is called “The Stand Out” which talks more about your strengths, roles and puts you in several categories of manager, leader and sales.

There is a couple of ways you can approach it. From there you are talking to your team and working with them in a way that helps to discover what their strengths are and to find a way to leverage that as a coach, scrum master or manager.

Clayton:  Let’s say I am a manager and I have this scrum team or agile team, how do I implement this? Do I make everybody take a questionnaire and then put people in boxes? How do these two roles meet?

Scott:  That is a great practical question! What I have done before is something that I have detailed on my blog. We can circle back to that later but I do try and make it so people can go to and follow the cheat sheet.

But basically what I do is I give everyone a couple weeks’ head up and notice in saying, “I’m going to be putting books on your desk. Don’t worry about reading it right now. Just take the assessment in the back. You’ll find the code. You’ll go to a website and register and use that code to start your assessment.”

That gives them details about how the test works and try to lower the level of anxiety. It’s not a pass/fail test. You can’t not have any strengths. You’re not going to have a strength like loser or something like that show up, and you’ll be…

Clayton:  Roy hasn’t taken the test yet.

Roy:  That’s right. I’m really strong in the ability of being fired.

[laughter]

Roy:  Sorry. Go ahead.

Scott:  Is beer drinking a strength? Well…

Roy:  I think I’ve got that one covered, too.

[laughter]

Scott:  Yeah, you’ll get lots of funny responses, but the amazing thing is the results I’ve had. I’ve done this with at least 200 people so far. On every team that I’ve been on when I was independent we’d always do this because one, it’s a big team‑building thing. It’s very affirming. These people come out like, “Wow.” They’ll routinely say, “That really nailed me.”

I promise you, over 99 percent of the time they’re saying, “That was so accurate. They’ve been reading my mail. I can’t believe this.” It’s a very affirming process. Not just for them, but that next step after they’ve taken it I schedule a meeting for all the team to come in.

We just walk through their strengths. I just list them up on a grid. I’m writing them up in front of everybody, and I’ll open up the book and read off, or I’ll read off their reports. Everyone’s getting to hear about each other’s strengths, what they’re naturally good at where they’ll find the best of each other. These teams aren’t great teams because everyone’s well‑rounded. They’re great teams precisely because each person’s not, and you find out. You get that insight.

I had one manager come up and say when she followed that. That was the most her team had talked to each other in four years. You get these amazing sharing and insights into each other as a team, and that’s part of the team‑building process as well. From there you start talking about coaching, and we can get into that a little bit later.

But even if you just did that, you’re talking 12 to 14 bucks for this book, a one‑hour meeting. They spend a half an hour of their own time taking the test, and it’s a huge ROI as far as just the connection that they’re going to make and your insights as their manager or Scrum master as well. It’s very powerful.

Clayton:  What do the results look like? I’m trying to think of, I think it’s the Myers‑Briggs Personality Test or something like that. I can’t remember. I think they have these little codes. Is it the same type of idea?

Scott:  No, and I like the Myers‑Briggs. I took it, and my response is what I think most people think the strengths assessments are going to be, which is, “Oh, that’s interesting. That says that I’m an extrovert.” Well, but what do I do with that? How do I use that at work? Be more extroverty? You don’t know what to do.

The strengths by it, it’s going to give you top five strengths, which are really more like action verbs, or the stand‑out will give you your top two roles and list out all nine. But, there are some that are actionable, like a maximizer. It’ll give you action items to take with that. If the stand‑out will say, “Here’s what you’re best at. Here’s what you can do with that. Here’s a great next step.”

If you’re a maximizer, look for areas where something’s happening with your team, or the company, or a process. It’s OK, but it can be made great. You’ll naturally be pulled towards making things great. Average bugs you.

It opens your eyes to say “Wow, that’s true. We had a deployment processes, and it’s OK, but I know that we could shrink the time down. Or, a build process, we could shrink that.” These people, if they’re on your team, and they’re a maximizer, they’re going to love doing that. They’ll thrive doing that. They’ll learn the most, and grow the most and perform the most. The team can lean on it, and these people will never get tired of doing that stuff. That’s one of the insights. Each one of those will be like that.

I had a team member once, and we were at a lull at work as a Web team. I said, “Just take it easy. Surf the Web. No big deal. Enjoy your paid time off here.” It turned out she got frustrated and left for another job, and the reason was one of her strengths was activator.

The worst thing I could have done for an activator, or I should say an achiever‑‑ that’s someone who loves to check off everything they’ve done that day. They love coming in that day, and there are 10 things to do. They get to check, check, check. “Look, I’ve been productive. Look…”

Scott:  …that was driving her nuts. She would rather have me just cook up some work or given her a checklist of things to do and say, “Hey, could you just take a look at some of these areas in the code base, and review it for areas for opportunity”? Anything. I could have made it up. For me, that would have killed me. For her, it bugged her so much that she left for another opportunity where they would have kept her busier. Those are a couple of examples of doing that.

Clayton:  I understand that it’s a really good tool for figuring out what kind of jobs the members of the team can do that are personally motivating.

Do you find it’s, also, a good tool to use to help team members discover their weaknesses? So that they can try to round out areas they might not necessarily be proficient, or necessarily enjoy as much? Try to find enjoyment in areas where they don’t excel, so that the team can go more for that “Everybody in our team is a well‑rounded individual”?

Scott:  Right. That’s a great question. That’s a common one, because most of our performance reviews are really spent like, “I see that you’ve done this, and this, and this and this. Thank you for your contribution. Now, let’s spend the rest of our hour talking about these areas where you [laughs] suck.

Where you’re not so strong, where you failed, or come up short, or you just don’t perform well.” Those areas where you’re looking at the clock and say, “Is the clock broken? I hate doing this, anything but this. Let me check my email one more time.'” That type of work.

For me, it was organization. “Here’s our recommendation. Use the DayRunner, or why don’t you try the PalmPilot?” I’ve tried those things. The truth is, areas where we’re weak, those things that we do that just drain us that we loathe, all the effort we might put in to try to get better at that will be a lot of pain and not much result.

If you look back over those areas, and you might know what some of those are. I certainly know some of mine. I look, and I have put a lot of time and effort over the years, and I ain’t much better. I’m about the same, marginal improvement, despite putting a lot of time and effort, and money even, at times.

What would be much better for me, especially as a team member, is to invest all that time and energy into my areas of strength, where there will be leaps in growth, much productivity and engagement. I’m better to be around. Look for someone else in those areas where the team might need someone who is detail oriented, who loves to check things off, who loves to tackle the tough nuts. Then, find out where we can shift the work.

On these agile teams as a whole, we should be volunteering. We’re self‑organizing. We’re self‑managing. This is the perfect playground to say, “I love doing this.” The whole team wins when you do that. “I’m not so good at doing this, and someone else probably would like that and they would thrive.”

Now, you’re not playing in areas where you just won’t ever grow that much, or do that well, and getting not such positive performance reviews, and someone else could. They’re not getting the opportunity to do more of what they would love to do.

We actually say, “Play to your strengths. First of all, discover them. Find out what they are, and begin carving out time each week to invest in learning about that‑‑activities that you could do to practice.” That’s how we grow, right? We learn and we practice doing it. Manage around your weaknesses. On the ROI side, it’s just not worth putting time into your weaknesses. Just work around them.

Clayton:  It sounds to me, if everybody is playing to their strengths and doing the things that they’re best at, you will naturally have a tendency to form information silos and skill silos. You’ll start to form a team that doesn’t pass the hit by a bus test. Is that something that you’ve seen happened? How do you prevent that from being an issue?

Scott:  I would separate the difference of technology skill. I’m definitely one who really believes in generalists. I don’t want specialists, and I really love breaking down silos.

But there’s a difference between, say, technical knowledge, your abilities and aptitude, and what you actually are doing versus areas where you’re playing your strengths, so several people that might be developers might love development for those different reasons.

A lot of us in IT have the strengths around learning and input. We love the process of learning, and we love input. If we hated learning, we probably wouldn’t be IT. We would probably be complaining every time they have a new version of the software out.

But outside that, you’ll find people who love to do it because they love the analysis part of it, trying to figure how this works, people that love it because they’re fixing problems. They don’t mind doing process work. They love tackling problems and restoring things back to what they should be working.

We have people who love it because they love teaching others as they’re building. “Hey, this is what I have learned. Let me share this with you,” whether it’s business side or IT, so those same strengths, whether they’re all Java developers or not, those strengths will come and play in different ways.

They can still be generous and share the technology vine. They all work in the codebase, and I would want that. I want collective ownership of the codebase for sure. But why they do it and how they do it is different, and they can play their strengths differently. I’d look for that, and I still look for ways.

You might have to shepherd them all around a little bit and say, “Here’s an opportunity over here. I’ve noticed that only one person is the expert in this.” I’d do that by nature anyways. But I don’t think that strengths will get in the way and shift them up and just all playing together in the sandbox so to speak with the actual technology itself.

Clayton:  The last question on the strengths topic is there an example you can give us or maybe a situation where you introduced this concept, and you had people to take the test, and it just really went south? Maybe some people are really against it and just really want to participate. Anything like that? Or people usually just willing to give it a shot?

Scott:  Everything is always going perfect and sweet for me.

Roy:  I thought that was the case, but I just wanted to make sure. That’s good to know.

Scott:  [laughs] No, I did have someone who was a bit of a rebel stallion which actually I like about them. I loved it when people don’t just accept what I’m saying. Skepticism’s good. A healthy skepticism is something I like to see.

But this person took it to the extremes and just really basically refused to be…He felt he’s going to get labeled. I like to say, “The issue isn’t the issue.” I don’t think that was an issue. I think it was an issue on vulnerability. He was afraid of what the results might say. He knew it would be public. All the other people have their strengths pinned up on their cubes and were talking about it and all that. I think that was the issue.

But in the end, I let it slide and just gave him time and said, “I’m not going to make you participate. I wouldn’t want to do that.” Later on, on the side just after all the excitement had die down a bit later, he did take it, and he said, “It really did nail me. It was accurate, and it was insightful.” Then we had a nice quiet conversation about that, and that was good to know.

Outside that, people will approach it skeptically, but they’ll usually participate. They’ll understand that there’s a win it for them, and I’ll try to take time for that. More importantly, no one’s ever come up afterwards and said, “That wasn’t a good experience for me.” They might say, “I wasn’t sure about this particular strength or that one.”

But overall, they say it’s really good. The conversation will draw insights. But there hasn’t been resistance except for maybe management saying, “What’s happening? Are you doing my job as far as developing my people?” which you need to make sure you’re on the same page with them and talk with them beforehand.

Or HR saying, “It should be on our category not yours.” In fact, a very big supporter of this is HR. It’s worth checking with them, and they can share organizationally that they’re on board and that they know where this is going.

For me, it’s all about team building and the agile team being self‑managing and self‑organizing. I take it from that route and just make sure everyone’s aware and not over‑communicating, but no significant problems after the fact.

roy:  We’re about out of time. But is there anything that you’ve been excited about lately ‑‑ maybe a book, blog, training course, or anything like that ‑‑ that you want to share with anyone?

Scott:  Yeah, I’m such a person of immediacy, I guess. There’s a movie called “Blue Like Jazz” which is actually based on a book. But that term, “Blue Like Jazz,” is talking about jazz doesn’t resolve, and I’m realizing there’s issues in our agile community, I think, that don’t always resolve around what we believe and hold true and what we actually live out.

I’ve been noodling about that. It maybe challenges us maybe to get back to the community a bit more and see what we can do to make a difference beyond just what teams and individuals themselves within the companies and contributing to the greater good. By the end of the day, I would love to have everybody know scrum and agile process. I’m looking in the ways to do that. I’m looking for ways to push out on the other communities outside that.

I just finished lean start‑up and was really impressed me with that on top of the way we can partake accountability for evaluation of what we say we’re contributing to the business. If they can’t measure that, and they don’t have metrics upfront of how they’re going to validate that really added value, what are we doing? That closes the loop, the learning loop for scrum, and if they are willing to, I really recommend everyone to take a look at that as well.

Roy:  Great. Thanks for joining us today. We appreciate it.

Scott:  My pleasure. Thanks for having me, and thanks for all the great questions.

[music]

Announcer:  Is there’s something you’d like to hear in a future episode? Head over to Integrumtech.com/podcast where you can suggest a topic or a guest. Looking for an easy way to stay up to date with the latest news, techniques, and events in the agile community? Sign up today at Agileweekly.com. It’s the best agile content delivered weekly for free.

The Agile Weekly Podcast is brought to you by Integrum Technologies and recorded at Gangplank Studios in Chandler, Arizona. For old episodes, check out Integrumtech.com or subscribe on iTunes.