Bad Boss Archetypes

I've worked up a list of mismanagement behavior patterns - common personalities and/or misbehaviors found in the workplace.

The pages that follow will present the behavior pattern (the 'archetype' if you will) followed by a fantasy response from the mismanager's staff.

Please revisit this page from time to time - we will be expanding the list as time goes on. Feel free to comment - we'd love to hear what you think!

Dealing with workplace sociopaths and psychopaths

Psychopath. Sociopath.

The terms strike fear in the hearts and minds of normal, conscientious, caring people. The media use these terms when describing vicious murderers or torturers. But what do the words really mean? Are all who can be labeled 'psychopath' or 'sociopath' prone to violence and physical abuse? Or are there other, more subtle, yet just as serious ways that these personality types manifest themselves in our daily lives?

Learning to identify and deal with psychopaths and sociopaths in the workplace is an important skill, even though they may represent only a small part of the population.

Identifying Sociopaths

Identifying sociopathic behavior is not as easy as it seems. Many of the factors used to identify the sociopath are present in less extreme (and 'normal') behavior patterns. One can conclude that one is probably dealing with a sociopath only when a combination of factors is present.

Four Questions

Recent studies show that certain behavioral elements have a strong predictive value for antisocial personality disorder, which may be a predictor for future problems:

In a recent study (Comp. Psych. 48, 529), Dr. Heather Gelhorn and her colleagues from the University of Colorado have determined the four questions that identify sociopaths with a good degree of accuracy (sensitivity and specificity). Additionally, there are some other questions that also help. The best part is that these questions are easy to ask so you don’t have to have a Ph.D. or an M.D. to ask them.
Link

Here are the four questions:

1. Have you ever hit someone so hard that you injured them, or they had to see a doctor? OR: Physically hurt another person in any other way on purpose?

2. Have you ever used a weapon, like a stick, knife or gun in a fight? (Editor's note: The last two questions don't take into account self-defense situations - context is important, isn't it? Hmm...)
3. Have you ever had a time in your life when you lied a lot, not counting any times you lied to keep from being hurt? OR: Used a false or made-up name or alias? OR: Scammed or conned someone for money, to avoid responsibility or just for fun? OR: Forged someone else’s signature—like on a legal document or on a check?
4. Have you ever robbed or mugged someone, or snatched a purse?

Two additional questions were also found to be good indicators:

1. Have you had a time when you bullied or pushed people around or tried to make them afraid of you? OR: Harassed, threatened or blackmailed someone?
2. Have you ever stolen anything from someone or someplace when no one was around? OR: Shoplifted?

Why do Sociopaths Behave That Way?

...sociopathy is a disorder where people use coercion, either physical or non-physical, to overpower other people. Why do sociopaths do this? As Dr. Steve said this week, because they like to. This power behavior gives them pleasure. To them, having power is like having an orgasm. The reason physical violence is especially pleasurable for some is that observing someone else crying or wincing over what they did makes them feel especially powerful. Those sociopaths who are better at observing and understanding people just lie to hurt. They don’t have to see physical pain before they can get that gratification.
Link

Employee Bill of Rights

I once worked for an interesting video game software company - the employee handbook contained an "Employee Bill of Rights". The most interesting item was freedom of speech - a manager telling an employee "you can't say that" was subject to dismissal, according to the handbook.

Now, I don't know if this clause was ever enforced, but I found this to be a refreshing change from the usual politically-correct employee handbooks telling the employee what they can and cannot say, and outlining all manner of obligations the employee has towards the company. (I later found out from a company old-timer that this clause was rumored to be a result of the company founder's own abuses towards underlings!)

This was in 1992. Needless to say, shortly thereafter, as the company grew from its smaller beginnings into the behemoth that it is today, the corporate mentality took control, the previous handbook was discontinued, and the replacement handbook was just another run-of-the-mill corporate handbook full of rules that employees were expected to abide by - things you can't say, protected classes of people (as in sexual and racial harassment), etc. - but nary a peep about the employees' broad rights to be treated with dignity and respect by the company.

So, I'd like to propose a revival of the notion of an employee's bill of rights - that a progressive company should and must enumerate the employees' protections against abuses of power on the part of company management.

Here's a starter list:

