A Techie Thought

Passion for Technology

Archive for the ‘Learning Organization’ Category

This category represents my understanding about wide set of organizations mostly IT companies and oddly others.This also represents my ideas,thoughts about problems faced by many organizations and how I think,organization as a unit can perform better.

Programmer’s Bad Habits II

Posted by lalitkale on September 14, 2009

Continuing part I of this series, here are some more things to add to bad habits or common fallacies and traps of programmers that are holding them from performing well.

1. Carry over the dead code/experiments/comments with you.

Go to any system/project’s codebase that is more than a year old and you will get to know what this means. You see the comment that says “Sales Invoice in next five lines” and more than 20 lines of code that is commented out and another 10 lines code that are currently working as you debug…and nobody can explain what that old commented code does but they don’t dare to clean that up.

2. I can’t fix another programmer’s code, rather I will rewrite it.

Ah! This is a classic and I admit that I had been also got hold of it in my early carrier. One programmer never says good things about another programmer’s code. I think this is in our gene and sometimes even if I think of this ,I think programmers in somewhere deep down their minds wanted a perfect world and each one has their own version J of it. Anyway, what all I can suggest is they can read martin fowler’s classic ‘refactoring’ book and this notion will go away.

3. The world can be written only with “if-else” and “for” loops and method reuse.

Junior junkie who can code for days and night and fresh from colleges or worse spent one or two years in some company can write entire systems in if-else and for loops and some procedure reuse. I think some or the other way this has a root cause of “failing to unlearn what we had learned first”. Most of these guys had learned C language as their first programming language and may found they were good at it or they presume that they are good at it. Biggest mistake our schools and some local book authors has did is they are teaching procedural and object oriented programming language the same way.

These authors had not thought over the object oriented principles, rather their focus is teaching upon the tooling of object orientation like inheritance and polymorphism and unfortunately this is the case in India which has got some credibility in IT.

4. Testing is inferior to programming. It is not what true programmer’s do. Testing is THEIR (Test Engineer’s) JOB.

I spent my early years of career in small start-ups where we don’t have luxury of appointing a separate test engineer. Whatever we write, we have to make sure that we are doing it correctly and the result of it is though I have got respect for the test engineers since I realized that say after testing for basic flows and validation errors it is very difficult to think of something different that can break the system. In regard of this thought I had learned some testing basics from various websites and still those are very handy even as a programmer.

Nowadays, While working with midsized firm and continually reading about TDD all I am realizing is, programmers had a misconception that they can write a code that had errors and they can just give it to test engineer to clear even basic things like spelling mistakes.

It is shameful that people do not want to test their own code and worst of all rely on some other individual for correcting their own mistakes.

The notion of TDD is good but their also our cleaver programmer (as well as some lousy test engineers) friends tell us the list of excuses like schedule, how can I write the test when there is no development etc.

5. Code review means somebody should check their code line by line for all aspects and point out the mistakes that they had made.

Yes, it is insane but I had seen some managers and some programmers have such ridiculous expectations from code reviews. First thing is programmer should be responsible for the code he/she is writing and not the other fellow who is helping it out to make that code better.

Code reviews should be conducted on sample basis and with the help of some tools likes of static code analysis etc. Checking the mere code conventions should not be the only intent of review. It would be more beneficial that code reviewer should do some firsthand refactoring and in that process programmer would learn things and two about the code as well as this leads to better design.

6. Creating a build means compiling the code.

For the people who have not been in the agile/product development have this misconception that compiling the code is the thing that makes the build process.

These people are missing so many steps that makes build process. I even really doubt that these people consider build as a process.

Many times project requires code signing ,obfuscation of code, replacing connection strings from test environment to production environment ,building for various platforms likes of Windows,*nix or 32 bit,64 bit as well as routine tasks as zipping the release, pushing the release over ftp, emailing about the release to stakeholders etc.

The people ignorant about the build process should really search for the continuous integration and trivial toolset of it which includes brilliant TFS, cruise control, Hudson, rake, NAnt etc.

These fallacies and traps are costing our customers millions and we should recognize it. In my opinion the root cause of these is the way SME’s hiring the resources, further on lack of training and setting the culture to sub standards.

The more I go deeper, I think the waterfall thinking model is still lurking people to write bad code and managers had their fear to adopt the bottom up management approach and what we need is agile mindset and learning organization.

“Learning is not child’s play; we cannot learn without pain.”
- Aristotle


Share this post :

Posted in Learning Organization, Technology, code | Tagged: , , , , , , | 3 Comments »

Programmer’s Bad Habits

Posted by lalitkale on September 6, 2009

“Good habits are formed; bad habits we fall into.”

There are much literature that has been written on habits or misconceptions that gets acquired by human beings and how it become hard to leave, especially if those habits or concepts are considered as bad. Bad habits as we all know, seems easy and “quick” solutions that are acquired, mostly unconsciously. But good habits are hard to acquire but gives long lasting benefits to us.

As a developers/programmers or architects, we also acquire habits/misconceptions in our work that consciously or unconsciously imposed seems “quick and easy” solutions to our programming problems. I wanted to throw some light on such bad habits of us-developers…I had also gone through some of these bad habits but thankfully dropped them in my journey to become good dev. Some people may also term them as “anti patterns”, but I am not very comfortable about the word ‘anti-pattern” ;maybe I explain my reasons of terminology in some other post, but now let’s focus on these bad habits or misconceptions.

1. Ignore the warnings, while compilation since they are not causing any problems.

I had seen this many times and I hate this. Some colleague of mine calls me up says that s/he couldn’t find the bug in their program and even after spending a couple of hours and tried all the things s/he can do…

First thing I would try is, I rebuild codebase and see if they had any compilation errors or warnings…and here we go..many warnings yelling for attention!! When questioned about the warnings, the usual answer I hear is “oh! They are not causing any problem so we just ignored them”…and when I see the warnings..Most of the unfound reasons of the bugs are lying in warnings that are in front of the programmers but they can’t see it.

I am not suggesting that you convert all those warning messages into error messages, but warnings are generally-the sign of future or runtime error places and signaling towards inefficiencies in code ;so treat them like errors and work on those.

2. If code is compiling, it is working code.

If you give some junior any requirement and say them that “ok, you need to code this feature/use case etc.” and just watch them. They just start writing the code at the blink of the eye and eager to show their worthiness. But the unfortunate part is next, and that is when they say I am done with the feature/s after their code is getting compiled. Hey Guys! Wake up… writing a compiling code is just a first step and hell…you are not done…Your code has not even passed those unit tests and how you dare to say that your are done.

3. Code once written and running should never be touched.

I generally deal with legacy not in C/C++ terms but have reengineered systems those are in VB 6, .NET 1.1, and likes.

In my opinion, legacy should be termed as “system with inefficiencies even it’s written with latest and greatest likes of .Net 3.5.” Unfortunately that is not the de-facto definition.

Most of the developers and even sometimes project managers have this nausea that if the code has written and that is running that should never be touched.

They say, hey! That is running and as per specifications, why you want to change it or make it better [they see as, this idiot is fooling us by wasting hours on thing that is already done!!] What they miss out is; it is like rusting of the iron. If the code can be improved even a bit by any means, it should be done. It is like you see a piece of rusting iron in your vehicle and still you do not do anything and run your vehicle until any accident occurs.

Damn, that kind of code can carry any characteristic like rigid to requirement changes , fragile like showing strange behavior like fixing bug in one part of code throws the strange error in some other part of the code which is not even related with first. So, the point here is ,we need to remove the inefficiencies.

4. New features can only be floated out by writing tons of new code.

This is really hard to realize that we had picked up such misconception and even harder to come out of this!!

For example, during one re-engineering project, I realized that our architecture is giving ability to product that the client can sell different modules/subsystems to the end users as on need basis and we communicated this to product owner and he liked that idea and which in turn given the product the new revenue stream.We have delivered a feature that is making a strong business sense for product owner without adding extra code!!

