UpdatingMentalModelsofSoftwareDevelopment

This is a question I've been pondering recently:

In many companies, the people making strategic decisions that involve technology are way up in the organizaiton... they've moved up the management ladder, and haven't really written (or seen) any code for 15 - 20 years.

And building software these days isn't always like it was 20 years ago. Now developers are likely to stitch together commercial components and add some application code on top of that. THe difficulty is around the interfaces and in working with code that you can't see, don't have access to and have to rely on someone else to debug and fix (in their own sweet time, of course).

I keep running into top managers who are working out of the mental model of what it was like writing code 15 - 20 years ago.

How do we help managers who have been away from development for a long time update their mental model of developing software?

What does every manager need to know about the current realities of developing software?

EstherDerby 090202

I've seen a couple of models for what should happen to keep decision makers in touch. I just finished Geoffrey Moore's Inside the Tornado about coping with the accelerated rate of change in high-tech. His closing chapter noted that (as of 1997) HP was head and shoulders above other technology firms at flexibly altering its marketing, customer intimacy, & engineering leadership as the phase of adoption shifted. Moore attributed this to HP's policy of splitting a division every time its revenue reaches $100 million. This keeps decision making closer to the customers, the engineers and the situation. Moore points out that the geometrically increasing speed/power/affordability of hardware keeps enabling formerly impossible or uneconomic approaches every 3-5 years. This keeps churning the assumptions and mental model basis for decisions.

Another approach taken by GE's Jack Welch, was to focus on results and allow up & coming managers to propose divisional strategy, present it for "walk thru" critique, then go for it. Mistakes are OK when not repeated.

Either case pushes decision making downward where it has no excuse to have stale mental models.

Peter Block, in Stewardship suggests that management see itself as an inverted pyramid - eliminating obstacles not command & control.

I think all of these come down to distribution of authority and facilitating across organizations. These tactics require influence, a safe place to make mistakes, and learning from experience.

--BobLee 2002.09.02

Experiences built the prevailing mental models of managers who make decisions about technology. The manager's head contains models about technology and, more importantly, about obtaining and maintaining their rung on the organizational ladder.

I wonder whether managers make decisions based on outdated technology models because they must create perceptions that justify their position? Too many organizations these days layoff middle level managers who don't appear decisive.

Organizations get what they reward. Do they reward managers for making quick decisions? Or, do they reward manager for making effective decisions? Any idiot can measure how quickly someone makes a decision, but measuring the effectiveness of a decision requires long-term feedback, which requires a more methodical approach.

You can change the manager's mental model about technology by giving them new experiences. We do a lot of that at AYE through the use of simulations. For the manager who wants to explore different mental models, simulations are an effective way to build more relevant models.

The bigger problem, at least in my mind, is organizational. That solution set requires first a significant situation that jars the executives out of their institutionalized thinking. If they don't adapt, they get replaced, which changes the thinking.

SteveSmith 2002.09.03

There's a survival rule here: "It's not OK to ask for help." Males are really vulnerable to this one (just ask any wife!) Deborah Tannen has a lot to say about this one in Talking From Nine To Five - Men and Women Talking at Workby Deborah Tannen (ISBN 0380717832) Men who ask for help are "putting themselves one down" by doing so, so they'd rather flip a coin. Making good decisions safe to make well (with trust of subordinate's knowledge specialties and depths) entails trust and lack of destructive "CYA" culture. Congruent managers can ask for help, and 2 brains are better than one. Pair-managing, anyone?

BobLee 2002.09.03

Bob,

You reminded me of the commonly held notion that men will NEVER ask for road directions even if desparately lost. :)

I like the idea of "pair managing". Too often managers feel they are individuals in competition. In talking to managers I have found that they may get off balance trying to "be competitive" and "be effective".

- BeckyWinant 2002.09.03

If we were lost, we would ask for help, but we're merely exploring. That probably applies to managers, too, male or otherwise - JerryWeinberg 2002.09.03

Becky,
I think we traditionally used to have pair managing when managers used to have secretaries - the 2nd pair of eyes and "Are you sure you meant to say..." The demise of the secretary to MS Office removes that peer review process.

- BobLee 2002.09.04

Last year at AYE, Pascal suggested pair project managers. I've been thinking about that, and trying to practice at home with my husband. We don't do software projects, but we do lots of other projects.

I have to admit, I have no clue how to pair manage. I know how to ask for help. I know how to ask for review. I know how to delegate. I know how to ask for discussion time. But when it comes to making things happen, one of us takes responsibility for following through on things, and the other doesn't.

Pair management sounds great, but I have no idea how to make it happen. If anyone else knows how to do pair management, and has some experience managing in pairs, please tell me how. If you've only thought about it, that's interesting, but after thinking and practicing for a year, thinking is extremely different from performing pair management. -- JohannaRothman 2002.09.04

Esther: I keep running into top managers who are working out of the mental model of what it was like writing code 15 - 20 years ago.

Ditto. I also run into a lot of managers who did hardware development, and have mental models based on having worked with software developers 10-20 years ago. These models often contain something along the lines of "You software guys sucked, and we had to beat you with sticks. It seemed to work then, so that's what I'll do now."

DaveSmith 5 Sep 2002

So what do we do about managers who are operating on mental models appropriate for what software development will be 15-20 years from now ? -- LaurentBossavit

Laurent,

Good question! What do you think are the important differences (between then and now) that managaers need to appreciate? - BeckyWinant 2002.09.05

Whoa! I've seen too way many managers whose mental models came from believing the latest salesman of silver bullets! (Like believing that this new product is what it might become in 5-10 versions?) Nothing against inspiration, but misbelief is something else. I still want Dave's time machine to bet on the stock market or the horses! --BobLee 2002.09.05

So if we were to write a primer on useful models of the current practice of software development, what would we want managers to understand?

EstherDerby 090502

Apropos this, I've been reading Alistair Cockburn's Agile Software Development, which touches on mental models and communication. Cockburn makes the point early on that perfect communication within projects is impossible, and (paraphrasing) that the best you can expect is a converging of understanding over the course of a project. This supports the XP premise that you should spread requirements analysis and design out over the course of a project, rather than expecting to do it all up front (when you know the least).

I want enough managers to understand this that there's critical mass for defending the idea up the hierarchy. I've spent too much energy fighting against forces that want the false assurance of Waterfall.

DaveSmith 6 Sep 2002

Dave, I recently read Jim Highsmith's Agile Software Development Ecosystems and liked his take. Highsmith is a long time project manager / heavy lifter, so his arguements speak well toward management process assumptions. He and Cockburn are quite a duo. He also surveys all the Agile SD processes and interviews the principal thinkers / inventors behind them. Highsmith takes the WHY of Agile to the management viewpoint where Beck is down in the grass roots. Recommended.

I've got to take a look at Cockburn's book next. I'll bring Highsmith to AYE.

--BobLee 2002.09.06

Jim, or his book?

Sorry, but I believe Jim is engaged at OOPSLA concurrently in Seattle. I doubt that I've got that kind of pull, but maybe Jerry does!

--BobLee 2002.09.07

You "doubt" it ? Why don't you email Jim and find out instead ? What do you think Jerry would do that's different from what you could do ? (Offtopic, but I'm curious.) -- LaurentBossavit 2002.09.07

I invited Jim to be a guest speaker at this year's conference. As Bob stated, Jim is commited to the OOPSLA conference during the time period of AYE, so he couldn't attend this year. Jim and I have talked about him joining us next year. He is interested and there is no commitment at this time.

SteveSmith 2002.09.07

Updated: Sunday, September 8, 2002