Category Archives: Mindset

Is appreciation the most underappreciated tool in your toolkit?

In today’s times when budgets are tight, promotions are slow and the amount of new product development opportunities rare, it is not easy to motivate your team members. As a project manager, you don’t have so many tools or resources at your disposal to engage your team members in a meaningful dialog to enhance their motivation, intrinsically or extrinisically. Really?

Most people (and people managers) believe you can’t really motivate your team members if you don’t give them obscene salary hikes every year, award annual bonuses that put shamed Wall St bankers to shame, promote them every second year and throw lavish parties every month! Sadly, they can’t be any further from truth. Most of us don’t realize (or perhaps, don’t want to realize) that the most effective means to motivate people are two simple things: match people’s assignment to their passions, and appreciate them for their efforts. And none of them require a dime :). Granted that we often can’t match people’s assignment to their passions (though most managers don’t even make a reasonable attempt and a genuine communication when that can’t be done), in this blog post, I want to talk about the second one. To appreciate someone needs no capital budget, no planning, no strategy, no right timing, no resources, no MBA degree, no technical expertize, no PhD in creative writing, no big slogans, no special finesse, no world-class oratory skills, no big-banner problems, no game-changing events, no ‘senior-enough’ title, and most importantly, no approval from anyone! All it needs is an open mind and a geniune will. And who says an appreciation has to be in an email, with a gift voucher, or a memento at the next town hall or limited by some monthly quota on number of appreciations possible? I think the most effective appreciation probably needs no more than 5 minutes (or even less!) of genuine conversation to let the other person know what a sweet job they have done and how you feel about it. Yes, that’s it. If your words are genuine, they could change someone’s life like never before. Read this small story from The Simple Truths of Appreciation, which is a great example of how it changed someone’s life and pretty much set him up for lifelong success!   

My friend, Bob Danzig, has an amazing story. Simple words of appreciation and encouragement changed his life. Bob was in five foster homes during his youth, and said he spent his childhood trying to find someone to love and appreciate him.

When he was nine years old, he had a new social worker. He said after she had done all the paperwork to move him to yet another foster home, she sat him down, looked him directly in the eyes, and said, “Bobby, I want you to always remember these words: YOU ARE WORTHWHILE!”.

Bob says that no one had ever said anything like that to him, and each time they met, she repeated those words. They became an affirmation of appreciation that he heard over and over again in his head.

Bob graduated at sixteen, not because he was smart, he says, but because he got mixed up in the system!

He soon took a job at the Albany New York Times as a copy boy, and his very first boss was a woman named Margaret. After he had worked there about six months, Margaret called him into her office one day and asked him to sit down. He thought for sure he was going to be fired! She looked him right in the eyes and said to him, “I have been the office manager for 15 years – I have been observing you – and I believe YOU ARE FULL OF PROMISE.” Those words, on that day, gave him permission to aspire.

Those two positive messages of appreciation played over and over again in his head and ultimately gave him the courage to be the very best he could be. Sixteen years later he became the Publisher of the Albany New York Times, and seven years after that, he became CEO of Hearst Newspapers, one of the largest newspaper companies in the world; and he credits it all to those simple words of appreciation and love. What a wonderful example of how little gifts of appreciation can make such a difference in a life!

What a powerful and compelling reason to make that small bit of effort to reach out to a fellow human being’s craving for appreciation! I especially liked the words “permission to aspire”. Perhaps every one among us is waiting for someone to give us that permission to aspire that will change us forever, set us free to dream and make us feel so worthwhile. Even if we ourselves haven’t got such ‘permission’ from someone yet, it doesn’t stop us to give such ‘permission’ to others! Like the great Gandhi said, “Be the change that you want to see”, why not take that initiative today and be the one friend, the one manager, the one co-worder, the one subordinate, and most importantly, the one human being who is the biggest fan, greatest cheerleader and a die-hard supporter of every well-intentioned initiative, every brave effort and every single result, howsoever small it might be. After all, what goes around, comes around!

So, as a manager, have you given the permission to your team members to aspire? Or, is appreciation the most underappreciated tool in your toolkit?

Our methodology is 100% pure, our result is another thing!

What is worse then an anarchy ? You might say that is the absolute abyss, but I think blind allegiance is even more dangerous (and that includes following the letter but tweaking the spirit – things like ‘creative accounting‘ or its parallels in every field). Anarchy at least allows for things to become ‘better’ in order to survive – whether it is the idealogy, resistance, or even musclepower, or any other ills (and hopefully at some point, social forces of constructive destruction take over). But in a land where unquestionable compliance and blind allegiance rule the roost, IMNSHO, is like a terminal patient off the ventilator support. When people are on their deathbed, they don’t regret things that they did but much rather the things they did not do!

In project management, life is no less colorful. We have process pundits (read “prescription police”) shouting from the rooftop with a megaphone on how heavens will strike them bone dead with lighting if they ever as much as strayed from the ‘standards’. When projects are being postmortemed, we don’t often ask what or why the project did something that they did, but why they did not do things that they did not do. And quite often, you find answer in the map itself – because the map did not factor-in those conditions that were actually encountered on the terrain, the blind followers just followed the Pied Piper and danced their way into the river of death. What a terrible waste of human talent.

Why do we get stuck with methods so much that our result-orientation takes a back seat ? I think there might be many answers, but some that deserve merit:

We fall in love with ‘our’ methods

Let’s face it – introducing a new methodology in an organization, or a team, is not easy. People have their favorites, and it already is a fairly serious political game to get such groups to a decision (whether or not there is a consensus). After you have sold the executive sponsor to go for a particular methodology, you have to now somehow sell to middle-managers and the teams – without their support, you are toast. Sometimes you might have legitimate power (“position power”) to thrust the decision down their unwilling throats, but most often that doesn’t work anymore (even in jails!). So, you have to use your charm offensive to somehow make the other stakeholders believe that this methodology is the god’s greatest gift to mankind, and how it will take their next project to unprecendented glories. If only that were half-true! What follows next is a qunitessentially Bollywood storyline – the project is in tatters and the project manager and teams are exhausted and some even ready to bail-out. You go and put some more pressure on them, ask for weekly reports to be given on daily basis and take away even more productive hours into endless meetings to discuss yesterday’s weather. In short, we do everything but realize that our methods might be wrong…perhaps…for a change? Most people don’t get it, but sometimes, the smarter ones do get it. But by then, they are so much neck-deep in love with their methods that they can’t afford to take most obvious and the only correct decision – take a U turn, and admit their mistakes. Our professional ego checkmates us. Falling in a bad relation is bad, staying in it even after realizing one’s folly is worse.

We believe blindly in marketing claims

These days, there are dozens of marketing gurus, each extolling the virtues of their methods. In a way, it is like entering a village market – each vendor selling the same portfolio of vegetables, but each has to ‘differentiate’ from his neighboring vendor, and hence some make wild performance claims, quite often unbacked by any reliable data, and almost always trusted by gullible buyers at face value. So, some of us just go by the tall claims in glossy marketing brochures. You don’t believe me – tell me, how else you can explain those knowledgeable investors getting duped by Madoff’s elaborate Ponzi scheme in this age and day! Tell me how most banks fell for easy money in the subprime market. And if we were to assume, for a moment, that everything these marketing brochures said was indeed true, how come rest of the world had not quite figured it out already ? I think intelligence is not the elite preserve of a learned few – the rest of us lesser mortals also deserve to be treated with some professional respect that we can figure out what works and what doesn’t. In a previous blog, I once did an interesting analysis of one such marketing claim Blame your flaccid developers and your flaccid customers for your poor quality products !.

We are are too scared to experiment and take sensible risks

This is a real classic. Many organizations, certainly many more than we think there are, are so stuck in ‘command and control’ that they create a system where compliance is rewarded and creativity is shunned. This might work well in some industries or companies, but certainly doesn’t work for most of us. A beauty about such companies is that such outright disdain to new ideas might not just start and end at the top – depending on how deep-rooted the indoctrination is, it might be running in every employee at all levels. In the zest to display unflinching loyalty and to project oneself as a corporate citizen second to none, many employees (and many managers) simply abort new ideas because that might threaten the ‘status quo’ and makes them look very bad in front of the powers that be.

Because everyone else is doing it

This is groupthink at its best. Just because every Tom, Dick and Harry about town is doing it, I must also adopt (simply continue following mindlessly) the latest management fad. For example, we have all heard of (often unverified) stories how investors in the bay area during the dotcom boom era would only look at business plans that had an India component. Just because everyone is doing offshoring might not be good enough why I should also do it. Similarly, just because everyone I know is into Agile, does that make a strong case for my business also ? I think we should stop and think before succumbing to trade journals that routinely publish such forecasts and doomsday prophecies.