1. An employee is to be treated with respect and dignity by company management.
2. An employee is to know where he or she stands at any given time. Waiting until review time to tell an employee about longstanding problems is incredibly bad management.
3. An employee is entitled to a reasonable amount of preparation for an upcoming candidate interview. This includes time to read the candidate's resume, devise a list of questions, and time to put current tasks away before the interview. Dropping the candidate's resume on an interviewer's lap 15 minutes before the interview is a big turn-off and not conducive to good hiring outcomes.
4. A salaried employee should never be pressured by management to work long hours to complete a project when the tardiness is not due to the employee's poor performance.
5. More to come...

Suggestions?

Leave a comment below!

Growing and Managing Technical People

What

People are the most important success factor in any size technical company. Even start-ups need solid management to support their people and solid tools to support their managers. It’s important to build in some amount management structure and focus to ensure that the company retains its valuable employees. Although the information in this paper is specific to technical employees – and most specific to software development and other software professionals - the concepts are applicable to all employees regardless of skill set or background. Good management is critical in any company.

Why

In a software development company, workers are the only real assets. The loss of any key engineer is a blow to the company. In a small company – and especially a start-up - every worker is a key worker.

Retaining employees requires excellent management, even in the post-dotcom era. Stellar engineers will often follow trusted managers from company to company. Of course there’s no way to put a management treatise into a short subject paper, but the basics are consistent and straightforward. Each person must be treated and evaluated fairly and consistently. Identifying and correcting performance problems is essential to the morale of all employees – no one wants to be picking up after others when there’s already more than enough work to go around. Professional development, including career path and education, must be addressed for each employee. Finally, from a practical perspective a solid base must be created in order to avoid any legal problems.

How

Define job levels and pay grades

The first step in developing good management practices is to hire and pay consistently. In order to do this well, the company will need job titles and/or levels, and descriptions for each level. The description should describe the expectations of the job at the specific level – assignment types, skills and skill levels, education, and experience. There should be a pay range for each level to (public or not) to ensure that employees of similar skills are paid at a comparable level. (No matter what management thinks or directs, employees almost always discuss pay levels and stock options with peers.)

Communication

Regular communication with each employee is crucial. Employees have differing communication needs – some will need weekly meetings with their manager or team lead, others like drive-bys, still others just prefer to find and talk to their manager when they feel the need. The key is to determine each person’s preference and try to accommodate it. Some people will simply want to use the manager as a sounding board; others will want regular performance feedback and direction. Still others want to know that things are going well. If managers in the company are too busy to keep up this kind of communication with each direct report, work should probably be re-allocated. In any case, reviews should be held no less frequently than yearly, and nothing in a performance review should ever be a surprise. People need to know when they’re performing well and when they need improvement, and should always receive sufficient opportunity to make improvements after receiving feedback.

Professional Development

All employees want (and deserve) professional development. Unfortunately for managers, professional development means different things for different people and a formal development program is often not practical for a small or rapidly growing company. There are, however, some fairly easy things that each manager can do to ensure that employees feel their development needs are recognized, even if the needs cannot be met immediately. It’s important for the manager to determine the needs of each employee and to be able to offer advice on how to proceed with development. For some employees, development simply means promotion to the next level. These people will need to be coached to perform at the next job level (one of the places the job descriptions are very useful) in order to be promoted. For others, development means expanding certain skills to a greater depth – more expertise in a particular technology, for example. Once these needs are understood the manager can use job assignments, technical mentoring, and outside classes to help the employee gain the expertise. For some employees, development means expanding to a greater breadth – gaining new skills in new (but associated) functional areas. Again, job assignment, mentoring, and classes can help the employee obtain this breadth. Finally, some employees will want to develop skills to move into another job area entirely. This is a much slower process and needs to align with company goals and needs, but should involve identifying the skills necessary to move to the job area and providing assignments and classes to help gain those skills. For all of these development needs, the manager and employee should come up with some sort of plan. Such a plan is not a contract with the company, just a loose direction to help keep moving in the right direction. Review the plan and needs regularly – quarterly is good – because people and circumstances change.

Career Progression

