Technical Debt

Dealing with Old Management Habits

Responding to:

John Hebley said the following on 10/20/08 11:08 PM:
Philippe, Jon

May the force be with you. I was about to rant and rave about incompetent managers etc, but that would be just preaching to the choir.

That is a new topic, if you want to discuss it. How do you work with these, often senior managers, that have no idea what you are trying to do, and insist on applying 1970's thinking?

John

I find it very common that many folks (yes, some of these are "older" managers) retreat to the comfort of what they were familiar with in the "good old days". Probably human nature when confronted with being out of the comfort zone. I have been doing agile development since the early 90s and have been taking unique approaches to solving problems for longer than that. I am familiar with folks who don't "get it" or who need a preponderance of evidence to be won over.

A partial list of my responses to an "older manager":

• I have to suppress being impatient (see personality profile below)... You see, for me, many times it feels like battling the Flat Earth Society; or the "Gravity Points Up" mentality; or "The Ostrich Society"
  • By nature I have always been an early adopter.
  • By nature I am an engineer
  • By nature, I trust, but verify
  • By nature I am impatient to get results
• When I feel stressed by those that seem to "take issue" with what I am trying to do to achieve (largely their) business success, I take it as a sign I need to do more educating, show more, explain more, assume they have validity in their feelings.
• I ask them for things they would like to see that would "prove" (to them) whatever the particular matter is at hand
• Funny thing, many times they can't think of what to ask for, they just know "it doesn't feel right"... Sometimes I find myself moving the level of thought "up" for them and I provide ways to achieve degrees of "proof" that never before existed at their company or in any other project.
• I am profuse in beating the drums of process, quality, testing, automation, and many small bits that make up a high-performing team and on-track project
• I will make uncertainty, variability, and risk more visible to combat the illusion that traditional Gantt charts or Work Breakdown Structure approaches to managing software feature development are better than the way I run iterative development.
• I will try all sorts of approaches to communicate if at first I don't succeed
• The project wiki is a huge part of this
  • I blog about the project ("News")
  • I stand up special pages when I have to address yet another "senior management" challenge
  • I ensure as many stakeholders and other managers as needed are in the loop and are helping to allow the whole extended group to "get it"
• When it might be "embarrassing", I keep the education private (and when it would benefit all, I make sure the wiki post or blast to the development/project mailing list is not tied to the requestor).
• I work very hard to shelter the team from the details of these sorts of "senior management" moments. I let the team know if/what folks are "asking", but I like to minimize those moments that are more distractions on the core development trajectory, than helpful.

At the end of the day, I know I am doing my best, often working harder than anyone to achieve the ultimate business goals that the project has been chartered to achieve. I live and breathe the project business goals. I let the chips fall where they may.

For obvious reasons (to me, anyway), in any complex project that I am involved with, there would be no chance of me doing it as fixed-price work. That would compromise being able to respond to the "human" parts of the project and client needs.

-- jon

ps: My personal response can range widely, I am sure. Here is the beginning of one (of many) behavioral profiles for me:

Jonathan likes to be forceful and direct when dealing with others. His desire for results is readily apparent to the people with whom he works. He is driven toward goals completion and wants to be in a position to set policy that will allow him to meet those goals. He displays a high energy factor and is optimistic about the results he can achieve. The word "can't" is not in his vocabulary. Many people see him as a self-starter dedicated to achieving results. Jonathan is aggressive and confident. He is deadline conscious and becomes irritated if deadlines are delayed or missed. He is a goal-oriented individual who believes in harnessing people to help him achieve his goals. He needs people with other strengths on his team. He is often considered daring, bold and gutsy. He is a risk taker who likes to be seen as an individualist. Jonathan may have difficulty dealing with others who are slower in thought and action.

Stovepipes

An agile modeling poster:

How does agile prevent stovepipe systems and implementations. My inquisitor seems to think that agile development processes actually increase the incidence of stovepipe systems and thinking. (I'm paraphrasing here)

Agile is recursive.

Just as the power of components, objects, interfaces is applicable in the small or in the large...

The parallel being: the mere existence of the "tools" to avoid poor solutions doesn't mean that poor solutions will not happen. We still have excellent code and poorly-written code.

The overarching agile requirement is to use good old-fashioned, smart thinking.

Agile neither precludes nor promises brilliant designs and abject failures. Only people can do that.

Apply the tenets of agile development recursively "upward" and you might be able to avoid stovepipe thinking.