We are looking for easy cookbook solutions

Let’s accept it – some people are just plain lazy, or just too risk averse to do any meaningful research on what works for them. Instead of investing in figuring out what’s best for them, they are looking for some quick wins, some jumpstart, some fast food, some room service, some instant karma. They believe they can learn from other’s mistakes (which is definitely a great way to learn – definitely a lot better than not learning from anyone else’s mistakes!) and sometimes they might be successful, if they have copied the right recipe, but very often, that only results in wrong meal to wrong people at wrong time. What people don’t realize is that every problem is cast in a different mold, and whatever one says, there simply is no way one could airlift a solution and drop on the face of a second problem – in its totality – and expect the solution to work. Similarly, there is no way a cookboo solution might work. For example, Agile was designed around small collocated teams that have so high communication among itself that trust replaces formal contracts and communication replaces documentation – I mean they thrive on such a high-energy environment. But, sadly, simply to prove that Agile can fix any problem in the world, management consultants have stretched (should I say ‘diluted’) those very Agile princinples and they now try to forcefit those methods on a distributed, large team, that often has a heterogeneous ‘salad bowl’ culture than a homogeneous ‘melting pot’. So, you land in the situation that just because it worked for some random cases, some among us just naively believe it could work for our random case too. Does it get any more smarter than this 🙂

We believe compliance leads to repeatable success

Standards are often treated like insurance against catastrophes – both the termites and the tornadoes types (think of tornadoes as something that just comes out of the left field and kills a project overnight – like a meteor hits a neighborhood, and think of termites as slow and steady erosion that goes on and on and goes undetected until the time the damage is complete, comprehensive and beyong damage control). They ensure that no one deviates from the beaten track and tries something adventerous (without getting rapped on the knuckles), because that could lead to unpredictable results. And we all look for standards and certifications – ISO-this and ISO-that, CMM and CMMI (and the sunsequent obsession with all other 5-level models), Scrum, PMP, PRINCE2, MBA, PhD, IEEE, …so much so that even in the field of creative arts, there are schools that specify what creativity is allowed and what is out! There are success formulas for Bollywood movies – rich girl meets poor boy and the anti-social forces strike boy’s family. Eventually, our hero saves the day. Similarly, in Hollywood movies, it has to be the hero saving the nation from external threat (very often, coming from the space). In software development, ISO championed the cause of non-negotiable compliance and blind CMM practitioners only perfected it. Agilists were born out of the promise to create a world free of compliance, but it seems they have also ended up growing their tribes with their own mini-rules that give an instant gratification by useless things like Scrum Test to massage one’s ego that my Scrum is more Agile than your Scrum! Do, if you score a certain score in the Scrum Test, you are almost ‘guaranteed’ to get some x level of productivity improvement! Does that remind you of yesteryears, or does it make the future look more scarier?

Conclusion

Human behavior never ceases to amaze. For every one rational thinker, the world has to produce thousands of blind followers. Our schools and colleges teach us to learn the knowledge but they don’t always teach us how to convert it into wisdom. So, when we reach workplace, we are deeply apprehensive of trying out new stuff. We are excellent followers, but simply shudder at the mere thought of questioning status quo. We often behave like the monkey whose hand is stuck in the cookie-jar but refuses to release the cookies even when it knows that the only way he can extricate his hand out of the jar is without cookies. When those workplaces ignore result-orientation and only worship the compliance, the story only gets murkier. Think of a state where compliance is handsomely rewarded and questioning it seen as full and frontal attack, and its timid citizens are only too happy to oblige. They think a lifetime of blind obedience to methodology is far more superior than a moment of experimentation, even if leads to bad results.

After all…our methodology is 100% pure, our result is another thing!

(Inspired by a slogan on a tee: Our vodka is 90% pure, our reputation is another thing. very inspiring, indeed :))

Does your project management methodology lets you free think?

Its not about the project management methodology anymore. Frankly, it never was, even though it has triggered off some of the most senseless wars in the history of project management. Starting with Frederick Winslow Taylor‘s Scientific Management to Henry Ford‘s assembly-line based mass production system and eventually landing in a flavor-of-the-day methodology (CMM, ISO, Agile, XP, Scrum, Lean, Kanban…and add your favorite one here), project management community, especially in software field, has seen it all…and still counting! All these project management methodologies have been eulogized as silver bullets in their heydays (and some still continue to be worshipped as we speak), and have subsequently been improved upon by the next wave of innovation driven by ever-evolving business needs, state of technology and the sociological changes at the workplace. However, each predecessor has been uncharitably rejected and unceremoniously relegated to trash by every successive methodology champs. However, that doesn’t seem to have stopped project woes, certainly not – going by the claims made in their marketing brochures :). So, whom are we to trust – the overzealous champs or their ever-evolving methodologies ?

For most practitioners, novices and experienced folks alike, project management methodology became this one large target to shoot at, the advertisement to get the project deal, the crutches to hold the project on to, the lame excuse against change in project specs, the insurance against failures, perhaps the raison d’tre for project managers ? “Sorry, the manual says do it this way, we can’t change that”.The process handbook says we can’t take any changes anymore – tell customers to wait until the next release which is just six months away”. “You are not approved to prototype, so stop that effort”. “Our company’s org structure doesn’t allow an engineer to manage the project – the risks are too high”. “Our metrics are within the control limits, so I don’t understand why engineers fear a project delay”. Goes without saying, they come in all hues.

Little did we realize that the “problem” was a moving target. We continued to evolve our solution blissfully unaware that the problem was also upgrading itself. Every new fix has led to a newer generation of problem that seems to have outpaced the development of solutions so far, and I see no good reason why we will ever have a perfect solution for every type of problem. So, it doesn’t amuse me when people on Agile / Scrum discussion boards try to indiscriminately apply those principles to just about every type of problem under the sun, and then when, predictably, things don’t work, they blame that Agile / Scrum is not being applied in its spirit. Have you ever seen a project manager so baptized that he won’t think beyond the book ? I think those blind preachers are just living like a frog in a well.

Try to imagine this scene pictorially in your mind: You are walking down the road with a map in hand. You see a puddle of water that’s not on the map. What do you do ? Agilists will have you believe that waterfallists will merrily walk through (or drown through, depending on depth of the puddle) whereas Agilists will “inspect and adapt” a sophisticated term for “trial and error” (which is, by no means, a bad term). So, they will step into the puddle a little every time, and based on the results of that, determine if they want to go ahead or change the course. I will ask you something: forget the books (its actually much better if you burn them literally), what will you do if no one told you anything. You will simply avoid it. I think humans are infinitely more capable of acting on their own, especially in matters of their own interest, that they don’t require anyone to tell them what to do. So, let’s not try to be their parents. Right? Or wrong?

In my small world, we are all grown-ups who have a right to view the problem with our own private lenses without owing anyone an iota of apology about the unique problems we alone face and struggle with, whether we understand or not. And we are free to blend any major or minor, known or unknown, new or old, and right or wrong methdologies to solve our own problems. As real-life practitioners solving non-glamorous, project management template-agnostic problems, we don’t need to display our camarederie and unflinching loyalty to some obscure methodology whatever anyone says. After all, they don’t sign your paychecks, but your customers do! Your solutions should only be aligned to what your customer wants – and not what a methodology wants!

So, it is simply not about methodology. If anything, its all about:

  • Refusing to get ringfenced by a process document, howsoever great that might be
  • Outrightly rejecting the idea that things can’t be improved any further
  • Optimizing things that can be done better than in the past when a given process was written
  • Eliminating deadwood from a process simply becuase something makes no sense
  • Embracing change because your problems were not designed keeping your process in mindIn fact, it is not even about a project anymore. If anything, it is about your fundamental right to free thinking. But then, my view should not come in your way of your free thinking :).

So, think again….does your project management methodology lets you free think?

Where is the shark in your cubicle ?

A friend sent this story sometime back:

The Japanese have a great liking for fresh fish. But the waters close to Japan have not held many fish for decades. So, to feed the Japanese population, fishing boats got bigger and went farther than ever. The farther the fishermen went, the longer it took to bring back the fish. The longer it took them to bring back the fish, the staler they grew. The fish were not fresh and the Japanese did not like the taste. To solve this problem, fishing companies installed freezers on their boats. They would catch the fish and freeze them at sea. Freezers allowed the boats to go farther and stay longer. However, the Japanese could taste the difference between fresh and frozen fish. And they did not like the taste of frozen fish. The frozen fish brought a lower price. So, fishing companies installed fish tanks. They would catch the fish and stuff them in the tanks, fin to fin. After a little hashing around, the fish stopped moving. They were tired and dull, but alive.
 
