Thoughts On Software

Posts

20 Reasons Why the Traditional Performance Review For Software Developers is Bad For Business

1. Undermines Teamwork Teamwork suffers when your incentive system primarily recognizes individual achievement. Collaboration is key to producing quality software. 2. Undermines Autonomy & Purpose Feeling like you're performing to get a carrot (raise or promotion) or avoid a stick (termination) undermines an individual's sense of autonomy and purpose which is strongly tied to intrinsically motivated behavior. It is critical to have intrinsically motivated people in creative problem-solving jobs like software development. (See previous posts) . 3. Damages Trust Between Manager and Subordinate It reinforces the idea that the manager's role is primarily to evaluate and critique. Instead of being on the same team working toward common goals, the performance review clearly places the manager and subordinate in antagonistic roles on opposites sides of the table. It reinforces the worst boss stereotypes. 4. Not Objective No one has found a good way to quantify a so...

Managing for Motivation Not Efficiency

Beginning in the era of the industrial revolution, managers were trained and encouraged to focus on increasing productivity though increased efficiency. This trend has continued into modern management with techniques such as Total Quality Management that focus on identifying and eliminating waste in a system. It can't be denied that this approach can be very effective when applied to a consistent, repeatable process like a manufacturing assembly line. However, this focus on efficiency is inappropriate and even detrimental when applied to creative, problem solving activities like software development, and unfortunately these lessons learned from manufacturing dominate the way software development is organized and managed. It even influences some of the practices taught under the banner of Agile. This fallacy, that software development can be organized into consistently repeatable processes, was the assumption of the waterfall methodology. Software developm...

The Power of the Tribe

Organizations ignore the power of the tribe at their own peril. In our earliest primitive state, a human being had almost no chance of survival on his own. It is only as a group that we thrive. So it is no surprise that scientists believe that the primary purpose of our large sophisticated brains is social interaction - the complex glue that holds groups together. These instincts around our tribe are hardwired in our brains. They can motivate us to unparalleled levels of self-sacrifice and loyalty or drive us to irrational conflict and mistrust. There are almost no boundaries to the lengths that we will go to protect and sustain the people we consider to be a part of our tribe, and almost no depths to which we won't sink to eliminate threats from opposing tribes. It is the root of obsessional loyalty to professional sports teams, as well as murderous gang violence, and ultimately war. It is no surprise then that organizations from the m...

Intrinsic Motivation

"Carrots & Sticks are so last Century. Drive says for 21st century work, we need to upgrade to autonomy, mastery and purpose." So says Daniel Pink as a summary of his best-selling book Drive that has popularized the astonishing research into the nature and power of intrinsically motivated behavior. How can a software development organization apply these principles to create a competitive advantage? Pink popularized the research of many behavioral scientists, particularly Edward L. Deci, which began with his landmark publication Intrinsic Motivation published in 1975. Pink uses the Open Source software movement as an example of the power of intrinsic motivation. In Open Source projects, we see people creating world class software, such as Linux, without any extrinsic motivation - no carrots (no financial incentives) and no sticks (fear of being fired). Something from within - something intrinsic - drives them to these creative heights. (If intrinsic motivation seems to...

Software Development Like a Restaurant Kitchen?

Maybe it's because of the relative youth of the profession of software development that we seem to be constantly looking to other, more established, professions for analogies as guides to how we should organize and manage our work. If taken too far, I think this type of comparison is detrimental such as the numerous analogies often made to the building trade - e.g."building software", and "software architects". There may be a few similarities, but overall the work is so different that adopting terms and practices from construction often leads to misunderstanding and frustration. What about a restaurant kitchen as an analogy for a software shop? Is there anything we could learn? I worked in a large restaurant as a waiter in college and had the opportunity to see how a traditional restaurant kitchen is structured. It is very hierarchical with distinct and well bounded roles. At the bottom of the ladder are kitchen assistants. These are minimally skill...

Uncertainty

I recently listened to an interview with Dan North in which he discussed his efforts to encourage organizations embrace uncertainty. What I took away was the idea is that there are some things that are just unknowable and that building processes that give the appearance of certainty is wasteful and dangerous. For example, elaborate planning processes whether they be in the Agile or Waterfall camp often yield the appearance of predictability, but in reality, major risk factors are often left undiscovered. Putting more and more effort into refining these processes gives the appearance of improved accuracy, but what we really want is effectiveness. For example, we may spend hours haggling over story card points, when the biggest risk to a project - a key contributor is looking for another job - is left undiscovered and unaccounted for. As human beings we generally dislike uncertainty. We rely on our understanding of cause and effect to survive. When primitive cultures d...