Nov 29, 2006

Great Mistakes in Technical Leadership

Great Mistakes in Technical Leadership

If you are a good leader who talks little, they will say when your work is done and your aim fulfilled, "We did it ourselves." Lao-Tse, cited in 1

Perhaps the most difficult job to do on any software development project is that of Technical Lead. The Technical Lead has overall responsibility for all technical aspects of the project - design, code, technology selection, work assignment, scheduling and architecture are all within his purview. Positioned right at the border of the technical and managerial, they are the proverbial "meat in the sandwich." This means that they have to be able to speak two languages - the high-level language of the project manager to whom they report, and the low-level technical language of their team. In effect, they're the translator between the two dialects.

Observation suggests that there are not that many senior techies who have the skills and personal characteristics necessary to perform the Technical Lead role well. Of those I have seen attempt it, perhaps ten percent did a good job of it, twenty percent just got by, and the remaining seventy percent screwed it up. Therefore most of what I have learnt about being a good Technical Lead has been learnt by counter-example. Each time I see a Technical Lead doing something stupid, I make a mental note to avoid that same behavior or action when I am next in the Technical Lead role.

What follows is the abridged version of the list of mistakes I have assembled in this manner over the last thirteen years of watching Technical Leads get it wrong. It is my contention that if you can just avoid making these mistakes, you are well on your way to doing a good job as a Technical Lead. You might consider it a long-form equivalent of the Hippocratic Oath "First do no harm," although given the self-evident nature of many of these exhortations, it is more like "First do nothing stupid."

Mistake #0: Assuming the team serves you

Perhaps the most damaging mistake a Technical Lead can make is to assume that their seniority somehow gives them an elevated status in their organization. Once their ego gets involved, the door is open to a host of concomitant miseries such as emotional decision making, defensiveness and intra-team conflict.

I can't emphasize enough how important it is to realize that although the Technical Lead role brings with it many additional responsibilities, it does not put you "above" the other team members in any meaningful sense. Rather, you are on an exactly equal footing with them. It's just that your duties are slightly different from theirs.

If anything, it is you that is in service of them, given that it is part of your role to facilitate their work. To put it another way, you are there to make them look good, not the other way around.

Mistake #1: Isolating yourself from the team

In some organizations, having the title of Technical Lead gives you entitlements that the rank and file of your team do not enjoy. Sometimes, the title is considered sufficiently senior to entitle you to an office of your own, or at least a larger workspace if you must still dwell in cubicle land.

It is a mistake to take or accept such perquisites, as they serve to distance you (both physically and organizationally) from the people that you work most closely with. As military leaders know, it creates an artificial and ultimately unhealthy class distinction between soldiers and officers if the latter are afforded special privileges. To truly understand your team's problems and be considered just "one of the guys" (which you are), you need to be in the same circumstances as they are.

Mistake #2: Employing hokey motivation techniques

Different sorts of people are motivated by different sorts of rewards. Programmers and managers certainly have very different natures, yet it is surprising the number of managers and aspiring managers who ignore those differences and try to reward technical staff in the same way they would like to be rewarded themselves.

For example, managers value perception and status, so being presented with an award in front of everyone, or receiving a plaque to display on their wall where everyone can see it, may well be motivating to them. However programmers tend to be focused on the practical and functional, and value things that they can use to some advantage. Programmers regard the sorts of rewards that managers typically receive as superficial and trite. They have a similar view of "team building" activities, motivational speeches and posters and the like.

So if you want to motivate a developer, don't start cheering "Yay team" or force him to wear the team t-shirt you just had printed. Instead, give him something of use. A second monitor for his computer will be well received, as will some extra RAM, a faster CPU, cooler peripherals, or a more comfortable office chair. It's also hard to go wrong with cash or time off.

Developers are also constantly mindful of keeping their skill sets up to date, and so will value any contribution you can make to their technical education. Give them some time during work hours to pursue their own projects or explore new technologies, a substantial voucher from your local technical book store, or leave to attend a training course that interests them - it doesn't have to be something that bears direct relationship to company work, just as long as it has career value to them.

Mistake #3: Not providing technical direction and context

A common mode of failure amongst Technical Leads is to focus on their love of the "technical" and forget about their obligation to "lead." Leading means thinking ahead enough that you can make informed and well-considered decisions before the need for that decision becomes an impediment to team progress.

The most obvious form of such leadership is the specification of the software's overall architecture. Before implementation begins, you should have already considered the architectural alternatives available, and have chosen one of them for objective and rationally defensible reasons. You should also have communicated this architecture to the team, so that they can always place the units of work they do in a broader architectural context. This gives their work a direction and promotes confidence that the teams collective efforts will bind together into a successful whole.

