In my last post I talked about how to instigate process change, which is something managers should always be thinking about. Now I'll take a look at it from another angle, which is: how do you handle ideas for change that come from others, especially those on your team.
You should consider yourself lucky if you have members of your team that think this way. Nobody is likely to promote a change that they think will be detrimental. They probably have good intentions and are trying to improve things.
The Scrum process teaches the "sprint retrospective", where at the end of each sprint, the team talks about how things went, and folks are encouraged to suggest how to make things better for the next go-around. In my teams, some people are not very shy. I've been a part of over 100 sprint retrospectives, and there's always someone with something to say in each one.
As a manager, I have a unique role in these conversations, in that my reactions to people's comments is very important. The individual contributors with new ideas will look to me to implement them. Some ideas will be great, out-of-the-box improvements (like: "let's automate this or that mundane task we do every day"), while others will just be new time sinks that aren't all that practical (maybe: "I don't like the architecture...we need to rewrite the app from the ground up"). Other times you'll just hear complaints in a retrospective, and you'll be the guy expected to come up with ways to make it better. My favorite complaint (sarcastically speaking) is "people aren't communicating enough...". Ok, so now what?
When you're in agreement...
The easy situation is when someone makes a suggestion and everyone, including you, agrees. Ya, let's do that! It's important, is valuable, and we can do it immediately. The only problem you might have is whom should get the implementation task? Well that's easy too. I usually kick it back to the person with the idea. If they really believe it, they should be the one to champion it. Buy-in is already there. Done.
When you're not in agreement....
Disagreement about a new idea might be your own, or it can come from others in the team. But the handling for the manager is the same. You should make sure my initial reaction is always positive. I always try to start by voicing appreciation for the idea and the positive effects it could have, whether I like it or not. Then its time to explore the idea further.
The most important question, and the guiding principle for this whole blog post is...
What problem are we trying to solve?
As I said in my last post, I believe we should always be looking for ways to change or improve, but I also believe in "don't fix what's not broken." Let's say, for example, someone suggests using a cool new app that does a virtual scrum board on an iPad, where you can drag sticky notes across the screen as you pass around the iPad in the daily standup. Sounds cool, right? Let's buy iPads and start doing this! Or not. What problem are we trying to solve? Seriously, what real problem does your team have that this solves for you? If you can't answer that clearly and easily, it's not worth making the change.
Once you know what problem you're trying to solve, now you have to examine the merits of the proposed solution. Does it solve the problem long-term? What is the cost and resources required to implement it? What is the priority relative to other things going on? What other ways are there to solve the same problem?
This might sound like a naysayer who's just looking for ways to say "no" to the idea. That's not a very positive attitude, is it? Well, no its not....and yes it is. It depends. Its all about the initial reaction being positive, and the subsequent considerations that lead you a decision. If your initial reaction is always "no", you've started out all wrong, and you'll stifle future suggestions and damage team morale. But, if you're ultimate answer is still "no", even after showing due consideration for the idea's merits, then folks are likely to respect your decision much more.
Choose your battles
A final consideration for a manager when facing an idea that meets with disagreement is what you might call "choose your battles". If someone has an idea you're not necessarily comfortable with, but their intentions are good and they seem really motivated, then you have to decide if nixing the idea is a good call, even after considering and discussing all its merits and pitfalls.
The point here is that someone had the idea, and they will feel good if it gets adopted. You see flaws in the idea, and you would never suggest it yourself. But you want people to feel good, so you should let them pursue their idea, right? Sometimes.
This is where your own confidence comes into play. If you're going to put your foot down, you darn well better know that you're right, because there will be a large morale cost to saying no if you're not able to convince others with reasoning. If you're not sure of yourself, well, maybe you're wrong. Maybe the idea will be a winner. You'll also earn a lot of goodwill by letting go of your objections and empowering your employee.
In summary, the "happy place" is when your team is full of ideas, everyone loves them, they're all willing to implement them, and you have the resources available to do so. I haven't discussed that much here.
But things are less rosy...when you have more ideas than resources, or ideas meet with disagreement, that's where your management skills have to kick in to help the team figure out when to say "yes", "no", or "maybe later".
No comments:
Post a Comment