Unfortunately, the Japanese could still taste the difference. Because the fish did not move for days, they lost their fresh-fish taste. The Japanese preferred the lively taste of fresh fish, not sluggish fish. The fishing industry faced an impending crisis! But today, it has got over that crisis and has emerged as one of the most important trades in that country! How did Japanese fishing companies solve this problem? How do they get fresh-tasting fish to Japan?
 
To keep the fish tasting fresh, the Japanese fishing companies still put the fish in the tanks. But now they add a small shark to each tank. The shark eats a few fish, but most of the fish arrive in a very lively state. The fish are challenged and hence are constantly on the move. And they survive and arrive in a healthy state! They command a higher price and are most sought-after. The challenge they face keeps them fresh!
 
Humans are no different. L. Ron Hubbard observed in the early 1950’s: “Man thrives, oddly enough, only in the presence of a challenging environment.” George Bernard Shaw said: “Satisfaction is death!”
 
If you are steadily conquering challenges, you are happy. Your challenges keep you energized. You are excited to try new solutions. You have fun. You are alive! Instead of avoiding challenges, jump into them. Do not postpone a task, simply because its challenging. Catch these challenges by their horns and vanquish them. Enjoy the game. If your challenges are too large or too numerous, do not give up. Giving up makes you tired. Instead, reorganize. Find more determination, more knowledge, more help. Don’t create success and revel in it in a state of inertia. You have the resources, skills and abilities to make a difference.
 
Moral of the story: Put a shark in your tank and see how far you can really go!

Not sure if you agree with such extreme measures to push people (or is it motivate people ?) to achieve the impossible or even accomplish everyday tasks, but I think there is an important message in the story. Quite often, we underestimate the power of ‘positive pressure’ (some might prefer to call it a negative pressure, though) dismissing it as a constraining force rather than an enabling one. However, there might be situations where such tactics might actually be a good, rather better, way to get things done.

I believe opportunities almost always masquarade as problems. I have never seen an opportunity present itself as a career-building assignment, or a game-changing company event on a silver platter. They all present themselves as a small, constant irritating pain of no major importance or immediate consequence. Most of us ignore them and walk right past them, prefering to often wait to work on ‘bigger’ problems, strategy and so on. I remember a highly inspiring talk by Scott Cook, founder of Intuit, a few years back in Bangalore. Scott talked about how they do the strategy for their products. Instead of a very hi-tech way to define product development strategy, they go about identifying pain-points their customers experience while using their products. They simply work on improving the user experience as the primary way to create opportunities for themselves. And it works for them.

Don’t run away from the shark in your cubicle, and if you have none, start by putting a shark in your cubicle first 🙂

Would you make a popular decision over a right decision ?

This is another one of those doing rounds on the net. Source unknown, but good learning value.

A group of children were playing near two railway tracks, one still in use while the other disused. Only one child played on the disused track, the rest on the operational track.

The train is coming, and you are just beside the track interchange. You can make the train change its course to the disused track and save most of the kids. However, that would also mean the lone child playing by the disused track would be sacrificed. Or would you rather let the train go its way?    

tracks

 

Let’s take a pause to think what kind of decision we could make……………. 
.  
.
.

Most people might choose to divert the course of the train, and sacrifice only one child. You might think the same way, I guess. Exactly, I thought the same way initially because to save most of the children at the expense of only one child was rational decision most people would make, morally and emotionally. But, have you ever thought that the child choosing to play on the disused track had in fact made the right decision to play at a safe place?

Nevertheless, he had to be sacrificed because of his ignorant friends who chose to play where the danger was. This kind of dilemma happens around us everyday. In the office, community, in politics and especially in a democratic society, the minority is often sacrificed for the interest of the majority, no matter how foolish or ignorant the majority are, and how farsighted and knowledgeable the minority are. The child who chose not to play with the rest on the operational track was sidelined. And in the case he was sacrificed, no one would shed a tear for him.

The great critic Leo Velski Julian who told the story said he would not try to change the course of the train because he believed that the kids playing on the operational track should have known very well that track was still in use, and that they should have run away if they heard the train’s sirens. If the train was diverted, that lone child would definitely die because he never thought the train could come over to that track! Moreover, that track was not in use probably because it was not safe. If the train was diverted to the track, we could put the lives of all passengers on board at stake! And in your attempt to save a few kids by sacrificing one child, you might end up sacrificing hundreds of people to save these few kids.

While we are all aware that life is full of tough decisions that need to be made, we may not realize that hasty decisions may not always be the right one.

“Remember that what’s right isn’t always popular… and what’s popular isn’t always right.”  

Everybody makes mistakes; that’s why they put erasers on pencils.

I don’t know enough to comment if Leo Velski Julian’s approach is right or wrong, but it surely resembles the reality: we often disregard the ‘right’ and protect the ‘wrong’ because of relative costs of choosing between the two of them. I guess ‘popularity’ is more important than being ‘right’ for most of us in most of the situations.

Decision-making is not as straight forward as choosing between right and wrong anymore, if it ever was! Most often, there are two or more choices, none absolutely right or absolutely wrong, and the right choice being made depending on the relative cost/benefit of one over other, with not all factors known upfront with enough clarity or certainty! While sometimes flipping the coin might be the best way to make decisions when both options look equally good (or equally bad, depending on how you look at life) and you want that extra bit from the heavens to help you make the right choice, we might not always have the luxury to flip a coin to take the decision and being able to justify, especially when things go wrong, as they eventually will. The system expects us to use an explainable rational thought process to arrive at a decision even if that goes wrong as opposed to a plain intuition-backed decision that might go right.

I believe the single-most important function of a manager is the decision-making ability. When things are clear and certain, it is often a no-brainer – and it might not be an exaggeration that the manager is not even required! What is interesting is how a manager, or just about anyone will digest raw, incomplete, uncertain and highly dynamic information and produce a decision that will stand the test of time. As someone said, hindsight is always 20/20, and so, it is always extremely easy to trash a decision after the event has happened and all details are available. The thing is, do you have what is takes to make a decision knowing very well that future possibly won’t be kind to it?

In software development and most other knowledge-based disciplines, we are increasingly seeing a firm, irreversible and healthy trend towards teams taking and owning decisions that impact them. This surely eliminates, or at least mitigates, the risk associated with a sole decision-maker, and allows decisions to be made with two distinct advantaes: everyone’s involvement is akin to ‘wisdom of crowds’ and hopefully will bring team to a better decision, and there are higher chances of a team buying-in the decisions made.

How do you take decisions? Do you take decisions for your team, or does your team take decisions for themselves, with your participation, as required? How does your team deal with the issue of a majority taking a popular opinion that might be like diverting the train to the unused track to protect people even if they are clearly wrong? Would you or your team make a popular decision over a right one?

Situational Leadership in Software teams

In a previous post, What is the leadership style in your software teams ?, I discussed about four key types of leadership and their evoluation, and how it could possibly relate to software teams. In this blog post, let’s dwell on this topic further, and explore how to decide what leadership style suits a given situation. The assumption here is that there is no such thing as an “all-weather” or a personal favorite leadership style – each tool and method has pros and cons depending on why, how, when, what and where they are applied. The value one derives depends on how well a given style ‘fits’ the context – to that end, it it highly imperative to identify the ground conditions and only then decide what could work here more effectively.

Our industry has a difficulty articulating with what type of leadership we want to have. We surely don’t like the ‘Great Leader’ or the ‘Command and Control’ leaderships (discussed in my previous post). We believe this leads to a highly autocratic or centralized organizations which is the not the best way to manage highly educated, unapologetically assertive and fiercely independent knowledge professionals. We feel empowerment is the way to go, and eventually want to be able to manage own destiny by ourselves. There is a fair amount of consistency in these thoughts among young professionals cutting across countries and cultures. This should make the task for managers easier, because they kind of know what is expected of them, and all they need to do is to just do it! However, like every management advise, it is easier said than done. For one, most managers from the shop-floor era of management might not be skilled or ready for the new-age management mantras. They might feel insecure letting go of almost all their authority, or might feel underconfident about younger professional’s competence, or some other reasons. So, that’s one part of the issue.

Second part of the issue is how young professionals want their leaders to support them. Contrary to most people’s beliefs, everyone does want someone ‘above’ them to support them when they are need help, give them some directions when they are doing something for the first time, give them feedback when they have done something, shower them with praise and recognition when they accomplish something, and (surprise ! surprise !) even pull them up when they mess things up (of course, not in a way that kills them, but in a way that lifts them).

Most managers understand these intuitively or learn them from the school of hard knocks. First-time managers often have the tendency to either overcontrol the team (by using management tools such as “death by process” or “death by compliance”) or the other extreme end to overappease the team. We have seen them in all shapes and sizes. What I found is that people generally tend to overcontrol because they don’t want to fail, and want to do everything possible to ensure that projects stay on tracks. It is not so much about them not trusting their teams, but more about whether the project will be completed successfully if they are not involved. They want to look good to their seniors that by making them the manager of this project, they did not make a bad decision. Some managers share their solidatiry by following every process to the hilt, some will overstuff their plate full of every possible requirement because they don’t want to be seen as the project manager who says ‘No’ to a customer, some might make the team work extraordinaliy hard over weekends so that upper management sees their ‘commitment’ to the project and the organization. They probably believe that overcontrol and being a tough manager can solve all people issues on a project.

Other type of extreme behavior is about turning the team environment into an Osho commune. The idea is to ‘buy’ motivation to the task, commitment to the organization and loyalty to themselves by ’empowering’ the teams. Most people will never admit that they are ‘buying’ motivation, commitment and loyalty from the team but that’s what it is more often than not. After all, the are not ’empowering’ their newly assigned teams on the basis of their merit and performance just yet, so that else could explain their motives? I have seen managers who were technically or managerially weak buying their team’s respect by trading their authority. I have seen managers who do not want to spoil their relationship with team members (especially low performers) using this strategy. They are trying to ‘please’ everyone on the team. Obviously they haven’t heard “I cannot give you the formula for success, but I can give you the formula for failure: which is: Try to please everybody” by Herbert Swope.

Surely, this is a continuum with these two being its extreme ends, and the right way is somewhere in between. However, what might be the ‘right way’ for some might not be seen as the ‘right way’ by another. To illustrate what I mean, look at the same behavior but which could mean entirely different things to different people:

  • Behaviour 1: A manager is heavily involved working with the team in discussing and resolving every single issue, looks into the details of every single decision, participates in all estimations and commitments, sits and writes code and reviews it, etc.
    • Interpretation 1: She is a great leader. Supports us in all our problems, gets involved, and an eye for details. By getting involved in the commitment-making process, I feel more secure that I won’t be blamed for any issues, and that my manager is in it with me. She still knows the entire code by heart!
    • Interpretation 2: She doesn’t trust us, and gets involved in every single issue. There is no freedom to do what we want to do. I would say she micro-manages us. If she also contributes as an individual performer, she should be one of the engineers and not a manager

We have a manager here who might have felt her involvement with the team will be welcomed. She might have had her own reasons to get involved (maybe new project for the company, very critical, high expectations, her own views about team being capable of executing it, etc.) but different team members are likely to view it differently. Similarly, let’s take another case on the end of the spectrum:

  • Behavior 2: The manager is not involved in day to day team inolvement, allow the team to manage its own issue
    • Interpretation 1: he is a great leader, he has delegated every decision-making and empowered us like we have never known. he trust us with our ability to do things
    • Interpretation 2: he is totally aloof from the team and takes no responsibility for the team. has no feeling for what pressures we go through in the trenches. I wonder why the company pays him. He doesn’t come and help even when we are knee-deep in hot water. A simple illustration like this can bring out the fact that we are all different and likely to interpret same observed behavior differently. As you rightly point out, 99% depends on context – we should know all possible permutations and combinations and what are the specific issues in each of those, and what would be the best way to address those issues.

Again, the behavior of this manager is likely to be interpreted differently by different people in his team, irrespective of what and why he thinks about it.

Clearly, these trivial and overexaggerated examples do highlight the fact that a singular style won’t serve all needs well. The need is to identify an approach that individual people could relate to personally, and feel that their concerns and needs are addressed individually by the leader rather than being met with collectively by the leader (which essentially means that no one’s needs are being met, because an ‘average’ by definition is at best a numerical compromise what falls short of numbers higher than it and scores higher than number below it, thus matching none of the numbers).

Hersey-Blanchard Situational Leadership model serves as a great example to address this dilemma:

Situational Leadership modelEssentially, this recognizes the fact that ‘followers’ undergo development in stages when following a leader, and based on where a follower is in the stage of development, a leader must modify his leadership style. As we see in the Situational Leadership model, a leader adjusts his style (from quadrants S1->S2->S3->S4) from ‘Directing / Telling’ style when his followers need very high direction but not so much of support. This is pretty much a one-way, centralized leadership that realizes the fact that followers are not skilled enough to decide for themselves, and hence must be clearly guided on their tasks.

As the team matures and is able to understand much of task requirements, they require lesser direction and are able to contribute to tasks in terms fo ideas,knowledge and skills. This turns the communication into two-way and requires the leader to get into a ‘Coaching / Selling’ mode.

As the team matures and requires lesser of directions, the leader changes gears again and gets into ‘Supporting / Participating’ mode where more responsibility has been handed down to the teams but the overall control still remains with the leader.

Finally, when the teams have grown to the stage where they are self-directed, they assume decision-making from the leader, who is only involved when the teams want him to get involved. At this point, the leader is in ‘Delegating’ mode and has delegated responsibility as well as authority with his followers or the team.

As we can see here, the ‘power’ of a leader is gradually shared with the team as they develop. This model is cognizant of the fact that no one behavior could suit every situation – it all really depends on where the team is at this point of time. Of course, the leader is also responsible for developing the team from R1 through R4 and in that process, he must be prepared to ‘lose’ his traditional power and authority to the teams. In a way, he must work towards making himself redundant! But that is what transformational leadership is all about.

Some interesting and important observation from this model:

  • However seasoned a leader might be, she can’t always start operating in a particular quadrant in which she is currently operating, or is proficient in. When being part of another team, she must analyze the follower preparedness and readiness before directly getting into the empowering mode lest that be midsunderstood and create a chaos.
  • There is nothing good or bad about a given leadership style. Like a right tool in the right hands, it must be seen as the right response to a given problem. So, if some manager comes across as a ‘Telling’ manager, that might not necessarily be a bad thing.
  • Leadership style mismatch typically happens when the leader opens the floodgates a little too early for the team to handle. This could result in a chaos, as the team has not yet had the opportunity to transform itself into a high-performing self-organizing team. On the other hand, other leadership dysfunction is about not letting it go even when the team has demonstrated its ability to manage its own fortunes. We took those examples earlier in this blog.
  • There might be individuals with high competence in their functions, but what matters in our context is the preparedness and readiness as a team. There will always be individuals in any team in any stage who will either be very self-directed (and hence, not very open to being directed) or highly dependent for directions. A leader’s job becomes difficult because she must not only maintain a particular leadership style to suit the team development stage, but also make adjustments as per the individual differences.
  • To be a good leader, one doesn’t always have to be in S4 quadrant. One could be in S1 quadrant and still serve the team with excellent results. Similarly, a bad leader doesn’t always have to be always the one who is seen as wielding control over the team, say, in S1 quadrant. A leader operating in S4 quadrant could come across as an incompetant leader.
  • Finally, (a) organizational culture for decision-making (centralized vs/ shared), (b) risk apetite and (c) the task under question will also determine how much ‘allowance’ a manager has in developing his team and sharing decision-making with them. This model dosen’t factor-in those external environment factors that will often have an overriding influence on the development of leadership, often even when the team has (or has not) matured to a given level of readiness.

We have barely scratched the surface with this discussion. Surely, there are many more critical factors that will eventually determine (a) which leadership style an organization will let a manager decide, and (b) how successful would that be. Some of these might help us understand better why Agile adoptions don’t always work in some organizations, or why some organizations prefer a formal project management method. At a team level, this model could also help us understand what type of team members are likely to be motivated and productive and what type of team members are likely to become disenchanted and eventually leave the team or the organization.

How do you go about determining leadership style on your software teams ?

Initiative + Continuous Improvement => Superior Performance

Disclaimer: I got this in an email. This is not written by me, and is not my intellectual property. If you know the original source to it, I will be happy to link to it, and if it is copyrighted, I will be happy to seek permission to repost on my site, or take it off, as the case might be. I am sharing it here because I think there is good value in this illustration that everyone can learn from. I enjoyed reading it, and hope you enjoy too 🙂

Every company has a performance appraisal system in place to measure the effectiveness of its employees. Employees are normally rated in most of the companies in the Good, Very Good, Excellent, Outstanding categories. Apart from the above, non performance category is also there, which is not depicted here). Needless to say everyone wants to be rated Outstanding.

