Ambling down the Tightrope
Date: Tuesday , October 31, 2006
We know of the right as right simply because we are oriented that way since our childhood. So believes Virendra Gupta of Huawei Technologies India. As Associate Vice President, and leader of a team of 290 engineers at the India center, his take on right people for the right role is quite simple: “All of us have the capability, it is the orientation that is important.”
In keeping with this view, Gupta spends a lot of time interacting with the engineers under
him, focusing on their orientation and direction. “It can only be done up to a certain point though. Beyond that, you need to give them the freedom to perform,” he says. In charge of the embedded software division at Huawei India, Gupta strikes what he calls ‘optimal balance’ between business and people. He explains it thus: “India being a services hub, the orientation is such that managers give more preference to people than
business. Engineers too want to have as many varied experiences as they can.”
“Even when they shift to product development, after a year, the engineers feel that they are repeating themselves and want a change. They want to move over to a different product,” he says. Gupta’s years in Huawei have taught him to decipher the fine line between logic and emotion in such cases and figure out whether such a movement will benefit the company’s business. “Most often than not, such frequent movement hurts the organization. Hence the need to educate engineers of the value of expertise, and how they stand to benefit by staying on the same product,” he notes. For this, the techie’s accomplishment and his contribution to the company need to be pointed out at regular intervals.
The eternal challenge for project managers, believes Gupta, is to ensure higher quality. Central to this are the following tenets:
1. Risk management.
It is one primary area that managers often fail to address. As a result, in the event of a crisis, people have to work overnight to rectify the problem. A good project manager needs to identify what may go wrong—the symptoms are very much present in the environment, he says—and amplify them,
so that it becomes evident to everybody.
Gupta’s own take on risk management was fashioned out of a bitter experience. The contract between the customer and the company he was then working for had been signed, and the commitment given by the marketing team was not in proportion with the work involved. In charge of the group responsible for delivery, and not able to foresee the impending problem, Gupta delegated project responsibility to one of his direct reports. “I over-relied on him,” he recalls. The deadline tightened its noose around Gupta and he gasped for breath. Desperate for a way out, he committed what he says is the second cardinal pitfall of project managers—excuses.
2. Result orientation.
“Every project manager is a mini CEO, and must function like one,” he says with understated conviction. Rather than building a repository of excuses—as he had been laden to do on that occasion—he must learn to take responsibility. “Customers do not care for excuses. Whether the excuses are justified or not, in the end, the project manager must own responsibility.” Be it success or failure, he must bear the brunt, says Gupta, likening leading a project to owning a business. As in one’s own business, there is a need for managers to be proactive, and drive the environment towards success. Over and above all else, there is a need to walk the tightrope between the organizational goals and the project objectives.
3. Standard setting.
Once the balance is achieved, it is important to focus on setting standards. Once again, the presence of a large number of services people in the products arena means that the horizon is muddled in the latter. “Engineers fail to shift their focus from the number of people to building expertise in the organization,” says Gupta. Generally, they are all concerned about playing it safe, and in the event of being assigned a higher goal, their automated response is a ‘cannot be achieved’ statement.
He cites an example from his early days in Huawei to illustrate the point: Gupta had set the standard of requirement stability for projects at 100 percent. “Most of the project managers unequivocally said that it was impossible,” he recalls. A few of them really tried and were successful as well in achieving it. Broadly, the attempt on part of the managers was missing. Such cautious tactics are resorted to for the fear of outright failure, but there is hardly any substance in those fears. “You always begin with some ground,” he says.
4. Quality consciousness.
A spin-off of wanting to play it safe is the ‘wanting to finish’ phenomenon. “Project managers across the board believe in only ‘reasonable’ quality,” he notes. Not only do they need to ensure ‘best’ quality, but they must also plan for long-term capability in the team. The requirement is an action plan for building tools for higher deliverance. As part of his own efforts to ensure quality and long-term capability, Gupta has constituted a number of task forces, one of them, for example, is working on improving the code review checklist. The team is responsible for identifying and developing specific sections of checklist for facilitating focused reviews, so that project managers can allocate each section to different reviewers based on their experience and knowledge.
As part of his own people management principles, Gupta enunciates a practice that is pretty much a reflection of his demure persona. “Poor performers are a perennial bane, no doubt, but it is important to identify the reason behind their lack of polish,” he says. More often than not, it is a matter of skill mismatch, and changing the domain of employee turns him into a winner. “At times there are attitude issues though, and then you need to be tough,” he points out.
A tête-à-tête with Gupta confirms that he is a quite a lover of harmony. Be it his words or his practices, there are hardly any jagged ends. Even while choosing project managers, he maneuvers with caution. “The character of the project must synchronize with the attributes of the manager to whom it is assigned,” he says. A specific project, for example, might need an aggressive lead, and it would be hara-kiri to assign it to a laidback engineer.