A Technical Lead lacking in self-confidence can be a major frustration to their team. They may find themselves waiting on the Lead to make decisions that significantly effect their work, but find that there is some reticence or unwillingness to make a firm decision. Particularly when new in the role, some Technical Leads find it difficult to make decisions in a timely manner, for they are paralyzed by the fear of making that decision incorrectly. Troubled that a bad decision will make them look foolish, they vacillate endlessly between the alternatives, while their team mates are standing by wondering when they are going to be able to move forward. In such cases, one does well to remember that a good enough decision now is often better than a perfect decision later. Sometimes there is no choice amongst technical alternatives that jumps out at you as being clearly better than any other - there are merely different possibilities, each with pros and cons. Don't belabor such decisions indefinitely. In particular, don't hand over such decisions to the team and hope to arrive at some consensus. Such consensus is often impossible to obtain. What is most important is that you make a timely decision that you feel moderately confident in, and then commit to it. If all else fails, look to those industry figures whose opinions you trust, and follow the advice they have to give.

Finally, always be prepared to admit that a decision you've made was incorrect, if information to that effect should come to light. Some of the nastiest technical disasters I've witnessed have originated with a senior techie with an ego investment in a particular decision, who lacks the integrity necessary to admit error, even when their mistake is obvious to all.

Mistake #4: Fulfilling your own needs via the team

You will occasionally hear people opine that one should not let the personal interfere with the professional. In other words, difficulties at home should not interfere with the execution of duties in the workplace. In some environments, the obvious expression of emotion is simply taboo. But such ideas don't mesh with reality too well. People are holistic creatures and our life experience is not so conveniently compartmentalized, no matter how desirable some Taylorist ideal may be.

Just the same, there are practical and social limitations upon workplace behavior which some may be tempted to flaunt, to the discomfort and embarrassment of their colleagues. The broader one's influence, the greater the opportunity to co-opt activities that should be focused on work, and turn them to personal effect.

For example, meetings (complete with buffet) make a fine social occasion for those not concerned with making best use of company time. Team-building exercises provide an easily excused opportunity to get away from the office and out into the sun, as do off-site training courses and conferences.

Pair programming seems to be most appealing to those who like to chat about their work ... continually. An excessive focus on group consensus-based decision-making for all technical aspects of the project, even the trivial ones, may be a sign that a Technical Lead is more concerned with the sociology of the project and their place amongst it, than with leadership and making efficient use of people's time and effort.

Mistake #5: Focusing on your individual contribution

Changing roles from developer to Technical Lead requires a certain adjustment in mindset. As a developer you tend to be focused upon individual achievement. You spend your time laboring on units of work, mainly by yourself, and can later point to these discrete pieces of the application and say, with some satisfaction, "I did that."

But as a Technical Lead your focus shifts from individual achievement to group achievement. Your work is now to facilitate the work of others. This means that when others come to you for help, you should be in the habit of dropping everything and servicing their requests immediately. A fatal mistake some Technical Leads make is to try and retain their former role as an individual contributor, which tends to result in the Technical Lead duties suffering, as they become engrossed in their own problems and push the concerns of others aside.

The constant alternation between helping individuals with low-level technical problems and thinking about high-level project-wide issues is very cognitively demanding. I've come to call the problem "zoom fatigue" - the mental fatigue which results from rapidly changing between the precise and the abstract on a regular basis. It's like the physical fatigue that the eye experiences when constantly switching focus from long distance to short distance. The muscular effort required within the eye to change focal length eventually leads to fatigue, making the eye less responsive to subsequent demands. Similarly, you get cognitive fatigue when in one moment you are helping someone with an intricate coding issue, and in the next you're examining the interaction between subsystems at the architectural level. The latter requires a more abstract mental state than the former, and alternating between the two is quite taxing.

As a result, people may come to you seeking help with something that has been the sole focus of their attention for several hours or days, and you will find it difficult to "task switch" from what you were just doing into a mindset where you can discuss the problem with them on equal terms. I find it helpful to just ask the person to give me ten minutes to get my head into the problem space, during which I might retreat to my own machine and study the problem body of code in detail, before attempting to help them with it.

Mistake #6: Trying to be technically omniscient

Just because you have the last word in technical decisions, don't think that it is somehow assumed that you are the programming equivalent of Yoda. With the variety and complexity of development technologies always growing, it is increasingly difficult to maintain a mastery of any given subset of that domain. As in most growing fields, those who call themselves "expert" will progressively know more and more about less and less.

It is therefore entirely possible that you will be learning new technologies at the same time as you are first applying them. The mistakes you make and the gaps in your knowledge will be abundantly obvious to your team members, so it is best to abandon at the outset any pretext of having it all figured out.

Be open and honest about what you do and don't know. Don't try and overstate or otherwise misrepresent the extent and nature of your familiarity with a technology, for once you are found out, the trust lost will be very difficult to regain.

There is an opportunity here to widen the knowledge and experience of all team members. You might like to appoint certain people as specialists in particular technologies, giving them the time and task assignments necessary to develop a superior knowledge of their assigned area. To avoid boredom and unnecessary risk, be sure to give these resident experts plenty of opportunity to spread their knowledge around the team, and to exchange specialties with others.

Adopting this "collection of specialists" approach makes it clear that you are not presuming to be all things to all people; and that you have faith in the abilities of your colleagues. But it will require you to park your ego at the door and be prepared to say "I don't know" quite frequently.

But be careful not to lean on others too heavily. It is still vitally important for you to have a good overarching knowledge of the technologies you are employing, particularly those elements of them that are critical to their successful interoperation in service of your systems architecture.

Mistake #7: Failing to delegate effectively

