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?


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.

2 thoughts on “Dealing with Old Management Habits

  1. John Lamb

    Agile in a CMMI/Rigid Systems Engineering Process World

    In a recent project, as a member of a large bureaucracy, I’ve had to deal with being held to a rigid systems engineering (SE) process. The whole nine yards, OCD, SRD, SFS, SRS, IRSs, the documentation list goes on and on.

    SE Process can be a very good thing when implemented properly. My problem was that my team was being held to a higher standard than our customers and was being held there by the sponsors (an anonymous PMA).

    So on one hand we had to adhere to strict documentation and review cycles but at the same time we weren’t getting spelled out requirements. We were getting the requirements in an Interface Design Specification (IDS) and were being told that the IDS represented complete requirements along with a PPS and User’s Manual. Can’t tell you what the project was but suffice it to say, it was massive.

    In addition to all this, the schedules were compressed and money was tight as usual.

    Question: How do you implement a more Agile approach when your neck deep in process and in a compressed schedule with limited budget?

    My solution: slowly reduce the documentation within your own process and push back on requirements and hope the PMA doesn’t tell you to just get it done anyway and then start looking to blame you when the project gets into trouble, even though it was their fault for not listening to you to begin with.

    Jon: I know for a fact you’ve dealt with this before…any advice?

    Proposed next topic: “Agile-CMMI” It can be done but they seem to be at odds with “Working software over comprehensive documentation”

  2. jon

    Hmmm. Tough situation for sure. Frustrating I bet, too. One idea… bring it up to the powers that be… See if there truly is a desire to succeed, or a desire to follow process regardless of actual success.

    Another idea: make all of the tasks visible and blessed by the stakeholders. Make it clear as to what they are asking for and how much it costs.

    And, be sure to check that you are doing truly useful documentation to the proper level to allow the team to do their best. But for “make work” documentation, try to get away with the bare minimum.

Comments are closed.