Category Archives: Problem Solving

Are you thinking about solving the problem, or simply fixing it?

What is the first thing that comes to mind when we see the problem? Most of us immediately jump in to start solving it. While this might appear to be a natural instinct and a logical choice for some simple problems, reality could often be otherwise, especially for complex problems. If we don’t know enough about genesis of that problem, we might spend countless hours ‘fixing’ it, and yet hardly make any meaningful headway. Or, we might fix it in the short-term, but might not solve it in the long-run, i.e. address the root-cause behind it. For all we know, the first thing we do might actually be the worst!

“If I had an hour to solve a problem, I’d spend 55 minutes thinking about the problem and 5 minutes thinking about the solutions” – Einstein

There is an interesting story about the famous Jefferson Memorial. A few years back, for no apparent reason, the monument was found decaying significantly more than other monuments. At the initial inspection, it seemed like it was acid rain or some such thing, but on detailed inspection, and after asking a series of ‘why’ questions, the root-cause was found to be completely unrelated to the original problem. Here’s roughly how the chain of thoughts proceeded:

Problem: Jefferson Memorial was found crumbling more rapidly then other similar monuments.

Question:Why was Jefferson Memorial crumbling faster than other monuments? Was it due to acid rain?

Answer: It was not acid rain. The monument was being cleaned both inside and outside twice a week with strong cleaning soaps. Upon further investigation, it was revealed that erosion was being caused by soap solution reacting with exhaust from jet fuel from the airport across the river.

Question: Why was the monument being cleaned twice with such strong cleaning agents?

Answer: Because there were lots of bird droppings, which were spoiling the monument, and to keep the monument clean, they had to wash it frequently.

Question: Why there were such high numbers of birds at this memorial compared to other memorials?

Answer: Because there were very high numbers of spiders at the memorial which birds like to eat!

Question: Why there were such high numbers of spiders at this monument?

Answer: Because there were a large number of midges (tiny aquatic inspects) that these spiders love to feast on.

Question: Why were there so many midges at this memorial?

Answer: Because midges were coming out for sex (yes, literally!) at dusk and were being attracted by light which was caused by the floodlights that were being put on just before the dusk – to make the memorial beautiful for the tourists! They would promptly die thus triggering the whole food chain.

So, that was the key. This was a long-lead food chain that had eventually turned into a problem. While the initial possible solutions included building a huge glass cover around the memorial, or even moving the airport far away (both of which seemed like very costly and complex solutions), eventually National Park Service delayed putting on the floodlights by one hour which led to midges population going down by 90% and the food chain was broken, and the problem was solved.

You can watch a nice short video on this from Juran Institute here: 

 

 

This is of course a great application of the Five Whys that was originally developed as a problem-solving tool by Sakichi Toyoda, the father of Japanese industrial revolution, at Toyota and became part of the Toyota Product System. Over the last several decades, several of the principles, tools and practices of TPS have found its way beyond automobile manufacturing, and are now generally considered as a vital problem-solving process for pretty much anything.

So, why this blog post?

Because the subsequent process of initiating required change is not as easy or straight-line as it appears to be.

Surprisingly, we still continue to see knee-jerk response to ill-understood problems that end up paying just a lip service to the real issues. Invariably, the 4th or the 5th why lands us into an unfamiliar territory – another function in an organization that we don’t have control over. In case of Jefferson Memorial problem, the solution involved getting in pigeon expert and then spider expert, and so on. Solving the problem effectively requires people to muster up all their courage and go over the fence and work with stakeholders to change something in their way of working – something easier said than done! There is a nice story of how a mousetrap, meant to be problem just for the mouse ends up being being a problem for everyone else but the mouse himself! It is a nice and simple illustration of how smaller causes cascade into bigger effects, and how trivializing them in the initial stages only ends up growing them into a monster problem that one is simply not able to handle. However, hindsight is always 20/20, and if only we could rewind the problem and get another chance to start it all over.

