The Regenerate Web

I would like to collect a story from you.

There is a brew-ha-ha brewing over at Aubrey Daniels' blog about such things as reward vs reinforcement vs motivation. This got started as Dan Pink's Drive hit bookstores. Aubrey was puzzled over some of Pink's observations.

"Contrary to what Pink asserts in his book, the surprising truth about what motivates us is that reinforcement always works, but not always as it is intended. The science of behavior has validated that fact in thousands of research studies over the last century. You don’t always get more of the behavior you reward, but you always get more of any behavior that is reinforced. That is true today and it was true thousands of years ago. If creative behavior is reinforced, you (the company, the person) will do more of it. Count on it. When work environments are properly arranged to produce positive reinforcers for highly productive, creative outcomes, they always do produce such outcomes."

So, here is the story I would like to collect from you. What reward system have you tried in the past, that produced unintended consequences? Post your story at Ask Tom and then we can kick the can around.

• moon bases
• jet packs
• 200 mph cars 

but has no...

• cell phones,
• Internet,
• and no laptop computers

Over the long haul, dramatic things happen to change the equation.

Sunil Paul, quoted in The Atlantic, “Better Luck This Time,” July/August 2009.

Via Wayne Abba's PMI Baltimore Chapter address, September 17, 2009. A former senior contract performance management analyst in the Office of the Secretary of Defense from 1982-99.

Forecasting the impact of the latest gadget, process, or method is very sporty business.

For every complex problem there is an answer that is clear, simple, and wrong. - H. L. Mencken

I'm attending a National Defense Industry Association conference on Program Management. I took a break to read some emails - you can only take so much of Earned Value, probabilistic cost modeling, a DCMA self assessment audit guidelines.

There's a discussion going on about how agile software development methods can be applied to safety critical systems. First I earn my living working on programs that contain safety critical system. As well I designed and deployed a safety critical system - the Tricon a classic 80's product name.

The discussion from the agile point of view is typical agile - we've got this really cool way of doing things, you can use it on your problem too.

In the absence of a domain and context, probably not. I spoke for two nights this week at Carnegie Mellon University, San Jose on the 5 immutable principles of project management. My co-speaker is a senior manager at Pay Pal, which make very good use of Scrum in the development and maintenance of its code base.

One of the learning from that series of lectures is that a software development method needs to have a domain and context for it to be effective. If we say a development method is valuable in the absence of that domain and context, we are following Mencken axiom

I wrote a little article about Barriers to Agility in the most recent version of PragPub, the online magazine from the Pragmatic Bookshelf. There’s a bunch of other good articles in there, too. Andy Lester has a great article about speaking as a way to practice interviewing, a bunch of comments/thoughts/rants about the iPad, and much more. Take a look!

Tweet This Post

From the Ask Tom mailbag:

Question:
I learned today that my salary, as a manager of a department, is less than the people on my department team. My boss told me that adjustments will be made during my review. What is the best way to deal with this without feeling betrayed by my employer? I have been with the company fewer years, but promoted twice and my skills far exceed those on my team.

Response:
Your situation is not unusual. Most companies have only an intuitive idea about appropriate compensation and much less of an idea when asked to explain their compensation structure. Curing a compensation structure that is out of whack is quite difficult.

This is complicated by the fact that compensation gets wrapped up in the self concept of a person's value. Not the case. Compensation must be based on the contribution of the role. The person may have higher capability and the potential to play a higher role, but it is the role that commands the compensation, not the person.

Elliott Jaques was quite specific and clear on the subject of compensation. He offers a simple basis for compensation banding with Time Span as the metric. Compensation, in Jaques model, is directly tied to the effective Time Span responsibilities in the role. And in your case, as a manager, your task assignments (goals) would necessarily have longer Time Spans associated. This would command a higher pay band than those on your team.

Your employer gets the benefit of the doubt on this one, acknowledging that an adjustment is appropriate. And it is likely to take some time to fix this systemic misunderstanding. And an even longer time for your boss to understand why.

