Becoming A Star Engineer-Part III

This is final part of article of Becoming A Star Engineer.You can go through Part-I and Part-II.

Becoming a star

We conducted a long-term study evaluating how productive engineers were before and after they had learned star work strategies by going through our productivity improvement program. Currently called Breakthrough, this program has been taught for the past seven years to over 1000 people in many companies not only in the United States but in Europe as well. It is licensed to professional training companies and is being used in universities both in the classroom and for staff development

As a basis for our evaluation, we met with managers, star performers, and average workers, asking them to list the factors indicative of increased productivity in a person working in their departments. Several iterations ensured that people who rated highly on these factors were indeed highly productive.

Then we asked direct managers to rate 300 participants and 300 nonparticipants on this list of productivity factors, once before the training sessions began and a second time eight months after finishing the program.

On the basis of these managerial evaluations, program participants were found to have increased their rate of productivity improvement significantly. The engineers who went through the program solved problems faster, produced higher-quality work, and consistently impressed their customers.

The star strategies program is not a remedial course for poor performers. About 30 percent of the participants taking part in our productivity improvement programs already were wearing the star producer label. Their productivity gains have been similarly impressive.

The most dramatic changes were in the ranks of women and minorities, according to their bosses’ pre- and post-evaluations. Their productivity improvement rates shot up 400 percent on average.

The success of these groups underscores a key finding in our work. Becoming highly productive does not require magic. When engineers produce at undistinguished levels, it is seldom because they are less capable–it is because they never learned the work strategies that lead to high productivity. Once these engineers are given access to the star strategies, their productivity takes off.

Author :Robert E. Kelley

Share this post

Becoming A Star Engineer-Part II

This is the continuation of article from my last post-Becoming A Star engineer-Part I.

Nine work strategies

So, if you are an engineer searching for a productivity boost to your intellectual capital, what must you do to dazzle everyone? Prior to our work, an answer did not exist. The star work strategies were taught nowhere, not in school or on the job. For the most part, it was a matter of trial and error. But many technically competent engineers make too many productivity errors to end up as more than average. For example, they fail to take initiatives or take initiatives of no importance to the organization.

We found that you need to change how you do your work and how you work with others. Star performers in fact do their work quite differently from the pack. They weave their starring strategies into a consistent pattern of day-to-day behavior. But any engineer with the necessary smarts and motivation can acquire their power.

All the same, no Big Bang revelation unleashes this kind of productivity. No magic pill or silver bullet will blast you to the top. Instead, stellar performance is based on a set of nine interlocking work strategies. They are ranked in order of importance and synthesized into an expert model.

1. Blazing trails

What did you think of Henry and Lai? Did you see Henry’s emphasis on just technical competence as undervalued or Lai as being rewarded for, well, schmoozing?

Average performers, like Henry, imagine initiative is coming up with ideas for doing their job better or volunteering for little extras in the workplace, like planning the annual picnic or recruiting people for the blood drive. Indeed, Henry believed he was taking initiative. “I gathered up the latest technical information and learned about the latest software tools so that I could do a bang-up job on my assignment. Nobody told me to do any of that,” he told us.

What Lai understood, and Henry did not, is that only certain actions earn the initiative label. Star-quality initiative means:

  • Seeking out responsibility above and beyond job description (as when Lai installed the PC software), while still completing your core assignment.
  • Undertaking extra efforts for the benefit of co-workers or the larger group, as when Lai offered to help fix the software program on her co-workers’ project.
  • Stepping willingly into the gaps between job descriptions where important work often pops up, grabbing your share of it, and doing a bang-up job on it.
  • Sticking tenaciously to an idea or project and following it through to successful implementation, as Lai did when she worked the extra days necessary to install the new office software.

Many average performers suppose the only worthwhile initiatives are on the order of inventing a commercially successful new product, like the object-oriented Java language. If something will not make the front-page of The Wall Street Journal under a headline proclaiming a steep climb in bottom-line profits, then it isn’t worth the effort.

Star performers in our studies were adamant that while they are always looking for roof-raising initiatives, the small, day-to-day efforts had the same impact over time. Moreover, they noted that the whopper initiatives tend to follow a long string of lesser efforts. If the work climate you create does not value small initiatives, they will dry up and the big ones will never get a chance to happen. Lai’s helping-hand initiative, for instance, may have given a co-worker the breathing space needed to make a meaningful breakthrough.

The stars also believe that expectations about the initiative you may take hinge on your level of experience. As a new employee, Lai was not expected to take big initiatives, but her record of taking smaller ones pleasantly surprised her co-workers and soon established her reputation as a productive engineer. As she gains more experience, Lai will be expected to take on higher-level initiatives of greater difficulty and riskiness.

Our observations of Henry, Lai, and hundreds of other engineers show that any newcomer in a unit of professionally skilled, competitive workers must demonstrate initiative. Such behavior impresses managers, but more importantly, it impresses your co-workers and customers. Co-workers look for people who do not lock themselves within a rigid job description. They want colleagues, like Lai, who are willing to step into the gaps between jobs because they know that if the new worker does less than her or his share, the rest of them will have to carry more of the load. They need people who extend themselves–whether it be to their colleagues, to the customers, or to the changing needs of the marketplace.

Customers are also looking for these characteristics in the employees they encounter. A new hire who falls short of these expectations will be relegated to the pack, labeled, perhaps like Henry, as competent but not productive in ways that benefit the group.

2. Knowing who knows

Average performers think networking just means building a grapevine for learning the latest office gossip, or socializing with people in their field and with executive head hunters who can help them in future job hunting.

Star producers engage in addition in a more important type of networking. As they realize, the information overload of today’s society means that few people know all they need to know to get their jobs done. They know maybe 50-80 percent, and until they can make up the deficit, they are stuck. What helps the stars get unstuck is effective networking.

A star knows it is vital to develop ahead of time dependable two-way streets to the experts, who will help each other complete the tasks critical to the bottom line. The goal is to minimize the knowledge deficit that every engineer discovers as she or he measures up to a new job.

Stars’ networks differ from typical workers’ networks in two important respects. They have the right people in them, and they are faster.

The people in their networks can provide the right answer the first time. Average performers get wrong answers more frequently either because they ask the wrong people or because the experts with the right answers are not in their networks. So they spin their wheels or go down blind alleys.

The faster networks get the stars unstuck and back on the task sooner than the rest. If it takes a star a half-day to get an answer, it takes the others one to two days to get it and often it is wrong. Over time, these extra days add up.

Better-connected and faster networks allow the stars to turbo-charge their productivity, so that they outpace the average performers, who might have similar talent, but go it alone.

Claudio, an information technology consultant working for the international consulting firm, Andersen Consulting, was assigned to write a contract proposal to a tight deadline. At stake was a $500 000 contract for providing information technology support for bio-assaying processes used in biotechnology firms.

Claudio remembered an undergraduate classmate who had gone to work for Genentech Inc., the industry leader, and called her. In turn, she put him in touch with the scientist who had pioneered the assaying process. In just two afternoon phone calls, he got the information critical for his report.

Contrast what befell Newt, an Andersen colleague of Claudio’s who needed the same information. Instead of thinking through his network, Newt followed the company’s recommended procedure and posted his question on the in-house electronic bulletin board. When he logged into his computer the next workday, 40 leads were waiting, all of which had to be plowed through. Many of the messages contradicted one another, but as he knew none of the people who responded, he could not to judge the quality of their answers. He was essentially still at square one with 40 potential leads to track down.

Thus, while Newt was still struggling with his information overload, Claudio had already used his starnetwork to move faster and farther ahead.

The current rage in many upper management circles is to embrace computer intranet-ing as the high-tech solution to knowledge deficits. Managers spend millions of dollars on additional computer hardware and software, believing workers like Newt can e-mail their way out of such quandaries. But successful networking is most often accomplished in one-to-one interactions, not in the impersonal, one-to-many format of computer technology. Star networking entails building, maintaining, and operating within a group of experts who share knowledge for mutual benefit. It has little to do with technology.

3. Proactive self-management

Average performers believe self-management means managing time and projects better. If their work is done within schedule, budget, and specifications, then they must be good self-managers.

Star producers know that much more than time or project management is at stake. These requirements you are expected and paid to meet. Their work strategy helps them proactively create opportunities, direct work choices, perform extra well on the job, and carve out a career path. It enables them to develop a portfolio of talents and work experiences that increases their value to the company.

Elena worked in the R&D department of an advanced materials ceramics company supplying the auto industry. She requested travel funds to attend a productivity and quality conference. As it was not directly related to her work, her boss could not see the point; besides travel funds in the budget were low. Elena was undeterred. Since she believed the conference would make her more valuable to the company, she took vacation time and paid her own way.

While she was there, she learned about Europe’s upcoming quality standard, ISO 9000. The goal of these bidding requirements was to ensure higher-quality raw materials, products, and processes–all to give European companies a greater competitive edge in world markets. If a supplier company, like hers, could not meet them, it would not be allowed to bid on European projects.

Elena came back all jazzed up. On her own time, she got up to speed on ISO 9000 requirements and explained them to her work group during a brown bag lunch. Pretty soon her co-workers were excited, too, enough to go to their management and persuade them of the benefits of getting ahead of the learning curve on Europe’s ISO 9000 bidding specs.

Upper managers were a harder sell. They were skeptical that the Europeans would ever agree on these new standards, let alone enforce them. But Elena kept working the decision-makers, sending them articles and writing memos about the benefits of being first. Finally, the top executives saw some concrete advantages and got behind the idea. Europe is now the company’s biggest customer and the company’s improved quality is attracting U.S. business as well.

The company’s increased success sprang from Elena’s self-management. She took it on herself to enhance her value despite her unsupportive manager. She was also spotting opportunities to increase the company’s value. Finally, Elena’s actions point up the interconnectedness of the work strategies. Her self-management also involved initiative–a willingness to move beyond her narrow job description, beyond even the boss, to reach a goal that benefited everyone. To top things off, she refused to give up.

4. Getting the big picture

Average performers suffer from tunnel vision. They see the world from their viewpoint only and keep pushing the same points over and over again.

Stars, in contrast, step outside their own viewpoint and adopt a variety of perspectives: “How do my customers think about this? What do my competitors think? How about my colleagues? What about top management or the shareholders?” Because they can evaluate the relative importance of a variety of viewpoints, they are able to improve on the product or develop better solutions to problems.

Star perspective grows out of getting enough experience to develop pattern recognition. Sarah took a software development job in Silicon Valley after completing her master’s degree in computer science. During school and on her software designer job, she kept a notebook of observations on the solutions to common problems. Every night, she would review the notebook, looking for clues and patterns like another Sherlock Holmes.

With her combination of practice and experience, she certainly kept up with the other new hires, but what eventually separated her from the pack was her internalized grasp of software and computer logic. Co-workers were quick to recognize her insightfulness, seeking her help in surmounting their brick walls. Such encounters gave her valuable exposure to problems she would not have faced in her own work.

After her first year, Sarah stunned her colleagues by requesting a transfer to software testing, an assignment often mistakenly considered second-class, a career dead-end. The tester checks on others’ work, to determine if the software does what it should. There is scant personal satisfaction of the kind that comes from creating new products. Software developers tolerate testers, albeit reluctantly and usually defensively, as the necessary bearers of bad news–identifying bugs and checking for quality.

But Sarah saw the tester job as a chance to understand her work from a fresh and crucial perspective. She would become familiar with a wider range of problems that could make software fail. She would gain years’ worth of experience in just a year or two. She would collaborate with top customers on building testing programs of relevance to their perspective.

In the process, Sarah would avoid mistakes of substance and perspective in her own future software designing. Testing also opened a window into the perspective of her colleagues. She learned techniques her co-workers used in writing software and corrected flaws found during the testing process.

When Sarah returned to software development two years later, the testing stint started to pay off. Her colleagues were soon referring to her as the Zen Master of software, and she became known as a leading software guru, helping propel her company to the top in Silicon Valley.

Star performers, like Sarah, who have mastered the nuances of perspective, were not born to the art of it. They seek it out and cultivate its benefits.

5. The right kind of followership

Average performers believe that followership–that is, the relationship with people having organizational authority and power over them–means showing managers and co-workers that they know how to toe the line, take orders without question, and not threaten the leader.

Star producers learn very early the importance of a more positive form of followership, of being a good No. 2–that it is often more important to make the assist than the score. They are actively engaged in helping the organization (and usually the leader) succeed, while exercising independent, critical judgment about what needs to be done and how to do it. Star followers work cooperatively with a leader to accomplish the organization’s goals even when there are personality or workplace differences.

This finding was surprising since it contradicts what many people think–that a star is always a leader or the center of attention. Often star followers support the leader by alerting him or her to trouble spots, by serving as a thoughtful sounding board, or by challenging the leader’s decisions.

In many technology companies, a fine line must be walked between what the company believes the customer wants and what the knowledge workers think is best. I often hear bosses complain that theirengineers are building a Rolls Royce when the customer only needs a Dodge. Enamored of their ability to build the best, workers want to attach all the latest bells and whistles, even though this can lead to delays or budget overruns.

In one such exchange, a star engineer at Bell Labs had to confront the boss’s nagging about his extra efforts. The boss wanted to ship a stripped-down call-routing feature for the telephone switch in order to come in ahead of schedule and win points with the customer.

“Forget about all the extras. The customer would rather have a basic model today than the greatest model one month from now,” she said.

Not necessarily, said the star performer, and sat down with her to review the product’s short- and long-term goals for this customer and others in the marketplace.

“Sure, there might be short-term gains with this customer,” said the follower, “but there are risks, too. They may relegate us to the low end of the line when we have staked out the high-end market. Also, if we do the extra work on this customer’s product now, we’ll save on product development time for other customers already in the pipeline. But let’s find out what the customer prefers.”

Our star as follower understood the boss’s immediate concerns. At the same time, he tried to shift her perspective to the larger overall goals they shared. When possible, such followers temper their own efforts so that they fall in the range of company objectives–or they find an organization that is a better match.

6. Teamwork as joint ownership of a project

Average performers think teamwork means working cooperatively with others on a project or problem and doing your part on the team.

Star producers take it to a higher level. They see it as a complex series of skills that involve taking joint “ownership” of goal-setting, group commitments, work activities, schedules, and group accomplishments. It also means being a positive contributor to the group’s dynamics–helping everyone feel part of the team, dealing with conflict, and assisting others in solving problems.

A medical equipment supplier formed a crisis team because hospitals were furious over recent failures in the companies’ latest critical care monitors. The equipment gave off emergency warnings at random, distressing both patients and the hospital staff who would rush into triage alert only to find nothing wrong.

The team consisted of professionals from five departments, including production, research, and customer service. Of the group’s seven members, the only star was Aiden, an engineer who had moved into customer service to learn more about that side of the business.

During the third hour of the first team meeting, a heated debate erupted over what action should be taken immediately. Ewing, a 53-year-old production engineer with 25 years of experience at the company, argued for continuing to send repair people to the disaffected hospitals to fix the machines on site. But Julie, a recent hire in the research department, argued for following Johnson & Johnson’s lead from the Tylenol disaster–recall all the machines.

The discussion dragged on, with Ewing and Julie getting more heated and less civil. Aiden noticed that he and others were getting frustrated and fidgety. Rather than let the matter go unchecked, he mentioned it, and upon getting nods of agreement from several of the others, he suggested, “Why don’t we take a 10-minute break, so that we can all take a breather and maybe find a way around this?”

When the meeting resumed, Aiden thought he could break the impasse by asking Julie to present and argue for Ewing’s approach and getting Ewing to argue hers. Although both Julie and Ewing were wary, the tactic defused the mounting tension and anger. Then other group members started to bat ideas around. Eloise, an experienced but shy designer who sat in the corner and had not said a word all day, spoke up in a soft voice: “Since not every hospital is complaining, shouldn’t we first find out why these particular machines are malfunctioning? Either they’re broken to start with, or something is going on in the hospitals they’re in. So, rather than pull all the machines, maybe we should pull only those having problems and gather information on each setting to see if something there is causing the problem, like a high magnetic field.”

No one commented on her idea and the discussion resumed. After a few minutes, Aiden joined in, saying, “I’m not sure everyone heard Eloise’s suggestion. I think that she might have a way out of this for us. Would you mind repeating it for us?”

With that, Eloise made her point again. Aiden observed that it demonstrated customer responsiveness but was less expensive than a total recall. The rest of the group then supported Eloise’s suggestion to get through the group impasse, and moved on to other topics.