In my experience, apart from the ignorance about the power of a simple problem-solving tool such as five whys, when it still fails to find an effective solution, it is generally because it requires two different set of skills –

  1. the first is about doing a series of deductive reasoning steps to keep double-clicking on what is being presented as a cause till everyone agrees on the root-cause behind the problem. This needs smart thinking, ability to go beyond the obvious and build and test hypothesis that uncover more deeper issues.
  2. the second part is all about actually influencing people in another part of the organization to go and fix it. Invariably, the reaction is – “that’s not my problem”. In a way, this is like the Butterfly Effect – the flap of a butterfly wing sets off changes in a system causing a chain of events that eventually manifest in something very big in a completely different time and place. Solving this problem, then, is significantly difficult because it requires establishing the entire chain of events that led to the current problem. Given that these events are likely to be spread out in time (e.g., decisions made over time) and space (e.g., different functions in a organization), no one is likely to own them individually.

So, how do you go across organizational silos and ask people to take some preventive action that really solves the problem they have probably not even heard of! In general, making someone agree that they need to change something is hard enough.

I have found the following approach that works in many situations –

  1. First, get all the data. In the absence of data, we are all only conjecturing, and as creative that might be, we need to back it up with objective data to eventually make meaningful and better decisions.
  2. Whenever possible, involve other affected groups or individuals in the process at the earliest. No point second-guessing on their behalf.
  3. If they haven’t been part of the original root-cause analysis, instead of shooting off an email to them asking them ‘what’ is to be done, walk them through the entire process and ask them for validation. At this point, get an agreement on the problem without telling them your view of the solution.
  4. Once there is an agreement on the problem, half the battle is already won. Now start asking them how would they solve it.
  5. An ideal situation is when their solution is same as yours. But that might not always happen. If their solution is different than yours, first understand what is it that they are telling you, and why do they think that will solve the problem.
  6. At this stage, if you are not convinced of their approach, let them know so, and share what your original root-cause analysis exercise has come up with. The idea is not to confront them, but rather present another perspective and to compare and contrast what is better way to address the issue.
  7. If there is a toss-up between these two approaches, it might make sense to go with their solution rather than yours for two primary reasons – they are the primary function owners and hence expected to have better subject-matter expertise and professional judgment than you, and secondly if you go with their perspective, you are likely to get a better buy-in in the long run.
  8. However, if there is a deadlock, and quite often that is the case, one has to be accommodating. A very natural response is to go up the reporting chain and push for our solution, but I haven’t seen that is very productive in the long run. I would give benefit of doubt to the concerned group or the function and ask them to try for a reasonable and mutually agreed upon period of time till we see if the problem is resolved effectively. If it is not getting resolved, it’s time to once again get back to the drawing board.
  9. Hopefully you have an agreement by now on a solution that actually addresses the core issue and solves it. God bless you.
  10. Always remember – today’s solutions are tomorrow’s problems. While you might have solved the problem, in the bargain you might have inadvertently triggered-off another problem that is waiting to be manifest somewhere else in the organization in due course of time. So, keep your eyes and ears open if any new issues are reported – it is quite likely that they are regression effect of the current solution!

In today’s world, solving a problem effectively is as much a hard process as it is an individual and sociological change – affected people need to understand not only the required changes, but also the reasons behind it and adapt accordingly, which is more often than not, very discomforting. In a way, one can even argue that this is not even ‘change management’ – it is ‘change initiation’ which requires chartering unknown waters. Initiating the change requires even higher level of individual courage, leadership and persuasion skills to bring all affected parties on the same page. In a large and complex organization, it means hopping over silos and other political boundaries and tribal cultures and getting them agree to something else. Apart from a very strong understanding of systems thinking, it also needs very high amount of political capital and people suaveness to get it done. It also takes a lot of time to get this done, and most of us are simply not prepared to initiate such transformational change for a variety of additional reasons (e.g., if my performance system rewards result-orientation at the cost of long-haul systemic improvement, how can I demonstrate results by the time next review is due, and so on). So, we settle down for what appears to be second-best – just fix it. In reality, that is just postponing what eventually needs to be done anyhow – and perhaps at an even greater cost!

So, think again – are you thinking about solving the problem, or simply fixing it?

Effective Escalation Practices

This article was provided by Erin Palmer from the University Alliance. Erin writes about project management topics such as PMP certification.

