Sunday, April 15, 2012

What about change ideas from others?

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".

How do you make change happen?

As a manager, part of my responsibility is to be an instigator for process change.  That's not to say I believe in change for change's sake.  Far from it actually.  I'm a firm believer in "don't fix what's not broken".  But at the same time I also believe there's always room for improvement, and if you're not going for it, you're stagnating.  If fact, you are even likely to regress and fall back into bad habits.

In this post I'll talk about change ideas that come from you, the manager.  In the next, I'll talk about ideas that come from those on your team.

Changes I Want to Make

Suppose I have a great idea for a process improvement.  As the manager, all I have to do is tell my team to do it, and its done, right?  Heck no!

The last thing I want is to be seen as a dictator who makes decisions unilaterally and imposes more work on people.  "More work" is exactly the negative connotation your idea will receive if it's pushed on people without their buy-in.

A better approach I like to use to socialize the idea over time.  First, the light bulb turns on in your head.  Then, spend a while thinking about it on your own.  Then, start looking for opportunities to sell it.  If your team does scrum, it might be in a sprint retrospective, where people are noting a problem that your idea solves.  Another great time is during one-on-one conversations, or over lunch, etc.  Over lunch is a particularly good time to share, because your listener is likely more relaxed and willing to hear you out.  They're not feeling rushed to move on through their work day.

As you do this, you'll get feedback to help you improve and develop the idea.  Perhaps that feedback will come from naysayers.  All the better.  You can use this feedback to improve it, and come back later to sell it again with their input taken into account.  Socializing your idea before mandating it can only help your cause.

The (in my view, acceptable) down side of this technique is that it requires patience.  It might take weeks, months, or even years!  Your idea might be some really big change that meets a lot of resistance, and there's no way you're going to make it happen overnight.

Let's say, for example, that you want to create a culture of Test Driven Development in a team that is accustomed to black box testing.   Your developers feel that TDD takes too much time, and your QA team feels threatened by it, or doesn't believe it produces a better result.  If you simply say "From now on we're doing 100% TDD" you'll surely be met with revolt.

Think baby steps.  Maybe start just by e-mailing online articles about your idea, so folks can see that it works elsewhere.  Come up with a smaller idea that's easier to sell and heads you in the right direction.  Make it happen, and then celebrate the results.  You could even start "doing it yourself" to set an example that others will follow.

Another technique is to build a base of allies gradually.  If you have one person on your side, try to get that person selling the idea for you.  If the naysayers hear it from more than one source, they're more likely to warm up to the idea.

And lastly, I hate to say it, but if you work through all these techniques with diligence and you're still not able to make your change happen, then maybe it shouldn't happen.  Simply put, if others don't buy in after patient and persistent encouragement, then maybe there's a flaw in the idea.  Putting your foot down and insisting on it will only make you unpopular, and them unhappy.