Yesterday, we kicked off our new Subject Area in our Working Leadership Program, Goals, the Essence of Time Span.

This community is growing. We currently have 81 members with an additional 72 people participating in the Free Trial. This activity level is unbelievable and we would like to share it with you. We are going to hold our Free Trial open for two more days. Follow this link to Working Leadership Free Trial.

Here is what we know about our community.

1. Our participants have a day job, as a manager.
2. Our participants are really busy.
3. Our participants want to be more effective, now.

This is Real
Working Leadership Online is practical. There are no quizzes or tests. There is no make-work. This is not extra work. The Field Work is real.

At Your Pace
Participants login on their schedule.

Unforgettable
The problem with most training programs is they stop. After a few classes, it's over, good luck. Working Leadership Online goes year-round. It changes the way you think about your role as a manager.

How This Works
Your first Subject Area is on us. Then you decide. We are holding the next 50 slots. Word is already on the street, so we expect to close this offer in the next few days.

Here's Some Feedback

This program is anti-matter to today's barage of costly management solutions. The program covered a great deal of critical leadership material that managers can immediately benefit from. -Cathy Darby

Some people live online and I'm not one of them. I'd much rather be in a human presence. Having said that, after Tom's first response he won me over. His honesty and feedback is invaluable. -Jane Hein

There's a lot of valuable information in this course that isn't easily available elsewhere, and the coaching from Tom in addition to accountability for actually carrying out the assignments makes for a solid learning experience. Keep up the good work. The online format makes the course accessible, and makes it easy to put into practice directly in a work environment. -Erik LaBianca

www.workingleadership.com

Here is the schedule for the coming year.

2010 Subject Area Schedule (Total 15 Subject Areas in 2010)

• Jan 11 - Planning - Your 2010 Business Plan - COMPLETED
• Feb 1 - Goal Setting - The Essence of Time Span
• Feb 22 - Decision Making - Time Span of Discretion
• Mar 15 - Managing Time - Managing Yourself
• Apr 5 - Spring Break
• Apr 12 - Communication - Mineral Rights Conversation
• May 3 - Delegation - Leveraging Time Span Capability
• May 24 - Control Systems and Feedback Loops
• Jun 14 - Team Problem Solving - Time Span Inside a Team
• Jul 5 - Summer Break
• Jul 12 - Coaching - Bringing Value as a Manager
• Aug 2 - Coaching Underperformance - Time Span and the Employment Contract
• Aug 23 - Coaching High Performance - Time Span and Maximum Capability
• Sep 13 - Fall Break
• Sep 20 - Managerial Authorities - Time Span and Accountability
• Oct 11 - Managerial Authorities - Time Span and Hiring Talent
• Nov 1- Time Span and Effectiveness
• Nov 22 - Break (Thanksgiving USA)
• Nov 29 - Bringing Out the Best In People
• Dec 20-Jan 9, 2011 Winter Break

Reserve your spot today - Working Leadership Free Trial

From the Ask Tom mailbag:

Question:
One of my biggest frustrations, as a manager, is the expectation from the people that report to me that I 'spoon feed' them answers to all of the problems and challenges that they face. Do I have the wrong people? How can I get out of this trap?

Response:
Your solution is in your question. You are spoon feeding them the wrong stuff. When you provide answers to your team, you are creating a co-dependent relationship that you turns you into Radio Shack (you've got questions, we've got answers). You are actually training them NOT to solve their problems, but to bring them to you for solutions.

So, STOP it.

Every team member is entitled to have a competent manager, with the Time Span capability to bring value to their problem solving and decision making.

As a manager, you do NOT bring value by spoon feeding answers. Learning happens through questions, not answers. As a manager, your greatest value is in the questions you ask your team members. And if you are not getting the response you want, then you are asking the wrong questions.