Great leaders know how to focus on project management competencies. Perhaps nowhere in project management do effective soft skills shine through more than in the process of escalation and escalation mitigation. Knowing when and how to escalate requires more than just an intimate knowledge of the emerging issue, but a deeper understanding of the entire business landscape surrounding the events that have led you to this moment. Handling conflict in an action-oriented manner that effectively brings about resolution and promotes team cohesion may at first seem like contradictory goals. On the contrary, effective project managers know that teams work best when trust in leadership is palpable and when team members feel confident that if a problem arises, the leader will expediently and effectively resolve the issue. Strong leaders have strong teams and that is why it is imperative to spend time considering the finer points of an escalation strategy as part of your overall professional development process.

The Art of Knowing When to Escalate 

Establishing long-term communication protocol for all team members is vital to maintaining a feel for the pulse of the project and anticipating challenges before they become full blownissues. Some challenges cannot be avoided, such as a major upheaval in supply chain management when sudden events like natural disasters or international social unrest grind project progress to a halt. It is the more mundane situations encountered over the course of a career that will test your effectiveness more intensely than the occasional huge event. Here are a few questions to ask yourself before escalating.

1. Do I have all of the facts?

Escalation in its purest form is a strategic move. Make sure you have all your facts together and have taken the time to consider alternatives before escalating. If the issue personally involves team members, strategize how this escalation will be a learning tool if at all possible.

2. Will this issue come to a complete surprise to superiors?

If communication is open and effective throughout a project, then your superiors should have some indication that a challenge is present before the escalation occurs. The soft skills involved in finessing communication techniques over the course of a career become more complex and more important as the stakes grow. Be sure that your communication skills grow with increasing responsibility. Seek professional mentoring or other professional development to keep skills current.

3. What do I want from this process?

Escalation as a management strategy involves a comprehensive understanding of outcome goals and long-term project planning. Escalate too many issues and you may be perceived as the “Boy Who Cried Wolf” which may result in the lack of engagement of superiors when you truly need them. Holding back and waiting too long to escalate an issue can result in the project falling apart. Effective escalation takes skill, knowledge, and experience.

4. Am I prepared?

While seasoned professionals will disagree about when or how to escalate an issue, most will
agree that if you are going to escalate an issue you need to be completely prepared. Accumulate your documentation about what you have done so far to mitigate the situation; prepare a concise report detailing any related financials; have clear ideas about your outcomes. You want to be a partner in the process, so involve your team as necessary and engage your superiors as colleagues. An escalation can be an effective learning tool for teams if strategized properly.

Additional Factors to Consider

Effective escalation requires a certain level of professional maturity that emanates from top project managers. When you are in the presence of great leaders, how they handle conflicts and unexpected issues becomes the glue that builds team cohesion and is noticeable from a distance. Every company has divisions and teams that work smoothly despite issues that arise as projects evolve. Project management is a dynamic field with a strong history of building innovative solutions to business’ toughest challenges. It promotes a collegial environment where collaboration is a key element. Developing effective escalation strategies can help you keep your skills relevant and leverage career growth throughout the longevity of your career.

A checklist is more powerful than an org chart?

Most of us so-called ‘knowledge workers’ don’t particularly fancy the term ‘checklist’. It smacks of an antiquated top-down command-and-control Dilbert-style bureaucracy where someone sitting on 42nd floor of corporate headquarters hands down a piece of paper for you to blindly follow and to make you feel dumb and outright humble – for it dilutes your role and underplays your intelligence as if anyone else in your position could have done it! In short, it seems to trivialize the knowledge, skills and expertize required for the job into a mechanical routine requiring no human intelligence, and places the decision-making into hands of people irrespective of their competence levels. And we hate it!

Wikipedia defines a checklist as:

“A checklist is a type of informational job aid used to reduce failure by compensating for potential limits of human memory and attention. It helps to ensure consistency and completeness in carrying out a task. A basic example is the “to do list.” A more advanced checklist would be a schedule, which lays out tasks to be done according to time of day or other factors.”

From the definition above, it seems like an innocuous tool that just helps you keep focus on the most critical things – things that you might skip rather unintentionally or lose track of during one of the numerous hand-offs, or mix-up their sequence when there is time pressure. Obviously, there is no way a checklist could enlighten a dummy into being an expert overnight!

