Saturday, May 16, 2015

Achievers take these 3 steps to produce sustained results



To perform well in a current job, you must achieve three objectives. First objective is to deliver the desired job results.This is basic requirement. Only after we produce the desired results in a current job, we can aspire to achieve big tasks in life. 

Average professionals only take these two steps 

Every professional takes these two steps to achieve results in their job.

Identify the KRA in their jobs

First method to identify their roles in the job: There are basically five roles in a job: Doer who does the work, Manager who synthesises the work of doers, Trainer who teaches a skill, mindset or knowledge, Researcher who develops new basic knowledge or application knowledge and Advisor who advises and consults like doctors. Each of these roles have different outputs.

So if you are Doer, you do different tasks. For instance, if you are a programmer in a programming team, your role is to write the program. In you are a doer in sales team, you sell in x territory. If you are working in telemarketing, you task is to call customers in the x territory. You must first understand your prescribed role ( both explicit as well as implicit) in the team.

Second method is to list down the KRA's given by your company. Some companies list down KRA's. For instance, programmer's performance may be evaluated by KRAs such as Writing programs in time, Writing programs with less errors and so on. Or Sales officer's performance may be evaluated by sales calls, sales revenue, sales quantity, new product sales and so on. 

To produce desired results, they make an action plan based on their tasks alone 

Actions have to be taken in one's work area, in the job.

For instance, as programmers have to perform five tasks - Understand the User requirements, Understand the technical design of the software, Write your module programs, Unit test those programs, and Deliver it to Tester - they take actions on these five fronts.

Or if they work as Sales executive, they focus on 4 selling tasks - Understand the technical nature of your product, Prepare to call the customers, Make a call to the customer to understand his requirements and sell, Make a proposal, Close the order - to produce the results.

They assume that doing these tasks better and faster will help them produce the desired results. So they take further training. For instance, Programmers take the training on 'How to code better" or " How to test in a better way". Sales executives take training on 'How to Negotiate' the order.

They assume that if they know something more about their tasks, they will be able to perform their tasks more efficiently. For them producing results is only about doing the task better, faster and easier.

Most of the professionals however stop at this step.

Achievers go ahead and take the next three steps 

Achievers increase their possibilities of adding value in the job by understanding the value chain in which they are performing the job. They take these three steps:

Step 1: They discover the rules of the value-chain in which they function 

Achievers do not restrict their options to the tasks they perform in their job. They look at the value chain of which they are part of. A value chain starts from the understanding what the outside customer requires and ends with fulfilling that customer requirements.

For instance, a programmer is part of value chain which starts with, say, Understanding the business requirement of a customer to delivering the 'software program' to the customer. So typically, a software value chain includes Business Analyst who drafts customer requirement, while designer designs the modules of program, programmers who write the program, and Tester who tests the program, and Go-live team which makes the program functional in the customer's site.

A value chain of  'Sales executive' includes Marketing, Sales, Production and delivery, Commercial transaction, and After sales services.

They investigate and understand the 4 rules of value chain ( at least).

Rule 1: Upstream function impacts the efficiency and effectiveness of the downstream function in the value chain.

For instance, if the Business Analyst is good in listing down all the requirements of a customer, it will increase an efficiency of the programmer. In software, for instance, although business analyst's task may be a very very small fraction of the total output, it is very critical in determining the quality of the total output of the team. If the customer requirements are not understood well by business analyst, the final program will not satisfy the customer irrespective of the quantity and quality of work the programmer. In such a scenario, a programmer has to take extra care before he starts writing his program. In other words, programmer's job  alone ( program) does not determine the quality of final satisfaction of the customer.

Rule 2: Allocation of resources within the functions impacts the results of 'total' work.

If more budget and time, for instance, is spent on 'business analysis', the programmer gets better results in programming, because upstream quality is improved. On the other hand, even if high quality programmers are put in the team, results will improve marginally. Distribution of resources between the functions is a decision that is taken outside the team. If , for instance, your company is more keen on 'selling' and bagging new customer without understanding the business requirements, which often happens, it will directly hamper results of a programmer. 

Rule 3:  Environment-facing functions in the value chain often get incomplete 'information' to produce desired results.

Sales or Marketing function face this difficulty. Staff in these functions often have to spend lot of time in 'sifting' data from the huge pile of data. I had coached a MBA executive working in a new bank. The bank had set up a 'Loan selling' department to increase its 'loan basket'. While the bank was trying to improve its results, executives in loan-selling department could not produce 'desired results' because the ' the company' mistakenly was trying to solve a wrong problem.    

Rule 4: Power structure of the different functions in the value chain impacts a professional's results.

If , for instance, 'testing' function is the 'blue-eyed' function in a software  company, a programmer will struggle to make the company listen to his suggestions. On the other hand, if 'design' is a blue eyed function, a programmer will find it very difficult to 'point out errors' in the design, even if has detected them.

Step 2: Understand the nature of team that is involved in the various stages of value chain 

In the entire value chain, many team members are working. So they investigate the nature of the team and how it functions: who automatically help each other, who help in specific situations, whose help is more critical, and how to ask for their help.

Understand the 'proximity' of team members involved

In the programming team, the team generally sits together in one location. However, as companies try to reduce cost, on-shore and off shore teams sit at different locations. In sales case, the team is sitting at different places, not at one place.

As a rule, when the team members sit at different locations, you will have to spend much more time and effort to gain 'trust' with them. And that will reduce your options in producing your desired results in a job.

Understand the nature of resource dedication in the team

Sometime the team members are dedicated to your value-chain. That helps. Because all team members are working together to produce the 'final result', it is more easy to get cooperation from them.

On the other hand, for making it cost-effective, some team members work in multiple teams. For instance, if you are working in sales, marketing team often works for multiple products and geographies. In such situations, the team members have different 'interest' in producing results in your value chain. This will make it difficult for you to convince them in 'helping you'.

Step 3: Understand the task-interdependency of the team members 

Sometimes the tasks of team members are tightly woven. The interdependency is high. In such situations, the coordination required is very high. Further, when the interdependency is high, it is difficult to spot errors and even to correct them.

This is playing cricket versus playing football. Cricket game has less inter-dependency, while football game has very high. That is why, when something goes wrong in cricket, it is easy to correct. For instance, if you fail as a batsman, it is your failure. But in football, it is very difficult to spot the error. If you are an attacker, did you not score the goal, because you received a wrong ball pass, or was it because you failed to respond to the pass at the right time?

The same is true in corporate teams. When task-interdependency is less, the task boundaries between team members are distinct. I can 'evaluate' if you have done the task well before I take it over from you. For instance, in jobs like programming, it is easier to spot a mistake (and their causes), because the task interdependency between members is less. The task boundaries are distinct. If i am a programmer, I can see the 'Business Analysis' requirement document and evaluate if he has done his 'part' of the overall task.

But if you are in sales job, and not meeting your targets, it is very difficult to diagnose the cause because sales job has much more fluid boundary. Did your sales decrease because the product development function designed a poor product/ Or did it decrease because the policies set by marketing function were inappropriate? It is very difficult to 'identify the cause' and do the correction in one's activities where task boundaries are fluid.

Coordinating not only means cooperating with others to produce better output but also pointing out errors that are hindering the team output. Because value chain is producing the final output, coordinating is more important than focusing on individual contribution in a company, or in playing a sport. And between cooperating and conflict resolution, professionals find it very difficult to resolve conflicts. Cooperating is easier than sitting and identifying the conflicts.

For instance, if a programmer recognises the mistakes of the work done by upstream member (like Business analyst or Designer), he must have the ability to communicate it to the Business Analyst without blaming them. He must also bring it to the notice of all, without sounding like a whistle-blower, and even help correct it.  That is why, in jobs with fluid boundaries like sales, it is important to gain the right reputation within your team and align with your team boss.  

Summary

As you would have observed from the above, by undertaking these 3 steps, Achievers generate many more options in their job. More importantly, they can sustain their achievement for a longer period. They are not playing to win the next match. They are playing to win many more matches. By increasing their coverage of their 'net', they hope to carry more fish. Simply because they have 'wide-scoped' their vision, they can see more opportunities to improve their results.  

But is this enough? It is not enough to know the options. It is also important to exercise those options. Achievers therefore take another step to cash those options. They track the 'System's readiness'. Only if the system is ready, they exercise those options. If the system is not ready, they wait for the 'system to get ready'. They don't just wait. They actively wait. Let us how they actively wait.

Image courtesy:  Chris Shine and Associates

No comments: