Thursday, April 14, 2011

Ask why, don't accpet non-answers

There is an old 1970’s psychology study about monkeys and learned behavior. This blog tells it simply and if you can make the time, read and reflect on it.

http://blogs.sun.com/krabhishek/entry/being_monkey_a_sad_reality

The gist is, I believe we are a lot of new monkeys and occasionally we get beat by the other monkeys. It is going to happen and I don’t know of a way to avoid it. When this happens, we must ask the other monkeys ‘why’ and not join the mob because ‘that is what we do’. Do not accept that as an answer.

This means we take some beatings, so be it. We will live and come out the other side stronger for it. Eventually we will get our banana. Go for the banana when there isn’t a real reason not to and always question 'why'. Remember that forgiveness is often easier to obtain than permission.

The scientific study is a real thing, not just a story: http://wiki.answers.com/Q/Did_the_monkey_banana_and_water_spray_experiment_ever_take_place



Tuesday, June 23, 2009

Adhocracy

Today I had a flashback. It happened while a senior developer was telling me why something simple was hard and time consuming. This particular developer is brilliant and he ended his story with, 'we are a bureaucracy you know'.

As it turns out, I don't know and I reject the reality that a web shop can be a bureaucracy. We can't replace intelligence with a book of rules and steps. Web shops cannot afford to lumber along as large corporate agencies, arguing over formalities that smother innovation and progress. Internet developers must, for necessity of survival, function closer to something like an adhocracy.

The moment I heard the 'b' word exit the developers vocal chords, I remembered a former manager hanging a hand drawn picture on his door. It was a picture of a garbage can with the words "Put your process here" over it.


At the time, I didn't fully grasp the brilliance of this simple drawing. My challenge to each of you this week is to use wisdom over rules, reason over procedure. Remember this simple, line-drawn picture as reminder to avoid displacing thought with protocol.

Tuesday, October 7, 2008

Allowing individual accountability

Today I failed and it is nothing new. I was late for a meeting, I spilled some coffee and didn't answer all my email. I fail everyday and so do you. Most of the time, personal failures are small and insignificant micro level failures like forgetting your car key. People move on, learn from the mistakes and improve. In rare instances, individuals fail at a macro level and must deal with consequences of those failures via bankruptcy, divorce, community service, etc. Macro failures are generally the result of many micro failures compounded.

Organizations fail regularly too. Unlike infrequent individual macro failures, corporate failures tend to be bigger, frequent, costly and noticeable. It seems odd to me that intelligent, responsible people who avoid macro failures individually, get together and blow it as a team. I believe this behavior has ties into accountability.

Individuals generally accept responsibility when they don't make their car payment. However, when a corporate team project fails it is a different story. Those same people are found busy writing lists of what was done wrong for the third time or standing at the water cooler mumbling about how they pointed out problems from the beginning. It sounds like there is a lack of accountability in workplace. Well, there is but ask yourself these questions:

Why do talented people function well as individuals but fail more frequently in teams? Further, why do they accept accountability for personal mistakes but reject accountability as a group?

Those are complex questions to answer but this I am certain of, individuals will not feel accountable when they felt powerless to influence the outcome. Once people are given power, they become accountable. Ken Blanchard wrote, "Empowerment means you have the freedom to act; it also means you are accountable for results."

Surely it is to everyone's benefit if employees take the kind of ownership over their work that they take in their personal lives. To engage people at that level, there is an intrinsic need for people to feel control over their work, to have input and not feel controlled.

Friday, July 4, 2008

From the ashes of failure

Previously, I wrote on fearing failure for lack of trust. Failure is a seemingly endless and interesting topic but since I've been diagnosed with NADD (thanks Rands), I doubt I'll write about it beyond this post. To wrap this topic up with a nice little bow, it seems useful to discuss how to leverage failure into success.

A strong team will self organize, Agile development is generally founded on this concept. So why then does a highly skilled and motivated team fail? Well, that is complex but a few common reasons for failure include:
  • Fear of saying no to customers or executives. Nobody wants to appear unskilled, slow or inadequate.
  • Unrealistic goals. Tight time lines from hard milestones, many known risks, incomplete planning and undefined issues are all indicators of unrealistic goals.
  • Poorly defined goals. When project goals are unclear and requirements are subjective, your running full speed at a brick wall.
  • Poor estimation skills. Software is more art than science at times and even the best, brightest and most experienced developers commonly fail to estimate task level of effort. It is always a good idea to remember the definition of an estimate.
  • Lack of cohesion in the team.
  • Wrong skills on the team.
  • ...
Once failure has occurred, the only way to improve is to own it, dissect the situation and share it with others. Seriously, developers have to get over themselves for this one. This is one time ego's can't be allowed to win. So, how do we ensure failures are not repeated in organizations? The steps are relatively easy but execution of them is progressively challenging:
  • Identify. Do a full autopsy of the successes and failures as a team. Get your team in a room and walk through the project from inception to post release. Some companies call these meetings recaps or postmortems. It doesn't matter what you want to call them as long as you do it. Michael Greer has a good set of primer questions every team should ask themselves.
  • Document. Spell important issues out in painful detail. This is the pitfall feed back to use to avoid problems and the successes you must actively try to recreate in your future projects.
  • Share. Broadcast what you learn so others uninvolved can learn by proxy.
  • Support. This is the most important step, it is where the rubber meets the road. If you learned that some of your basic process is misinformed, you need support from other teams and management. If you can't get support for change, you will have to become super creative or you will be doomed to repetition. In my experience, this is where organizations fail to learn the most. We make mistakes, identify, document, share and then fail to get actionable support. Lots of lip service for change but not real change. So we lather, rinse and repeat while frustrations across the organization mount.
I've found that there are ancillary actions that help organizations avoid serious failures as well. First, retain your employees. Employee turn over will condemn the organization to repeat mistakes. I'm not suggesting you retain everyone, just the people that matter. From where I am sitting, I don't know who that is in your company but you do. Second, protect historical knowledge through documentation. I don't mean 100 page MS-Word documents, I have yet to see that work. Tailor something to work for your organization. I have always found faq-o-matics and wiki's encourage frequent updates and collect useful data. Finally, cross-pollinate by mixing up your team members between projects. This allows people with recent knowledge to seed new teams and supports the idea of sharing project learning.

Friday, February 8, 2008

Failure, fear and trust

Some say failure is good. I disagree, I hate failure. Failure is depressing and demoralizing. Even though I don't believe failure is good, I believe failure can be healthy but only if learning occurs from it. Failure without learning is useless. Repeating failures is insane.

Lack of failure is an indicator of risk avoidance, people not willing to reach for something more, unable to innovate. Executive rhetoric frequently espouse the virtue and acceptance of failure but even when people believe in the virtues of failure, organizations fear and avoid it. The reason for fear of failure is simple: trust

Organizations lacking trust will be mundane and develop a host of problems. Trust isn't bought, it isn't negotiated and it isn't forced out of people. Trust is hard earned currency and can be spent through disagreement or lost by subversive or contradictory behavior and lack of transparency.

Leaders embody trust by being reliable, consistent, competent, available, honest, loyal, open and supportive of individuals in their organizations. Productivity and job satisfaction can be high even in the face of other organizational problems such as low pay or overall company stability. Organizations that have trusted leadership can do amazing, innovative work.