Atul Gawande has done a wonderful job of elevating the good old checklist in his pathbreaking “The Checklist Manifesto” to a modern management tool that can be used to prevent unintentional human mistakes and improve collaboration and decision-making in emergency situations – even in the areas that require utmost brainpower. He cites real-life examples from some of the most complex endeavors – complex human surgeries, constructing tall building and flying jet planes, among others, that no doubt require very high

A short pencil is better than a long memory…

amount of individual cognitive skill in respective functional areas, but also require a high precision in the steps to be followed – both during meticulous planning and preparation, and in making split-second decisions during an emergency, be it flying at ten miles above ground or a complex brain surgery on operation table. One after other, he repeatedly presents compelling data from such hi-intelligence professions that reinforce his assertion that something as rudimentary as a checklist could have such dramatic impact in complex human endeavors.

In this article, I have taken some teasers from this book that I liked and made a lot of sense to me. I have also included my own commentary and perspective for each of these.

Knowledge continues to grow at an astounding pace. No one person can hope to ever keep pace with all latest advances in any one single field, let alone build a body of knowledge around core specialization area and adjacent knowledge areas. And yet, in many cases, we have no option but to rely on the individual judgment by a supposed ‘expert’. What if that ‘expert’ was not good enough, or as good as we make out of them? What if that one single source of true knowledge, the true ‘Master Builder’ was more like someone who was a mediocre talent as best, and could not live up to the high expectations of infallibility, and yet we place almost entire decision-making into their independent charge? That would be a true disaster. Gawande calls out such challenge:

“…in the absence of a true Master Builder – a supreme, all-knowing expert with command of all existing knowledge – autonomy is a disaster. It produced only a cacophony of incompatible decisions and overlooked errors.”

So, while autonomy is the desired end-state, we need to be cognizant that perhaps there is no such single person in real life who deserves to be the undisputed knight of all things worldly! At best it is an urban myth and at worst, it is a nightmare played out multiple times in each field! A cacophony of incompatible decisions and overlooked errors! Sounds outrageous, but apparently not so rare.

Let’s walk a bit with the fact (?) that there is no one single person supremely capable of mastering all the knowledge so as to be the single source of truth. What would then be the second-best way to manage complex human endeavors? Perhaps assign it to teams who are then chartered to figure out the solution? A group of perhaps regular people who individually posses a bit of knowledge each, and collectively represent whatever it takes to address the problem at hand? That does seem like a logical way, because we believe more heads are better than one. However, it is difficult enough to get a collocated team perform in top gear, imagine distributed teams in multiple time zones, contractors from different companies with different and often incompatible cultures and processes working together, employees coming from various departments for whom local departmental gains are more important than the global organizational goals. Can checklists provide some guidance?

Here again, Gawande has some interesting viewpoint:

“in the face of the unknown – the always nagging uncertainty about whether, under complex circumstances, thing will really be okay – the builders trusted in the power of communication. They didn’t believe in the wisdom of the single individual, of even an experienced engineer. They believed in the wisdom of the group, the wisdom of making sure that multiple pairs of eyes were on a problem and then letting the watchers decide what to do.

Man is fallible, but maybe men are less so.”

However, we often believe that by simply crowdsourcing, we can fix the problem. We expect a reasonably sized group to eventually gravitate towards one common solution. While this might be true for simple party games like ‘guess the weight of the cake’, how do we extend and apply this to more real-life problems that entail tangible risks, such as do we need an additional overhead beam to distribute the load on the 37th floor of a highrise building, or whether we need to give more anesthesia to a 63-year old patient of severe diabetes and hypertension on the table for his bypass? In traditional management, a manager would be supremely empowered to make such decisions – his knowledge and experience was ‘supposed’ to mitigate any risks associated with such centralized decision-making, because, well, the ‘workers’ in that quintessential industrial age were after all dumb. In such one-sided match, the worker participation was almost always zero, and the decision-making was the elite preserve of the management class. We can’t say if that was effective or not (though we do know that was not the most motivational way), but apparently that’s the only thing that was! However, the advent of knowledge-economy brought with it three important changes : rapid pace of creation of new knowledge, new means and mechanisms to rapidly mass proliferate the newfound knowledge and a faster obsolescence rate of old knowledge have all collectively led to a more balanced play at work. No longer is ‘manager’ the Mr. Know-all, but is increasingly dependent on the critical inputs from her team member – most of whom have much more current knowledge and also hate a centralized hoarding of decision-making.

In such workplaces, it’s time the decision-making was made more democratic. What would be the risk of democratizing decision-making? Would it be akin to the inmates running the asylum? How can we ensure that best decisions will be made, and who will be accountable for those decisions? Can checklists help in this regard?

“In response to risk, most authorities tend to centralize power and decision making. That’s usually what checklists are about – dictating instructions to the workers below to ensure they do things the way we want. ….it spelled out to the tiniest details every critical step the tradesmen were expected to follow and when – which is logical if you’re confronted with simple and routine problems; you want the forcing function.”

So, apparently, the checklists ‘decentralized’ the decision-making but more as a forcing function. In a way, we can say that since Managers couldn’t be everywhere, Management created Checklists! Clearly, that’s not the best reason to justify or support checklists, even though we might have succeeded in our nefarious designs.

However, history has repeated shown us that every new invention has two sides – the good and the bad. While a checklist might have succeeded in its ‘forcing function’, it also has a positive side. This is the aspect that helps pilots and brain surgeons achieve better planning and performance. This allows for teams to create better bonding as much as making life-or-death calls in a split second. You have the read Gawande’s book to believe that.

So, why is that people hate checklist? Do they fear loss of individuality, respect, authority? Gawande offers some perspective and the counterintuitive wisdom:

“The fear people have about the idea of adherence to protocol is rigidity. They imagine automatons, leads down in a checklist, incapable of looking out their windshield and coping with the real world in front of them. But what you find, when a checklist is well made, is exactly the opposite. The checklist gets the dumb stuff out of the way, the routines your brain shouldn’t have to occupy itself with.”

As an example, he cites an interesting anecdote about what makes a team high performing by a simple act of just making sure that people follow the simple checklist of introducing themselves to the team by just telling their names:

“People who don’t know one another’s names don’t work together nearly as well as those who do.

The investigators at John Hopkins and elsewhere had also observed that when nurses were given a chance to say their names and mention concerns at the beginning of a case, they were more likely to note problems and offer solutions. The researchers called it an “activation phenomenon”. Giving people a chance to say something at the start seemed to activate their sense of participation and responsibility and their willingness to speak up.”

Imagine if the simple act of sharing names could accomplish so much, what else lies unexplored? However, in the absence of a checklist that ‘mandated’ such ‘routine’ we were potentially wasting this opportunity. Surely we could do away (and perhaps should do away) with checklists if only we could do such ‘common sensical’ stuff without them!

So, if checklists are an important management tool, how best to operationalize them? Should the manager ‘own’ the checklisting process? Here is an interesting take from the field of aviation, where, as we all know, once you take-off, you are literally hanging in the mid-air, and hence must do everything right to land safely:

“In aviation, there is a reason the “pilot not flying” starts the checklist. The “pilot flying” can be distracted by flight tasks and liable to skip a checklist. Moreover, dispersing the responsibility send the message that everyone – not just the captain – is responsible for the overall well-being of the flight and should have the power to question the process.”

So, there we are. It seems that there is a significant body of work to support the conjecture that checklists can be beneficial in more ways than one. They are not simply a forcing function, nor do they impede empowerment not stifle creativity. On the contrary, they help facilitate conversations during unexpected non-trivial situations. They also make the decision-making more decentralized and often democratic. To that end, a checklist is more powerful than an org chart. Too bad if that scares you!

Use checklist for all reasons and all seasons. As they say, a short pencil is better than a long memory…

Role of Integrative Thinking in Project Management

I just finished reading the brilliant “The Opposable Mind” by Roger Martin. He introduces the notion that we all possess the so-called  “opposable mind” which has this amazing capability to simultaneously hold two contradictory views about a problem.

The conventional wisdom is to try to find a via media but that is perhaps meekly surrendering to complexity by taking a short-cut to a suboptimal solution. He argues that the some of the most exceptional leaders do not succumb to the obvious “either/or” thinking but rather work patiently towards synthesizing the best from both of these opposing views to create a best-of-breed solution that is far superior to either of these. He calls it “integrative thinking”.

