Motley says: "The management team refuses to change. I give up."

  • Article

Summary

 

Motley:  I cannot get management to accept our "new" way of executing. They are stuck in their ways of thinking.

 

Maven: Change is hard. Do your best to come up with a plan that explains the "why" of the change, enumerates the benefits, mitigates risk, starts small and iterates, presented in a way the management team understands.

______________________________

 

[Context: Maven manages to catch Motley on his way out the door fairly early in the day. Motley's boss, Mark (director of development for Cynthesis) is the topic at hand]

 

Maven: I've been noticing that you haven't been working that many hours in the last few days and that your physical self hasn't been in the office as much. Anything wrong? May I help?

 

Motley: I am just frustrated and, I suppose, lacking some motivation. The team has been doing some great work with agile practices but he is giving us lots of pushback to remain in the waterfall model. The guy just won't accept change. It's his way or the highway.

 

Maven: I can see how that can get you down. From what I have seen, your team is making terrific strides in quality and efficiency with agile processes. Why do you think Mark is so opposed to agile practices?

 

Motley: I don't think it has anything to do with agile, per se. I believe Mark is so constrained in his ways. He doesn't want to see change at all. I think Mark is a great guy, but this kind of leadership will doom us.

 

Maven: Yes, it sure can. Why do you think Mark is so resistant to change?

 

Motley: I don't know - he's just inflexible. It gets me really angry!

 

Maven: Let's get to the bottom of it. Here are some possibilities for why people resist change:

  • Change is difficult. Mark may be comfortable with his routines. When something has worked in the past, even if it worked minimally well, it's tough to take on something else.
  • The change is not understood. Perhaps Mark does not see the benefit in changing his ways. The company may take a hit in efficiency while new processes are introduced. Perhaps Mark does not see long term benefit.
  • History is not understood. Is there history that you are not aware of? Have Mark's teams tried agile before and failed? You need to understand his past with respect to the change.
  • There is too much risk. Any change plan involves risk. Any change management plan must also include risk mitigation. Mark likely wants to be sure that the proposal will not have long term negative impacts on the business.
  • Influence by other factors. The change agent - you - needs to understand how Mark is influenced and tailor your proposal. Perhaps Mark is not as interested in the technical benefits to agile as he is about end value to the business.

 

Motley: Argh. Why can't he just take my word for it and let me execute? Mark is micro-managing by getting in the way here.

 

Maven: That may be the case. Ideally, Mark should focus on results and not how your team is getting those results. However, Mark has background as a developer and takes an interest in how the software is built. He is simply looking out for the business. It makes your job a little more difficult.

 

Motley: No kidding. Unless you have some suggestions for me to try, I'd rather just continue my exit of the building.

 

Maven: You know me, I always have suggestions!

 

Motley: I should have known. Stupid me for suggesting otherwise.

 

Maven: That's the spirit! Firstly, don't give up here. This is a small problem, and I am sure we can bring Mark around to your thinking around agile. I am 100% convinced. Let's start working on a plan.

 

Motley: I guess you're right - it's a small problem. Wait - did I just say that out loud? Fine. You're right. I owe it to the team to follow this through.

 

Maven: Excellent. Change is an opportunity to improve, and you are grabbing hold of that opportunity and using it to move forward on the way we engineer software. Here are some steps we can take. Firstly, want to change. Really want to change. This has not been a problem for you, but you need to show that passion when you approach Mark.

 

Motley: I've really only presented the argument through e-mail, but I guess I should speak with him. Passion does not come across in e-mail.

 

Maven: That is a great idea - talk to him in person. Next, don't be afraid of failure. One thing that stifles innovation is the attitude that every project - large or small - must succeed. In fact, even those that do not have a permanent benefit are successes as long as you learn from the mistakes and do not repeat them. In Mark's case, if he is afraid of failure, your could start with a small non-critical project. Mark is more apt to say "yes" if failure on that feature will not adverse affect the release of the entire product.

 

Motley: I have to be clear that only one of our teams is developing in an agile way based on my ideas - okay, with your suggestions - and we could ship without the feature if we needed to. Then I show the success and slowly expand to other teams. I like the approach.

 

Maven: Sounds like a great plan. When presenting the plan to Mark, make sure you cover why you are making the change. Avoid just trying a new process for fun. There should be some solid rationale for why you are doing it. Present the benefits in terms that Mark understands. If he is quality-focused, show the gains you get in quality. If he is business focused, show him the change to the bottom line. For example, you may ship sooner and the product will be of higher quality with fewer support calls.

 

Motley: Knowing Mark as I do, even though he has a developer background I need to cover the business issues. The technical stuff generally rolls up into the business anyway.

 

Maven: Once you are clear on the reason for the change, formulate a plan with risk identification and mitigation. Anticipate the questions Mark will ask up-front. Have answers ready. Show how you will iterate and improve on the execution of the proposal. Present how failure is actually a success but you will do what you can to prevent it. Provide the details Mark will need. Ensure the plan focuses on results. Try to ensure Mark is thinking about results and allows you some leeway in how you produce those results.

 

Motley: This seems like a lot of work for a small change.

 

Maven: It really isn't a lot of extra work. You need to go through the thinking around the change anyway. As I said earlier, change for the sake of change is not valuable. Know the reasons for it. The extra work comes into play where you have to present the plan in a way Mark understands and appreciates. It also helps to get others on board with your proposal before you present.  These people can help be a proponent for the change and put out any issues. If Mark is influenced by number of people already on board, this can help your case.

 

Motley: Okay, okay. I'm heading back to my desk. I will work on a plan right away. I guess we have a bit of an advantage here in that we have been doing agile for a while under the radar. We have already seen some success and I can point to that.

 

Maven: Sure, but be careful. You may have to play some politics here. If Mark is the type of person that gets upset when people do things he is now aware of, you may hurt your cause instead of help it.

 

Motley: Let me mull that over...

______________________________

 

Maven's Pointer:  As Motley eludes to above, sometimes it's better to ask for forgiveness than permission. When the change is small and generally inconsequential to upper management, often the best approach is the Nike approach: "Just do it." If the change fails, learn from it. If the change succeeds, use it as starting point to bigger and better things and communicate your success if the company culture warrants it.

 

Maven's Resources: