killthemeeting

Vital to career success in the modern office environment is the concept of "Visibility."  This is the idea that, in order to get ahead, you have to ensure that your work is visible to managers and others who will be responsible for your career success.  In some places this is transparent (indeed, at one job I held employees were actually advised during their performance reviews about things that will maximize their visibility), whereas at others it's obscure, but it's always there.

On the surface, this doesn't seem like a bad thing.  After all, what's wrong with making people aware of the work you're doing?  If you work hard and accomplish a lot, shouldn't your managers know about it and reward you for it?  Besides, how can you be rewarded for things they don't know?

However, visibility can actually turn out to be quite a big problem in a software development organization, impacting both productivity and morale to a great degree.  And there are two fundamental reasons:

1.)  You may have heard the phrase "It is amazing what you can accomplish if you don't care who gets the credit."  This is by and large true.  So is its inverse.
2.)  The usefulness of a task and its visibility are not necessarily related.  In fact, it is often true that fake work is more visible than real work.

These are both a serious problem because people respond to incentives.  The attempt by various employees to achieve objectives in a maximally visible fashion means that they care very much who gets the credit.  From a purely self-interested perspective, it is important for you to get the credit for a task being completed well, no matter who does the most important work.  The initial result of this is that it encourages dishonesty and backstabbing -- people will emphasize their own role in a project while downplaying others.  After all, decreasing others' visibility increases your own.  But the worse impact this has is that it is better, in a purely self-interested sense, for a project to not be completed than for it to be completed without your visible effort.  After all, you can only work on so many things at a time.  If you don't have time to work on project B because you're busy with project A, you can do whatever you need to to delay project B until it can command your attention.  In addition, it strongly encourages fiefdom-building: ensure that you are responsible for everything whether you should be or not.  Managers try to get every project under the sun placed in their organization, not because of any logical synergy but so they can take the credit for the project when it's finally completed.  Often this results in overburdened organizations, unrealistic schedules, and delayed projects that could have been already completed by another team.

Fiefdoms are poisonous to any large organization.  When managers actively encourage their organizations not to cooperate with others, and to hoard tasks and responsibilities on their team, cross-group collaboration becomes largely impossible.  The product suffers as a result -- valuable integration opportunities are lost, and investigating bugs that cross team boundaries becomes very difficult.  A fiefdom environment cultivates the idea that another team's priorities are not your priorities at all; incentive to help others within the organization drops to zero.  Often this happens without the managers realizing what they've created -- they wonder why the members of their team are so slow to help out other teams without being directly ordered to, not realizing that it's their own priorities that have this result.

Thus, an environment in which everyone cares about visibiltiy creates an incentive to build fiefdoms and interact in a competitive fashion.  In addition, it creates an incentive to prioritize tasks based on their visibility, not their priority to the organization.

The most visible work is not always the most useful.  Indeed, a person's most useful work in a development environment is generally their day-to-day tasks -- writing code on features they own, finding or fixing bugs, maintaining the build system or IT environment, etc.  Maintaining the status quo is often a person's primary responsibility.  Of course, maintaining the status quo is entirely invisible; visibility requires being an agent for change.  Change, good or bad, is noticed.  Now, it's definitely preferable to be visible for good changes rather than bad ones, but there's some truth to the idea that all press is good press (unless it's really bad.)

Prioritizing based on visibility leads to make-work.  People invent their own projects and tasks that impact multiple groups and then pursue them because they know that impact will be noticed.  If this leads to neglecting their day-to-day tasks, so be it; no one notices those anyway.  The most vital work then coasts by with minimum attention (just enough to avoid appearing less productive than other employees), while the real work goes into "special projects."

This may seem mostly theoretical -- atfer all, most people are basically good.  They do not intentionally look for ways to abuse the system, to exploit their employer to get as much as possible out of them for as little effort, no matter what dishonesty or abusive behavior that requires.   Good employees do not want to engage in this sort of behavior -- we went into development and high-tech fields because we genuinely like the technology, and we want to see it work properly and succeed.  Surely we're not all out there neglecting the product and the organization in order to show off, are we?

Well, some people are.  People respond to incentives.  The degree varies -- the good people are harder to corrupt than the bad ones.  But if you reward bad behavior, and punish good behavior, you must expect to get some degree of bad behavior.  What's more, in the evaluation and performance review cycle is the worst place to do this, because it results in the worst people rising to the top.  Organizational hierarchies operate under Darwinian principles -- those with the best survival characteristics (visibility) will survive and advance.  The problem is that these people are the ones least likely to break the cycle -- they're the ones who profit from a culture emphasizing visibility over substance, why would they want to alter it?  I think most people who have been in an office environment for a few years have seen someone who moves up not by skill or ability in their field but by skill in politics.

Those of us who aren't manipulated by such incentives, on the other hand, face another problem -- morale suffers.  We're stuck with a choice of "do what you know is best, and be punished for it, or do what you recognize as worthless make-work, and reap the rewards."  Either choice leads to dissatisfaction -- either the feeling of injustice from not being rewarded for the contribution you know you've made, or the feeling of futility from spending time and effort on minutiae.  And where does this dissatisfaction emerge?  In the best employees, the ones an organization as a whole most wants to retain.  I feel like I'm wasting my time, but the politicians are satisfied.

So how does an organization fight the culture of visibility?  A few ways come to mind:

1.)  For God's sake, don't outright encourage it.  I don't think organizations that do this realize the ultimate conclusions that their policies lead to, or the incentives they're creating.  On the other hand, are the organizations consciously encouraging it... or are managers, recognizing the implications of the culture, just trying to warn their employees of the sort of system-gaming required to get ahead?

2.)   Use objective measures when possible.  In the development world this often isn't possible, since metrics like tests run or lines of code written are often meaningless absent some context.  However, some objective measures can be used -- such as on-time deliveries, deadlines met, budgets met or exceeded.  Any measure is better than "did the other managers like you."

3.)  Managers need to actually understand what their employees do.  This cuts down on fake work.  If your manager does not really know what you do, it becomes quite irrelevant how well you do it so long as you can spin it well.  While managers specialized in managing makes sense in most industries, it does not make sense in IT and development -- managers need to have actually done the sort of work their employees do.  This is a strong plus to promoting from within -- something that organizations seem increasingly reluctant to do, preferring to hire someone from without with "management experience" than take a chance on a bright internal.  It is extremely easy to pull the wool over the eyes of a development manager who doesn't do any development.

4.)  Keep people who don't understand what the employee does out of the performance review process.  Having other managers give their input may sound like a good idea -- after all, what better way to reward cross-group collaboration? -- but those people are even easier to fool.