To successfully lead a group, there must be an attitude of implicit trust and assumed good intent between the leader and those being lead. Therefore a Technical Lead must be willing to trust his team to be diligent in the pursuit of their goals, without feeling the need to watch over their shoulder and constantly monitor their progress. This sort of micromanagement is particularly loathed by programmers, who recognize it as a tacit questioning of their abilities and commitment.

But ineffective delegation can also arise for selfish reasons. Several times now I've seen Technical Leads who like to save all the "fun" work for themselves, leaving others the tedious grunt work. For example, the Technical Lead will assign themselves the task of evaluating new technologies, constructing exploratory and "proof of concept" prototypes, but once play time is over and the need for disciplined work arrives, hand over the detailed tasks to others.

Not only is effective delegation desirable with respect to team morale and project risk, on large projects it is simply a necessity, as there will be too much information to be managed and maintained at once for one person to be able to cope.

Mistake #8: Being ignorant of your own shortcomings

Some people simply don't have the natural proclivities necessary to be good Technical Leads. It's not enough to have good technical knowledge. You must be able to communicate that knowledge to others, as well as translate it into a simpler form that your management can understand.

You also need good organizational skills. Coordinating the efforts of multiple people to produce a functionally consistent outcome is not easy, and demands a methodical and detail-oriented approach to planning and scheduling. If you can't plan ahead successfully, you will find yourself constantly in reactive mode, which is both stressful and inefficient.

If you don't have these qualities naturally, you may be able to develop them to some extent, through training and deliberate effort. But it may ultimately be necessary for you to lean on others in your team to support you, should they have strengths in areas in which you have weaknesses.

Mistake #9: Failing to represent the best interests of your team

Perhaps the most nauseating mistake a Technical Lead can make is to become a puppet of the management above them. As the interface between management and technicians, it is the Technical Lead's role to go into bat with their management to represent the best interests of their team. This means standing up to the imposition of unreasonable deadlines, fighting for decent tools and resources, and preventing the prevarications of management from disturbing the rhythm of the project. A weak-willed or easily manipulated Technical Lead will incur the disrespect of his team.

Unfortunately, such spineless behavior is quite common amongst the ranks of the ambitious, and you don't have to look far to find obsequious Technical Leads who will gladly promise the impossible and impose hardship on their team, in the interests of creating a "can do" image for themselves.

Mistake #10: Failing to anticipate

An essential part of the Technical Lead's role is keeping an eye on the "big picture" - the system-wide concerns that are easily forgotten by programmers whose attention is consumed by the coding problem they currently face.

These "big picture" issues include those non-functional requirements sometimes called "-ilities" - maintainability, reliability, usability, testability and so on. If you don't make a conscious effort to track your progress against these requirements, there is a high probability of them slipping through the cracks and being forgotten about until they later emerge as crises.

If you don't have a dedicated project manager, it may also fall to you to handle the scheduling, tracking and assignment of tasks. It isn't uncommon for Technical Leads to find themselves playing dual roles in this manner. You may not be very fond of such "administrative" duties, but their efficient performance is critical to the smooth running of the project, and for the developers to know where they are and where they're going. Don't make the mistake of ignoring or devaluing these tasks simply because they are non-technical in nature.

Mistake #11: Repeat mistakes others have already made

It is common for developers to dismiss the experience reports of others as having no relevance to their own situation. Indeed, it is wise to approach all anecdotal evidence with skepticism. But it is unwise to completely disregard the advice of others, particularly when it is accompanied by sound reasoning, or can be independently verified. Ignoring good advice can be very expensive; it is said that "Experience keeps a dear school but fools will learn in no other."

The unwillingness of developers to learn from the mistakes of others, and the ease with which you can encounter software project horror stories in the literature and recognize your own projects in them, is evidence suggesting that the software industry as a whole is not getting any wiser.2 You need not contribute to that collective stupidity.

Mistake #12: Using the project to pursue your own technical interests

Remarkably, developers can reach quite senior levels in their organization without having learnt to appreciate the difference between work and play. Many are attracted to programming to begin with because, as hobbyists, they enjoyed fooling around with the latest and greatest technologies. Somehow they carry this tendency to "play" with technologies into their working lives, and it becomes the aspect of their jobs that they value most. From their perspective, the purpose of a development effort is not to create something of value to the business, but to create an opportunity to experiment with new technologies and pad their CV with some new acronyms.

Their technology selection is based upon whatever looks "cool". But a rational approach to technology selection may yield quite a different result to one guided by technical enthusiasm or a fascination with novelty. New technologies are often riskier choices, as the development community has not had much time to apply the technology in varying circumstances and thereby discover its weaknesses and shortcomings. Putting an immature technology on a project's critical path is especially risky. So an older, tried and true technology may be a more rational choice than a new, unproven one.

Mistake #13: Not maintaining technical involvement

In order to fully appreciate the current status of the project as well as the difficulties your team is facing, it is vital that you maintain a coding-level involvement in the project. If you're not cutting code, it is too easy to become divorced from the effects of your own decision making, and to be seen by other developers as being out of touch with the technical realities of the project.

Mistake #14: Playing the game rather than focusing on the target