To prepare the company for growth as well as to aid in employee development, it’s very useful to establish a career progression for each technical function. For example, development engineering typically has either 4 or 5 levels, from junior to very senior and ending at architect. Using job descriptions, it’s fairly simple to plot out the skills progression from level to level. This helps employees to determine what’s needed to reach the next level (and to decide whether the next level is something for which they’d like to aim – often job responsibilities include more staff/administrative skills and activities at higher levels, and not everyone is interested in the change). It also helps management determine whether more employees are needed at different job levels and whether current employees will be able to fill the needs.

Reviews and Assessments

Each employee should receive a written assessment at least yearly. Usually, these assessments are tied to pay raises, stock grants, and promotions. The job descriptions should be the basis for the reviews so that all employees are confident that they are being assessed against the same baseline as their peers. Unless performance is unsatisfactory, reviews should focus on positive gains as well as areas for growth. The reviews should be given to the employee verbally as well as in written form, and each person should have the chance to respond to their own review. Self-reviews can be extremely useful as well – people are usually much harder on themselves than managers will be, and the self-review is an excellent vehicle for discussion. The bottom line, though, is that nothing in a review should be a surprise. As noted earlier, regular communication is key.

Any serious performance problems should be addressed when they occur and should be documented in writing (email is fine) after discussion with the employee. Serious performance problems should be followed up on at least weekly until they are resolved, or further action needs to be taken. A performance plan policy will help ensure that this happens in a consistent manner. Delaying discussions with the employee will cause morale problems both for the employee with the performance problem and with the employee’s peers; it is very important to deal with the problems as quickly as possible.

Rewards and Recognition

Rewards and recognition are an important part of employee morale. Here again, everyone is different in their needs and preferences for rewards and recognition. Some people thoroughly enjoy being recognized in a group setting, in front of their peers. For others this type of recognition is excruciatingly embarrassing. Be sure to understand each person’s preference before recognizing them in public. For others stock and monetary rewards are motivating factors rather than recognition before their peers. In any case, look for reasons to reward employees. Everyone thinks of public praise and monetary awards when considering recognition; however, there is a host of other ways to reward good work. The accomplishment doesn’t need to be huge to gain a pat on the back. Think about parking places, spa trips, coffee house gift certificates, and other small rewards for accomplishments. For engineers, a reward involving toys is often worth far more than the cost of the toy (either electronic gadgetry or actual toys). Sometimes an unexpected afternoon off is worth more than any amount of money. Be creative, and match the rewards to the person and to the effort involved.

Growing Software Processes

What

All companies must use some variety of process to run their businesses. In early-stage start-ups, processes are usually lightweight and are often ad-hoc – which means that, while flexible, they are not repeatable. For a business to run efficiently, processes should be at least minimally defined. A balance is needed between the flexibility required to maneuver and the predictability required to produce a product on schedule, at cost, and at the right level of quality.

Why

Poor or incorrect process definition will eventually sacrifice quality, flexibility, growth, and employee morale. To operate efficiently, a software development organization must identify the key processes and institute these processes at the right level, providing enough definition without too much weight or rigidity and ensuring that the processes can grow and develop with the business.

Lack of Consideration and Definition

Key processes must first be identified. If the identified processes are not clearly defined they are not repeatable. (Clear definition does not mean rigidity or complexity, just a clear understanding of the steps and boundaries.) Even if a given process appears to work and to be well-understood in very early stages of the company, new people and continued growth will quickly dilute this understanding to the point that no one really knows exactly how the process should work. If key processes are not defined and broadly understood, at some point these processes will probably require retooling — an expensive proposition during rapid and/or sustained growth.

Process Too Flexible or Lightweight

If a process is too loosely defined it will be open to interpretation by each person involved. The key is to provide structure at the points where this type of interpretation will cause errors and confusion, while allowing more flexibility in the areas that will enable the company to maneuver easily as conditions change. Solid definition at critical points in the key processes will ensure a common understanding, traceable actions, and the predictability needed to produce a quality product on schedule. Such definition will also make it easy to grow and change the process as the company changes — the key areas will already be understood, and the less critical areas can be further defined as necessary.

Process Too Structured or Heavyweight

If key processes are defined in too much detail too early in the company's history, the company will find course changes and corrections very difficult. Teams will get bogged down in unnecessary detail, and the most creative members of the team — those especially critical to start-ups — will become frustrated quickly. Additionally, extremely detailed processes can be very difficult to change as the company changes.

It is important to note that some processes must have structured definition. Processes ensuring quality for some types of software (financial or health, for example) must be very well-defined, understood, and followed in order to ensure a very low rate of errors in the field and/or to ensure compliance in certain industries. These same processes would require considerably more flexibility for other types of software, especially those with quick release cycles and adoption rates.

How

1. Articulate the corporate culture — processes must conform to and support the culture. For example, if many engineers work offsite regularly, requiring in-person walkthroughs of all code would make either the culture of offsite work or the process of walkthroughs difficult to maintain.
2. Define the product lines and other corporate drivers for the foreseeable future.
3. Determine the key business processes. For software development companies, these typically include the development methodology (waterfall, spiral, agile, XP, etc.), configuration management, architecture and design, code, build, review and unit test, quality engineering/quality assurance/quality control, release, and maintenance.
4. For each key process:
• Gauge the level of structure required based on the corporate culture, product lines, and other corporate drivers.
• Define the basic process flow — the basic, generic steps required to complete the process.
• Determine the critical points of the process flow. These are the activities that must be performed in the same way consistently by everyone involved in the process.
• Clearly define the required actions for each critical step in the process, preferably working with a team consisting of representatives from each group involved in the process.
• Working with the same team, define the required outcomes of each non-critical step in the process. This allows flexibility in methodology while ensuring that the goals of the process and its components are well-understood by the team.
• Chart a growth path for the process based on the projected evolution of the company. At a minimum, determine checkpoints for re-examining the process to determine whether adjustments are needed.
5. Document each key process in an easily accessible format and location.
• Don't over-document, or the documentation will be out of date almost as soon as it is written
• Depend heavily on pictures — charts are available in many different tools. Add text where it is critical for understanding, but do this with the knowledge that most engineers will probably not read the text, especially under schedule constraints. Start-ups are volatile environments; any process documentation requiring substantial time to read and understand will largely be ignored. Provide clear, step-by-step instructions wherever possible.
• The best place to post process documentation is on the company intranet. Everyone can access the intranet easily even over VPN, and it's an easy medium to update.
• Consider use of a Wiki for people to post hints on how they've implemented the more flexible process areas in different situations. This often evolves to the next stage of the process through common use, with very little upheaval.
6. Review each key process regularly, updating as necessary. Because the environment is changing, the key processes will require regular adjustment. A good time for process review is immediately after a product release, especially during the project post-mortem. With a cross-functional team, note what worked well with each process and what requires adjustment, then determine the appropriate adjustments. Be sure to update the documentation with the changes, and communicate the changes broadly across the company.

Project Management for Non-Project Managers

What

Every software company needs to be able to tell where they are in a development cycle. Understanding progress and being able to make decisions quickly and accurately are key to bringing a product to market in the right timeframe at the right level of quality. For small projects or small teams, it is often possible to accomplish this type of tracking without a professional project manager and with very simple tools.

Why

For each project (and amongst projects) the company needs to understand, set, and communicate priorities of products, features, cost, quality, and schedule. Without this understanding, no foundation exists upon which to make decisions – the only alternative is ad-hoc decision-making, which generally does not take into account any but the most immediate factors and alternatives.

Progress on a given project must be understood and communicated in order to understand when decisions and trade-offs must be made. Typically, decisions and trade-offs based on project status need to be made quickly as well as accurately; project status needs to be well and easily understood to make these decisions and trade-offs effectively. There should be no surprises – slips should happen only with warning.

Finally, it’s vitally important to understand when a shift in resources – people, equipment, etc. – needs to be made in order to keep a project on track. Without adequate project status, it can be extremely difficult to recognize this need in time to respond quickly and effectively.

How

For relatively straightforward projects with minimal interdependencies, it is not necessary to acquire the services of a project manager, to use Microsoft Project, or to implement many of the other complexities of professional project management. The keys are planning, communication, and follow-through.

Planning

