Basic Management Skills ( Part 2 )

How to Build Quality into your Team

Quality is primarily viewed in terms of corporate culture, multi-departmental ad-hoc task forces and the salvation of entire companies. This article, instead, will view these ideas as they might be applied by a Team Leader with a small permanent staff.

Quality has become the philosophers' stone of management practice with consultants and gurus vying to charm lead-laden corporations into gold-winning champions. Stories abound of base companies with morose workers and mounting debts being transformed into happy teams and healthy profits; never a day goes by without a significant improvement, a pounds-saving suggestion or a quantum leap in efficiency. With this professed success of "Quality" programmes, there has evolved a proscriptive mythology of correct practise which has several draw backs:

the edicts call for nothing less than a company wide, senior-management led programme
the adherence to a single formula has a limited effect, precludes innovation outside these boundaries, and reduces the differentiation which such programmes profess to engender
the emphasis on single-task, specially formed groups shifts the focus away from the ordinary, daily bread-and-butter
Of course, these criticisms do not invalidate the ideas of Quality but are simply to suggest that the principles might well be viewed from a new angle - and applied at a different level. This article attempts to provide a new perspective by re-examining some of the tenets of Quality in the context of a small, established team: simply, what could a Team Leader do with his/her staff.

What is "Quality"?
In current management writings "Quality" has come to refer to a whole gambit of practices which themselves have resulted in beneficial side-effects; as a Team Leader, you will want to take advantage of these benefits also.

The Customer
In simple terms, attaining Quality has something to do with satisfying the expectations of the customer. Concern for the wishes and needs of customers becomes the focus for every decision. What the customer wants, the company provides. This is not philanthropy, this is basic survival. Through careful education by competitors, the customer has begun to exercise spending power in favour of quality goods and services; and while quality is not the sole criterion in selecting a particular supplier, it has become an important differentiator.

If one ten-pence ball-point runs dry in one month and another ten-pence ball-point lasts for three then the second ball-point is the make which the customer will buy again and which he/she recommends to others - even if it costs a little more. The makers of the first ball-point may have higher profit margins, but eventually no sales; without quality in the product, a company sacrifices customers, revenue and ultimately its own existence. In practical terms, Quality is that something extra which will be perceived by the customer as a valid reason for either paying more or for buying again.

In the case where the product is a service, Quality is equated with how well the job is done and especially with whether the customer is made to feel good about the whole operation. In this respect Quality often does cost more, but the loss is recouped in the price customers are prepared to pay and in the increase of business.

Reliability
The clearest manifestation of Quality is in a product's reliability: that the product simply works. To prevent problems from arising after the product is shipped, the quality must be checked before-hand - and the best time to check quality is throughout the whole design and manufacturing cycle. The old method of quality control was to test the completed product and then to rework to remove the problems. Thus while the original production time was short, the rework time was long. The new approach to quality simply asserts that if testing becomes an integral part of each stage of production, the production time may increase but the rework time will disappear. Further, you will catch and solve many problems which the final "big-bang" quality-check would miss but which the customer will find on the first day.

To achieve this requires an environment where the identification of errors is considered to be "a good thing", where the only bad bugs are the ones which got away. One of the most hallowed doctrines of Quality is that of zero defects. "Zero defects" is a focus, it a glorious objective, it is the assertion that nothing less will suffice and that no matter how high the quality of a product, it can still be improved. It is a paradox in that it is an aim which is contrary to reason, and like the paradoxes of many other religions it holds an inner truth. This is why the advocates of Quality often seem a little crazy: they are zealots.

People as Resource
While Quality has its own reward in terms of increased long-term sales, the methods used to achieve this Quality also have other benefits. In seeking to improve the quality of the product, manufacturers have found that the people best placed to make substantial contributions are the workforce: people are the most valuable resource. It is this shift in perspective from the management to the workforce which is the most significant consequence of the search for quality. From it has arisen a new managerial philosophy aimed at the empowerment of the workforce, decision-making by the front line, active worker involvement in the company's advancement; and from this new perspective, new organizational structures have evolved, exemplified in "Quality Circles".

Without digressing too much, it is important to examine the benefits of this approach. For such delegation to be safely and effectively undertaken, the management has to train the workforce; not necessarily directly, and not all at once, but often within the Quality Circles themselves using a single "facilitator" or simply peer-coaching. The workforce had to learn how to hold meetings, how to analyse problems, how to take decisions, how to present solutions, how to implement and evaluate change. These traditionally high-level managerial prerogatives are devolved to the whole staff. Not only does this develop talent, it also stimulates interest. Staff begin to look not only for problems but also for solutions. Simple ideas become simply implemented: the secretary finally gets the filing cabinet moved closer to the desk, the sales meetings follow an agenda, the software division creates a new bulletin board for the sports club. The environment is created where people see problems and fix 'em.

Larger problems have more complex solutions. One outcome of the search for Quality in Japan is the system of Just-In-Time flow control. In this system, goods arrive at each stage of the manufacturing process just before they are needed and are not made until they are needed by the next stage. This reduces storage requirements and inventory costs of surplus stock. Another outcome has been the increased flexibility of the production line. Time to change from one product run to the next was identified as a major obstacle in providing the customer with the desired range of products and quantities, and so the whole workforce became engaged in changing existant practices and even in redesigning the machinery.

The Long Term
However, I believe that the most significant shift in perspective which accompanies the introduction of Quality is that long term success is given precedence over short term gains. The repeat-sale and recommendation are more important than this month's sales figures; staff training and development remain in place despite immediate schedule problems; the product's reliability is paramount even over time-to-market. Time is devoted today to saving time in the future and in making products which work first and every time.

Team Quality
While the salvation of an entire corporation may rest primarily with Senior Management, the fate of a team rests with the Team Leader. The Team Leader has the authority, the power to define the micro-culture of the work team. It is by the deliberate application of the principles of Quality that the Team Leader can gain for the team the same benefits which Quality can provide for a corporation.