In some organizations, being a Technical Lead is a politically sensitive position. Technology choices, work assignments and project outcomes are all just tools to be used in the pursuit of personal agendas. To some, this "game" of political influence is both fascinating and addictive. They play it in the hope of gaining some advantage for themselves, and do so to the detriment of the project and the individuals upon it. When they don't have their eye on the ball like this, devoting more energy to Machiavellian maneuverings than to the technical difficulties of the project, then the project inevitably suffers.

Mistake #15: Avoiding conflict

Many people find interpersonal conflict distasteful. Some dislike it so much that they will do practically anything to avoid it, including giving up in technical disputes. Such people are prone to being walked over by those more aggressive and forthright.

This is bad enough for the individual, but worse if that person is meant to be representing the best interests of a team. A meek Technical Lead can be a real liability to a development team, who will find themselves buffeted about by external forces that they should have been shielded from, and burdened by demands and goals that are not informed by the project's reality.

With such a disposition, a Technical Lead may be unable to even deal effectively with unruly behavior or inadequate performance from members of their own team.

Mistake #16: Putting the project before the people

It's one thing to be focused on the project's goals, but quite another to adopt a "succeed at all costs" attitude. Ambitious Technical Leads, concerned with the image they project to their management, sometimes accept impossible goals or unreasonable demands, because they lack the courage or integrity to say "no." These goals then become the development team's burden to shoulder, leading to increased stress, higher defect injection rates, longer working hours and lower morale. There is a tendency to be so focused on the end goal that the effects of the project on the developers gets overlooked. It is not uncommon for successful delivery on a high pressure project to be followed by the resignations of several disgruntled team members, making the project's triumph a pyrrhic victory indeed.

Given the costs of hiring and training staff, treating developers as expendable resources makes no financial sense, quite aside from the ethical implications of such treatment. A wise Technical Lead will know that putting the well-being of the developers first also produces the best results for the project and the business. Project success should leave the participants satisfied with their achievement, not burnt out and demoralized.

Mistake #17: Expecting everyone to think and act like you

Being a Technical Lead may be the first time you are exposed so frequently and directly to the problem solving styles and low-level work habits of others. Programming is traditionally an individual activity. Programmers are often able to face the technical difficulties of their work in isolation, emerging sometime later with the completed solution. But as a Technical Lead you will frequently be called on to help those who are stuck part way through the problem-solving process, unable to proceed. Seeing a solution that is "under construction" might be a bit of a shock to you at first, as you may find your colleagues approach to problem solving dramatically different to your own. Some people work "outside in", others "inside out", others jump all over the place, some work quickly with lots of trial and error, others slowly and methodically. It is tempting to stand in judgment of approaches and methods that don't gel for you, pronouncing them somehow inferior. Avoid the temptation. Learn to accept the varieties of cognitive styles on your team, and recognize that this cognitive diversity may actually be an asset, for the variety of perspective it brings.

Mistake #18: Failing to demonstrate compassion

Although I've put this last, it is in some ways the most important of all the mistakes listed here. Always remember that your team members are people first and programmers second. You can expect them to be temperamental, inconsistent, proud, undisciplined and cynical - perhaps all in the same day. Which is to say they are flawed and imperfect, just like you and everyone else. So cut them some slack. Everyone has good and bad days, strengths and weaknesses; so tolerance is the order of the day.

If someone breaks the build, it's no big deal. If a regression is introduced, learn something by finding out how it got there, but don't get upset over it or attempt to assign blame. If a deadline is missed, stand back from the immediate situation and appreciate that in the grand scheme of things, it really doesn't matter. Mistakes happen and you should expect your colleagues to make many, as you will surely make many yourself.

References

  1. Becoming A Technical Leader - G. M. Weinberg, Dorset House, 1986
  2. Facts And Fallacies of Software Engineering - Robert L. Glass, Addison-Wesley, 2003

Discussion on Change management by Dr Nirupa Bareja

Change is the only constant thing in the world stage

Dr Nirupa Bareja

Introduction

Dr Nirupa Bareja is the ex- group head-HR, Biocon Limited, the biopharma giant of India . With a PhD in Marine Biotechnology, Dr Bareja joined Biocon in December 1989 and she was instrumental in setting up the HR division of the company before working in domains like manufacturing and quality assurance. She lets us know her ideas on change management on her discussions with TAPMI PGDM students

Company

Biocon

Is India's leading biotechnology enterprise. Established in 1978, the company today is an integrated biotechnology enterprise focused on the development of biopharmaceuticals. The company serves partners and customers in over 50 countries. Within the biotechnology space, the company ranks first in Asia in terms of revenues and market capitalization and sixteenth globally.

What is change management

Organizational change management is the process of developing a planned approach to change in an organization. Typically the objective is to maximize the collective benefits for all people involved in the change and minimize the risk of failure of implementing the change. The discipline of change management deals primarily with the human aspect of change, and is therefore related to pure and industrial psychology.

Many technical disciplines (for example Information technology) have developed similar approaches to formally control the process of making changes to environments.

Change management can be either 'reactive', in which case management is responding to changes in the macro environment (that is, the source of the change is external), or proactive, in which case management is initiating the change in order to achieve a desired goal (that is, the source of the change is internal). Change management can be conducted on a continuous basis, on a regular schedule (such as an annual review), or when deemed necessary on a program-by-program basis.