It's Groundhog Day - a day proliferating the myth that a rodent can predict the weather six weeks out.  Personally, the day means nothing to Iowans.  There will almost always be foul winter weather during the high school basketball tournaments in March.  And spring doesn't really arrive until my neighbor, Ann, and I come out of our mutual hibernations and have our first prolonged driveway chat.

But for a moment, let's assume this myth about seeing the shadow thing is true.  We then have another example of how systems ignorance (the opposite of systems thinking) can mess up decision-making.

Dissect this with me.  The groundhog makes a decision to leave his home and go outside.  If he DOES NOT see his shadow, he decides everything is okay, and he can stick around for a while (thereby ushering in spring).  If he DOES see his shadow, however, he freaks out, decides outside is unsafe, and scurries back into the safety of his abode.

Pretty absurd, eh?

A manager (or executive, or any other form of so-called leader) pokes his head out of his organization into the world at large.  Seeing nothing threatening out there, he (or she, to be fair) decides that the environment is non-threateningly great and that he and his organizational can flourish.  However, if the rodent manager sees that his actions (shadow) have had an impact on the outside environment, he becomes freaked out and retreats back into his cubicle, hoping a prolonged status quo will prevail.

OK, that's a little tongue-in-cheek.  As organizational groundhogs, we need to seize the shadow.  We need to recognize our role that our outputs are having on the environment around us.  If we do see those impacts (positive or negative), we need to be accountable for them, embrace them, seize them, and own them.  And if that means fixing them, so be it.

Will you simply see your shadow today?  Or will you also seize your shadow as well?

There is one of those semi-heated discussions on an agile forum around CMMI, Agile and the confusion between them. Here's a summary from CMMI DEV V1.2. Note that the software development activities live in Engineering.

An Update

I'm presenting to a graduate class at Carnegie Mellon West Monday and Tuesday of this week. As well I'm in a loop discussion on an agile forum about CMMI and agile.

It's breathtaking how many people confuse CMMI with a software development method. Much in the same way there is confusion between PMBOK and a project management method.

The chart above - if you in fact take CMMI as a framework for software based product development maturity assessment - shows where "development" activities live and where other activities live. CMMI says you need all these process areas to increase the probability of success.

So agile software development provides methods to fulfill some of these process areas. Specifically the one in the Engineering Process Group. But there are process area where agile has little our nothing to say.

So Agile is not project management in the sense used by those defining the processes of project management. If you redefine the process needed to increase the probability of success of the software project, then maybe you can call agile project management.

I just returned from Tokyo, where I keynoted at JaSST, the Japan Symposium on Software Testing. 10 years ago, when they started the conference, maybe it was just about testing, but now it’s evolved to be about quality in the organization.

Some highlights from my trip:

• Everyone (and everything) I met appeared quite orderly. Everything had a place and everything was in its place. I saw this at the lost-luggage counter, in the hotel, and at the conference.
• I was pleasantly surprised that the subway ticket machines had an “English” button so I could buy my ticket and know what I was doing. The maps were in English as well as Japanese, so I could know in advance what my trip would be and which stop to get off at. I had a little trouble with which track, but that’s probably because I was jet-lagged.
• I was pleasantly surprised to see evidence that the simultaneous interpretation for my keynote worked fairly well. I could tell because people laughed when they were supposed to :-)
• For the tutorial, I did not allow enough time for the consecutive interpretation or for the questions about agile, so I needed another 20 minutes, which I did not have :-(
• I was a little concerned that when the panel prepared for the questions, I thought we might be boring. Nope, we were thought-provoking and funny.
• My Japanese hosts were amazingly solicitous and helpful for my entire experience: to/from the airport, to/from the conference, to/from sessions at the conference

I had a blast. I hope I have an opportunity to return to Japan. Now, all I have to do is get enough sleep so I’m awake during the day…

Tweet This Post

"Things are managed; people are led" - Capt. Grace Hopper

Thanks to John Goodpasture for the reminder. I once had the privilege of "trying" to carry Captin Hopper's bag at the Orange County airport for an ACM meeting she was speaking at. She wouldn't let anyone "give her a hand."

I am a big fan of welcoming naysayers and devil's advocates into the conversation. I reminded myself of this last week and enjoyed the outcome, so I thought I would share the concept with you. Not only is inviting a challenge a great way to unearth diverse ideas, it helps enroll people into the process and improve their acceptance of my work. Naysayers make great evangelists!

• Create a rough draft of your proposal. Offer the rationale, describe the idea, and give as much context as possible.
• Select a small group of pre-early adopters. These should be people who you think can – and will – give you interesting feedback. Include people who are the most logical detractors.
• Create a list of questions you would like your pre-early adopters to answer. Include questions like, “what are all the reasons that you think this idea will not work?” and “what about this idea do you find least appealing?”
• Invite the pre-early adopters to review the plan and provide feedback. If possible, invite them to a 15-minute meeting where you hand out the rough plan and questions and ask for their feedback within XX days. If a meeting is not possible or practical, give each person a quick call asking them to participate and letting them know they will soon get and email with the plan and questions attached. Let your pre-early adopters know that you do not want them to sugar coat the feedback and that you believe that all feedback is a gift – even when it is tough to hear.
• Once you get the feedback, thank everyone sincerely and warmly, regardless of how critical they were of your ideas. Then use their feedback to improve your plan.

You will find that when you invite a challenge, you create many more fans than detractors. Even those who do not like the idea will become more accepting of the revised plan implementation. It’s magic! In addition, when we establish an environment where people feel comfortable sharing their concerns and ideas, we will be more likely to hear about and catch mistakes and head off problems as they emerge. You want to know what’s happening as soon as possible; otherwise your options for dealing with barriers will quickly diminish.

While responding to a post on Herding Cats, I came across a $75 Outlook based PM tool MissingLink Project Management

So minus the software interpreted process of Andrew's tool, what's the difference here? Outlook is ubiquitous, possibly on every desktop and cell phone in some form. It's highly configurable and like Andrew is fond of saying "as easy as email." It is email.

We get brilliant results from average people managing brilliant systems. Our competitors get average results from brilliant people working around broken systems

– Fujio Cho, Chairman Toyota Motors

People are needed. But the "system" is the critical success factor. Tools implement the "system," but tools must support the processes defined by the "system." If not the tools are worthless and the people cannot perform their job, so the whole thing falls apart.

Bret is a reader of Management Craft. He tried to leave a comment (on this post about the Aubrey Daniels slam on Dan Pink's book Drive) but was unable due to length (again!). I looked at my Typepad settings and could not find anything I could check or uncheck to change the allowable length of comments, sorry! I don't quite know why this is happening. Here is Bret's comments, my thoughts at the end:

===========================================================

Hi Lisa:

www.bretlsimmons.com 

==================================================================

Thanks, Bret. I appreciate your comment and that you took extra energy to get it to me by email.

I like giving managers both the concepts and some specifics and here is why. I think it is helpful to facilitate a deeper understanding with examples and "what this might look like in practice." Take something seemingly simple like:

• Showing we care
• Removing obstacles
• Collaboration
• Partnership
• Catalytic coaching
• Clarifying expectations

I have worked with managers who thought they knew what these practices looked like and would have said they are using them. But when we talk about some specifics - what it looks like on a daily and weekly basis, what it looks like in action at a staff meeting, what it looks like in a morning huddle, etc... they find that they did not understand the practice and that they are not currently doing this much at all. The specifics are not the ONLY ways - they are examples of ways for doing _____.

Organizations spend a lot of time defining desired practices, expectations, core competencies, values, and such but not nearly enough time training managers on what this looks like at their level and what this looks like on an every day basis.

I recently designed a four-hour class, for example, that does only one thing - it takes two concepts (accountability and ownership) and progressively drills down on what they are, how they are different, and the daily and weekly actions supervisors do that affect both.