The best ideas for any particular team are likely to come from them - the aim of the Team Leader must be to act as a catalyst through prompts and by example; the following are possible suggestions.

Getting Started
There will be no overnight success. To be lasting, Quality must become a habit and a habit is accustomed practise. This takes time and training - although not necessarily formal training but possibly the sort of reinforcement you might give to any aspect of good practise. To habituate your staff to Quality, you must first make it an issue. Here are two suggestions.

The first idea is to become enthusiastic about one aspect at a time, and initially look for a quick kill. Find a problem and start to talk about it with the whole team; do not delegate it to an individual but make it an issue for everybody. Choose some work-related problem like "how to get the right information in time" and solicit everybody's views and suggestions - and get the problem solved. Demand urgency against a clear target. There is no need to allocate large amounts of resource or time to this, simply raise the problem and make a fuss. When a solution comes, praise it by rewarding the whole team, and ensure that the aspects of increased efficiency/productivity/calm are highlighted since this will establish the criteria for "success". Next, find another problem and repeat.

The second idea is the regular weekly meeting to discuss Quality. Of course meetings can be complete time wasters, so this strategy requires care. The benefits are that regularity will lead to habit, the formality will provide a simple opportunity for the expression of ideas, and the inclusion of the whole group at the meeting will emphasize the collective responsibility. By using the regular meeting, you can establish the "ground rules" of accepted behaviour and at the same time train the team in effective techniques.

One problem is that the focus on any one particular issue may quickly loose its efficacy. A solution is to have frequent shifts in focus so that you maintain the freshness and enthusiasm (and the scope for innovative solutions). Further benefits are that continual shifts in emphasis will train your team to be flexible, and provide the opportunity for them to raise new issues. The sooner the team takes over the definition of the "next problem", the better.

Initial Phases
The initial phases are delicate. The team will be feeling greater responsibility without extra confidence. Thus you must concentrate on supporting their development. Essentially you will be their trainer in management skills. You could get outside help with this but by undertaking the job yourself, you retain control: you mould the team so that they will reflect your own approach and use your own criteria. Later they will develop themselves, but even then they will understand your thinking and so your decisions.

One trap to avoid is that the team may focus upon the wrong type of problem. You must make it clear any problem which they tackle should be:

related to their own work or environment
something which they can change
This precludes gripe sessions about wages and holidays.

As with all group work, the main problem is clarity. You should provide the team with a notice board and flip-charts specifically for Quality problems. These can then be left on display as a permanent record of what was agreed.

If you can, steer the group first to some problem which has a simple solution and with obvious (measurable) benefits. A quick, sharp success will motivate.

Team Building
To succeed, a Quality push must engage the enthusiasm of the entire team; as Team Leader, you must create the right atmosphere for this to happen. Many aspects of team building can be addressed while Quality remains the focus.

You must create the environment where each team member feels totally free to express an idea or concern and this can only be done if there is no stigma attached to being incorrect. No idea is wrong - merely non-optimal. In each suggestion there is at least a thread of gold and someone should point it out and, if possible, build upon it. Any behaviour which seeks laughter at the expense of others must be swiftly reprimanded.

One crude but effective method is to write down agreed ground rules and to display them as a constant reminder for everyone, something like:

all criticism must be kind and constructive
all our-problems are all-our problems
BUGS WANTED: DEAD OR ALIVE (but not for long)
if it saves time later, do it now
Another method is to constantly talk about the group as the plural pronoun: "we decided", "we can do this", "we'll get back to you". This is especially effective if it is used in conversation with outsiders (especially management) within ear-shot of the team. Praise and reward the whole team; get the team wider fame by a success story in an internal newspaper.

Most importantly, you must enable failure. If the team is unable to try out ideas without rebuke for errors, then the scope of their solutions will be severely limited. Instead, a failure should be an opportunity to gain knowledge and to praise any safe-guards which were included in the plan.

Mutual Coaching
An important aspect of team interaction is the idea of mutual support. If you can instill the idea that all problems are owned by the entire team then each member will be able to seek help and advice when needed from every other team member. One promoter of this is to encourage mutual coaching. If one team member knows techniques or information which would be useful to the rest, then encourage him/her to share it. Specifically this will raise the profile, confidence and self-esteem of the instructor at the same time as benefiting the entire group. And if there is one member who might never have anything useful to impart - send him/her to a conference or training session to find something.

Statistics
One of the central tenets of Quality programmes is the idea of monitoring the problem being addressed: Statistical Quality Control. Quite simply, if you can't measure an improvement, it probably isn't there. Gathering statistics has several benefits in applying Quality:

it identifies (the extent of) the problem
it allows progress to be monitored
it provides an objective criterion for the abandonment of an idea
it can justify perceived expense in terms of observed savings/improvements
it motivates staff by providing a display of achievement
and, of course, some problems simply disappear when you try to watch them.

The statistics must be gathered in an objective and empirical manner, the outcome should be a simple table or graph regularly updated to indicate progress, and these results must be displayed where all the team can watch. For example, if your team provides product support, then you might monitor and graph the number of repeat enquiries or the average response time. Or if you are in product development, you might want to monitor the number of bugs discovered (i.e. improvement opportunities).

In the long term, it may be suitable to implement the automatic gathering of statistics on a wide range of issues such as complaints, bug reports, machine down-time, etc. Eventually these may either provide early warning of unexpected problems, or comparative data for new quality improvement projects. It is vital, however, that they focus upon an agreed problem and not upon an individual's performance or else all the positive motivation of staff involvement will be lost.

Projects
Clarity of purpose - this is the key to success. You need a simple, stated objective which everybody understands and which everybody can see achieved.

Any plan to improve the quality or effectiveness of the group must contain:

the objective
the method
the statistical display for monitoring the outcome
the agreed criteria for completion or curtailment
By insisting on this format, you provide the plan-owners with a simple mechanism for peer recognition (through the displayed notice board) and yet enable them to manage their own failure with grace.

For a small established team, the "customer" includes any other part of the company with which the team interacts. Thus any themes regarding customer satisfaction can be developed with respect to these so called internal customers. In the end, the effectiveness of your team will be judged by the reports of how well they provide products for others.

A simple innovation might be for a member of your team to actually talk to someone from each of these internal customer groups and to ask about problems. The interfaces are usually the best place to look for simply solved problems. The immediate benefit may be to the customer, but in the long run better communications will lead to fewer misunderstandings and so less rework.

Building Quality
Quality costs less than its lack; look after the pennies and the profits will take care of themselves. To build a quality product, you must do two things:

worry the design and the procedures
include features to aid quality checking
It is a question of attitude. If one of the team spots a modification in the design or the procedures which will have a long term benefit, then that must be given priority over the immediate schedule. The design is never quite right; you should allocate time specifically to discussing improvement. In this you should not aim at actual enhancements in the sense of added features or faster performance, but towards simplicity or predicting problem areas. This is an adjunct to the normal design or production operations - the extra mile which lesser teams would not go.

Many products and services do not lend themselves to quality monitoring. These should be enhanced so that the quality becomes easily tracked. This may be a simple invitation for the "customer" to comment, or it could be a full design modification to provide self-checking or an easy testing routine. Any product whose quality can not be tracked should naturally become a source of deep anxiety to the whole team - until a mechanism is devised.

One of the least-used sources of quality in design and production in the engineering world is documentation. This is frequently seen as the final inconvenience at product release, sometimes even delegated to another (non-technical) group - yet the writing of such documentation can be used as an important vehicle for the clarification of ideas. It also protects the group from the loss of any single individual; the No.7 bus, or the head-hunter, could strike at any time.

In devising a mechanism for monitoring quality, many teams will produce a set of test procedures. As bugs emerge, new procedures should be added which specifically identify this problem and so check the solution. Even when the problem is solved the new procedures should remain in the test set; the problem may return (perhaps as a side effect of a subsequent modification) or the procedure may catch another. Essentially the test set should grow to cover all known possibilities of error and its application should, where possible, be automated.

Role Change
As your team develops, your role as leader changes subtly. You become a cross between a priest and a rugby captain, providing the vision and the values while shouting like crazy from the centre of the field. Although you retain the final say (that is your responsibility), the team begins to make decisions. The hardest part, as with all delegation, is in accepting the group decision even though you disagree. You must never countermand a marginal decision. If you have to over-rule the team, it is imperative that you explain your reasons very clearly so that they understand the criteria; this will both justify your intervention and couch the team in (hopefully) good decision-making practices.

Another role which you assume is that of both buffer and interface between the team and the rest of the company: a buffer in that you protect the team from the vagaries of less enlightened managers; an interface in that you keep the team informed about factors relevant to their decisions. Ultimately, the team will be delegating to you (!) tasks which only you, acting as manager, can perform on its behalf.

Quality for Profit
By applying the principles of Quality to an established team, the Team Leader can enjoy the benefits so actively sought by large corporations. The key is the attitude - and the insistence on the primacy of Quality. As a Team Leader, you have the power to define the ethos of your staff; by using Quality as the focus, you also can accrue its riches.

How To Write Right

Writing is an essential skill upon which all engineers and managers rely. This article outlines simple design principles for engineering's predominate product: paper.

"Sex, romance, thrills, burlesque, satire, bass ... most enjoyable".

"Here is everything one expects from this author but thricefold and three times as entertaining as anything he has written before".

"A wonderful tissue of outrageous coincidences and correspondences, teasing elevations of suspense and delayed climaxes".

(reviews of Small World by David Lodge)

This has nothing to do with engineering writing. No engineering report will ever get such reviews. The most significant point about engineering writing is that it is totally different from the writing most people were taught - and if you do not recognize and understand this difference, then your engineering writing will always miss the mark. However, this article outlines a methodical approach to writing which will enable anyone to produce great works of engineering literature.

Why Worry?
Writing is the major means of communication within an organisation; paper is thought to be the major product of professional engineers; some estimate that up to 30% of work-time is engaged in written communication. Thus it is absolutely vital for you as a Professional Engineer to actively develop the skill of writing; not only because of the time involved in writing, but also because your project's success may depend upon it. Indeed, since so much of the communication between you and more senior management occurs in writing, your whole career may depend upon its quality.

Two Roles
In an industrial context, writing has two major roles:

it clarifies - for both writer and reader
it conveys information
It is this deliberate, dual aim which should form the focus for all your writing activity.

There are many uses for paper within an organization; some are inefficient - but the power of paper must not be ignored because of that. In relation to a project, documentation provides a means to clarify and explain on-going development, and to plan the next stages. Memoranda are a simple mechanism for suggestions, instructions, and general organisation. The minutes of a meeting form a permanent and definitive record.

Writing is a central part of any design activity. Quality is improved since writing an explanation of the design, forces the designer to consider and explore it fully. For instance, the simple procedure of insisting upon written test-plans forces the designer to address the issue. Designs which work just "because they do" will fail later; designs whose operation is explained in writing may also fail, but the repair will be far quicker since the (documented) design is understood.

If you are having trouble expressing an idea, write it down; you (and possibly others) will then understand it. It may take you a long time to explain something "off the cuff", but if you have explained it first to yourself by writing it down - the reader can study your logic not just once but repeatedly, and the information is efficiently conveyed.

Forget the Past
Professional writing has very little to do with the composition and literature learnt at school: the objectives are different, the audience has different needs, and the rewards in engineering can be far greater. As engineers, we write for very distinct and restricted purposes, which are best achieved through simplicity.

English at school has two distinct foci: the analysis and appreciation of the great works of literature, and the display of knowledge. It is all a question of aim. A novel entertains. It forces the reader to want to know: what happens next. On the other hand, an engineering report is primarily designed to convey information. The engineer's job is helped if the report is interesting; but time is short and the sooner the meat of the document is reached, the better. The novel would start: "The dog grew ill from howling so ..."; the engineer's report would start (and probably end): "The butler killed Sir John with a twelve inch carving knife".

In school we are taught to display knowledge. The more information and argument, the more marks. In industry, it is totally different. Here the wise engineer must extract only the significant information and support it with only the minimum-necessary argument. The expertise is used to filter the information and so to remove inessential noise. The engineer as expert provides the answers to problems, not an exposition of past and present knowledge: we use our knowledge to focus upon the important points.

For the Future
When you approach any document, follow this simple procedure:

Establish the AIM
Consider the READER
Devise the STRUCTURE
DRAFT the text
EDIT and REVISE
That is it. For the rest of this article, we will expand upon these points and explain some techniques to make the document effective and efficient - but these five stages (all of them) are what you need to remember.

Aim
You start with your aim. Every document must have a single aim - a specific, specified reason for being written. If you can not think of one, do something useful instead; if you can not decide what the document should achieve, it will not achieve it.

Once you have established your aim, you must then decide what information is necessary in achieving that aim. The reader wants to find the outcome of your thoughts: apply your expertise to the available information, pick out the very-few facts which are relevant, and state them precisely and concisely.

The Reader
A document tells somebody something. As the writer, you have to decide what to tell and how best to tell it to the particular audience; you must consider the reader.

There are three considerations:

What they already know affects what you can leave out.
What they need to know determines what you include.
Wha
t they want to know suggests the order and emphasis of your writing.
For instance, in a products proposal, marketing will want to see the products differentiation and niche in the market place; finance will be interested in projected development costs, profit margins and risk analysis; and R&D will want the technical details of the design. To be most effective, you may need to produce three different reports for the three different audiences.

The key point, however, is that writing is about conveying information - conveying; that means it has to get there. Your writing must be right for the reader, or it will lost on its journey; you must focus upon enabling the reader's access to the information.

Structure
Writing is very powerful - and for this reason, it can be exploited in engineering. The power comes from its potential as an efficient and effective means of communication; the power is derived from order and clarity. Structure is used to present the information so that it is more accessible to the reader.

In all comes down to the problem of the short attention span. You have to provide the information in small manageable chunks, and to use the structure of the document to maintain the context. As engineers, this is easy since we are used to performing hierarchical decomposition of designs - and the same procedure can be applied to writing a document.

While still considering the aim and the reader, the document is broken down into distinct sections which can be written (and read) separately. These sections are then each further decomposed into subsections (and sub-subsections) until you arrive at simple, small units of information - which are expressed as a paragraph, or a diagram.

Every paragraph in your document should justify itself; it should serve a purpose, or be removed. A paragraph should convey a single idea. There should be a statement of that key idea and (possibly) some of the following:

a development of the idea
an explanation or analogy
an illustration
support with evidence
contextual links to reinforce the structure
As engineers, though, you are allowed to avoid words entirely in places; diagrams are often much better than written text. Whole reports can be written with them almost exclusively and you should always consider using one in preference to a paragraph. Not only do diagrams convey some information more effectively, but often they assist in the analysis and interpretation of the data. For instance, a pie chart gives a quicker comparison than a list of numbers; a simple bar chart is far more intelligible than the numbers it represents. The only problem with diagrams is the writer often places less effort in their design than their information-content merits - and so some is lost or obscure. They must be given due care: add informative labels and titles, highlight any key entries, remove unnecessary information.

Draft, Revise and Edit
When you have decided what to say, to whom you are saying it, and how to structure it; say it - and then check it for clarity and effectiveness. The time spent doing this will be far less than the time wasted by other people struggling with the document otherwise.

The following are a few points to consider as you wield the red pen over your newly created opus.

Layout
The main difference between written and verbal communication is that the reader can choose and re-read the various sections, whereas the listener receives information in the sequence determined by the speaker. Layout should be used to make the structure plain, and so more effective: it acts as a guide to the reader.

Suppose you have three main points to make; do not hide them within simple text - make them obvious. Make it so that the reader's eye jumps straight to them on the page. For instance, the key to effective layout is to use:

informative titles
white space
variety
Another way to make a point obvious is to use a different font.

Style
People in business do not have the time to marvel at your florid turn off phrase or incessant illiteration. They want to know what the document is about and (possibly) what it says; there is no real interest in style, except for ease of access.

In some articles a summary can be obtained by reading the first sentence of each paragraph. The remainder of each paragraph is simply an expansion upon, or explanation of, the initial sentence. In other writing, the topic is given first in a summary form, and then successively repeated with greater detail each time. This is the pyramid structure favoured by newspapers.

A really short and simple document is bound to be read. This has lead to the "memo culture" in which every communication is condensed to one side of A4. Longer documents need to justify themselves to their readers' attention.

The Beginning
Let us imagine the reader. Let us call her Ms X.

Ms X has a lot to do today: she has a meeting tomorrow morning with the regional VP, a call to make to the German design office, several letters to dictate concerning safety regulations, and this months process-data has failed to reach her. She is busy and distracted. You have possibly 20 seconds for your document to justify itself to her. If by then it has not explained itself and convinced her that she needs to read it - Ms X will tackle something else. If Ms X is a good manager, she will insist on a rewrite; if not, the document may never be read. action).

Thus the beginning of your document is crucial. It must be obvious to the reader at once what the document is about, and why it should be read. You need to catch the readers attention but with greater subtlety than this article; few engineering reports can begin with the word sex.

Unlike a novel, the engineering document must not contain "teasing elevations of suspense". Take your "aim", and either state it or achieve it by the end of the first paragraph.

For instance, if you have been evaluating a new software package for possible purchase then your reports might begin: "Having evaluated the McBlair Design Suite, I recommend that ...".

Punctuation
Punctuation is used to clarify meaning and to highlight structure. It can also remove ambiguity: a cross section of customers can be rendered less frightening simply by adding a hyphen (a cross-section of customers).

Engineers tend not to punctuate - which deprives us of this simple tool. Despite what some remember from school, punctuation has simple rules which lead to elegance and easy interpretation. If you want a summary of punctuation, try The Concise Oxford Dictionary (1990); and if you want a full treatise, complete with worked examples (of varying degrees of skill), read You Have A Point There by Eric Partridge.

For now, let us look at two uses of two punctuation marks. If you do not habitually use these already, add them to your repertoire by deliberately looking for opportunities in your next piece of writing.

The two most common uses of the Colon are:

1) To introduce a list which explains, or provides the information promised in, the previous clause.

A manager needs two planning tools: prescience and a prayer.
2) To separate main clauses where the second is a step forward from the first: statement to example, statement to explanation, cause to effect, introduction to main point.
To err is human: we use computers.
The two most common uses of the Semicolon are:
1) to unite sentences that are closely associated, complementary or parallel:

Writing is a skill; one must practise to improve a skill.
Engineers engineer; accountants account for the cost.

2) to act as a stronger comma, either for emphasis or to establish a hierarchy
The report was a masterpiece; of deception and false promises.
The teams were Tom, Dick and Harry; and Mandy, Martha and Mary.

Spelling
For some, spelling is a constant problem. In the last analysis, incorrect speling distracts the reader and detracts from the authority of the author. Computer spell-checking programmes provide great assistance, especially when supported by a good dictionary. Chronic spellers should always maintain a (preferably alphabetical) list of corrected errors, and try to learn new rules (and exceptions!). For instance (in British English) advice-advise, device-devise, licence-license, practice-practise each follow the same pattern: the -ice is a noun, the -ise is a verb.

Simple Errors
For important documents, there is nothing better than a good, old-fashioned proof-read. As an example, the following comes from a national advertising campaign/quiz run by a famous maker of Champagne:

Question 3: Which Country has one the Triple Crown the most times?
Won understands the error, but is not impressed by the quality of that company's product.

Sentence Length
Avoid long sentences. We tend to associate "unit of information" with "a sentence". Consequently when reading, we process the information when we reach the full stop. If the sentence is too long, we lose the information either because of our limited attention span or because the information was poorly decomposed to start with and might, perhaps, have been broken up into smaller, or possibly better punctuated, sentences which would better have kept the attention of the reader and, by doing so, have reinforced the original message with greater clarity and simplicity.

Word Length
It is inappropriate to utilize verbose and bombastic terminology when a suitable alternative would be to: keep it simple. Often the long, complex word will not be understood. Further, if the reader is distracted by the word itself, then less attention is paid to the meaning or to the information you wished to convey.

Jargon
I believe that a digital human-computer-interface data-entry mechanism should be called a keyboard; I don't know why, but I do.

Wordiness
When one is trying hard to write an impressive document, it is easy to slip into grandiose formulae: words and phrases which sound significant but which convey nothing but noise.

You must exterminate. So: "for the reason that" becomes "because"; "with regards to" becomes "about"; "in view of the fact that" becomes "since"; "within a comparatively short period of time" becomes "soon".

Often you can make a sentence sound more like spoken English simply be changing the word order and adjusting the verb. So: "if the department experiences any difficulties in the near future regarding attendance of meetings" becomes "if staff cannnot attend the next few meetings". As a final check, read your document aloud; if it sounds stilted, change it.

Conclusion
Writing is a complex tool, you need to train yourself in its use or a large proportion of your activity will be grossly inefficient. You must reflect upon your writing lest it reflects badly upon you.

The Art of Delegation

Delegation is a skill of which we have all heard - but which few understand. It can be used either as an excuse for dumping failure onto the shoulders of subordinates, or as a dynamic tool for motivating and training your team to realize their full potential.

"I delegate myne auctorite" (Palsgrave 1530)

Everyone knows about delegation. Most managers hear about it in the cradle as mother talks earnestly to the baby-sitter: "just enjoy the television ... this is what you do if ... if there is any trouble call me at ..."; people have been writing about it for nearly half a millennium; yet few actually understand it.

Delegation underpins a style of management which allows your staff to use and develop their skills and knowledge to the full potential. Without delegation, you lose their full value.

As the ancient quotation above suggests, delegation is primarily about entrusting your authority to others. This means that they can act and initiate independently; and that they assume responsibility with you for certain tasks. If something goes wrong, you remain responsible since you are the manager; the trick is to delegate in such a way that things get done but do not go (badly) wrong.

Objective
The objective of delegation is to get the job done by someone else. Not just the simple tasks of reading instructions and turning a lever, but also the decision making and changes which depend upon new information. With delegation, your staff have the authority to react to situations without referring back to you.

If you tell the janitor to empty the bins on Tuesdays and Fridays, the bins will be emptied on Tuesdays and Fridays. If the bins overflow on Wednesday, they will be emptied on Friday. If instead you said to empty the bins as often as necessary, the janitor would decide how often and adapt to special circumstances. You might suggest a regular schedule (teach the janitor a little personal time management), but by leaving the decision up to the janitor you will apply his/her local knowledge to the problem. Consider this frankly: do you want to be an expert on bin emptying, can you construct an instruction to cover all possible contingencies? If not, delegate to someone who gets paid for it.

To enable someone else to do the job for you, you must ensure that:

they know what you want
they have the authority to achieve it
they know how to do it.
These all depend upon communicating clearly the nature of the task, the extent of their discretion, and the sources of relevant information and knowledge.

Information
Such a system can only operate successfully if the decision-makers (your staff) have full and rapid access to the relevant information. This means that you must establish a system to enable the flow of information. This must at least include regular exchanges between your staff so that each is aware of what the others are doing. It should also include briefings by you on the information which you have received in your role as manager; since if you need to know this information to do your job, your staff will need to know also if they are to do your (delegated) job for you.

One of the main claims being made for computerized information distribution is that it facilitates the rapid dissemination of information. Some protagonists even suggest that such systems will instigate changes in managerial power sharing rather than merely support them: that the "enknowledged" workforce will rise up, assume control and innovate spontaneously. You may not believe this vision, but you should understand the premise. If a manager restricts access to information, then only he/she is able to make decisions which rely upon that information; once that access is opened to many others, they too can make decisions - and challenge those of the manager according to additional criteria. The manager who fears this challenge will never delegate effectively; the manager who recognizes that the staff may have additional experience and knowledge (and so may enhance the decision-making process) will welcome their input; delegation ensures that the staff will practise decision-making and will feel that their views are welcome.

Effective control
One of the main phobias about delegation is that by giving others authority, a manager loses control. This need not be the case. If you train your staff to apply the same criteria as you would yourself (by example and full explanations) then they will be exercising your control on you behalf. And since they will witness many more situations over which control may be exercised (you can't be in several places at once) then that control is exercised more diversely and more rapidly than you could exercise it by yourself. In engineering terms: if maintaining control is truly your concern, then you should distribute the control mechanisms to enable parallel and autonomous processing.

Staggered Development
To understand delegation, you really have to think about people. Delegation cannot be viewed as an abstract technique, it depends upon individuals and individual needs. Let us take a lowly member of staff who has little or no knowledge about the job which needs to be done.

Do you say: "Jimmy, I want a draft tender for contract of the new Hydro Powerstation on my desk by Friday"? No. Do you say: "Jimmy, Jennifer used to do the tenders for me. Spend about an hour with her going over how she did them and try compiling one for the new Hydro Powerstation. She will help you for this one, but do come to me if she is busy with a client. I want a draft by Friday so that I can look over it with you"? Possibly.

The key is to delegate gradually. If you present someone with a task which is daunting, one with which he/she does not feel able to cope, then the task will not be done and your staff will be severely demotivated. Instead you should build-up gradually; first a small task leading to a little development, then another small task which builds upon the first; when that is achieved, add another stage; and so on. This is the difference between asking people to scale a sheer wall, and providing them with a staircase. Each task delegated should have enough complexity to stretch that member of staff - but only a little.

Jimmy needs to feel confident. He needs to believe that he will actually be able to achieve the task which has been given to him. This means that either he must have the sufficient knowledge, or he must know where to get it or where to get help. So, you must enable access to the necessary knowledge. If you hold that knowledge, make sure that Jimmy feels able to come to you; if someone else holds the knowledge, make sure that they are prepared for Jimmy to come to them. Only if Jimmy is sure that support is available will he feel confident enough to undertake a new job.

You need to feel confident in Jimmy: this means keeping an eye on him. It would be fatal to cast Jimmy adrift and expect him to make it to the shore: keep an eye on him, and a lifebelt handy. It is also a mistake to keep wandering up to Jimmy at odd moments and asking for progress reports: he will soon feel persecuted. Instead you must agree beforehand how often and when you actually need information and decide the reporting schedule at the onset. Jimmy will then expect these encounters and even feel encouraged by your continuing support; you will be able to check upon progress and even spur it on a little.

When you do talk to Jimmy about the project, you should avoid making decisions of which Jimmy is capable himself. The whole idea is for Jimmy to learn to take over and so he must be encouraged to do so. Of course, with you there to check his decisions, Jimmy will feel freer to do so. If Jimmy is wrong - tell him, and explain very carefully why. If Jimmy is nearly right - congratulate him, and suggest possible modifications; but, of course, leave Jimmy to decide. Finally, unless your solution has significant merits over Jimmy's, take his: it costs you little, yet rewards him much.

Constrained Availability
There is a danger with "open access" that you become too involved with the task you had hoped to delegate. One successful strategy to avoid this is to formalize the manner in which these conversation take place. One formalism is to allow only fixed, regular encounters (except for emergencies) so that Jimmy has to think about issues and questions before raising them; you might even insist that he draw-up an agenda. A second formalism is to refuse to make a decision unless Jimmy has provided you with a clear statement of alternatives, pros and cons, and his recommendation. This is my favourite. It allows Jimmy to rehearse the full authority of decision making while secure in the knowledge that you will be there to check the outcome. Further, the insistence upon evaluation of alternatives promotes good decision making practices. If Jimmy is right, then Jimmy's confidence increases - if you disagree with Jimmy, he learns something new (provided you explain your criteria) and so his knowledge increases. Which ever way, he benefits; and the analysis is provided for you.

Outcomes and Failure
Let us consider your undoubtedly high standards. When you delegate a job, it does not have to be done as well as you could do it (given time), but only as well as necessary: never judge the outcome by what you expect you would do (it is difficult to be objective about that), but rather by fitness for purpose. When you delegate a task, agree then upon the criteria and standards by which the outcome will be judged.

You must enable failure. With appropriate monitoring, you should be able to catch mistakes before they are catastrophic; if not, then the failure is yours. You are the manager, you decided that Jimmy could cope, you gave him enough rope to hang himself, you are at fault. Now that that is cleared up, let us return to Jimmy. Suppose Jimmy gets something wrong; what do you want to happen?

Firstly, you want it fixed. Since Jimmy made the mistake, it is likely that he will need some input to develop a solution: so Jimmy must feel safe in approaching you with the problem. Thus you must deal primarily with the solution rather than the cause (look forward, not backwards). The most desirable outcome is that Jimmy provides the solution.

Once that is dealt with, you can analyse the cause. Do not fudge the issue; if Jimmy did something wrong say so, but only is very specific terms. Avoid general attacks on his parents: "were you born this stupid?", and look to the actual event or circumstance which led to the error: "you did not take account of X in your decision". Your objectives are to ensure that Jimmy:

understands the problem
feels confident enough to resume
implements some procedure to prevent recurrence.
The safest ethos to cultivate is one where Jimmy actually looks for and anticipates mistakes. If you wish to promote such behaviour, you should always praise Jimmy for his prompt and wise action in spotting and dealing with the errors rather that castigate him for causing them. Here the emphasis is placed upon checking/testing/monitoring of ideas. Thus you never criticise Jimmy for finding an error, only for not having safe-guards in place.

What to delegate
There is always the question of what to delegate and what to do yourself, and you must take a long term view on this: you want to delegate as much as possible to develop you staff to be as good as you are now.

The starting point is to consider the activities you used to do before you were promoted. You used to do them when you were more junior, so someone junior can do them now. Tasks in which you have experience are the easiest for you to explain to others and so to train them to take over. You thus use your experience to ensure that the task is done well, rather than to actually perform the task yourself. In this way you gain time for your other duties and someone else becomes as good as your once were (increasing the strength of the group).

Tasks in which your staff have more experience must be delegated to them. This does not mean that you relinquish responsibility because they are expert, but it does mean that the default decision should be theirs. To be a good manager though, you should ensure that they spend some time in explaining these decisions to you so that you learn their criteria.

Decisions are a normal managerial function: these too should be delegated - especially if they are important to the staff. In practice, you will need to establish the boundaries of these decisions so that you can live with the outcome, but this will only take you a little time while the delegation of the remainder of the task will save you much more.

In terms of motivation for your staff, you should distribute the more mundane tasks as evenly as possible; and sprinkle the more exciting onces as widely. In general, but especially with the boring tasks, you should be careful to delegate not only the performance of the task but also its ownership. Task delegation, rather than task assignment, enables innovation. The point you need to get across is that the task may be changed, developed, upgraded, if necessary or desirable. So someone who collates the monthly figures should not feel obliged to blindly type them in every first-Monday; but should feel empowered to introduce a more effective reporting format, to use Computer Software to enhance the data processing, to suggest and implement changes to the task itself.

Negotiation
Since delegation is about handing over authority, you cannot dictate what is delegated nor how that delegation is to be managed. To control the delegation, you need to establish at the beginning the task itself, the reporting schedule, the sources of information, your availability, and the criteria of success. These you must negotiate with your staff: only by obtaining both their input and their agreement can you hope to arrive at a workable procedure.

When all is done for you
Once you have delegated everything, what do you do then?

You still need to monitor the tasks you have delegated and to continue the development of your staff to help them exercise their authority well.

There are managerial functions which you should never delegate - these are the personal/personnel ones which are often the most obvious additions to your responsibilities as you assume a managerial role. Specifically, they include: motivation, training, team-building, organization, praising, reprimanding, performance reviews, promotion.

As a manager, you have a responsibility to represent and to develop the effectiveness of your group within the company; these are tasks you can expand to fill your available time - delegation is a mechanism for creating that opportunity.

The Human Factor

In the management of a small team, the human factor is crucial to success. This article considers possible motivators and a simple framework for dealing with people.

When you are struggling with a deadline or dealing with delicate decisions, the last thing you want to deal with is "people". When the fight is really on and the battle is undecided, you want your team to act co-operatively, quickly, rationally; you do not want a disgruntled employee bitching about life, you do not want a worker who avoids work, you do not want your key engineer being tired all day because the baby cries all night. But this is what happens, and as a manager you have to deal with it. Few "people problems" can be solved quickly, some are totally beyond your control and can only be contained; but you do have influence over many factors which affect your people and so it is your responsibility to ensure that your influence is a positive one.

You can only underestimate the impact which you personally have upon the habits and effectiveness of your group. As the leader of a team, you have the authority to sanction, encourage or restrict most aspects of their working day, and this places you in a position of power - and responsibility. This article looks briefly at your behaviour and at what motivates people, because by understanding these you can adapt yourself and the work environment so that your team and the company are both enriched. Since human psychology is a vast and complex subject, we do not even pretend to explain it. Instead, the article then outlines a simple model of behaviour and a systematic approach to analysing how you can exert your influence to help your team to work.

Behaviour
Consider your behaviour. Consider the effect you would have if every morning after coffee you walked over to Jimmy's desk and told him what he was doing wrong. Would Jimmy feel pleased at your attention? Would he look forward to these little chats and prepare simple questions to clarify aspects of his work? Or would he develop a Pavlovian hatred for coffee and be busy elsewhere whenever you pass by? Of course you would never be so destructive - provided you thought about it. And you must; for many seemingly simple habits can have a huge impact upon your rapport with your team.

Take another example: suppose (as a good supportive manager) you often give public praise for independence and initiative displayed by your team, and suppose (as a busy manager) you respond brusquely to questions and interruptions; think about it, what will happen?

Probably your team will leave you alone. They will not raise problems (you will be left in the dark), they will not question your instructions (ambiguities will remain), they will struggle on bravely (and feel unsupported). Your simple behaviour may result in a quagmire of errors, mis-directed activity and utter frustration. So if you do want to hear about problems, tell the team so and react positively when you hear of problems in-time rather than too-late.

Motivation
When thinking about motivation it is important to take the long-term view. What you need is a sustainable approach to maintain enthusiasm and commitment from your team. This is not easy; but it is essential to your effectiveness.

Classic work on motivation was undertaken by F. Herzberg in the 1950's when he formulated the "Motivation-Hygiene" theory. Herzberg identified several factors, such as salary levels, working conditions and company policy, which demotivated (by being poor) rather that motivated (by being good). For example, once a fair level of pay is established, money ceases to be a significant motivator for long term performance. Herzberg called these the "Hygiene" factors to apply the analogy that if the washrooms are kept clean, no one cares if they are scrubbed even harder. The point is that you can not enhance your team's performance through these Hygiene factors - which is fortunate since few team leaders have creative control over company organization or remuneration packages. What you can influence is the local environment and particularly the way in which you interact with your team.

The positive motivators identified by Herzberg are: achievement, recognition, the work itself, responsibility, and advancement. These are what your team needs; loads-o-money is nice but not nearly as good as being valued and trusted.

Achievement
As the manager, you set the targets - and in selecting these targets, you have a dramatic effect upon your team's sense of achievement. If you make them too hard, the team will feel failure; if too easy, the team feels little. Ideally, you should provide a series of targets which are easily recognised as stages towards the ultimate completion of the task. Thus progress is punctuated and celebrated with small but marked achievements. If you stretch your staff, they know you know they can meet that challenge.
Recognition
Recognition is about feeling appreciated. It is knowing that what you do is seen and noted, and preferably by the whole team as well as by you, the manager. In opposite terms, if people do something well and then feel it is ignored - they will not bother to do it so well next time (because "no one cares").
The feedback you give your team about their work is fundamental to their motivation. They should know what they do well (be positive), what needs improving (be constructive) and what is expected of them in the future (something to aim at). And while this is common sense, ask yourself how many on your team know these things, right now? Perhaps more importantly, for which of your team could you write these down now (try it)?

Your staff need to know where they stand, and how they are performing against your (reasonable) expectations. You can achieve this through a structured review system, but such systems often become banal formalities with little or no communication. The best time to give feedback is when the event occurs. Since it can impact greatly, the feedback should be honest, simple, and always constructive. If in doubt, follow the simple formula of:

highlight something good
point out what needs improving
suggest how to improve
You must always look for something positive to say, if only to offer some recognition of the effort which has been put into the work. When talking about improvements, be specific: this is what is wrong, this is what I want/need, this is how you should work towards it. Never say anything as unhelpful or uninformative as "do better" or "shape up" - if you cannot be specific and say how, then keep quiet. While your team will soon realize that this IS a formula, they will still enjoy the benefits of the information (and training). You must not stint in praising good work. If you do not acknowledge it, it may not be repeated simply because no one knew you approved.

The work itself
The work itself should be interesting and challenging. Interesting because this makes your staff actually engage their attention; challenging because this maintains the interest and provides a sense of personal achievement when the job is done. But few managers have only interesting, challenging work to distribute: there is always the boring and mundane to be done. This is a management problem for you to solve. You must actually consider how interesting are the tasks you assign and how to deal with the boring ones. Here are two suggestions.
Firstly, make sure that everyone (including yourself) has a share of the interesting and of the dull. This is helped by the fact that what is dull to some might be new and fascinating to others - so match tasks to people, and possibly share the worst tasks around. For instance, taking minutes in meetings is dull on a weekly basis but quite interesting/educational once every six weeks (and also heightens a sense of responsibility). Secondly, if the task is dull perhaps the method can be changed - by the person given the task. This turns dull into challenging, adds responsibility, and might even improve the efficiency of the team.

Responsibility
Of all of Herzberg's positive motivators, responsibility is the most lasting. One reason is that gaining responsibility is itself seen as an advancement which gives rise to a sense of achievement and can also improve the work itself: a multiple motivation! Assigning responsibility is a difficult judgement since if the person is not confident and capable enough, you will be held responsible for the resulting failure. Indeed, delegating responsibility deserves another article in itself (see the article on Delegation).
Advancement
There are two types of advancement: the long-term issues of promotion, salary rises, job prospects; and the short-term issues (which you control) of increased responsibility, the acquisition of new skills, broader experience. Your team members will be looking for the former, you have to provide the latter and convince them that these are necessary (and possibly sufficient) steps for the eventual advancement they seek. As a manager, you must design the work assignment so that each member of the team feels: "I'm learning, I'm getting on".
Problems
We are going to look at a simple system for addressing people-problems. It is a step-by-step procedure which avoids complex psychological models (which few managers can/should handle) and which focuses upon tangible (and so controllable) quantities.

One work of warning: this technique is often referred to as Behavioural Modification (BM) and many balk at the connotations of management-directed mind control. Do not worry. We are simply recognising that staff behaviour IS modified by the work environment and by your influence upon it. The technique is merely a method for analysing that influence to ensure that it is positive and to focus it to best use.

In any group of people there are bound to be problems - as a manager, you have to solve or at least contain them. You ignore them at your peril. Such problems are usually described in terms like: "Alex is just lazy" or "Brenda is a bad-tempered old has-been". On the one hand, such people can poison the working environment; the other hand, these descriptions are totally unhelpful.

The underlying philosophy of BM is that you should concentrate upon specific, tangible actions over which you have influence. For instance "Alex is lazy" should be transformed into "Alex is normally late with his weekly report and achieves less than Alice does in any one week". Thus we have a starting point and something which can be measured. No generalities; only specific, observable behaviour.

Before proceeding, it is worth checking that the problem is real - some "problems" are more appearance than substance, some are not worth you time and effort. So, stage 1 is to monitor the identified problem to check that it is real and to seek simple explanations. For instance Alex might still be helping someone with his old job.

Stage 2 is often missed - ask Alex for his solution. This sort of interview can be quite difficult because you run the danger of making personal criticism. Now you may feel that Alex deserves criticism, but does it actually help? Your objective is to get Alex to work well, not to indulge in personal tyranny. If you make it personal, Alex will be defensive. He will either deny the problem, blame someone else, blame the weather, tell you that he knows best or some combination of the above. If, on the other hand, you present the situation in terms of the specific events, you can focus upon Alex's own view of the problem (why is this happening?) and Alex's own solution (what can Alex do about it - can you help?).

Stage 2 will sometimes be sufficient. If Alex ha