What is the yard stick and how do you measure these aspects?  

  • Employee “A” in a company walked up to his manager and asked what my job is for the day?
  • The manager took “A” to the bank of a river and asked him to cross the river and reach the other side of the bank.
  • “A” completed this task successfully and reported back to the manager about the completion of the task assigned. The manager smiled and said “GOOD JOB”

Next day Employee “B” reported to the same manager and asked him the job for the day. The manager assigned the same task as above to this person also. 

  • The Employee “B’ before starting the task saw Employee “C” struggling in the river to reach the other side of the bank. He realized “C” has the same task.
  • Now “B” not only crossed the river but also helped “C” to cross the river.
  • “B” reported back to the manager and the manager smiled and said “VERY GOOD JOB

The following day Employee “Q” reported to the same manager and asked him the job for the day. The manager assigned the same task again.

  • Employee “Q” before starting the work did some home work and realized “A”, “B” & “C” all has done this task before. He met them and understood how they performed.
  • He realized that there is a need for a guide and training for doing this task.
  • He sat first and wrote down the procedure for crossing the river, he documented the common mistakes people made, and tricks to do the task efficiently and effortlessly.
  • Using the methodology he had written down he crossed the river and reported back to the manager along with documented procedure and training material.
  • The manger said “Q” you have done an “EXCELLENT JOB”.

The following day Employee “O’ reported to the manager and asked him the job for the day. The manager assigned the same task again.

“O” studied the procedure written down by “Q” and sat and thought about the whole task. He realized company is spending lot of money in getting this task completed. He decided not to cross the river, but sat and designed and implemented a bridge across the river and went back to his manager and said, “You no longer need to assign this task to any one”.
The manager smiled and said “Outstanding job ‘O’. I am very proud of you.”

What is the difference between A, B, Q & O????????
Many a times in life we get tasks to be done at home, at office, at play.
Most of us end up doing what is expected out of us. Do we feel happy? Most probably yes. We would be often disappointed when the recognition is not meeting our expectation.

Let us compare ourselves with “B”. Helping some one else the problem often improves our own skills. There is an old proverb (I do not know the author) “learn to teach and teach to learn”. From a company point of view “B” has demonstrated much better skills than “A” since one more task for the company is completed.

“Q” created knowledge base for the team. More often than not, we do the task assigned to us without checking history. Learning from other’s mistake is the best way to improve efficiency. This knowledge creation for the team is of immense help. Re-usability reduces cost there by increases productivity of the team. “Q” demonstrated good “team-player” skills,

Now to the outstanding person, “O” made the task irrelevant; he created a Permanent Asset to the team. If you notice B, Q and O all have demonstrated “team performance” over an above individual performance; also they have demonstrated a very invaluable characteristic known as “INITIATIVE”.

Initiative pays of every where whether at work or at personal life. If you put initiative you will succeed. Initiative is a continual process and it never ends. This is because this year’s achievement is next year’s task. You cannot use the same success story every year.

The story provides an instance of performance, where as measurement needs to be spread across at least 6-12 months. Consequently performance should be consistent and evenly spread.
Out-of-Box thinkers are always premium and that is what every one constantly looks out for. Initiative, Out-of-Box thinking and commitment are the stepping stone to success. Initiative should be life long. Think of out of the box.
 

This is a nice illustration that the ‘performance bar’ keeps getting higher and higher as the time goes by, and doing something the same way won’t count as equally good performance as the last time. We all must constantly look for ways to improve the way of working. People who don’t take initiative and continue the routine way of doing things will soon find themselves out of place, literally ! The best performers in any team can be spotted by the way they go about the initiative they take to approach a problem. These is a clear linkage between initiative and performance. In another blog, I will explore a model to measure initiative that was handed over to me by a senior HR professional while working at Philips, and I have used it for last ten years and found great value in using it.  

This illustration also brings out a rather unfortunate fact of life: that life as a pioneer is not always kind. Perhaps the challenges (and odds) in doing something for the first time are far greater than subsequently improving upon it (well, mostly, I think), but we tend to short memories about initial contributions. I don’t have a good answer for it, except that I feel this is little unfortunate. I guess the only thing one can takeaway from this is not to sit on one’s laurels far too long, but get going as soon as the party is over !

Blame your “flaccid developers” and your “flaccid customers” for your poor quality products !

This is the text from a recent announcement for a course by Ken Schwaber on “Flaccid Scrum – A New Pandemic?” (text underlining is mine):

Scrum has been a very widely adopted Agile process, used for managing such complex work as systems development and development of product releases. When waterfall is no longer in place, however, a lot of long standing habits and dysfunctions have come to light. This is particularly true with Scrum, because transparency is emphasized in Scrum projects.

Some of the dysfunctions include poor quality product and completely inadequate development practices and infrastructure. These arose because the effects of them couldn’t be seen very clearly in a waterfall project. In a Scrum project, the impact of poor quality caused by inadequate practices and tooling are seen in every Sprint.

The primary habits that hinder us are flaccid developers and flaccid customers who believe in magic, as in:

Unskilled developers – most developers working in a team are unable to build an increment of product within an iteration. They are unfamiliar with modern engineering and quality practices, and they don’t have an infrastructure supportive of these practices.

Ignorant customer – most customers are still used to throwing a book of  requirements over the wall to development and wait for the slips to start occurring, all the time adding the inevitable and unavoidable changes.

Belief in magic – most customers and managers still believe that if they want something badly enough and pressure developers enough to do it, that it will happen. They don’t understand that the pressure valve is quality and long term product sustainability and viability.

Have you seen these problems? Is your company “tailoring” Scrum to death? Let Ken respond to your issues and questions!

Ken will describe how Scrum addresses these problems and will give us a preview of plans for the future of the Scrum certification efforts.

Here are my observations and thoughts from this synopsis:

  • line 2: what does “when waterfall is no longer in place” mean ? So, when waterwall was still in place, there were no issues ??? Somehow, one gets a feeling all the problems came to light only when Waterfall was “no longer in place”…so, why not get waterfall back in its place 🙂
  • line 5-6: In a Scrum project, the impact of poor quality caused by inadequate practices and tooling are seen in every Sprint ? …in every Sprint ?….now, wait a minute….I thought  Scrum project did not have any of these problems because there were no inadequate practices and tooling issues. And you certainly don’t expect to find such issues in every Sprint, or do you ?
  • line 7: OK, so now we have an official reason: “flaccid developers” and “flaccid customers” for all ills of the modern world. Wow! I am not sure if that is the best way to build trust either with teams or with customers by fingerpointing and squarely blaming them…without giving them a chance to even speak for themselves. And I thought Srcum was cool about trusting developers, not fixing blame on individuals, interacting with customers…but flacid developers and flaccid customer ??? Does it get any better than this ?
  • OK, I will probably agree ‘unskilled developers’ in the context of building an increment of product in an iteration, but what the hell is an ‘ignorant customer’ ? Try telling a customer that you are an ignorant customer…Scrum or no Scrum, you are guaranteed some unsurprising results ! And which Customer paying through his nose waits for the “slips to start occurring” ? In these tough economic times ?  
  • Is your company ‘tailoring’ Scrum to death ? I thought there were only two shades of Scrum – either you did Scrum-per-the-book or you did not. Since Scrum is the modern-day Peter Pan which refuses to grow up, we have only one version of Scrum to play around with, and unless some group of people decide now Scrum can grow to the next version (perhaps more because of commercial interests than anything else, whenever that happens). So, how can one ‘tailor’ Scrum – by any stretch of imagination, that is NOT Scrum. I mean, that is not allowed ! Right  ? So, why are we discussing it and wasting time – we might actually be acknowledging and unknowningly legitimizing that there is a secret world out there where Scrum can be ‘tailored’ and still be called Scrum ! That is sacrilege !

I always hate marketing messages that overpromise miracles, offer snake oil, belittle the intelligence of people, ridicule people…why can’t people simply stick to facts and figures ? Why don’t we talk in a non-intimidating language that encourages people to look up to what is being talked about ? And in the context of current subject, I doubt Scrum community is going down the right path if its next target is developers and customers. One of them does the work and the other one pays for it. Who gives us the right or the data to talk about any of them, in absentia ? Customers are customers, and even if they are irrational, they are still the customers, and whether paying or not, they alone are going to decide how they will behave. Yes, we might not like it, but is ridiculing them as ‘ignorant customers’ going to turn things into our favor ? Other industries like retail, hospitality, transportation, etc. have millions of years of collective experience in managing customers, yet they never break the singlemost cardinal rule of customer service: the customer is always right! And the first chance we software developers get to explain a poorly designed or a bad quality product and rightaway we blame the customers for it ! As if that is not enough, we then look inwards and blame the developers ! GREAT !