Work flow pattern

Workflow patterns refer specifically to recurrent problems and proven solutions related to the development of workflow applications in particular, and more broadly, process-oriented applications. The different kinds of workflow pattern are

  • Time management
  • Awareness of responsibility level
  • Team building
  • Pride in the work

New systems- Introduction and implement

Change management in her case includes People awareness and training in the HR function, documentation and quality systems in the quality function as well as dedication and hard work in manufacturing domain

Experience in manufacturing industry

Learning exercise

Transforming from a marine bio technologist to the single production girl was a change.

Complete streamlining of manufacturing process

Streamlining a different process and a challenge

Automation of process and system

Production operator’s motivation

Made sure that the motivation level of operators increased and this Increased productivity

New process of performance and management

The next transformation is to the QA department.

Restructuring process

Technical knowledge

Change into the HR function

Unique methodology of Setting the company apart

Optimization of resource

Tremendous sense of team- Open day, kids day

Language barrier

Introduction of novel training methods

Innovative induction process

Advantages of change management

Multiple experiences in different departments

Empathetic with team

Complete cooperation from all the departments

Learning personally each department needs and requirements

Respect of entire organization

Company recognistion

Company Innovision awards and external reorganization

Image and brand building- Individual to company

Company that celebrates together stays together

Stress, communication skills, time management, team building

Social responsibility

Dr Nirupa Bareja

Dr Nirupa Bareja, ex- group head-HR, Biocon Ltd. With a PhD in Marine Biotechnology, Dr Bareja joined Biocon in December 1989 and she was instrumental in setting up the HR division of the company. "I had a very unique role in Biocon and had a domain of my own. I thoroughly enjoyed working in the company. Kiran Mazumdar-Shaw has been a wonderful boss and Biocon is a superb organization. I will continue to have the same relationship with her and the others as it was when I was in the company," she said.

http://www.biospectrumindia.com/content/bioPeople/10502111.asp

DECISION MAKING talk by Prof. Ajit Chakravarti

DECISION MAKING by Prof. Ajit Chakravarti

Session Date: 11:11:2006

Terminology/Learning’s shared during the session:

· Quality Time: Add Value to time. The time during which we achieve what we aspire for

· All Decision Making – makes us move on a path of change

· The More we grow – the more Decision we take by Ease

· Stress Buster: Decision making is like a stress buster, whether decision take was appropriate or not, can be decided later but for that moment it acts like stress buster

Objectives of the session:

· Understand the Importance of Effective Decision Making in Management

· Understand the Role of Time and Relationships in Decision Making

· Experiencing Problem and Opportunity finding Processes in real life business Situations

· Understand the personality Dimension in the decision making process

· Appreciation of the distinction between programmed and non programmed decision

· Appreciation of certainty, risk and uncertainty in decision making

· Understand different decision making models

· Identify individual decision making approaches at the conclusion of the season

Parameters of the “Key Objectives” of the session:

· Involvement

· Sharing and Experience

· Open Mind / Willingness

· Effective Communication

· Risk Taking – Conscious of Consequences

· Participation

Why Decision Making? (A group Brain storming session)

· Life is Full of Opportunities

· Life is a Choice

· Status Check

· New Beginning

· Achieve a Goal

· New Beginning

· Turning Point

· Overcome Crisis

· Status Check

NIKE CASE STUDY: - Key Highlights

· Slow Growth in the market/De Growth

· Competition eating into

· While Reebok looked at short time success – Nike had long time Ambitions

NIKE CASE STUDY: - What decisions were taken by the company?

· Strategy to Specialize

· Decision to “get out of the situation”

· Part of the dream team in Olympics

· Worked on Comfort factor – in relation to the game of Basket Ball

· Longitivity of the Relationships

· Multiple form of identifications found in Jordan

· Teaming up with a “Fading Star”

· Choice of Jordan – why? - Multiple Personalities as Brand Ambassador

NIKE CASE STUDY: - How appropriate were the decisions?

· Relationship as a factor

· Creating a Differentiator

NIKE CASE STUDY: - Some of the Key Findings

· Calculated risk involved in all Decision Making process

· Decision making is a consequence of the prevailing circumstances – which were:

o Connect to the path which is different

o FORESIGHTEDNESS

o Detach and Detached Involvement

· Escalation of the commitment

· Decisions should be frozen on time

· Timing (and Environment) of the Decision making is very important

· Variable in Decision Making - What is there in today may not be there tomorrow

· Time Elapsed (from the time when the decision was taken and to the time when the action was implemented) – sharper perception for what would be there in future

· Game Theory – Decision Maker should create an environment for the decision to be appropriately followed

· Set of Decisions – Make a strategy (example that of many how many leaves make a branch of the tree)

· Closing of the Decision id VERY IMPORTANT

· Set of Decisions – lead to a Grand Play

TIME and HUMAN RELATIONSHIPS in Decision Making:

· Concept of Chinese/Japanese vis-à-vis Americans while signing an agreement

o While Chinese/Japanese make an agreement – for them that’s a start of Relationship