Martin writes, and I quote:

“…the leaders I have studies share at least one trait, aside from their talent for innovation and long-term business strategy. They have the predisposition and the capacity to hold two diametrically opposing ideas in their heads. And then, without panicking or simply settling for one alternative or the other, they’re able to produce a synthesis that is superior to either opposing idea. Integrative thinking is my term for this process – or more precisely this discipline of consideration and synthesis – that is the hallmark of exceptional business and the people who run them.…Human beings, it’s well known, are distinguishes from nearly every other creature by a physical feature known as the opposable thumb. Thanks to the tension we can create by opposing the thumb and fingers, we can do marvelous things that no other creature can do – write, thread a needle, carve a diamond, paint a picture, guide a catheter up through an artery to unblock it. All those actions would be impossible without the crucial tension between the thumb and fingers.…Similarly, we were born with an opposable mind that we can use to hold two conflicting ideas in constructive tension.”

The book is a treasure trove of how go develop integrative thinking, but I was struck by how much it is relevant to each one of us at all levels, not just for the leaders at the top. The field of project management is all about making sensible but often hard trade-offs. Effective management of Project Management Triangle is literally the holy grail of project management – one that not only is the nemesis of every project manager but is also, in fact, the genesis of modern project management. In layman terms, what we mean is that out of Scope, Cost and Time, you may pick up any two, but can never meet all the three of them at the same time. So, if the requirement is to build replica of Eiffel Tower in just three months and ten thousand dollars, then yes, it can be built but it might look more like a school project. If it is a fixed-scope project like migrating all tax payers to a new software by close of the current financial year, then one might need to look at costs involved without which either one of the scope of the time might not be possible to meet.

However, what ends up happening in reality in many situations is that a project still ends up taking the amount of money that is takes, and yet the scope delivered is too little, too late!

If one were to look at modern project management (though most of us in software industry would probably call it as ‘traditional project management’), I think we just don’t have any similar notion of integrative thinking. The only treatment I have seen is perhaps in the Theory of Constraints where the approach is more holistic.

In software development, the conventional project management is modeled around industrial model of a production process – the so-called waterfall. In a linear, sequential flow done by silos that specialize in a single functional area, there is natural tendency and inclination to optimize the area of responsibility. For example, a design team might be most concerned with how elegant their design is, whether is meets the future issues of maintainability or portability or not. Similarly, the high wall between developers and testers is industry-famous – which is a major reason why developers don’t trust testers (“they will come up with only Sev 3 bugs and kill us with volumes towards the release, and expect us to fix them all before GA”) and in turn, testers don’t trust developers (“they can’t write clean code”, “if only they did better code reviews and unit testing and found all code-level defects, we could do such a better job of finding all Sev 1 bugs and focus on performance and reliability aspects”). Clearly, such a process breeds a mutual trust deficit, and the narrowly focused project roles simply perpetuate it further. What happens is the tragic story of optimization of parts at the cost of sub-optimizing the whole – completely anti-lean approach!

Agile software development (the concept, not a particular methodology) helps by offering to eliminate such artificial boundaries that force “either/or” thinking. Instead of taking a monolithic approach of meeting 100% of the project triangle, it offers to simultaneously meet part of the scope at part of the cost in fraction of time that what would normally be needed in a waterfall model. However being recently introduced to this concept of integrative thiking, I am still thinking if agile philosophy fully addresses it, and on the surface, it doesn’t look like. However, I have been proven wrong in the past, so we will see…

How do you measure initiative?

A common feedback at performance appraisal meetings is to take more initiative. We all understand the presence or absence of initiative, but how does one know if one was taking enough initiative or not? Let’s examine one tool that does precisely that.

How can you tell someone who takes initiative? Well, mostly, you don’t have to tell her to do something – she is all by herself taking care of things without being asked to do so. On the contrary, how do you know if someone is not taking any initiative – chances are he is slacking off just doing the routine 9-5 work and generally waiting to be instructed at every step. Let’s develop the model from here.

Stage 1: ‘Wait’

Perhaps the worst and least desirable thing to to keep waiting for someone to come and tell what to do next. This means not only one is not taking any initiative, one is also playing extremely safe to maintain the status quo. We wall this as ‘wait’ on the five-point scale of initiative and is the lowest or default stage. There could be several reasons to be in this stage – demotivation, lack of interest, being too risk-averse or plain insubordination. It is extremely difficult to make someone wake up from this slumber and start being a little more proactive.

Stage 2: ‘Ask’

What does one do to get out of this wait state. Remember, we are talking about taking initiatives and not taking orders. A most natural behavior would be to ‘ask’ your manager to give you some more work! At this point, there is no confidence in us to go out and take up something by ourselves, so the only incremental change in behavior is to ask for work. Asking for work shows an increased awareness of one’s skills and competencies and a higher level of conscience that one must do more than what isbeing asked to do. We call this as ‘ask’ state and it represents the second step to be highly initiative. You will notice that unlike our friend in ‘wait’ state, the person in ‘ask’ state is generally beginning to get uncomfortable with the status quo and feels he could (and should) contribute more, but is not sure where to begin, or whether he has property rights to take up a certain task. He needs lots of support and direction as this point and any negative feedback can crush him and send him back to ‘wait’ state. So, a manager must be extra careful to provide him that little bit of support and understanding.

Stage 3: ‘Recommend’

How does one continue to demonstrate a genuine interest in state of affairs. In the ‘ask’ state, we are still not thinking and taking action, but is surely better than waiting forever. Once one has ‘asked’ for work a few times, two things happen: the person develops rapport with his manager and also develops some knowledge and competencies around the subject. This helps him to raise his stakes a little more by sticking his neck out once in a while and ‘recommend’ an opinion or a course of action to the manager. The act of recommending demonstrates that the person understands what’s happening instead of asking an open question whether he can do something, which essentially means that the person doesn’t really understand which is more important work and is asking his manager to make decisions for him.

Stage 4: ‘Act Independently but Report Immediately’

Now, imagine someone who has made several such recommendations, encounters  real-life situation where no one is around to take permission from. What does he do? He is surely confident of his understanding of the problem and has some idea of laying out a solution for the same. However, he is still not sure if that is the correct solution. This doesn’t stop him from taking the appropriate action that he deems fit, partly also because he has been positively supported by his manager in the past for sharing his opinions and recommendations about possible solutions, so what if not all of them were great ideas. So, off he goes and does whatever he feels is the best thing to do under the circumstances.

After doing something for the first-time by yourself, what is the most natural reaction apart from telling your mom? Telling your manager! Seems like a very right thing to do to build enough air cover should something go wrong – after all, he is still not sure if that is the best way to do to fix that problem. After all, he is only linearly building on his prior experiences, and thinks his manager will support him here too. This fourth stage is ‘taking independent action but reporting immediately’.

Stage 5: ‘Act Independently and Report Routinely’

What happens when the fourth stage behavior is not only actively supported by the manager, but also practiced a couple of times by the individual. It does supergood to the confidence of the individual not just about his subject matter skills, but also the rapport with his manager. Next time such a thing happens, he doesn’t wait for any instructions but simply takes independent action and – instead of immediately reporting, does what is ‘routine reporting’, meaning, he doesn’t feel the urge to either project it as a great accomplishment as a child doing something for the first time, not does he feel the need to build an air cover. He is ‘taking independent action and reporting routinely’.

So, here it is – the five-point model to identify behaviors at different stages of initiative. Try to visualize the behavior of someone new in his job, or working with a new manager, or someone who has just been promoted to take on new responsibilities. In pretty much all these situations, the scale of initiative will be reset and start from the first phase. Gradually, the rapport and confiedence will have to be built to keep moving on the higher stages of initiative. The irony is – when you reach the top stage of initiative, you are superperforming and getting ready for a promotion, and after promotion, you again enter an unknown world in the new role, and drop down back to to level one :). However, that should not be the reason not to take initiative, because only by taking sufficient initiative, you are opening up new avenues.

PS: This tool was introduced to me by my HR Manager, Mali, in ~1998. I haven’t been able to find any literature on it, but have practiced and shared with hundreds of people by now. I like its simplicity and amazing power to chart out your own course in any job, any role. Thanks Mali!

How do you measure your initiative?

Are you splurging long-term dollars for a short-term fix ?

Diagnosing the root cause of a problem is a critical analytical skill. Most often, what you see is not what you get – the symptoms might indicate something, but the root cause might be entirely different. Some cases require a short-term fix – an immediate one, while some require careful investment in the long-term to completely eliminate root cause of a problem. Generally, most problems require a combination of the two. While ‘Process Pundits’ favor a long-term, preventive action, the action-oriented Cowboys can’t wait for eternity and want some short-term, immediate corrective fix to the problem, even if the problem resurfaces a few weeks later. In a way, the corrective-action Cowboys are like John Keynes, who said: “The long run is a misleading guide to current affairs. In the long run we are all dead”. After all, of what possible utility would be a long-term investment if we are not around, say, next quarter. So, no arguments that an immediate need must be addressed first and foremost, but it is like the proverbial firefighting – lack of preventive action eventually leads to emergencies that simply need a big fire hose to douse the fire. Initial trivialization of small incidents only leads to benign neglect which eventually deteriorates into a full-fledged Frankenstien of problems that simply refuse to die.

If initial and repeated trivialization is bad, so is other end of the spectrum – taking every problem far too seriously and calling the army when a watchman will do. In a zest to solve problems, we sometimes make them appear larger than life, and then find solutions that would perhaps address every exception condition, every nook and corner – mindless of the fact that for perhaps 80% of the times, a 20% solution could have done. The result is wasted money, time and effort, and an overbureauracratic process that stifles not just creativity but even the work itself. Look at what happens to our bus driver in this nice story when he takes the problem a little too far: 

One fine day, a bus driver was driving his bus along the regular route. No problems for the first few stops, a few people got on, a few got off, and things went generally well.

At the next stop, however, a big hulk of a man got on. Six feet eight, built like a wrestler, arms hanging down to the ground.

He glared at the driver and said, “Big John doesn’t pay!” and sat down at the back.

The driver was five feet three, thin and basically meek. Naturally, he didn’t argue with Big John, but he was not happy about it.

The next day the same thing happened. Big John got on again, said, “Big John doesn’t pay!” and sat down. And the next day, and the one after that, and so forth.

This irritated the bus driver, who started losing sleep over the way Big John was taking advantage of his size.

Finally, he could stand it no longer. He signed up for body-building classes, karate, judo and all that good stuff. By the end of summer, he had become quite strong.

So the next Monday when Big John got on the bus and said, “Big John doesn’t pay!” the driver stood up, glared back and screamed, “And why not?”

With a surprised look on his face, Big John replied, “Big John has a bus pass.”

Moral: First, be sure there is a problem before working hard to solve one.

Can we relate this story to something at workplace?   Are we sometimes guilty of ‘goldplating’ a problem – perhaps to get enough management attention, or to get enough resources, or simply to promote our interests in the organization ? Goldplating of requirements is a perennial problem for a product manager (or the engineering team – depending on what camp you are from :)). Then again, haven’t we seen the second-time architect syndrome – the architect tries to play so safe to avoid all the problems he faced in his first architecture that the second one becomes a virtual fort – and ineffecient in the short run and quite clumsy in the long run. What about testing ? In last ten years or so, I have seen a dramatic shift in the testing philosophy. From the goal of “good software”, the software industry seems to have gradually moved to “good enough software” and finally to “good enough to ship software”. Look at the amount of patches that download into your system everytime you are connected to the net. Granted that the problem complexity is perhaps a few notches higher than before, and internet has specially made it easier to shorten the feedback look from end-users, but I am sure there is life in between two extremes. No one could test a software forever, but customer surely can do with a little better software :).

So, what do you do when you see a problem? Do you percieve that to be a ‘trivial’ problem and choose to ignore it till it grows tall to your eye-level, or you simply get into a panic mode and raise the emergency alarm? Or, you treat a long-term problem with patches and quick fixes in a hope that sustained amount of small efforts can eventually move the mountain. They sure can, if you are willing to wait for a while. Or, finally like our bus driver friend, you choose to fix a short-term problem with long-term efforts only to realize that you have not only been taken for a ride, but also lost most valuable resource of them all – time. I think the wisdom is in keeping options open until the time it becomes critical to take a call, but institute mechanisms for periodic checks and balances lest you are sent on a wild goose chase.