I think I will just develop software without blaming anyone else for my mistakes and limitations 🙂 

Art Fry shares views on Failure…

In  my previous post When are you planning to fail ?, I argued that early failures were a far more effective learning tool than early successes. Those ‘gentle failures’ could help you avoid, or at least minimize the chances of ‘grand failures’.

My colleague from PMI NPDSIG, Kimberly Johnson, shared that post with some of her ex-colleagues (Thanks Kim !), including Art Fry, inventor of perhaps most-well-known office product, Post-It Notes.  Here is what he wrote back:

“Good article, Kim. In most product development programs you must consider dealing with failure, because only one in 3000 to 5000 raw ideas become a success. So the question is, How do you check out the failures as quickly and inexpensively as possible?

One technique we have used with brainstorming sessions is to first brainstorm for the good ideas. This can be an individual or group effort. After a day of incubation, come back and brainstorm the barriers to success for those ideas. On day 3, Brainstorm the ways around those barriers. Sometimes a program that didn’t look so good at the start, turns out to have the most promising path. It is amazing how much time it can save in a program with a lot less cost than charging ahead with unchecked enthusiasm. Action without thinking is the cause of most failure.

Cheers,

Art”

He sent one more viewpoint:

“One more thought. Why would people want to work on new things, if most of their work is going to lead to failure? The good news is that when one of the individual’s ideas does find a successful path, it requires the help of a lot of people who have the satisfaction of building something successful. It is like hitting a good drive on the 18th hole. It keeps you coming back.

Cheers,

Art”

It is indeed great to have Art’s views on this highly underrecognized subject (in my view, at least). Art raises a very pertinent question: when the success rates are as low as just about 1 in 3,000 to 5,000, what is it that keep people going on and on and on ? Surely, large organizations could fund ideas in various stage of a concept-to-realization pipeline (that is, starting from thousands of raw ideas to finally the ones that will get productionized and are expected to be released on a commercial basis) even though they also need to count their R&D dollars (very carefully, I must add !), more so in these tough economic times. In the startup world, there is Darwin again at work – it is perhaps the democracy at its best that the strongest ideas stand up to various survival tests and eventually make it big. However, what is it that keeps people pushing at their ideas, day after day, week after week and year after year – just based on the strength of conviction about their ideas ? Are those ideas winners by themselves (i.e., genetically endowed), or is it the tireless efforts of those individuals that bakes those ideas to be a winner (i.e., genetically engineered) ?

Another colleague of Kim, Wayne wrote back:

“This conversation reminded me of the question Russ Ackoff posed to me when he came to town to speak for a day about 10 years ago . . .
 
Russ asked “Is it true what I hear about 3M that you give an annual award for the Biggest Failure to reinforce it is OK to fail?”  
 
Russ will always be a hero of mine for his insight into systems . . . see his wikipedia summary at this link –>
 
http://en.wikipedia.org/wiki/Russell_Ackoff
 
Wayne”

Wow…wouldn’t that be splendid to be awarded the “Most Promising Failure of the Year” or some such ‘recognition’. I think it is a valuable (and rare perhaps ?) skill to be able to ‘smell’ failures from miles away. Imagine the power of an action that helps a company move out of random choas and uncertain future into a clear direction. I think Performance Management Systems are overdue for a big overhaul, for they glorify and celebrate achievement-orientation and happy endings. I would really love to hear back about an appraisal system that actually places premium on intelligent failures as opposed to run-of-the-mill non-consequential routine ‘successes’.

Failure is the new Success. Do you care ?

When are you planning to fail ?

Yes, you read it right…when are you planning to fail ?

In the world where insatiable hunger for ‘success’ is an obsessive-complusive disorder (OCD), we don’t think of ‘failure’ much. It is shunned, scoffed at, systematically eliminated (or mitigated, at least), avoided, bypassed, ignored….everything but embraced with open mind and open arms. All management ideas are directed towards the age-old wisdom of “if you fail to plan, you plan to fail” and not on something like…”what won’t kill you only makes you stronger”. All project management philosophies are centred around safeguarding the projects from any possible failures…but has that stopped projects from grand failures? Every risk management action is towards making the project safe from failing…and yet we still see so many projects biting the dust, struggling for survival. Failure appears to be a social embarrassment that is best avoided at dinner table conversations. New-age enterpreunership, especially in Internet world, has helped a lot to eliminate the stigma that eventually comes with people associated with any well-known failure, but in everyday lives, we still continue to play safe, rather extremely safe. Of course, I am not talking about breaking the law and driving without seat-belts on or driving in the middle of the road jeopardizing everyone’s life. I am talking about thinking like Fosbury and challenging the established way a high jump is done – even at the risk of failing because what you are about to propose hasn’t been tested and certified to succeed. I am talking about taking those small daily gambles that strenghten you when they fail. I am not interested in those small daily gambles that are supposed to strenghten you if they succeed – honestly, they don’t teach you anything. In fact, those small successes might limit your ability to reach for higher skies because you remain contended by those sweet-smelling early successes. In my view, people who don’t want to risk gentle failures must prepare themselves for grand failure !

The word ‘fail’ is such a four-letter word that is evokes very strong emotional responses. In an achievement-oriented society and success-intoxicated corporate culture, fear of failure drives people to seek safer havens. When choosing what subjects to take in college, we ‘force’ our children to take the ‘safest’ subjects – they are the subjects that have maximum job potential ensure maximum longevity in job market. (I agree that ‘force’ is not the right word here, but it is not in its literal sense that I use this word here. The ‘force’ can come from parental expectations, societal pressure, peer pressure, ‘coolnees’ of a job, perks of the job, etc.). Traditionally, they have been Engineering and Medicine and anything else that ensured a government job (in India, and I am sure every country has had its own fixations at different times). So, the foundation to seek safety from failure gets laid right at the start of one’s career (well, in my view it is erected right after birth and we are still curing it by the time we start our careers, but that’s for another blog post). After graduating, there is once again a massive derisking operation: find some company that has a ‘big’ name (even if one is doing a fairly mechanical job there). Basically, trade any hopes or ambitions to do something new and creative in life with rock-solid jobb safety in a mundane assignment! As a rookie, you then become a link in this enormous chain where your job is dictated by the volumes of SOP (Standard Operating Procedures) that trade your urge to experiment / innovate with a higher ‘percieved’ safety of the given process. The logic being: this is the way we know it has been done before, and since it worked the last time, we expect it will always work and hence this is the standard procedure. Wow !

You then become a manager and have to now run a project. You have the ‘process police’ breathing down your neck challenging every single thought, let alone a decision, to deviate from those SOPs. You want to try an innovative recruitment…no, that is too risky. Why not first prototype this sub-system…no, the finance won’t allow that because we can’t bill the customer since nothing tangible has been delivered. How about a 200% make-or-break bonus for this team that is up against Mission Impossible….no way ! we will have mutiny in other projects. How about this….and how about that… Finally you give up and give in…and the project somehow starts. Most optimizations, if any, have been seriously watered down by now, and are highly local at best. The result is predictable – no substantial improvement from the previous project, at best, and an utter fiasco, at worst.

Let’s pause for a moment and quickly run through the script here. We are taking every beaten path that has individually been successful in the past (or so we have been told), and yet there is no guarantee of success in its next run. In each of these situations, the project manager faces the music – after all, the process did work the last time and if it is not working this time, this must be a capability issue (or, even worse, attitude issue) with the manager. Being at short end of the stick and facing an imminent loss of professional credibility, the manager pushes his team to burn themselves over really late evenings and long weekends and somehow gets past the finish line…but not before incurring emotional and professional scars, not before pruning down some of the original features, not without some ‘known’ bugs in the release and definitely not before going way above the original budget.

What went wrong ? We did everything to prevent ‘failure’ but we still failed to deliver a decent product on-time, within budget (even if overtime is unpaid, it still means shooting out of the budget), blah, blah, blah …???

This is what went wrong – in order to safeguard our project from any (all?) possible failures, we fortified the project. We poured money like water to avoid being mousetrapped. We used innovative processes that allowed us to take baby steps and gain early successes. Those early successes, after all, helped us validate our assumptions and only then did we go all out. And yet? In this process of scaffolding the project, we actually erected artificial life-support systems to make the project stand on its feet. Most assumptions were then tested in isolation for its validity under ‘standard test conditions’. Unfortunately, those early successes gave a false illusion that everything was fine, even though several of the chinks in the armor were not fully exposed. Absence of ‘gentle failures’ early in the project lifecycle ensured that the team thought they were on rock-solid footing. However, in reality, we could never fully guarantee that, especially when those early cycles were done with the intent to make something work and not make something fail ! Imagine you were testing a tool to detect landmines. To do acceptance testing of the equipment, you operate it under ‘specified test conditions’ and accept it. However, the enemy won’t lay mines under those very standard test conditions! Chances are extremely high that enemy’s plan will fail your equipment. I am only asking you to fail it yourself before someone else does it for you.