o Chinese/Japanese have a clarity of roles and what stage of negotiation they are in

o Chinese/Japanese would be there on site and not like Americans who would manage with, say – video conferencing

o Chinese/Japanese – while there decision making process – leave room for the “expect the unexpected”

· Decision Making process should not be done in isolation – and also be aware of the party involved in the same

· Time “0” to Time “T1”

Problem Finding and Opportunity Finding

· What is a problem?

· What is an Opportunity?

Example: that of 35 Afro American Farmers:

· Soya bean cultivation

· Problem was to find a new market

· And then Finding an Application (alternate plan)

Problem finding (sensing a plan)

· Deviations from the past experience

· Deviation from a set of plans

· The performance of the competitor

Alert Managers – Sense the same problem early

· Sense of REALITY

· FINE TUNED Perception

· EQ (able to sense thru “with people” through verbal acts

· IQ (ale to sense through knowledge and intelligence

Three Pitfalls

· False associations of events – Wrong Mergers and Acquisitions

· False Expectations of the events – FDI in Retail

· False Self Perception and Social Image – We are BIG, they are SMALL . . . so we will also do it and end up biting the dust)

Opportunity findings

· Missed Opportunity create problems

· Opportunities are found while exploring the problems

· Use of Di – Electical Enquiry Method (Devils Advocate)

Enormous Research on Problem solving where as little research on Problem Finding:

· “Quote Unquote” – Peter Ducker: Opportunities rather problems are the key to organizational and managerial success

· Solving a problem merely restore normality where as progress must come form the exploitation of the opportunities

Problem Recognition












What INFO to Collect




ROLE of JUDGEMENT

PEOPLE with ACUMEN

Example: Many People Leaving the Organisation – Realiszing that many people leaving the organisation id not about attrition but situation of “high pressure” leads to “weak people” leaving the organisation which is for the good og the organisation in the long run

Some more - Terminology/Learning’s shared during the session:

· Failure Avoidance: Let the juniors/subordinate take the decisions pertaining to there accounts and responsibility and let “you” as managers look into the larger interest. Rely on people that what ever task given, they would perform to there optimum level – trust there capability

· Certainty /Risk/Uncertainty

· Atkinson’s 3 Needs Theory:

o Affiliation

o Power

o Achievement

· LIFO – Last in First Out

· Pilot Plan

· Game Theory – You don’t operate in Isolation – take into account the competition

· Self Introspection on Problem Recognition:

o Growth

o Innovation

Nov 21, 2006

Interpersonal Dynamics

Teams: Red Square & Maniacs

Team assignment on case analysis of Bob Knowlton

  1. Identify the various factors that is contributing to the interpersonal dynamics between Knowlton and Fester in their team.

Bob Knowlton

- Felt that his leadership was at stake because a) Jerrold was extremely impressed with Fester and also was expressing that openly with the team b) Fester was very sharp and competent and had solved some old problems c) He felt that Fester was slowly taking over leadership informal control of the team

- Unable to discuss his opinions/feelings/conflicts with Jerrold and teammates a) although Jerrold and Bob share an open relationship, Bob has not indicated to Jerrold that he is having a problem. Because of this Jerrold also does not have a hint what is going on in Bob’s mind b) Bob should have communicated to Fester his roles and responsibilities while he was working in Bob’s team c) ?

- Reiterating the research lab’s and the team’s way of functioning when Fester confronted the team with his own philosophy of research. As a result of this Bob may have lost some self-esteem and the respect of his team members.

- In the face of Fester’s brilliance and challenge to his leadership, Bob did not respond in the manner in which the leader of the team should have done inability to exercise authority and control when parity in team is disturbed. As a result his self-confidence in his capabilities reduced.

Fester

- In the first meeting with Bob, he tried to over project himself. As a result of this he ended up making Bob uncomfortable. The first impression that Fester created on Bob was that of discomfort and annoyance.

- He was judgmental about people

- Very confident about himself and his ideas. Aggressive in his approach to solve a problem and well as put forth his ideas.

- He is rude to people sometimes he thinks are of lesser competence

- Fester thinks that Davenport and Oliver are not competent and he has expressed this to Jerrold. This is creating some division in the team and teamwork is getting affected.

- Challenging the conventional way of problem solving in the lab leading to dispute in the team about fester

- Fester created a perception of himself as a individualist and not a team player

The Seven Habits of Highly Effective People-By Stephen R. Covey

