In Search of the Motivated


I’m doing a lot of hiring right now. So much that I’ve had to form a hiring scrum and treat it like an engineering project. The scrum is doing a great job. We now have a systematic way to write job descriptions, assign interviewers, evaluate resumes, perform phone screens, and conduct interviews. All this to find the needle in the haystack: The motivated individual.

There are other requirements: The ability to code with grace and manage with charm is appreciated. Good manners and excellent communication skills a plus. Experience with open source, P2P networks, and super-scalable n-tiered web stacks don’t hurt your chances.

But all that means nothing without the man on a mission to drive it (or woman on a mission. I hear there are female programmers out there. There should be a lot more. Something is wrong with the world when less than 25% of programmers are women. We need to fix that).

Why is motivation so important? Let’s turn to the Agile Manifesto to find out. Principle 5 states:

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

This principle is in the form of a imperative. No reasons are given and a lot is asked of management. Shouldn’t the framers of the manifesto give us a few hints as to why we chickens should obey this command? It’s almost as if they expect us to know the basis for this principle a priori. Anyone with even a few months of experience in software development knows why the motivated individual is so important that you give him (or her) the keys to the executive bathroom, a company car, and the employee-of-the-month parking spot:

  • Unmotivated people, no matter how good they are at coding, managing, manners, communication, open source, p2p, or n-tier architectures get nothing of consequence done.
  • Motivated people, work wonders no matter how poorly they code, manage, or communicate! And if you find highly motivated l33t hax0rs then the world is your osyter iPad.

I don’t know of any organizations that don’t strive to hire the motivated. They put up all sorts of road blocks to filter out the underachievers. 12 hour interviews, brain teasers, reference checks all designed to make sure you really want the job. One startup I worked at would call applicants late on a Friday and ask them to prepare a presentation over the weekend and present it early the Monday morning as part of the interview process for salespeople. This was a brilliant filter. Only those  hunter/farmers who really wanted to work for the company would put up with this kind of hazing.

But here’s the rub: That same startup did not follow the rest of the Agile plan: They did not give the newly hired highly motivated salespeople the environment and support they needed nor did they trust them to get the job done. Nothing is more frustrating to the motivated than to be treated like slackers and held on a short leash. There was high turnover and poor sales. Management had to result to clever motivational hacks: Contests, awards, and threats to keep sales on track.

But every good manager knows the motivated out performs the unmotivated 10 to 1. The motivated need only a license to kill. For the motivated the journey is the reward.

Human sacrifice, dogs and cats living together… mass hysteria!

A product owner and his developer

What can we learn from Dr. Peter Venkman about the Agile development process? It’s true that Venkman was the less technical member of his team. Clearly Dr. Egon Spengler was the blue-sky researcher while Dr. Ray Stantz was the practical engineer.  But Venkman brought a lot to the table: Charm, business acumen, and the ability to spot an opportunity. In short, Venkman was the product manager.

Egon and Ray focused on arcane reference books and ecoplasmic gadgets. It was Venkman first used their technology to get results in the marketplace—or at least meet girls. Venkman was usually critical of Egon’s and Ray’s “out of the box” ideas but once won over Venkman stood behind his team and rallied them when the chips were down (as when Gozer the Destroyer took the form of the Stay-Puft Marshmallow Man).

Perhaps Ghost Busters is not a textbook example of product management in action but it’s a funny movie and I’ve worked with far less amusing product managers than Bill Murray’s lovable but obnoxious Venkman.

For all his faults Venkman obeyed the 4th principle in the Agile Manifesto:

Business people and developers must work 
together daily throughout the project.

Venkman did not separate himself from his team:

  • He lived in the Ghost Busters HQ (Hook and Ladder 8 ) with Egon and Ray.
  • He took his turn driving the ambulance that served as the Ectomobile (Ecto-1).
  • He even wore the overalls and shouldered a Proton Pack.

Clearly Venkman, Egon, and Ray worked together daily as equals on each project, whether it was ridding a fancy hotel of a noisy poltergeist or cleaning ectoplasm off a hapless victim.

Too often in semi-Agile development processes product management (the business people) function as the boss. They make the decisions. They are the “decider guys” stepping into the problem space for a moment, asking for the summary, and making a quick decision without context or technical expertise (like Walter Peck from Environmental Protection who demands that the Ghost Busters shutdown their “storage facility” and inadvertently releases hundreds of ghosts into Manhattan).

The problem here is that software development is a complex, subtle, and sophisticated problem. It doesn’t sit well with summaries and snap decisions. To really make a good software product decision you have to get into the details. You don’t have to be a programmer but you do have to live with one. Any complex, subtle, sophisticated process benefits tremendously from people who work so closely together they know each other’s strengths and compensate for each other’s weaknesses.

To ensure the cats and dogs are living together I recommend the following four “Make Sures” (as usual based on the bitter pill of experience):

  1. Make sure the product owners (product managers, business people, what ever you call them) sit with the engineers. It’s good if they eat lunch with them and go out for beers once a week.
  2. Make sure the product owners and engineers understand that they are all pigs. The product owners are not “management” and the engineers are not “labor”. This means product owners must participate in the development process in real time.
  3. Make sure the roles and responsibilities of the product owners and development leads are clear. PO’s own the backlog and priority. DLs own the sprint backlog and technical strategy.
  4. Make sure the team makes all decisions though rigorous debate. There is always a business trade off and a technical trade off that has to be resolved—If not you’re not innovating. Software development is not a democracy and everyone does not have to agree. But the best path, not the most obvious one, has be discovered.