Without Aiden’s intervention, Ewing and Julie might still be fighting, Eloise might never have been heard, and the group might have floundered indefinitely. By going beyond his role as the customer service rep to the team, Aiden was able to improve its effectiveness.

7. Small-l leadership

Average performers are fascinated by leadership with a big L: Big Vision, Big Charisma, Big Success. To them, leadership seems an in-born trait whose owners can flaunt their egos by being in charge, having the power to make most key decisions, and delegating whatever does not interest them.

Star performers, on the other hand, view leadership as a work strategy that builds on expertise and influence to convince a group of people to unite on a substantial task. The undertaking can involve a range of efforts–helping the group create a clear vision of where they want to go along with the high commitment and trust necessary to get there; finding the resources to accomplish the task; and shepherding the project to successful completion.

We all know very smart people who couldn’t lead a one-car funeral. Other critical skills besides intelligence are involved in leadership with a small l. Small-l leaders understand the human relationships that link people to each other, whereas Big Ls are much too focused on their own ideas, their own work styles, their own goals. Small-l leaders know they need to take into account the needs, skills, aspirations, and power of their co-workers on a project or team.

This focus outside the self is productive because of a work place reality that Big Ls often overlook. Small-l leaders seldom have formal authority over those they want to lead. Peers will go along only if they believe a member of the group who wants to lead is acting in their interest as much as his or her own. Bringing them around requires the kind of interaction that Big Ls believe is a waste of precious leadership time. The small-l leader who bonds with co-worker followers by slogging through the daily project grind and sharing late-night pizzas while meeting deadlines earns more loyalty and credibility than even the most charismatic Big L boss.

The big secret here from our star performers–the secret that separates them from Big Ls and other average-performing leaders–is their refusal to assume they know everything about other people. Most Big L hype portrays the leader as omniscient. The Leader knows what’s best for the followers and for the situation.

Our star performers make a habit of asking first, even when they think they already know. Anithia, a U.S.-based software designer for a German-owned business, rarely begins a new project without testing her assumptions about her co-workers. When assigned to lead six co-workers in a project to develop a new software program for the Internet, she took time out from the first meeting to ask about work roles and assignments.

“John, during our last project together, you said that you wanted more hardware experience. Is that still the case? Because this project has a strong hardware component to it.”

Like a perceptive psychologist, Anithia suspended her own assumptions and asked empowering, open-ended questions that got people talking about what skills each brought to the table and what each one wanted from the project. As a result, she was able to match work assignments to individual skills and interests more closely. She wanted to avoid pigeonholing her co-workers, in the way Hollywood producers do when they type-cast actors.

Of course, employees cannot always get everything they want. But with the sincere offer to listen and the attempt to meet some needs a small-l leader without formal authority wins a lot of influence. Those efforts also provide the firm platform needed when the inevitable stresses hit during the project’s crunch times. Demonstrated superiority in a technical area may in any case justify some small-l stars in becoming an interim leader. But they know that hierarchy does not extend to the interpersonal side, where instead, they try to create a we’re-all-in-the-trenches-together attitude.

To software designer Anithia, the Internet project in which she acted as small-l leader proved a huge hit with customers. At the annual awards banquet, the president of the North American division praised it as being “vintage Anithia.” Inviting her to the stage, he compared it to other successful projects Anithia had led in the past. If the company had 500 more like her, he said, domination of the U.S. market would be assured. Then, he summoned her to the podium to speak.

Like so many self-important actors clutching their Oscars, Anithia could have rushed through the standard nice words about her boss and project members. Instead, she invited them all on stage with her and asked one of them to introduce each member of the group. Then she stepped to the microphone and said, “This project was the result of our effort; without each person’s contribution, it would not have been the success it is. We were proud of it, and glad that you are, too.” Then they took a collective bow.

8. Street smarts

Average performers focus overly on ingratiating themselves as the surest way to get ahead in the workplace. They also pay obsessive attention to office politics or patronizingly ignore it.

Star producers know that any large organization has legitimate competing interests. Organizational savvy enables them to steer their way amid these clashes, to promote cooperation, address conflicts, and get things done. It can involve expertise in managing individual or group dynamics, understanding when to avoid conflicts and when to meet them head on, and knowing how to make allies out of potential enemies.

Remember Sarah, the software-developer star introduced in Strategy No. 4 on perspective [p.54] who volunteered for a stint in the testing section, though her co-workers thought her crazy to do so. She also identified people with whom she would interact in the future and began building working relationships. These organizational bonds not only raised her standing in their eyes, but also smoothed the way for future interactions.

Elena, the star performer from Strategy No. 3, on self-management [p.54], used extensive organizational savvy to focus her company on ISO 9000 and the opportunities presented by the European market. First, she held a brown bag lunch for her colleagues to tell them what she had learned at a professional conference. When she became more adept, she offered detailed tutorials. Meanwhile, she sat down with her boss to explain the benefits to the company of the special standards, and quietly lobbied upper management by sending them relevant articles and short memos on the sales and profit potential. Of course, she made sure to ask her boss’s blessing before contacting top executives. She then trained others in her company in how to bid for European customers. So while trying to promote her ideas, she was tying them to the company’s critical path and paying attention to organizational protocol.

9. Show and tell

Average performers think Show-and-Tell means getting noticed by upper management through slick presentations, long-winded memos, and public displays of affection for their own work. They focus primarily on their image and their message, not on the audience.

Star producers use a series of skills involving selecting which information to pass on to which others and developing the most effective, user-friendly format for reaching and persuading a specific audience. At its highest level, Show-and-Tell involves selecting either the right message for a particular audience or the right audience for the particular message.