The Seven Habits of Highly Effective People
By Stephen R. Covey
The Two Sides of Success
Aesop’s Fable, “The Goose and the Golden Egg,” is the story of a poor farmer who one day
visits the nest of his goose and finds at her side a glittering golden egg. Though he suspects a
trick, he decides to take it home where he learns to his delight that the egg is actually pure
gold. Every morning thereafter the farmer gathers one golden egg from the nest of the
goose, and soon becomes fabulously wealthy. As he grows rich, however, he also grows
greedy and impatient with the output of the goose. In an attempt to get at once all the gold
in the goose, he kills and opens it, only to find nothing.
The moral of this old fable has a modern ring to it. Like the foolish farmer, we often
emphasize short-term results (golden eggs) at the expense of long-term prosperity (the
goose). Indeed, it seems that we are often more concerned with doing things right
(efficiency) than with doing the right things (effectiveness). In his attempt to be efficient, the
farmer became grossly ineffective; he destroyed his capability for getting the desired results.
In this presentation, I introduce seven habits of highly effective people – habits used
consistently by people who achieve desired results. Albert E. Gray in his essay, “The
Common Denominator of Success,” says, “Successful people have the habit of doing the
things failures don’t like to do. They don’t like doing them either, necessarily, but their
disliking is subordinated to the strength of their purpose.”
Habits are patterns of behavior composed of three overlapping components: knowledge,
attitude, and skill. Since these are learned rather than inherited, our habits constitute our
second nature, not our first. We are not our current habits; hence, we should avoid defining
ourselves in terms of our habits, characteristics, and reactive tendencies. Habits of
effectiveness can be learned, habits of ineffectiveness unlearned.
Christopher Peck Page 2 of 5
www.Holistic-Solutions.net
Successful people daily weave habits of effectiveness into their lives. Often, they are
internally motivated by a strong sense of mission. By subordinating their dislike for certain
tasks, they develop the following seven habits and discipline their lives in accordance with
fundamental principles.
As illustrated, these habits are interrelated, interdependent, and sequential. The first three are
habits of character; they will help you achieve the daily private victory and progress from a
state of dependence to independence. The next three are the outward expressions of
character and lead to interdependence, mutual benefit, and public victories. The seventh
habit renews “the goose” and sustains the growth process.
Habit 1: Be Proactive
The habit of being proactive, or the habit of personal vision, means taking responsibility for
our attitudes and actions. It’s most instructive to break the word “responsibility” into two
parts: response/ability. Proactive people develop the ability to choose their response, making
them more a product of their values and decisions than their moods and conditions.
The more we exercise our freedom to choose our response/ability, the more proactive we
become. The key is to be a light, not a judge; a model, not a critic; a programmer, not a
program; to feed opportunities, starve problems; to keep promises, not make excuses; and to
focus upon our immediate circle of influence, not upon the larger circle of concern.
Habit 2: Begin with the End in Mind
This is the habit of personal leadership, meaning to begin each day with a clear
understanding of your desired direction and destination. Management is concerned more
with efficiency and speed along that course.
Effective people realize that things are created mentally before they are created physically.
They write a mission or purpose statement and use it as a frame of reference for making
future decisions. They clarify values and set priorities before selecting goals and going about
the work.
Ineffective people allow old habits, other people, and environmental conditions to dictate
this first creation. They adopt values and goals from their culture and climb the proverbial
ladder of success, only to find, upon reaching the top rung, that the ladder is leaning against
the wrong wall.
The second or physical creation follows from the first, just as a building from a blueprint. If
the design is good, the construction will go faster and better. Quality, after all, can’t be
inspected into a product; it must be designed and built into it from the beginning.
Habit 3: Put First Things First
This is the habit of personal management, and it involves organizing and managing time and
events around the personal priorities identified in Habit Two.
Christopher Peck Page 3 of 5
www.Holistic-Solutions.net
Studies show that about 80 percent of the desired results flow from a few (20%) “high
leverage” activities. To “leverage” our time, we should devote less attention to activities that
are urgent but unimportant, more time to those things that are important but not necessarily
urgent.
Urgent Not Urgent
Important I Urgent & Important
· Crises
· Pressing problems
· Deadline-driven projects,
meetings, preparations
II Important but not urgent
· Preparation
· Prevention
· Values clarification
· Planning
· Relationship building
· True re-creation
· Empowerment
Not Important III Urgent and not important
· Interruptions, some phone calls
· Some mail, some reports, some
meetings
· Many proximate, pressing matters
· Many popular activities
IV Not urgent, not important
· Trivia, busywork
· Junk mail
· Some phone calls
· Time wasters
· Escape activities
Borrowed from © Covey Leadership Center, Inc
Urgent things act on us and we usually react to them. But we must be proactive to do the
important but not urgent things. Only by saying “no” to the unimportant can we say “yes”
to the important (Quadrant II).
If you neglect Quadrant II prevention and opportunities, Quadrant I crises will disrupt your
life. And if you plan daily instead of weekly, you will live in Quadrant I, and your “planning”
will only prioritize your problems.
Habit 4: Think Win-Win
Win-win is the habit of interpersonal leadership. In families and businesses, effectiveness is
largely achieved through the cooperative efforts of two or more people. Marriages and other
partnerships are interdependent realities, and yet people often approach these relationships
with an independent mentality, which is like trying to play golf with a tennis racket – the tool
isn’t suited to the sport.
Win-win is the attitude of seeking mutual benefit. Win-win thinking begins with a
commitment to explore all options until a mutually satisfactory solution is reached, or to
make no deal at all. It begins with an abundance mentality, a belief that by synergistically
increasing the “pie,” there are pieces enough for everybody. People with a scarcity mentality
believe that there is only enough for the best; they seek win-lose solutions. And people who
are kind but lack courage usually end up with the lose-win leftovers. Effective people model
the win-win principle in their relationships and agreements.
Christopher Peck Page 4 of 5
www.Holistic-Solutions.net
The win-win performance agreement clarifies expectations by making the following five
elements very explicit: desired results, guidelines, resources, accountability, and
consequences.
Habit 5: Seek First to Understand, Then to be Understood
The fifth habit is the habit of communication-one of the master skills in life, the key to
building win-win relationships, the essence of professionalism. Doctors diagnose before they
prescribe; top sales people pre-assess needs and sell solutions to problems, not products.
We see the world as we are, not as it is. Our perceptions come out of our experiences. Most
credibility problems begin with perception differences. To resolve these differences and to
restore credibility, one must exercise empathy, seeking first to understand the point of view
of the other person. Empathic listening is deeply therapeutic because it gives people
“psychological air.” Once people are understood, they lower their defenses.
Hammering emotionally rooted problems by probing is often counterproductive.
Evaluation, sympathy, and advising are also ineffective as a means of gaining understanding
and influence – but they may have value once the other person feels understood.
Habit 6: Synergize
This is the habit of creative cooperation or teamwork. For those who have a win-win
abundance mentality and exercise empathy, differences in any relationship can produce
synergy, where the whole is greater than the sum of its parts. Synergy results from valuing
differences by bringing different perspectives together in the spirit of mutual respect. People
then feel free to seek the best possible alternative, often the “third alternative,” one that is
substantially different and better than either of the original proposals.
Synergy is the human resource approach to problem solving as opposed to a “please or
appease” human relations’ approach. Insecure people tend to make others over in their own
image, and surround themselves with people who think similarly. They mistake uniformity
for unity, sameness for oneness. Real oneness means complementariness.
Habit 7: Sharpen the Saw
This is the habit of self-renewal. As the farmer in the fable learned from sad experience,
success has two sides: the goose, which represents production capability, and the golden egg,
the production of desired results.
It is wise to keep both sides in balance. Yet when people get busy producing or “sawing,”
they rarely take time to sharpen the saw because maintenance seldom pays dramatic
immediate dividends.
The habit of sharpening the saw regularly means having a balanced, systematic program for
self-renewal in the four areas of our lives: physical, mental, emotional-social, and spiritual.
Christopher Peck Page 5 of 5
www.Holistic-Solutions.net
Without this discipline, the body becomes weak, the mind mechanical, the emotions raw, the
spirit insensitive and the person selfish.
It’s the law of the harvest; we reap as we sow. We will enjoy a successful harvest if we
cultivate these seven habits of effectiveness and live in accordance with the underlying
principles.
Resources
The Seven Habits of Highly Effective People, Stephen Covey. Simon and Schuster, 1989.
First Things First, Stephen Covey, Roger Merrill, Rebecca Merrill. Simon and Schuster, 1994.
The Effective Executive, Peter Drucker. Pan, 1970.

