Buckle up: it’s going to be a bumpy ride


It’s not easy to get good performance culture.


Perhaps at first blush you might think that it would be easy.  After all performance planning, like many other quality aspects, is about creating a better product for your customers in a better way.  It’s about having more control, making deliberate choices, and understanding and controlling your risks.


How could anyone in their right mind possibly disagree with value of these things?  It should be as easy as selling a no-calorie fat-free dessert that tastes as good as the best ice-cream you’ve ever had.  Why isn’t it?


Well the fact is that getting good performance culture is a lot more like getting people to buckle their seat belts than it is like getting them to eat a guilt-free dessert.


With seat belt buckling, especially in the early days, people use to say ridiculous things like “I’m strong I can brace myself,” or “It’s better to be thrown clear in an accident,” and those are just part of the battle.  Other things they would say are “The seat belt just isn’t comfortable,” or “I won’t let the government dictate what I do in my own car.”


All of these reactions are perhaps typical of what you face when trying to make a cultural change.  People can deny that there is a problem at all, so you work on awareness; they can be misinformed as to how it should be solved, so you have to help inform them; they may resist for reasons that are unwise (is it really prudent to trade a little comfort for that much safety?) so you help them understand the tradeoffs they are making; or they may rebel entirely against any new process just because they don’t want any process as they are all “responsible adults” who don’t need help from the likes of you.


That last one is perhaps the one that personally I find the hardest to deal with.  The fact is that even the best engineers make mistakes, often because they react inappropriately to time or cost pressure and then make decisions which ultimately do not serve them or their customers.  It’s only human nature.


Don’t believe me?  It isn’t hard to see in action.  Just go stand at an intersection for a few minutes and watch what happens when the light turns yellow.  Now remember, every one of these drivers you see has been educated and tested, and the law is very clear. In Washington State it says for instance, “You must stop if it is safe to do so.”  That’s clear enough right?  And yet drivers’ actions are not consistent with this; it doesn’t take long to observe that what people are doing is much closer to “You may proceed unless it would be unsafe to do so” than to the law.  In fact the situation in my area is now so bad that is unsafe to proceed when the light first turns green because someone may be testing their luck going the other way.  Yet the whole purpose of having a yellow light was to avoid that very situation.


Why does this happen?  Well my personal theory is that here, like in many other cases, a person is making a spot decision and is choosing the expedient rather than considering what the net result of their actions will be.  That the habit of pushing the yellow has in fact eroded the safe duration of the green never occurs to someone that is in a hurry.  That the overall bandwidth of the city streets is lowered by their actions and that therefore on average they get places more slowly doesn’t occur to them.  They just need to get through that yellow light.  Now.


And remember this is not one or two awful human beings doing all this that we’re talking about here.  This is prevalent behavior; it’s people we know and respect; it’s smart, educated people.   In other words it’s “Responsible Adults.”


Now suppose you needed to change the behavior in your city in the direction of having fewer people push their luck on the yellow lights.  Sobering thought isn’t it?  Yet changing the culture of a large development team is a very similar problem and you would use very similar techniques to accomplish the result.


As engineers we have rules and procedures in place to help us to avoid what is merely expedient and thereby act with the discipline that we aspire to.  If we choose our procedures wisely this helps us to be more productive, not less.  After all “productivity” comes from “producing” and production doesn’t count if all you made was a big mess.


Even so, your organization might need a reminder once in a while.   You can make a difference but it won’t happen overnight and it could be a little bit “bumpy” along the way.  But hang in there, I do 🙂