There is no getting around it. The economy of the 1990s is a tough place for professionals who have trouble presenting their ideas to groups, especially in personal presentations. For most knowledge workers, we’re not talking about big productions, like Bill Gates or Billy Graham addressing thousands in cavernous convention halls endowed with modern multimedia tools and computer-generated special effects. Instead, Show-and-Tell denotes small end-of-the-hall conference room presentations to groups of five to 20, with an occasional auditorium presentation thrown in. The audience is co-workers, or upper-level managers, or customers. The content is usually technical and product-related.

In the realm of the star producer, though, the process is more sophisticated. From our research, we observed a fine-tuning of Show-and-Tell–from mere transmittal of information points to the sculpting of the message. The stars we observed had mastered the ability to deliver a message to a targeted audience, to persuade listeners to accept the message, and to be proactive in deflecting criticism.

Where average performers fail most often is in making the leap from the basic dispensing of information to the high level of using the message to influence. Their style and framework of delivery remains the same even though their audiences can differ a lot in makeup.

A labor relations manager for a Fortune 500 corporation did it the right way when he had to reduce health care costs in a new contract to be negotiated with the company’s unions. The plan he developed had to be acceptable to both the top officers of the company and the unions.

His approach was to fashion the same information in radically different ways, first to a small group of lower-ranking union officials in bite-sized chunks over a week of meetings on their home turf. He provided them with clear, easy-to-read handouts that could be duplicated and handed out to rank-and-file members with a reasonable chance of being understood quickly. The presentation’s high point was the message that the union’s agreement to switch over to a managed care program would be balanced by the company’s promise to use the cost savings to modernize outdated plants, making them competitive and reducing the risk of closings and job losses.

His earlier presentation to the company’s chief executive officer (CEO) and top vice presidents contained fundamentally the same information, but it was packaged quite differently. First, the time window for his presentation was much shorter than that allowed by the unions. The bulk of his message was delivered in a no-nonsense, well-documented, and detailed report with a persuasive section on recommendations for acceptance. He was able to reinforce his basic message in person in a 1-hour meeting on the company plane with the CEO and the company president.

His position was that if management demanded changes in health care benefits without any creative incentives, the unions would balk and make negotiating a new contract nearly impossible. He noted that the company was just entering on a period of impressive growth and that stockholders would hardly take kindly to a protracted strike.

While there was criticism of his plan within both camps, the star labor negotiator had laid his groundwork well. In the end, both management and the rank-and-file approved the health care benefits proposal with only minor changes.

Of the many star Show-and-Tell lessons to be learned from this example, the most important is the one that differentiates between Show-and-Tell stars and average presenters: know your audience and shape your message to it.

Meara designs software for the transmission of images–X-rays, electrocardiogram readings, and live closed-circuit TV shots–over phone lines to and from hospital emergency operating rooms. She used a short video clip to start a presentation to emergency room physicians and hospital directors of her team’s latest software design. The clip showed a car slamming on screeching brakes, the whine of the ambulance siren, a small child being rushed into the emergency room, and a doctor flicking on her company’s equipment saying they only had minutes to save a young life.

“Our work can make the difference in saving this child’s or your child’s life,” Meara told her audience. “Throughout our project, we played this video clip to remind ourselves of the importance of giving it the best we could. Now let me share it with you.”

To compare her software’s effectiveness with that of previous versions, Meara used an electronic timeline accompanied by the thump of a heartbeat as heard in emergency rooms. First, she ran the old software, but as the audience waited for the pulsing images to come up on the screen, the timeline reached its end, the heart stopped beating, and the emergency room alarms went off. With the new software, the images arrived faster and beat the timeline.

Then Meara took the audience through the ups and downs of the project as they tried various solutions to shaving time off the process–what worked, what failed, and why. She wove technical points into the human drama of health professionals working to save peoples’ lives.

Meara hooked her audience by getting them to identify with the terror of their child’s being in a medical emergency and needing her company’s product to work. Then, she dramatically demonstrated the value of the new product.

continued…

Share this post

Becoming A Star Engineer-Part I

While surfing today,I eventually landed on this thoughtful article in Spectrum.It is very long article so for the sake of readability,breaking it into 2 Parts.

Please share your comments/views/feedback upon this topic.Enjoy the article…

Becoming A Star Engineer

By Robert E. Kelley
IEEE Spectrum, October 1999, Volume 36 – Number 10
While looking for innate factors that separate top-performing engineers from their colleagues, a Carnegie Mellon University professor discovered that stars are made, not born, and reveals how.

IN 1985, I WAS ASKED A SERIES OF QUESTIONS, AND HAVE been tracking down their answers ever since. Bell Laboratories (then part of AT&T Corp. and now mostly belonging to Lucent Technologies Inc.) was perplexed. It hired the best and the brightest from the world’s most prestigious universities, but only a few lived up to their apparent potential for brilliance. Most developed into solid performers of mostly average productivity who did not substantially further Bell Labs’ contribution to AT&T’s competitive advantage in the marketplace.

What the labs wanted to know was: what separates the star from the average performer? Is it innate or canstar performance be learned? Could a program to improve productivity be designed that would help turn average performers into stars?

Not just companies are asking these questions. Since 1985, I have met few professionals who do not want to be more productive. In their own minds, most engineers believe they can be stars. They dislike being outshone by a co-worker and strive constantly to do better than before. In the workplace, they are being forced to do more with less. Global competition, mergers, and downsizings have left them with greater responsibilities and fewer resources. Who among us is not working longer and harder today than five years ago? Who does not have more work piled up in the in-basket or long lists of unanswered e-mail and phone messages? Which of us is not afraid that if we are not more productive, we might get the ax next? Who does not want more control over their lives–a better balance between work and personal lives? Everyone is being told to work smarter, but no one seems to know what that means.

My colleagues and I have been working on these corporate and personal productivity questions ever since. Over a thousand engineers from Bell Laboratories, 3M, and Hewlett-Packard contributed to the original research as both collaborators and subjects. To discover the secrets of star performance, we used paper-and-pencil tests, direct observation, work diaries, focus groups, and individual interviews, drawing upon statistical analyses, content analyses, and iterative model building as appropriate.

Many other companies took part, from those reliant on electrical engineers–such as Analog Devices, Fore Systems, and Air Touch–to those like Shell Oil and Kimberly Clark that are involved in other kinds of engineering. They have used our productivity improvement program to turn their engineers into higher performers and in so doing have also contributed to the growing body of knowledge on star performance.

The path to stardom

Lai and Henry were hired at Bell Laboratories with similar credentials: 3.8 GPAs (grade point averages) from top-ranked undergraduate programs in electrical engineering; summer internships at computer companies; and glowing recommendations from professors. Yet they took distinctly different approaches to their first six-month assignment. Mornings, they took classes in telephone technology and the methods Bell Labs uses to conduct its work. Afternoons were spent on break-in projects–work that needed to be done but that would not jeopardize crucial projects if done badly.

Henry holed up in his office as if writing his dissertation or studying for a law bar exam. He collected volumes of technical documents to acquaint himself with the latest ideas, surfacing only for a bathroom break or a mandatory staff meeting. “What’s going to count,” he remembered thinking at the time, “is whether I can prove to my co-workers how technically smart I am.”

Lai set aside 3 hours each afternoon to work on her assignment and to sharpen her technical skills. In whatever time was left of her workday, she introduced herself to co-workers and asked questions about their projects. If one of them needed a hand or was facing schedule pressures, she volunteered to help. Lai was new to the work place culture, but even so her colleagues warmed to her willingness to pitch in, especially given that their problems were not hers.

One afternoon, a colleague was struggling with a recalcitrant program for a software project due the next week. Lai had picked up a new programming tool in an advanced course, and she thought it could handle the problem. So she offered to work on the program while her colleague focused on the larger project. On another occasion, some sophisticated software tools had to be installed on everyone’s office PC. Standard practice was for each PC user to do the job by trial and error. Having run into the same cumbersome procedure during an internship, Lai thought it more sensible for one person to install the tools in all the machines, and she offered to do the job. But the installations proved unexpectedly tough, requiring two weeks rather than the four days she had planned. Lai could have backed off but she saw it through, even though she had to come in early and stay late for several days so that neither her work assignment nor her class work would suffer.

After six months, Henry and Lai had finished their technical classes and their first assignments. Their projects were successful and judged technically competent. Indeed, Henry’s work may have been slightly more technically proficient than Lai’s.

But in the work place, Henry came up short. While known as a nice guy, he was also pegged as a loner. He was seen as technically adept, but his ability to share his skills with co-workers was questioned. He carried on as if still in school, where the individual’s performance is what counts.

But Lai came across as someone who took initiative, who saw several problems and stepped forward to solve them even though they were not her responsibility. She had created the impression of being in the lab group for far longer than six months. Managers of course noticed she was showing the characteristics of a star engineer and already were viewing her as a candidate for fast-track assignments.

As seen in the quiz onUnderstanding star performers”, most people (like Henry) have preconceptions about what causes star productivity, and most of their notions are as wrong as can be. Over the past 14 years, we have debunked many common myths and made some startling discoveries about the outstanding engineer. One of our first findings was that workers and their bosses tend to disagree on who the star performers are. We first asked managers to list their choices. We then suggested narrowing the list to those persons they would turn to if they had to staff an important new project, if they had a crisis that needed a SWAT (Special Weapons and Tactics) team, or if they were going to hire for their own business. When we showed the list to a group of star performers, they pooh-poohed the managers’ selections. “How did Joe get on the list?” they asked incredulously. “Joe hasn’t done much for years. And where’s Maria? Everyone turns to her when they hit a brick wall or need new ideas.”

The difference in their reactions gave us pause. We took a step back and asked managers and brain-powered workers to name those people who greatly out produced and outperformed their peers, especially if they did so with methods others admired. We were after the cream of the crop–we wanted to weed out the high producers who bulldoze their way to greater productivity but whose wake of destruction swamps any positive contribution.

The result of this exercise was only a 50 percent overlap between the two groups. Brain powered workers and their managers disagree half the time on who the stars are.

For our original research at Bell Labs, we refined our sample. We included only people on both managers’ and co-workers’ star lists. (In later work with 3M, we added the requirement that the stars receive customers’ approval, as well.) We also took into account the number of awards, honors, and performance bonuses won, as well as patent or publication credits where applicable. These undisputed stars were the group we studied and whose performance was the basis for our research.

To pin down how star performers and solid middle performers differ, our research team asked top executives, middle managers, engineers, and other researchers for their opinions. We accumulated 45 factors that managers and star performers close to the action believed led to outstanding performance. The four main categories were: cognitive factors, such as higher IQ, logic, reasoning and creativity; personality factors, such as self confidence, ambition, courage, and a feeling of personal control over one’s destiny; social factors, such as interpersonal skills and leadership; and work and organizational factors, such as the worker’s relationship with the boss, job satisfaction, and attitudes toward pay and other rewards.

Next, to figure out which of the 45 factors differentiated between the groups, we put hundreds of star and average performers in meeting rooms across the country and administered a two-day battery of tests. We also did surveys, developed detailed case histories, and interviewed employees and the managers who hired them. Engineers and managers also supplied us with biographical information and personnel file material.

Perplexingly, after two years, our data showed no appreciable cognitive, personal or psychological, social, or work or organizational differences between stars and non-stars. For each traditional measure, alone or in combination, we had come up empty. We compared the numbers a dozen ways, stretched computer analyses to their limits, and with each run, found the computer spitting back what we then thought was the result of some terrible methodological mistake: there were no quantifiable differences. between members of the two groups.

Yet, by recognizing this, had we not discovered something critically important? That the four factors we presumed were vital to star performance–cognitive, psychological, social, and organizational characteristics–were not the real drivers at all?

The long-term value of our effort was that it laid to rest the cloud of myths around star performance. And in fact, over the next years of our research, we learned that other factors were at play. Most engineers come to the workplace with more than enough potential to succeed splendidly, but most end up as run-of-the-mill. The stars were not standouts because of what they had in their heads but because of how they used what they had. The productivity mystery lay in learning how to transform their talents into high productivity–much like turning potential energy into kinetic energy. Stars, we saw, are made, not born.

continued…

Share this post :

Best of A Techie Thought 2008

First of all,Wish you a very happy new year! 🙂

Another year down! I will admit, more of the day to day use posts for SMB developers have been lacking , but I hope to pick that ball back up and start again real soon. Here are some my New Year resolutions for this blog:

  • Acquire domain and Host the blog on my own
  • Increase frequency of posts up to 2 posts per week
  • More posts focused towards SMB Developer

Here is the “no-fluff-just-stuff” posts of 2008:

  1. Programming is an Art
  2. Architect’s Standpoint
  3. Difference between Abstraction and Encapsulation
  4. Web Development Series-HTTP Basics
  5. User Driven product development and Innovation
  6. Indian IT in different perspective
  7. My Process Vision
  8. Process Commitment and communication

Web Development Series-HTTP Basics

Nowadays, you pick up any developer and ask on what they are working on and you will get resonating answer of web development. But hardly half or even less than that knows which version of protocol “web” is running on! [DON’T GOOGLE! (I had did that 🙂 ) if you do not know, its HTTP 1.1] this also indicates how far the original designers of the protocol had achieved their goal of abstraction and laying out good protocol.

HTTP means Hypertext Transfer Protocol. The name itself sums up the web into it. Web is all about Hypertext [linked text] and data transfer from to and fro in its basic sense. We had gone further with HTTP, adding tons of things.

For any web developer/programmer, three things hold most prominent importance apart from his/her dev platform/language and these are the basic pillars of web. These are namely,

1.       HTTP Protocol

2.       Web Server(IIS, Apache, JBoss etc)

3.       Web Clients(mostly Browsers like Internet Explorer, Firefox, Safari)

So understanding these basics is of prime importance. In this post, I am going to only focus on HTTP and limiting my scope to what fraction of knowledge that is essential (read assumed to have) for every web developer.

HTTP can be thought of as a communication system. Somebody calls up (Request) and somebody replies (Response) and yes the acknowledgments.

This basic nature of HTTP itself defines the existence of two types of programs that we had seen on the above list.

The program which calls up the fellow program at the other end is termed as web server and the programs which replies back is termed as web client.

These programs had mutually decided how to talk and via which language. This is our beloved and long standing man, HTTP.HTTP basically does not hold up the info with it about previous requests and its use. This is called “state”. I had talked to many developers who talks about HTTP being stateless protocol but they, surprisingly, unable to explain what it means.

This stateless nature of HTTP passes the worry of maintaining state to its both end programs that is web servers and browsers and here concept of state management takes its birth and becomes necessity of any server side platform. We will see the state management in detail in following posts.

Now, coming back to HTTP world, the talk between web server and browsers happen through commands. You must be well aware of GET and POST but there are also more to them.

Wikipedia has good explanation for all of these commands. You can refer to it here.

Now, we’ll see most interesting part of HTTP which is related to most of the developers i.e. error codes that HTTP provides.

You must be familiar with 403,404 numbers and those yuck ugly pages shown to your face by your browsers. (To those who are into browser development, why can’t you put those system-error pages to some nicely formatted pages which are meant for HUMANS, everybody is not geek ;)) .Anyway, have you ever thought about what it means and why those numbers are given in such fashion. Well, for that we need to delve deeper to history of HTTP. I am not adding yet another story to this post but if you are interested you can read the whole story about error codes especially of Room No. 404 at this site.

Now I want to conclude this post stating the meanings behind codes that are transferred to browsers.

1XX=Informational codes

2XX=Request Success Codes

3XX=Request redirection Codes

4XX=Client Error Codes

5XX =Web Server Error Codes

Hail! How I can I forget this? If we are talking about Web and HTTP then we always have to take one name. Yeah, Tim Burner Lee who is regarded as “The Father of Internet” or what we call as web. You can visit his homepage here.

Recommended Read:

1. World Wide Web consortium

http://www.w3.org

2. RFC 2616

http://www.w3.org/Protocols/rfc2616/rfc2616-sec1.html

3. Wikipedia

http://en.wikipedia.org/wiki/HyperText_Transfer_Protocol

4. Room 404

http://www.room404.com/page.php?pg=homepage

5. HTTP Pipe lining

http://www.mozilla.org/projects/netlib/http/pipelining-faq.html

Celebration-50th Post

Just realized that this is going to be my 50th post! It’s kind of a milestone for me. So, I thought to write a good post on this occasion but wait a minute! Rather than posting some serious ga-ga, the craziness bug bites me and here I am just celebrating this with YouTube!!