Here is something you might want to do on your next project. Identify all possible and potential ‘points of failure’ in the project (there are always more than one). Challenge everything and everyplace where Mr. Murphy can strike. Design the project plan to fail, fail softly, fail early and fail as often as required to ensure there is no grand failure (or at least a significantly lower chances of a grand failure). Design your test criteria such that success is measured by how many of those assumptions have failed. Cull out important lessons from those failures and now build your project plan to avoid grand failures. Of course, you won’t completely eliminate grand failures, but will have moved a couple of steps closer to avoid them or minimize their impact compared to what an early success approach would have given you.

So…when are you planning to fail ?

Ability to innovate is directly proportional to constraints in the system

We human beings love to innovate, create better ideas and solutions, achieve efficiency in operations and so on. To do so, most people ask for the latest and greatest tools, the newest of the management fads, the really costly consultants so that they could ‘innovate’. The solitary aim and hope being those ‘new silver bullets’ have the right power to fix your problems.

However, they could not be any further from truth – real innovation happens when there are real constraints on the system and not when you have infinte amount of resources and problem-solving tools. When you try to remove or reduce the constraints just by adding resources alone (which could be time, money, people, tools, methodology, ..whatever), you are actually making the problem worse. Without challenging the people to come up with smart solutions, you are asking them to move away from that ‘source of innovation’ and do something else. This might be ok in some cases, but invariably, it deprives the golden opportunity to find some real cool way to solve complex problems. A far more effective way would be to respect that constraint without trying to satiate the bottleneck by throwing money (or whatever you can afford to throw) at the problem.

The great Indian epic, Mahabharata, has the story of lower-caste prince Eklavya who is an expert archer and wants to become the world’s best archer ever. He goes to the guru of noble princes, Dronacharya, who refuses to teach him as he comes from lower caste, so what if he is a prince. Not to give up so easily, Eklavya makes a statue of his ‘guru’ and ‘learns’ from him and become the ace archer ! Who says you need a guru to learn something – you can even learn something without having the right tools in hands. When I was growing up, my father told me the story of a poor boy who is determined to learn typing and win the typing contest. The only problem is that he doesn’t know typewriting and has no means to attend typing classes. He comes up with a novel idea: he copies the QWERTY layout of the typewriter on a piece of paper and practices ‘hitting’ the key on that piece of paper ! After a month of practicing ‘typing’, he finally makes it !

Innovation, or atleast the innovating thinking flourishes at its best in places that have traditionally been deprived of capital to buy more fancier solutions and there was a dire need to change the current status. In the annals of history, names of people like Edison, Strowger (an undertaker who made the first automatic telephone exchange so that a telephone operator  favorable to his competitor could not favor him anymore) have a special place . They all challenged the status quo and neither dearth of capital not serial failures could dent their enthusiasm or efforts to find a more innovative way to solve a real-world problem. Go visit the countryside of India, or any country. From the ‘lassi’ shop guy who so smartly uses a washing machine to make ‘lassi’ to the innovations that help peel a coconut faster, we have it all. A couple of years ago, I went to this fabulous place known as Bhimbetka near Bhopal, India. Apart from the magnificant pre-historic cave paintings that this place is world-famous for, I also saw very strange and interesting things. All the dogs there had a spiky collar – it had like millions of nails jutting out of it. When I asked the reason, the locals told the most obvious reason: that area has many wild animals, including leopards and tigers. They attack the dogs in the night. Having such collar saves the dogs because when they attack the dogs, they first go for their necks, which doesn’t provi to be such a smart move after all. So, having such dog collars actually saves the dogs. Similarly, I read somewhere that the single biggest innovation that has saved human lives in similar rough terrains is usage of a human mask worn on the backside of the head. The tiger thinks the human is watching it and stays away. Innovation to survive doesn’t seem to be the elite preserve of people being chased by tigers and leopards. The desire (or rather the desparation) to survive is equally strong in urban jungles…the types that exist in corporate world 🙂

On the other hand, sometimes the brightest minds do seem to bungle up. You might have heard of the suppossedly true (?) tale of how NASA spent millions trying to develop an anti-gravity ballpen for its astronauts…and failed. The Soviets just used the pencils.

In software development, we have seen it all. From the CEOs who read the latest management fad in the airline magazine and wants to start ‘doing it’ rightaway to the architects who want to bet on the latest (and often, unproven) technology to the project manager who thinks having a couple of more engineers will help him complete on time….these are all classic examples of how we human beings are throwing more fuel on the buring house. Instead of hiring more people, he probably might be well-advised to look inwards as to why there is a delay after all, and how can he avoid any further delays. The architect who wants to solve the problem using the latest tools might be risking far too much in the bargain – including his own career. Where is he going to find people who also understand the new toolset, the proven ways to architecture the system for achieving best performance, and so on. The CEO who wants to implement the latest management mantra might be jumping too soon to the conclusions without having the right assessment of problem or having the buy-in of his team. Do you think any of these are really innovating ? In my view, they are simply avoiding the tough discussions by trying to take shortcuts.

So, instead of trying to create a picture-postcard version of the problem, try to understand the systemic constraints. They are the sources of what will ultimately make your solution stand apart in the crowd. Because in real-life, you don’t have a photo-editing software like Picassa to obliterate the blemishes to make your picture a picture-postcard quality.

[6-Aug-09] I am thankful to a reader, Prateek Narang, for pointing out a mistake in the blog title. It has now been corrected 🙂

Ten Commandments for Revolutionary Change Agents

Revolutionaries are a restless lot. In a way, they are like the ‘shooting stars’ in an organization – they are seriously outnumbered by the hundreds of twinkle-twinkle little stars, they enter an organization with tails-on-fire hurry, and (try to) change everyone and everything around them within the short time span that they are there, and then they burn out (or just lose interest when the work they set out for is either accomplished, or get bored when it doesn’t get accomplished) and just move on. They don’t have a lot of time, patience or socialistic motives making small changes here and there, or to make elaborate plans and do surveys, investigations and pilots, and so on. They would rather be out there in the middle of heat, dust and all the adrenalin-pumping and chest-thumping action than be found napping in a death-by-powerpoint meeting full of naysayers who believe it is their fundamental right to protect the status quo.

While some are born revolutionaries, some people don that role for some phase of their professional life. Irrespective of whether you are one or not, chances are that you might be reporting to one, or working with one, or managing one such person sometime in your life. I would even bet that sometime in your career, you might find the need to shift gears and play that role. These ideas have helped me over the years, and I hope they help you as well:

 

  1. Don’t ever give up. Conviction of ideas and persistence of efforts are as much a key to success as the merit of proposal. The easiest thing is to give up – and perhaps everyone before you just did that (that’s why no change ever happened before there). So, you have the choice to either join the ranks of people who just couldn’t handle the heat, or stay right there and befriend the heat. 
  2. Don’t scale down what you believe is right for the organization just because some people don’t feel that way. Again, it is very easy to offer a ten-percent solution that pleases the mighty bosses but misses out on the remaining ninety-percent hard part that will either optimize the way of working, or help it self-sustain for years to come, or make the operations more efficient, etc. By scaling down and showing only the best oranges, you might gain some immediate curreny for your ideas (and it might even be a perfectly safe ploy just to get out of a deadlock) but you run the danger of setting a precedent for your ideas: low cost, high returns. Like a ponzi scheme, you might be expected to routinely dish out such ideas that offer insane amount of returns on bargain prices, and that might kill the potential of other, far better ideas that might not offer the low-hanging fruits but are required for the organization.
  3. Don’t constantly remind people whenever things fail, even when they fail due to reasons being highlighted by you and ignored by them. Many a times, people will simply ignore your ideas and opinions for various reasons and will simply go ahead with their ideas. In some such situations, their ideas could also fail. The last thing you can do to help the organization (and yourself) is to “I-told-you-so”. We human beings need to save our face. When people are down on their knees, reminding them of the obvious risks (definitely obvious to you, but perhaps not so obvious to them) will not only make your relations strained with people, it will also not help the organization. Further, you stand to lose their support, especially when some of your ideas go wrong (as they will), you can imagine being paid in same currency.
  4. Use objective, industry-respected, hard data to support your proposals, especially if people doubt the merit of proposals (as the eventually will !). Nothing works like a fully-baked data to counter opinions of people, especially when those opinions are based purely on personal whims and fancies. However, also remember – it is not your job to respond to every possible objection. Let your work do the talking, but use as much external help as will be required to give wings to your ideas. After that, they must fly by themselves.
  5. If need be, run skunkworks. After all, the programming language Java was developed as a skunkworks at Sun. Sometimes the opposition to your ideas might be so much and strong that you must backtrack. What options do you have? Try running the project secretly. Only two outcomes are possible: either your ideas will emerge stronger, or you will discover limitations of your ideas. Either way, it is your progress. However, make sure you have some allies in the organization lest your efforts be seen as another one of the hobby projects by your already unhappy boss. 
  6. Build allies by sharing success stories from other organizations, making presentations. Most managers are extremely incompetent in the fine art of building allies. We think these are some dirty tricks of an old politician to save his government. Well, guess what, it applies as much to the workplace. The old command and control structure is gone, and in today’s world, we can’t force people to follow what we like. Even the owner of a firm might not always be able to impose his opinions upon the free will of his employees. Largely, that will be resisted tooth and nail, or offered a cold shoulder. You can avoid a lot of heartburn by building allies to support your ideas. (I will write another blog on this very important topic).
  7. Build your personal and professional credibility. If there is a possibility the reason you are not being heard within the organization is because you are not considered competant in that subject, build that credibility by writing articles, presenting papers outside the organization, get involved in your technical community networks, etc. However, this is a long-term effort. In the short-term, your ideas might get you branded as anti-establishment just because you are seeking a major shake-up and that could upset a lot of people who are not only used to doing things a certain way, they have also built their careers doing things that way. By insisting on your ideas, you might only start losing everyone’s support and your own credibility. Learn to feel the pulse of people around you when that begins to happen, and use alternate means to first restore your personal and professional credibility. Be seen as the guy who knows organizational stuff, has a feel for issues facing the company, is seen being a problem-solver, etc. Once that is done, you will be once again seen as ‘one among us’ and your ideas and opinions might then be viewed little more openly then before.
  8. Solve real problems with your change proposals. That will win allies faster than any attempt to woo them by any other legal means. Let the results speak for themselves. No organization can (and needs to) solve all its problems rightaway. Some of your ideas might be little too idealistic for the organization and some might be little too futuristic. On an apple to apple comparison, you might be right in proposing to take up your ideas, but you might be missing the big picture. Instead of taking the situation holistically, you might be able to command better respect (and support) by offering solutions for today’s problems that allow the organzation to move forward. Hopefully, today’s survival will propel the organization to tomorrow where rest of your ideas will be required. If the company doesn’t survive till tomorrow, of what possible use would those holistic ideas be ?
  9. Socialize ideas with engineers in the trenches – the people who will use them. If they understand and embrace the ideas, there would be a better buy-in as compared to the senior management asking everyone to follow. Through the history, we see one consistent pattern: the lower the level at which a revolution started, the more it endured the passage of time. Military coups have not stayed that long compared to people’s marches to democracy. So, don’t ignore the people power. They might not be the decision-makers but together they constitute a huge force that can alter the future.
  10. Don’t give up on the philosophy of the proposal. Don’t take your proposal as a prestige issue. If you can get something done today without losing out on sanctity of your proposal, it might be much better than insisting on a full support that might never happen. Further, the results from what you can do today might pave the way for future proposals. There is never a single best way to anything – if there were, everyone would already be doing it. Give credit to your colleagues, for their resistance to your ideas might be there for a reason. Be open to altering your course without diluting the vision. Just like in human relations, it is not always the content of communication that destroys the relationship – it is often the way it is conveyed. Same way, your ideas might still be palatable if served in the right china.

These have helped me over years, and still continue to help. How about you ?

 

Toyota’s Wisdom for Tomorrow’s Managers…published

In one of my previous posts, I had talked about an article I wrote for business review magazine. It got published in the Dec 2008 issue. The article discusses following ten ‘wisdoms’ from Toyota for its managers:

  1. Open the Window. It’s a big world out there !
  2. Make the most sincere efforts in your assigned position
  3. Taking on challenges is the way to gain experience
  4. Be an Innovative and Creative Thinker

  5. More uncertain the future, more important to have courage

  6. If a problem is left unsolved and the superior is uninformed, neither Kaizen nor cost reduction can be applied

  7. Unless we establish a unique pattern of control and organization, no amount of financial resources will be sufficient

  8. Eliminate muda, mura, muri completely 

  9. Ask ‘Why’ five times about every matter

  10. Trust is key

You can read the article here. 

Change yourself, not the mirror

Change is painful, especially when you have to change yourself. However, in reality all change is really about – changing yourself ! When people ignore this simple and timeless truth, they start accumulating a lot of ‘rigidity’ – growing at the rate of one day at a time, until that years-of-accumulated-and-hardened-behavior becomes a Frankenstein’s monster and an inseparable and indistinguishable part of themselves ! So much so, that they don’t even see that as the problem. I read somewhere that it takes an average of 21 days for a practice to become habit. I think the same must be true for negative change – i.e., refusal to adapt to changes around us. And in, perhaps, as little as 21 days, we just fortify ourselves against the impending and growing change around us. When that happens, another fantastic thing happens. Since we are out of tune with the system, there is a real danger of the system rejecting us. To preempt that from happening, we reject the system ! We criticise the environment around us, we comment on people’s behavior, we become cynical of changes, we are uncomfortable with others enjoying their newfound happiness…and we defend our own stand tooth and nail….and become even more rigid in that process. There is one thing as maintaining your values and convictions, and quite another to be rigid. A hairline separates them, and any judgment is as subjective as any other one. In reality, one person knows the right judgment – you.

The trick, of course, is to view every small, delta, incremental change as something as trivial as driving you brand-new car on a dirt road in the country. Just as you would slow down at every hump or look out for potholes, and chickens and dogs trying to cross the road, so should you in real life.

Mac Anderson is Founder of Simple Truths who make lovely self-help books. In a post, he shared a wonderful story:

A few years ago, British Rail had a real fall-off in business. Looking for marketing answers, they went searching for a new ad agency – one that could deliver an ad campaign that would bring their customers back.

When the British Rail executives went to the offices of a prominent London ad agency to discuss their needs, they were met by a very rude receptionist, who insisted that they wait.

Finally, an unkempt person led them to a conference room – a dirty, scruffy room cluttered with plates of stale food. The executives were again, left to wait. A few agency people drifted in and out of the room, basically ignoring the executives who grew impatient by the minute. When the execs tried to ask what was going on, the agency people brushed them off and went about their work.

Eventually, the execs had enough. As they angrily started to get up, completely disgusted with the way they’d been treated, one of the agency people finally showed up.

“Gentlemen,” he said, “your treatment here at our Agency is not typical of how we treat our clients – in fact, we’ve gone out of our way to stage this meeting for you. We’ve behaved this way to point out to you what it’s like to be a customer of British Rail. Your real problem at British Rail isn’t your advertising, it’s your people. We suggest you let us address your employee attitude problem before we attempt to change your advertising.”

The British Rail executives were shocked – but the agency got the account! The agency had the remarkable conviction to point out the problem because it knew exactly what needed to change.

When confronted, don’t change your mirror – change yourself.

Some ‘universal truths’ of software development

 

Over the years, I have had the good fortune of stumbling upon several universal truths of software development. that have stood the test of time. While some of them were gratefully borrowed from other more competent professionals, several of them have been earned first-hand 🙂

I offer them here for your critique:

  1. Good methodologies  are never at crossroads
  2. “One size, fit all” doesn’t fit any size
  3. Every good thing has a shelf life – and everything was good once
  4. Good engineers and great teams make a bad reference point for future estimations
  5. There are no pre-conditions to performance – especially when you are a manager
  6. People don’t just want to make good software – they also want to build a career alongside
  7. Nothing is new – especially the outside world is far more evolved than we believe
  8. A poor workman blames his tools – and a fool with a tool is still a fool
  9. Software development is not the goal – solving the problem is always the goal
  10. All silver bullets are made of clay
  11. A shaky take-off is better than not starting at all
  12. Best engineers self-train
  13. Project planning is a misnomer – but do it anyway
  14. Leadership is just another name for the response to a stimuli – and hence nobody has a monopoly over it
  15. Not everyone constantly working overtime might be a project’s best friend
  16. Most crisis managers were responsible for that snafu in the first place
  17. Invest in rookies – they will surprise you and everyone else