Comments (7)

  1. all those things apply to programming secure applications, I think the bottom line is that it requires a bit more of knowledge and effort, and unfortunately the average programmer just gets things to "work"

  2. Interesting — good analysis of human nature. As for how to deal with this type of behavior, it seems, from what I have heard, that "advertising" the behavior you want to encourage can definitely have an impact, even if some people are inclined to resist change in the ways you describe. Here are some examples, all related to traffic:

    (1) A few years ago in San Francisco, people’s aggressive driving was getting out of hand. So the city started an ad campaign of posters, some quite graphic if I recall, showing the consequences of dangerous driving. It worked; people started driving a bit more safely.

    (2) Just the other day, NPR had a story about a town in Illinois where people were getting in the bad habit of coasting through stopsigns. So the town started posting small signs immediately below some of their stopsigns — the smaller signs simply said, "Stop means stop." Seems kind of silly, but it actually worked — at those intersections, people did in fact begin obeying the signs, and coming to a complete stop.

    I guess my point is that there is hope: If you keep getting the message out there, it can have an impact. I had kind of thought that in both of these cases, people’s righteous, "don’t-tell-me-what-to-do" nature would have meant that the signs would have no effect. But in both cases, they did have an effect. Perhaps not on everyone, but on enough people to be worth the effort.

  3. Poor software performance causes annoyance and wasted money. One way to get developers to appreciate the end-user annoyance is to simply put them into the same boat: give them a machine to work with with only a limited amount of RAM and CPU speed.

    Suddenly you find enormous efficiency gains in the software.

  4. JConwell says:

    I used to work at a large multinational software company in redmond. Your yellow light analogy also applies to PMs, in trying to create a performance culture. When people see yellow lights, the punch it to make it through the intersection. When PMs see the yellow light of the project deadline, they floor it also. That "ship it" mentality causes them to make bad product desicions just so they can ship it and get their bonus(?)

  5. Vinea says:

    The thing about yellow lights is that traffic engineering has taken a back seat to revenue generation.

    Red light violations occurs most often when yellow light timings are shortened.

    Yellow light timings have departed from good engineering because the formulas for determining adequate yellow light timings have progressively been changed to allow shorter times. Yellow times are now allowed to use posted speed limits rather than the 85th percentile speed (ie the actual speed of traffic through an intersection). Red clearance times (when everyone has a red light) have been made optional and for the most part have disappeared.

    From 1976 to present the rules have effectively reduced yellow times by a third and eliminated all safety buffers. In 1976 red light violations occurred but were relatively rare. Since the rule changes (1982 and 1999) they are occuring more often and are much more dangerous since now opposing traffic gets green immediately when red occurs.

    The biggest problem is that posted speed limits are allowed to be used. Stopping distance (and time) is predicated on speed. Using a slower speed allows using a shorted yellow signal.

    Folks speed therefore the majority of the yellows are now too short. Now the average driver knows that yellow timing are likely inadequate for the speed he or she is travelling (from experience) and the equation for "stop if it is safe to do so" formula now results in either paniced braking (in the event there is a red light camera present) and increased rear ends or gunning the engine because there’s no way they can stop in time given the current timings.

    Drivers have been trained to push the yellow because adequate stopping distance has not been calculated for the actual speed of traffic. You can argue they should be going the speed limit. Right.

    Likewise, programmers have been trained to produce shoddy work. They know that the schedule precludes good work and some choose to "gun it" to meet the deadline anyway while others "panic brake".

    If you want people to perform better then make your desired outcome the "expedient" decision and the path of least resistance. Getting a "good performance culture" starts at the top and real $$$ commitment from management.

    Most engineers have decent BS meters. They know when quality or performance "cultures" are real and when its lipservice. They also know there’s no such thing as a free lunch. A "performance culture" like a "quality culture" has significant costs. It has good ROI (depends on market really) but requires the investment.

    This means longer schedules, more QA and testing support, better training and more devs.

    When you don’t see that, you know there is no commitment to "quality" or "performance" and management is either giving lip service or bought into the marketing hype of the process du jour.

    Vinea

  6. Vinea says:

    "As engineers we have rules and procedures in place to help us to avoid what is merely expedient and thereby act with the discipline that we aspire to. If we choose our procedures wisely this helps us to be more productive, not less."

    Oh…this qualifies as marketing hype. Having worked in multiple CMM-I, ISO 9000 organizations (including in such fields as telecom where five 9s is the "culture" but its not really…ask some Lucent or Nortel coders) the costs of quality are quite high and the performance (in terms of time to market) much lower.

    Total performance (in terms of reduction of re-work for defects) may or may not be higher but not in the silver bullet range as proponents of process quality (ie 20%-50% increases) like the SEI will tell you. This is silver-bullet territory.

    Depending on which metric you pick, and how much credit you give toward cost avoidance (from not performing rework) you may or may not see a positive ROI.

    You WILL likely end up with a better product. If this is insufficient rationale (ie ROI) for the extra expense even without a productivity increase you don’t have a "performance culture".

    If you are unwilling to trade productivity for quality you don’t have a "quality culture".

    In my experience the only "silver bullet" performance and quality improvement strategy is hiring better engineers.

    Vinea

  7. Recently I’ve been reading up on Rico Mariani’s blog.  What a gem!   One especially profound…