All this becomes possible not because we have added some more code for such business feature but cleverly re-architecting the system.

Oh! This post is somewhat getting bigger,I am sorry to break the continuum but just like ‘short methods’ is a good idiom to follow in code, I am keeping this post small and write it in chunks as a true agile developer :)

Till then Happy Thinking!

Hope to see you next time…

 


Share this post :

Posted in Learning Organization, Technology, code | Tagged: , , , , | 2 Comments »

Hiring Developers

Posted by lalitkale on August 23, 2009

Recruitment is the most important thing in learning organization. It can change the every aspect of your organization. You hire right people with right attitude, give them chance to flourish and they can turn your SME into fast, responsive well oiled machine which is ready to adapt to any kind of business challenge. In fact I think this is so crucial that if I am the CEO then, I must have taken part into interviews of prospective hire.

Nowadays developers know all fancy and shiny things and their resumes are flooded with the buzzwords such as web 2.0, WPF,WF ;but very few have mastered the art of computer science. I think basic developer should not fall into the trap of these buzzwords and go for building the sustainable portfolio. If you are a polyglot programmer that is good thing in today’s market, but you should be really a master of at least one technology.

Many Developers try to pretend to know everything that existed in the world that might be from MS-Office [don’t laugh! I had seen such resumes where people come for senior developer post and they even mentioned MS-Office in Skill set!] to WPF and WCF.

These are really jargon driven people who just think that they are commodity stocks.

In my opinion what senior developers should possess is;they should be at least good in algorithms. Not some Google’s page rank kind of algorithms but just real ground work algorithms like searching sorting and building up stack queues will be good enough.

Second most important thing is ,they should not be so much affectionate to some language’s syntactical curry rather I dare to say that even if they can write some good pseudo code I am fine with them.

Concept Implementation and differentiation is also good area where senior developers could look at. Inheritance, polymorphism implementation in various OO languages like C++, PHP, C# or Java should be known.

Last but not the least they should possess some good hobby that they really care about. Yes, this is crucial to look at from wide angle into life and things that falls beside computer knowledge. It will surely help them to grow into a good leader or good team player.


Share this post :

Posted in Learning Organization | Tagged: , , , , | 1 Comment »

Why Your Agile Project Can Not Be A Success

Posted by lalitkale on June 1, 2009

  1. You think agile is iterative waterfall.
  2. Somebody from your top management told you to use “agile” methodology on your project.
  3. You think Product Backlog = project plan,iteration = milestone , scrum-master = project manager,sprint retrospective = project status meeting and agile discipline = micromanagement.
  4. The sales team decreased your estimates because they believe you can work faster.
  5. You use same estimation techniques for waterfall and agile project.
  6. Project estimates magically match the budget.
  7. You have project manager on the project who is in charge of everything.
  8. Every Friday, your project team work on data collection and prepare metrics for your project managers.
  9. Your team do not have scrum master.
  10. Scrum Master do not participate in coding and testing.
  11. Your Scrum Master do not understand the acronyms DRY, YAGNI, or KISS.
  12. You had all the requirements predefined in specification document and you think project will be get executed according to specification.
  13. You think design activities are ,a time to fully and accurately define designs and models in great detail and programming as a simple translation of these to code.
  14. You try to plan a project in great detail from start to finish.You try to speculatively predict all the iterations and what should happen in each one.
  15. Your managers swear by Microsoft project.
  16. Your managers haven’t read “Peopleware” and “Mythical man Month”.
  17. You do not know anything about your team’s “velocity”.
  18. Your project teams don’t have burn down charts.
  19. You define all the architecture upfront at the start of the project.
  20. You have only one iteration.
  21. You think refactoring as a rework.
  22. The last book read by your senior developer is “Mastering VB 6.0”.
  23. Your software architect work in silos.
  24. There is no or minimal feedback and adaptation;users are not continuously engaged in evaluation and feedback.
  25. You think  “Test engineers”  cannot be introduced from day one of project since no code is developed.
  26. Everyday your developers work until Midnight everyday.
  27. You think software quality means creating some CMM compliance documents.
  28. Your QA team does not know how to code.
  29. Your test engineers could not code.
  30. You have specialized roles on your project teams like developers,test engineers,project managers.
  31. Your developers do not practice J/N Unit.
  32. You see deviations from requirements or design during later steps ,as failure or concerns in not having sufficiently skillful or through.Next time,you try harder to get it right.

If despite all these odds, if somebody is claiming that their projects are successful then I have no doubt that there are some software heroes working in their organization;who might be thinking of leaving that organization ;)

Posted in Learning Organization | Tagged: , , | 8 Comments »

Quality Quote

Posted by lalitkale on May 6, 2009

Quality is a perception of receiver.

-Lalit Kale.

Posted in Learning Organization, Mind Ramblings | Tagged: | 1 Comment »

Balsamiq Mockups Review

Posted by lalitkale on March 16, 2009

Nowadays I am doing requirement gathering and analysis for a good project here in Gibraltar.So you can imagine lot of user interactions ,taking interviews of end-users , sometimes shadowing them to their specific work function and lot of questioning etc are going on…at least project started off good and we are heading in correct direction.

For successful execution of project,the team which is going to implement or code,should get understanding of the ideas and concepts and functionality and thus the need of good mock up tool arise. These tools plays a vital role of explaining the ideas and bringing the life to boring documentation. It is truly said that “1 picture is equivalent to 1000 words!”.

In my previous projects,I had mostly used visio and its sort of standard at my workplace for mockups.Though recently I had also tried out serena prototype composer for one project.These tools have their advantages and disadvantages.

Visio is the huge software.It is not meant just for prototyping or diagramming.However,it comes at a price and it requires a lot of time to starting off and be expert with it.You can find massive features are poured on as just any other Microsoft stable software.After using visio ,I came to a conclusion that visio is good tool ,but still not a very handy tool for creating mockups quickly.

I explored a bit more on internet and found Serena Prototype composer.Serena prototype composer scores over visio ,when you want a clickable prototype.But then serena prototype composer needs to be installed where you want to run your prototype and seems to be pretty rigid kind of a tool.I didn’t like it much though it has unique advantage of creating clickable prototype.

Then again in search of perfect mockup tool,I downloaded and tried many. One day(actually night),when on the verge of just concluding that there is not so much great tool other than visio,I found the gold “Balsamiq Mockups”!!!

As a practice,Without much hopes,I downloaded and installed it.As a authentic software engineer,I never use manuals or help to use software [In fact,I had reached to conclusion that if you need help or manual for running a software,there is a problem with usability of that software]. Firing up balsamiq tools,I was just kind of landed in my dreams!! Since,it is just made for making mockups!!! Very no not friendly,I will say inviting user interface.there are all UI elements at the tops with really big and wide tool strip which shows of drag and drop user elements some common like buttons,text,all types of containers(i.e. group box,tabs etc) and some uncommon like accordion,cover flow,video player,street maps etc.The most surprising is I found sticky[comments as they call it ] and charts and graphs as well.Wow! pretty genius work.Since,many business software always need this and very few people do have mockups for this stuff.

basamiq-mockups

You can create a new mockup and start building your mockup by dragging and dropping these elements.When you drag and drop the vertical and horizontal guard lines appear to assist you for placing the elements,taking care of alignments which is again cool feature.

You can set properties of individual element by selecting the element and then property bar appears out of nowhere.You can drag it anywhere so that it will not disturb you or obscure the view of element that you are working with.Also The properties are fantastic set,Just as what needed no extras .These things truly live “YAGNI(You aren’t gonna Need It!!) agile principal.

On top of this,the mock up you created can be saved or imported as XML file or can be exported as PNG files.

Balsamiq Mockups team has really come up with really genius product !!

However,there is a saying that greedy man and end-user can never be satisfied  :)

I must also point out some things that they can improve into their next version.

After using it for two or more weeks ,I realized that grouping and un-grouping of containers and their child elements are somewhat confusing to me.Since,The controls that we drag goes back side of group box and another thing I wanted is the ability selection of many controls like visio gives. As of now,to move entire thing,we have to group them.There must be the selection ability for controls that are not grouped.

The community of Balsamiq Mockups is also good.And they had come up with several templates that you can find at http://www.mockupstogo.net .

All in all,It is insanely great tool built by genius people out their at Balsamiq.I think I can saved at least 40% of time required to create mockups with Basamiq compared to Visio.I will certainly recommend that try your hands on Balsamiq and you will be happy making your mockups ever after.

 

Share this post :

Posted in Learning Organization, Technology, Tools | Tagged: , , , | 6 Comments »

Types Of Software Companies

Posted by lalitkale on January 28, 2009

A 640 BC one-third stater coin from Lydia. 

Technology i.e. science and Management are two pillars of IT shops.The main theme behind separating these two terms is because of the ways these terms shape the culture of company.

The visible attributes of the the companies which value Technology as equal as Business are their software engineers/techies are to be believed as most precious entity in the organization.These companies are trendsetter in their own chosen field of work.The designation does not matter for raising your voice in arguments and expressing contradicting views to that of your colleagues[read your bosses if you are in management stuffed company].You can be your very own in such a environment.You can practice your craziness and spit out any damn idea or coin a new funky term,the only thing that matters is how good you are in your work.
These companies are often run by media shy and only get recognized by their products or when they broke out their new innovations.

On the other hand,there are companies that value Business more than technology.In such setups,software engineers/techies are treated like commodities.These companies are mostly flourished and dominated by some kind of management degree holders.These folks believes on laying down strict sense of organizational structure.These companies are more often profit tearing companies.The way they operate is more frequently like any other manufacturing unit.You can here lot of meeting agendas and close door discussions.Employees are more often pointed to their policies and often seen having water cooler gossiping etc.These have very good frontal face as they had good PR,Marketing departments those pays heed towards media.

Think for a while and comment about Where are you working now?


Share this post :

Posted in Learning Organization | Tagged: , , , | 1 Comment »

Cost Of Not Upgrading Developer’s Computer

Posted by lalitkale on January 22, 2009

Computers and Servers repairing snapshotMany times, there is situation where people in SMB and startup businesses do not upgrade their computers and perhaps their software tools too. Most of these businesses think that it is pretty ‘OK’ to run things as it is ,for years since either they are running the same things.And upgrading systems would add up to their cost.But they eventually forget the cost of loss of productivity of developers. This added cost would certainly pain for customers as well as it can harm your business severely.

Let me give you an example,If there is some code base of your product, which takes 3 minutes to build and compile and run on normal [read upgraded or having latest hardware and software], and you had a machine with your developer which is taking 7 minutes and project would gone up to 24weeks and developer had generally compiled solution even only 50 times per week then you are losing the productive time of 2 Person-Days. Assume, you had 8 working Hours per day.

Time lost in each Build/compilation = 7-3=4 minutes.

24 cal. Weeks = 24 X 50 X (Time lost in each code compilation) = 120 days.

24 cal. Weeks = 24 X 50 X (4) = 4800 Min/60 =80 Person-Hours= 10 Person Days].

So for 6 Calendar Months of work the organization is losing 10 Person days per developer.

Doesn’t that is good eye opener for managers? I think that is quite a lot valuable time and that it is wasted just because you had not upgraded your hardware or software system.

Sometimes, many of us forget that we are using computers just because those damn good and fast machines can do tasks faster than human can think of.


Share this post :

Posted in Learning Organization, Tools | Tagged: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , | 4 Comments »

Becoming A Star Engineer-Part III

Posted by lalitkale on January 12, 2009

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

Posted in Learning Organization, miscellaneous | Tagged: , | Leave a Comment »

Becoming A Star Engineer-Part II

Posted by lalitkale on January 12, 2009

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

Posted in Learning Organization, miscellaneous | Tagged: , | Leave a Comment »