Managing the De-Motivated


It still amazes me how a process created by engineers for engineers can make so many engineers so unhappy.

I’ve seen all kinds of responses to Agile from engineers. Some are immediately enthusiastic. Others are cautiously optimistic. Many are amused and cynical. And some are down right hostile. Over time the responses polarize and the body of engineers undergoing an Agile process split into two camps: Those for whom Agile is working and those for whom it isn’t.

I’d like to point out that I’m not talking about Fragile (Waterfall Agile) or Badgile (just a plain bad Agile implementation). Fragile and Badgile don’t work for anyone, not the Agile fanboys nor the management types that mistakenly create these processes. (If your boss says, “Agile yes, but we must have controls!” then you’re headed down the road to sadness.)

Unfortunately in my experience there are really good engineers out there for whom Agile in all its manifestations, from Scrum to XP, just doesn’t work. I’ve done a fair amount of work to figure out why and what to do about it. I’m going to use Scrum in my examples but this isn’t a problem of flavor. However you enact the principles the problems are the same for this segment of the engineering population. Also note this isn’t a generational thing. Agile-challenged engineers come in all shapes, sizes, sexes, IQs, and ages.

The top four reasons why Agile doesn’t work for some engineers:

  1. You have to like to talk to people. Engineering as a profession self-selects for people who find human-machine interactions more interesting then human-human or human-animal interactions. People who like to talk to people become salesmen or lawyers not programmers. But for some engineers human-human interaction is down right painful. If you are not into face-to-face communication Agile is not for you.
  2. You have to need and accept help. I love to remind people that intelligence is a side effect of evolution not its goal. (The gold of evolution, if there is one, to enable a species to adapt to a changing environment. Intelligence is just one experiment in adaptation and probably not the most successful one since it’s only worked for one species.) I’ve found that some really intelligent engineers are so smart that it’s difficult for them to accept help (like a prioritized backlog or a bug report) from people they view as obviously less intelligent. You can call this arrogance but then would Mozart have accepted help on his symphonies?
  3. You have to embrace change. Many people from all walks of life have difficulty handling change-rapid or slow. They just don’t like the idea that the world they have finally gotten used to and mastered no longer exists. Some of these change-adverse people happen to be engineers. You can spot them easily. They are programming in languages and paradigms that are no longer on the leading edge. I often have to say to them: Yes, you can still write desktop applications but nobody under 40 is going to care.
  4. You have to like focusing and working on a schedule. Whether your sprint in two weeks or two months isn’t important. What is important is that you stick to it-even it means, and it usually does, modifying your work to fit the time window. For the Agile-challenged engineer this is a blasphemy akin to chopping eight inches off the left side of the Mona Lisa. They see their software as a whole that isn’t finished until it is finished. Scrum’s timing boxing technique is admittedly arbitrary. The creative process cannot be bounded by deadlines without losing its integrity. At least that’s their argument. I see it differently, and can give lots of contrary arguments, but rational argument has little impact on personal preferences. These engineers find sprinting to be stressful where the Agile-friendly engineer finds sprinting to be liberating.

At the end of the day it’s a waste of time to force people to do something they simply don’t want to do. Unenthusiastic people need to find something they are truly enthusiastic about. There is nothing wrong with the Agile-challenged. They are master craftsmen, they are very smart, they are mavens, and they are artists. So what is an Agile organization to do with them?

The first thing to do is get them out of Agile. These engineers are wasted on Scrum and will simply quit and make a lot of other miserable on their way out. Smart unhappy people can make a lot of mischief!

The second thing to do is to create a lab, give them a mission, and turn them lose. It’s interesting to note that many of famous labs in the history of computation have been notoriously bad at implementing and productizing their creations. Xerox Parc invented most of what we use when we use personal computers yet it is in decline. It’s too bad that Xerox Parc didn’t merge with Apple or Microsoft, organizations that are good at creating markets and feeding them incremental improvements. Instead Apple and Microsoft developed R&D labs of their own so that they have a never-ending fountain of new ideas and home for their dreamers.

You can’t and shouldn’t manage the lab with Agile techniques and you must not staff it with Agile-friendly engineers. The engineers who thrive under Agile get lost in lab, their ideas can’t compete with the Leonardos and Michelangelos.

In the end the secret to managing the de-motivated is finding a place for them in the organization where they are motivated to be. Agile is great but it cannot be applied to all problems.


2 responses to “Managing the De-Motivated”

  1. Andrey Fedorov Avatar
    Andrey Fedorov

    I used to believe #4, but an anonymous blogger changed my mind:

    Creative success is taking what’s available and rising above that. The “that” doesn’t matter, you’ll only be credited with success if you go beyond it. Maybe Picasso had good canvas but he had to transcend an entire way of painting, that’s what made him great, not the physical painting itself. Otherwise we wouldn’t be buying prints.

    This points to another problem, though: if Picasso was looking to “transcend an entire way of painting”, he wouldn’t be interested in most programming work, which is the equivalent of working on murals on behest of someone else’s vision. That’s the right vision, because there’s nothing left to do in painting, right? I wonder if Picasso could have explained his intentions convincingly enough to work at the painters’ equivalent of a research lab…

    But more importantly, from the managers’ perspective, for each Picasso, how many bullshitters are there who will waste R&D efforts spinning their wheels? How do you tell the two apart?

    Can they tell themselves apart?

    From Picasso’s perspective, if he, by some coincidence ended up being the crazy uncle who couldn’t stop drawing pictures, was he really crazy, or just unlucky? Alan Kay has been fantasizing about the dynabook since the 60’s, the OLPC self-ploded, and it took a lot more than fantasizing to implement it as an iPad.

    And either way, how good would an iPad be without Apple’s “revolutionary” brand, impeccable taste, and brilliant marketing? “Software as a service” – also around around since the 60’s, but it took Google’s accidental ad goldmine to get the people who understood it the resources to make it possible just at the right time.

    All that aside, investing in people over ideas (and certainly over process) certainly seems wise. Being agile (the word, not the process) means understanding what people want, what they need, giving it to them, and expecting results (even if those results don’t end up having market potential).

  2. pav Avatar

    Thanks for comment–really more like a guest blog post 🙂

    In a nutshell I don’t think Genius can or should be managed. At best it can be directed (Hey Picasso, what about yellow?) The Agile “game” is not for Alan Kay and his ilk.

    At LimeWire we have Agile for engineering and the “Pony Farm” for R&D (Picasso, Alan, et al.) On the Pony Farm you prototype ideas, release them to the wild, and see which ponies come back. Eventually the awesome ponies are tamed and implemented into LimeWire.