The 7 Habits of Highly Effective People' by Stephen Covey.

Leaders visualization of the future --- Giboy Panicker

I will be taking you to two topics and then join them together in the conclusion

Have any one of you seen how the weaver bird build its nest? When it places the first string itself, it’s got the insight how the nest is going to get shaped up. Hope every one of you have done/ or seen a house getting build. The architect and the owner will have the vision of how the house will look like after it’s been build.

Let us discuss the topic on Leader’s visualization of the future

Simple words: To begin with the end in mind. What does it mean? Start any plan with the destination in mind. If you have a clear perception and understanding about your destination, then we know- where we are now and what steps you need to move further, in the right direction.

You must have heard the story of the Alice in wonderland -Rabbit asking Alice : “If you don’t know where to go, how does it matter where the path goes?”

Who is a leader?

Think we all are traveling in an expedition through a forest.

Efficient managers often respond “ we are making good progress” while Leader will climb up the tree and cries out” wrong way”

Powerful proactive leadership must begin with the end in mind. They should constantly monitor the environmental changes and must adapt to the changes.

How a leader finds out that the way is wrong?

Visualization of the future

Effectiveness doesn’t depend on how much effort you spend, but whether or not the effort we spend is in the right direction to necessitate the objective. No management success can compensate for the failure in leadership

We behave differently to different things in life. Take an example of a husband getting a conflict in his time between a party and professional work. What will be his priority ?

.

Let me introduce the topic : Life centerness

Some of the center ness we, we as an individual process

  • Spouse center ness
  • Family center ness
  • Money center ness
  • Work center ness
  • Pleasure tenderness
  • Friend/enemy center ness
  • Religion center ness

Most importantly- your principle center ness

Let us go back to the husband who had a time conflict with his personal and official things. Each of the centernesses comes in his mind. Finally which will happen? One with his centerness will overpower all the others. I will call it the ‘life centerness” I have some live examples of managers who never ventured out of his house on some critical network project execution days because of his family center ness

Conclusion:-

Once you have sense of mission, you have the essence of your own proactively. You have the vision and the values, which direct your life. You behave the basic direction from which you set your long and short-term goals.

Let us visualize every part of our future now. Expand your mind and visualize in rich detail. We have to think how we attain that goal now. Suddenly things are placed in a different perspective and values quickly surface.

We can think of what is our center of influence now. It gives us an orientation where we are heading. Plan your short term and long term goals according to that. Formulate a Personal mission statement, which is a personal constitution. And take it forward from there.