Wednesday, July 05, 2006

Leadership/EQ Rites of Passage and the Mythical Manager Month

A bit of a follow-up on my previous blog-entry about Matthew Edwards and his recently published a book on Creating Globally Competitive Software: The Fundamentals for Regular People.

I wrote:
I have a lot of respect for Matt, he and I went thru a lot of "stuff" together over a very short+intense period (more on that in a moment) and managed to come through it while spreading a little bit of light. During that time I also pointed Matt in the direction of Agile development as a possible "way out of the madness", and he did his part to help make that a reality.
Here's the story on that ... I worked with Matt back in 1999-2002 on what was then a hideously dysfunctional "death march" project that we were trying to pull out of it's own self-created and self-perpetuated hole. The product was an internal one, and Matt, a former testing Guru, was one of my key customer reps. The project suffered from just about everything under the sun:
  • Bad management (failure to set+manage expectations & appropriate interfaces)
  • Dysfunctional customer & internal organization (warring tribes, turf wars, political silos, and a severe lack of trusting/trustworthy mgmt leadership),
  • Management that felt senior architects/designers aren't supposed to get their hands dirty in "coding"
  • A tech-lead with great technical & project knowledge/skill/experience and strong passion for quality design but with an equally great reluctance to lead, overly trusting and possessing piss-poor leadership & communication skills at that time (me)
  • Managers that had great communication skills, but no clue about successful software development, and no interest in learning it
  • A highly talented team of young, promising developers, but with a total lack of software development experience/maturity (which wouldnt necessarily be a bad thing if not combined with all of the above)
And so much more ... in fact that project managed to take two of the best-known worst practices ("the mythical man-month", and "too many chiefs/generals, not enough indians/soldiers") and combine them into an even worse one that I dubbed "The Mythical Manager-Month":
The Mythical Manager Month -- adding more managament to a late & failing project just makes everything thing worse and everyone more miserable.
I have to say, that project really taught me a lot about leadership and communication, particularly ...
  • how leadership differs from management, and from cheerleading
  • the importance of planning your communication and having a communication plan
  • the huge impact of really good managers versus really bad ones,
  • the difference between credibility and trust
  • the difference between power/influence and authority
  • how incredibly selfish, two-faced, and despicably unethical some folks can be
  • how to recognize malevolent manipulators who appear to "befriend" you to gain your trust, but will betray and backstab to get what they want
  • and how to recognize (and handle) a demagogue masquerading as a "heroic manager."
The first two years of that project were both a painfully magnficent failure, and a painfully magnificent teacher. It was definitely a leadership "rite of passage" for me, and leading the successful turnaround of project (in which agility played a large part) was a deeply educational and visceral personal experience that has largely shaped my career & objectives since.

The books by Patrick Lencioni on team dysfunctions and how to overcome them, as well as organizational silos, politics & turf-wars would have done me a world of good back then if they'd been available (and if I'd had enough previous appreciation of those problems to have read-up on them and other works related discovering and raising my Emotional Intelligence).

That project marked my transition from "unconscious incompetence" about leadership & communication to "conscious incompetence" and really motivated me to navigate the path to "conscious competence." I yearn for the day when it becomes unconscious competence.

I'm not quite there yet. It's been a long leadership journey (much longer in experience and learning than in actual years) since that project, and I still have a long ways to go. But these days my bookshelf at home is replete with just as many books about leadership, EQ, influence, and communication as my technical bookshelf at work is with books on software development, and I think about a lot more than just the technical strategies/techniques/practices and lessons learned in my day-to-day work.

3 comments:

Anonymous said...

All of Patrick Lencioni books are written the same way. They are very good. I would also recommend Good To Great by Collins.

Jason Yip said...

Not exactly related to your entry but just this statement "Bad management (failure to set+manage expectations & appropriate expectations)" triggered a thought.

Is the quality of management mostly about expectation management? I'm thinking of what happened at NUMMI and I can't believe that the difference was better expectation management. I'd think it's more about obstacle removal and empowerment (can't think of a better word right now) than managing expectations.

Brad Appleton said...

Hi Jason! Just to clarify, the bullet-item about bad management and failure to set+manage expectations and interfaces wasn't intending to suggest the the former is primarily about doing a good job of the latter, it was intended to be more specific about exactly what aspect of the management strategy was most "wanting"

In this case, the project had several different customers (each a separate install-base) as well as several different internal stakeholders (development needed to work together with deployment/support teams, and IT infrastructure, and a couple other teams).

In this internal project, customers made requests in isolation of one another (often competing requests, where one customer did NOT want what the other customer wanted, they wanted something different). No attempt was made to get the customers together to come to any sort of agreement about what they wanted or what they priorities were (such as what a Scrum "product owner" would do).

Mgmt told customers what the wanted to hear instead of setting realistic expectations and managing priorities (I'm reminded of the saying "If you can't say 'no' then youre 'yes' means nothing").

Similar problems existed between the development teams and the other teams that needed to colloborate together to develop, deliver, deploy and support the software + HW +network infrastructure to meet the needs of the customer/business.

Empowerment from management of the technical subject matter experts would have helped too. But if the product-mgmt and program-mgmt wont even do any of the above, the technical guys don't have much chance (particularly when the mgmt guys wont respect their concerns/issues and address them)