• Involve as many team members as practical in each step of the project. In this way, there will be a more thorough understanding of any issues, more creative ideas will be generated throughout the process, and the team will buy into the results. Be sure to include the extended team – representatives from QA, Support, Tech Pubs, and Product Management as well as development, CM, database, etc.
• Understand the parameters and trade-offs of the project. The first step is to understand and set the traditional ‘4 dials’: features/functionality, schedule, cost/resources, and quality. Typically, only two of these dials can be set. If an attempt is made to fix all four, agility and the ability to make trade-offs will be lost. At least one of the four factors will suffer, but it will happen by default - without the chance to make choice. The factor that most often suffers is quality. Goals should be set for all four factors, but the relative priority of each must be recognized.
• Know when the project will be done. Set the project parameters. If using agile practices, for instance, this will be determined for each iteration, but the product ship should still have minimum ship goals defined. These goals can change if and when market conditions change, but the company should know its goals.
• Break the project down into the smallest pieces that make sense. The biggest tasks that are at all manageable are at the feature level; if possible, break down into the module level for development, the test run for QA, and the chapter for documentation. Track at the most detailed level that makes sense, but don’t break things down just for the sake of breaking them down – that will cause unnecessary work in tracking. A good rule of thumb is that no single task should be more than one week in duration at the absolute maximum – if there is a single task that takes more than a week, try to break it into smaller pieces.
• Once the project is broken down, estimate the time it will take to complete each task. Sometimes this will be very imprecise – some tasks just can’t be well-defined until others are complete. Recognize that this is the case, take a best guess, and create a task to generate a better estimate when conditions are correct.
• If there are any dependencies between tasks – one has to be done before another can be started, or two must start together or finish together – capture the dependencies.
• Create a schedule based on the estimates, taking the dependencies into account.
• Build some contingency into the schedule. For the remainder of the project focus on the scheduled completion date, but know that contingency can be used if needed. In the unlikely case that the contingency isn’t used, the product can ship early or can receive more extensive testing.
• Assign resources for any tasks that require special skills.
• Make a first-pass attempt to assign the remainder of the tasks to determine whether the company has enough people with the right skills to complete the project. Assuming that the people are available, consider the first week or two of task assignments fixed and understand that assignment for later tasks will probably move as they get closer. This is a good thing – it provides flexibility in the schedule. The unexpected will happen and the company needs the ability to react.

Communication

• The easiest and most effective way to communicate the project schedule is to put it on a reserved whiteboard where everyone can see it. (Agile practices often use posted index cards.) This makes for an easy way to update the schedule. Everyone can see it, and people can mark their own tasks complete.
• Keep a rolling list of tasks due for each week. Post it or send it out daily to remind folks – that way when someone finishes something they’ll communicate it. This will also make clear when tasks are not completed on schedule, allowing management to shift resources if possible. When the list is sent, be sure to note when tasks are completed. We all need recognition of our accomplishments, and this is an easy and effective way to help build your team.
• If any changes or decisions are made, send the information out to the entire extended team in email. Feedback will be generated immediately so adjustments can be made.
• Keep a running list of issues and decisions. Sometimes issues will turn up that can’t be resolved until later in the project, sometimes issues will take some time to resolve. Keep the entire list, including the resolution to past issues. Never revisit decisions unless new information comes to light – the running list of issues will help remind the team of decisions made previously.

Follow-Through

• Update the whiteboard at least weekly. If the schedule starts going past the end date- or into the contingency time - make the appropriate decisions to adjust the four ‘dials’. If you gain or lose resources, the schedule will also have to be updated.
• Have a meeting at least once a week somewhere in the vicinity of the whiteboard to communicate schedule, problems, and victories among the team. This is an excellent time to review the rolling week schedule, make any updates to the plan, and revise the whiteboard schedule.
• Be sure to have a party when the project is complete. Celebrating victories is key to good project management.

Staffing Technical Functions in Software Development

What

Staffing is the most time-consuming and critical function of any company, and is especially crucial for start-ups and small companies. Staffing of technical functions in software development companies requires careful planning encompassing skill sets, ratios between functions, transferable skills and other fit factors, and speed of hiring.

Why

Every person is critical in a small company. The cost of a bad hire is high; hiring errors must be found and corrected very quickly to avoid lasting damage to the company. The most effective solution, of course, is avoidance - the ability to consistently hire the right person at the right time.

Hiring the wrong person wastes significant time and money on the hiring process and resulting exit activities alone. Technical errors made by a person with the wrong skill set and not discovered until significantly late in the development cycle (or even after release) can be costly. Hiring a person who is overall a bad fit with the company - its culture and its people as well as its technical needs - can cause serious morale problems across the company, both during the person's tenure and following departure. Considerable management time, always in short supply in a small company, must be spent to correct hiring errors, either by counseling the person to productivity or by managing him out of the company.

The wrong mix or proportion of people amongst technical functions can keep the business from operating at peak efficiency. This mix is important to ensure flexibility and to meet schedule and quality goals.

How

One of the first (and most often skipped) steps to successful staffing is to define the desired ratios between technical functions. This will allow determination of the need for expansion in each area. For example, establish the ratio of development engineers to quality engineers (start-ups often use 4:1 for this); the ratio between support engineers to development engineers; and the ratio between technical writers and development engineers. Next, create a general staffing plan including hire order and timing with respect to funding, release schedules, and ramp-up of development. Following are some general guidelines for consideration:

1. The key architect is frequently the first hire. In a start-up environment, this person should also be able to code effectively until critical mass of engineers is reached.
2. At least one, probably several, more key developers will be needed.
3. Engineers are rarely good UI designers, particularly layout and flow, and correcting UI errors after the initial release can be very costly; however it's rarely cost-effective to hire a UI designer early in the staffing cycle. For a UI-intense application, consider using a UI consultant in early stages.
4. Hire quality engineers no later than hiring of the last developer for the predetermined ratio. (It is generally a good idea to hire the first quality engineer when the first developer is hired, then work into the desired ratio.) If you're unsure whether a quality engineer is needed, consider starting immediately with a contractor. Because software quality engineering is very different from development engineering, development engineers rarely have the skill set and orientation to test effectively.
5. The first Support engineer is typically hired prior to the first product launch unless subsequent schedules take support by implementers into consideration (note that having development engineers work directly with customers other than developers can be problematic). Support engineers can often double as educators and sometimes as professional support - for small, early-stage start-ups, try to get someone who can wear several hats. Take into account number of support shifts. If the Support function is a planned outsource, at least one internal support engineer will still be needed as a liaison and center of competence.
6. Don't have engineers write documentation. Use a professional contract technical writer until enough work exists for a full-time writer. Don't try to use marketing writers as tech writers or vice-versa - it's a different skill set. Look for tech writers to go contract to hire, and who understand online as well as hardcopy documentation. Many tech writers are good UI designers as well.
7. Monitor the amount of time engineers are spend filling I/T and configuration management (CM) functions. I/T functions can often be outsourced effectively; CM functions generally cannot. CM requires a certain orientation and attention to detail - if a development engineer is handling CM on a part-time basis because she has no other choice, she is unlikely to pay the attention to detail required long-term. One good way around this is to make much of the CM simple and automated - the same talented development engineer who doesn't have the patience to be a full-time build engineer might be an excellent choice to automate many of the CM functions.

It's a good idea to determine acquisition and interviewing strategies before beginning the hiring process. There are many options, some of them expensive, and it's good to take stock of your requirements before contracting for services. Some considerations for the hiring process:

• Personal referrals are always the best. Offer a reward if possible for successful referrals. (No one wants to refer a friend who can't do the job, so the company gets high-quality, known candidates who are typically a good fit for the environment.)
• Recruiters can be very useful resources; however, they can rarely screen resumes effectively because they don't have the requisite detailed technical knowledge and knowledge of the company culture. Don't rely on them to screen at any detailed level
• Be as specific (at least internally) as possible about the kind of person you want to hire for each position. Take the following into consideration:
• Corporate culture
• Specific skills for the current environment and role
• Transferable skills ('soft skills') - communication, flexibility, planning, etc.
• Experience - not only regarding specific skills, but company size and culture and rate of speed of learning (critical in a start-up). Generally it's best to avoid hiring extremely deep skills in a start-up. If very deep skills are required in a particular area that is not the long-term product core, consultants are a better option (with appropriate documentation). The enables a growing company to avoid having only one person knowing each piece of the codeset, and the resultant difficulties of having that person leave (or even take vacation).
• Education (and acceptable trade-offs with experience)
• Pay range
• Pre-screen the candidates, even if a recruiter is employed
• Check the resumes carefully.
• Consider electronic screening - have a 20-30 minute questionnaire specific to the position for someone to answer. This can be much more effective than a phone screen.
• Phone screen if an adept technical screener is available.
• Prepare for the interview
• Divide up the topics amongst the interviewers before the interview. There's nothing more annoying (or a bigger waste of time) than having 6 people ask a candidate why she's leaving her current position. If the same people can interview all the candidates on the same topic(s), it is possible to accomplish an excellent comparison of candidates.
• Be sure to include interviewing for fit. Bad cultural and team fits cause many more departures than bad skill fits. Most people know how to interview for skills - it takes more thought and preparation to interview for fit, but it's well worth the effort.
• Debrief after the interview

The sociopathic organization, and how to retain or regain your creativity

(Cartoon courtesy of gapingvoid.com)

This is one of my favorite resources from a few years back. Hugh MacLeod of gapingvoid.com offers his insights into some of the ways the modern organization fails to accommodate the human needs of the people in them. And he talks about ways to retain or regain your creativity and humanity.

Quirky, entertaining, and worth a read - and a re-read every once in a while, IMO.

(Cartoon courtesy of gapingvoid.com)

Top Ten Signs Of A Dysfunctional Workplace

There's no such thing as a perfect company - any enterprise consisting of more than one person is going to have issues (and to be sure, there are single-person enterprises that have major issues).

Frequently, the larger the organization, the more likely one or more of the following is going to be true. Note that there is a difference between an event or incident and an actual pattern. Incidents can sometimes be explained (everyone has bad days); patterns are worth noting.

Here, then, are the top ten patterns that could convince you to pack your bags:

1. Managers berate underlings publicly (and loudly). Airing dirty laundry in front of peers. People try to 'win' arguments by raising the volume rather than put forth reasoned arguments.
2. Managers don't delegate; lack of trust.
3. Meetings: Never or rarely have meetings (inadequate communications) -OR- too many meetings (no time to get things done).
4. Lack of preparation. Everything (or nearly everything) is an emergency.
5. Managers don't commit anything to writing - no clear documentation trail (ever notice some managers prefer to "drop by" or "call to tell you" rather than compose email or provide documentation...?)
6. Company or managers promise non-existent products or product features to customers without consulting the people who have to deliver the goods.
7. Three weeks before first customer ship date and your manager is adding features because of a recent project or sales lead.
8. Lack of timely and direct feedback. You find out about perceived problems only at review time, months (or more) after they occurred. The rest of the time, it's all peaches and cream.
9. Your manager acts nervous or uncomfortable whenever he (or she) sees you talking to someone outside your department.
10. An air of unreality permeates the organization.
11. Multiple boss syndrome: you're given directives (sometime conflicting) by more than one superior. And/or, people who report to you are also getting orders from your boss, a peer of your boss, the janitor, etc.
12. Webmasters and editors who can't count...

Talk Back!

Do you have any other symptoms you think ought to be included in this (or a future) list? Drop us a comment and we'll 'take it under advisement'.

What happens to the truth as bad news moves up through the company hierarchy?

Why does it seem that information gets a fresh coat of varnish as it passes up through the company ranks?

I know I've seen this happen too many times to count. The front-line grunts know that things are bad, that there's no way that the project will be done according to the current schedule (or worse). The conscientious and courageous ones let their managers know, in frank, honest terms, that there are major problems.

But reality seems to have a hard time leaking past certain levels of management. Are their managers liars? Are they inherently dishonest? I think not. I think this is due to human nature: the desire to avoid embarrassment, to avoid seeming negative, to avoid being viewed as "Chicken Little".

Bruce Webster, in an excellent post titled The Wetware Crisis: the Thermocline of Truth, argues for the existence of a natural, predictable barrier to honest communication between those nearest the problem and those most distant: the thermocline of truth. (A thermocline is a sharp thermal gradient between the cold water near the bottom of a body of water, and the warmer water at the top.)

He describes the factors that contribute to the existence of the truth gradient, and how it moves upwards depending on how bad things really are and the inability to continue hiding the truth from those above: if reality is about to assert itself (for example, something is supposed to be shipped next week, and there is no way it can possibly happen) the truth now moves up the chain, where before, hope and wishful thinking prevailed.

Webster's article is thought-provoking and worth a read. Now go read it!