Many people in corporate world think that You-tube is not for programmers, developers or who that are involved in software. Since, Software development is serious, but what they miss is techie people also love to enjoy their craftsmanship and off course, they do it in their own style. In fact, some companies go to the extent that they block the YouTube. I know there are some, hiding between us and because of them, their unprofessionalism, everybody had to lose the good value that is coming out of YouTube and other social sites.

I usually surf YouTube for some good stuff like Google Tech Talks as well as Google Developer days as well as Thought works events like this.

Apart from all that stuff, I also enjoy code-monkey variations that are created by so many people out there. Today, also on this celebration here I am presenting the Programmers song, Hope you will enjoy these as you enjoyed reading out my blog.

also enjoy damn crazy variation from Roy from PDC

After this celebration, am going to put future direction of this blog.

1.      Changing the direction from to-fro writing to much disciplined and focused writing.

2.      Now onwards, you can expect more technical day to day stuff like web development, programming problems, tips and tricks, tools and some insights.

3.      More posts about solving the problems of SME/SMB developers.

4.      More posts about how to optimize operations function in SMB.

I think this agenda will keep busy for another milestone.

I know that there is a long way to go and this is just a humble beginning…but we have to believe, CHANGE CAN HAPPEN.

So, stay tuned

“Picture abhi baki hai mere dost!”

Process Commitment and communication

Engineering Factories, manufacturing plants had always fascinated me since childhood. In my childhood, I had made several visits to the thermal power plant where my father works. The plant is open to families of people who are related to plant on the festival of Dushehara every year. I am still having very fond memories of those days. In my engineering years, I also had visited the Bosch plant which is near to our place.

Both plants are strikingly similar in many respects. They had some sort of control rooms through which they manages manufacturing process or power generation turbines. There were huge charts and flowcharts with Pressure, temperature instructions are noted. Off course they are complex and go beyond this li’l boy’s imagination…but my father still try to explain me what it means..how water is boiled and coal-ash is carried through big pipes on that charts…for me I just think how could these pipelines cross each other in such a good manner! ) New Employees while on training refers to those charts and afterwards they get used to it. Seasoned employees don’t have to look at them, but these old fellows also think that these charts are useful for them when plant management had to do some maintenance or install some new machinery.

In IT, in our company, we too make kind of flowcharts which are I think a little less complex than those found in engineering factories/plants. These flowcharts are treated as process definitions.People are expected to follow these while doing their day to day work to gain efficiency.

In general, we still find some trouble with them. They still are not our part of day to day life. As a process leader and most importantly as a constant observer and improver when I enquire about people involved in projects or with friends from other organizations, I found that they know that processes exists but on an average, organizations had failed to gain from processes than management’s expectations.

Organizations had constantly failed to make an impact on the way of working with their people;more on people who are smart or intelligent than a average employee. There are several reasons and other factors are related with it and I am not going to discuss the reasons here rather we will discuss about what can be done as a part of the solution.

I think though, Flowcharts serve as single reference point. Merely process flowcharts will not serve the purpose of committing to the following of process in each and every single day.[This is what we expected when we say “Institutionalization of process”].

MAKE PROCESSES VERY VISIBLE TO EMPLOYEES EVERY SINGLE DAY.THEY MUST SEE THEM EVERYDAY.

This may be keep these process definitions/flowcharts at the entrance of companies’ labs or notice boards or even put it as wallpapers of individual member’s desktops or at the front of individual employee.

Second most important thing where most of the organizations fail is conveying the importance of processes to their employees.

They just know since their successive bosses had made compulsion so they need to follow orders.

COMPULSION IS PROBLEMATIC WAY, since it gives false illusion that problem is solved or things are in order as per required.

People, should be shown advantages of following processes subtly, not just stating that “if you follow the process you will get the advantage.”

QA team can play a bigger role in all this. They should not act as a police [Now they ask WHY this document is not there? Rather they could have said with project example that look this document/practice of keeping the document had saved the team this issues or this rework etc.] ,but as a mentor, as a coach.

Saying that they [project teams] do not follow is not the way.

“You cannot change the whole world. Easier way is you have to change yourself.”

The Point here, I want to make is “Know your customers well”. See, project team members are organization’s internal customer. They must see their benefits into whatever you tell them to do.

People should get to know and understand the thought process that had gone behind creating the process definitions.

Most current process making mechanisms capture the end-results and not the enjoyable journey!

So from my stand point, we should add the intent of making such end result to process documents. [This can be very simple, just ask “Why?” at each process step and verify entire process. This way you can validate the process.]

If your process could satisfactorily answer the questions then chances are more for, it will be followed by the people.

1. Why my project team members should follow the ‘xyz’ process?
[I am not expecting the answers like its good to follow,you will get advantages. It should be concrete like you can save 40 man-hours by this. Or something like you will not face client saying that you need to do this requirement change NOW.I know this is kind of steep demand but if you want to buy your team members,its a must have.]

2. How could project get the benefits of it?

3. Process has overheads. How you have designed your process so that it had minimum documents/overheads.
[Answers could be something like…You create class diagram with visual studio. The same solution can be shown as design document. No need to create a separate document. Since project team always can create class diagrams with visual studio less than a minute.]

This is very much contradiction to current way of committing to process. People who are doing QA or involved in SEPG sends mail to respective stakeholders/project team members. [Sending a mail is NOT A COMMUNICATION..Sometimes old ways still had much more effect than e-way.Go and talk to your customers..as simple as that or participate in water cooler talks].Then we conduct training [Reading flowchart boxes is not training?]

IMHO, problem is importance and advantage is not communicated to team members and there everything start falling against the management expectation.