The Nature of Geek Work
The work that geeks do, which is largely intellectual, is often misunderstood by outsiders, and it has a strong effect on their daily behavior as well as their attitudes and customs.
Failure Is Normal
In technology, failure is the norm: a system doesn't work until it's made to do so, and the process or work is trial-and-error with a progression of many failures before a single success.
It is also not uncommon for even completed projects to fail (only 26% of IT projects are considered successful, and 28% are considered "complete" failures) or to be prematurely cancelled.
Compared to other departments, this seems dismal, but it's actually an improvement over previous years. In many ways, it's a result of the tractability of geek work: it is much easier to assess success (and declare failure) of an IT project than of a marketing campaign or a quality-improvement effort in other lines of business.
The sense of failure is often exaggerated by a geek's desire for perfection: a project that produces satisfactory results, but is not as efficient or effective as hoped, or that missed its deadline or budget, is often considered to be a failure.
Ambiguity Rules
Most work is relatively clear: you know what you want to accomplish, what you need to do, and how to do it. In the work that geeks do, there is often little clarity: the task is to ensure or improve upon stability and performance, establish a new system, replace an old one, etc. Much of it deals with degrees of success or failure - something is "better" or "more."
The work is also disconnected from any practical goal: if an IT department improves the payroll system to make it easier for the accountants to track taxable transactions, how does that relate to the organizational mission? How do you decide which project, among several, is the more important?
Figuring Out What to Do Can Be Harder Than Doing It
Much of geek work is planning and discovery: there are many ways to attach a problem, and deciding what to do and how to do it consumes a great deal of time. A whole lot of head-scratching goes on before the first line of code is written.
Work Is Organized by What You Don't Know
In most departments, the majority of actions take place with relative certainty: people can be trained to do routine tasks, which have routine results, many of which can be clearly understood and visualized objectively.
In geek work, most tasks are focused on discovery of something that is not presently known - there is no standard procedure for solving standard problems, and many solutions cannot be concretized: you must try something to know if it will work.
Deep Concentration
The concept of flow - the ability to focus entirely on a single topic without distractions or interruptions - is very important to the work that geeks do. Depending on the complexity of a task, it may take hours to resume productive work after even a brief interruption.
It's especially important for managers to be respectful of the need of knowledge workers to be left alone, rather than constantly prodded for updates - though it's noted that even technical manages who used to do geek work often do not consider this.
What Is Work?
For production workers, it's easy to define "work," as it pertains to activities that are easily observed by others - if the shovel is moving, the worker is working. For geeks, work includes the following:
- Typing code into the system (obviously)
- At the water cooler discussing a technical problem with a coworker
- Sketching out a system architecture or conceptual drawing
- "Surfing" the internet seeking information about the problem or system
- Reading
- Sitting quietly and thinking
One of the main conflicts with management comes from managers who do not understand that some of these activities constitute actual work. Managers may actually be interrupting or fouling progress when they accost a geek who isn't typing - and to insist that a geek "work" (type) without devoting time to thought is counterproductive, possibly even damaging.
The nature of work is also confounding to the ability to estimate work. In project planning, one cannot simply estimate the number of lines of code and apply a standard formula for estimating time.
And in looking at the work done, a geek who has spent twenty hours thinking and wrote ten lines of code may have done a "better" job than one who spent ten hours writing a lengthy program to accomplish the same goal (less efficiently or effectively).
Managers should minimize their desire to control or govern how geeks work, rely on their expertise in estimation, and consider the quality of the solution rather than the amount of apparent effort it required to derive.
Subordinates Know More Than Managers
In traditional business, managers are subject matter experts: the lead accountant often rose through the ranks of accountants, and knows more about the tasks done than his subordinates. For most professions, this has been true since the medieval guilds, possibly from the very start of organized labor.
In geek work, the opposite is true: the manager is not a technical virtuoso (and even if he rose through the ranks, his skills atrophy quickly, and may manage employees whose skills are slightly different).
Primarily, a manager must come to grips with his own insecurity in knowing less than his subordinates - and given that a manager may have authority over a team with diverse skills (programmers, database administrators, systems experts, UI developers, etc.), it's simply impossible for him to gain this expertise, or have more than a vague notion of the work his people actually do.
This requires a new approach to management, in which a manager leaves technical decisions to his staff, and handles "management" and coordination aspects of the job.
My Work, Our Work
Geeks depend heavily on the specialization of labor. Unlike many work teams, where several people do essentially the same task and could substitute for one another, the work of geeks in a team is specialized: each person has their own work to do, that contributes to the overall work product of the team.
Geeks tend to underestimate the importance of coordination with others: they set off on their personal tasks, without considering the ultimate impact of the work product of the group. They may also tend to define their success as the result of their individual efforts rather than that of the project as a whole, and be resistant to make "compromises" in their efforts to suit the common goal.
The Problem with Problems
Geeks default to the problem-solution model of work - in fact, the term "solution" has come to replace the word "product" in the IT industry (you don't sell a payroll software package, you sell a payroll solution). In many ways, the solution model is a robust and broadly-applicable model for the IT industry - but it does have limits and problems of its own.
Primarily, a "solution" is only as important or valuable as the problem it solves. Outsiders very seldom consider the difficulty of providing a solution, or the expertise required to implement it - the ultimate value of a solution is linked to the severity of the original problem.
Also, there's a great deal of trouble with problem-definition. Once of the reason IT projects fail to produce results is that they provided an effective solution to something that was not a problem - in that it was not the root cause of the situation the company was trying to change, and as a result did not have the intended results.
There is also the connotation that a "problem" is something that's inherently bad, and that someone is to be blamed for its existence in the first place.
Problems also depart from normal business operations, which are "normal" rather than exceptional. When you solve a problem, it is solved, and there is no follow-on action - you move on to the next problem. Planning ongoing operations is not as straightforward when there are no routine tasks.
Done Is Hard to Do
There is also a great deal of difficulty determining when a geek's work is done. If a project is to improve the efficiency of a payroll system, at what point is that accomplished? There is always room for improvement, even once it has been improved.
Likewise, when developing software, the number of features and functions seems to be limitless: a system can satisfy all its requirements, and new ones (generally for nice-to-have features) will constantly arise.
Ultimately, declaring a project "completed" tends to be more of a political issue than a technical one: it requires campaigning to convince stakeholders that the solution, in its present state, satisfies their requirements and the addition of additional capabilities is beyond the scope of the present project.
You Can't Control Creativity
Knowledge work requires creative thinking - which cannot be controlled as easily as the performance of routine tasks. Inspiration cannot be rushed, and throwing more people at the problem to get more ideas often slows things down rather than speeds them up.
Demanding "when will this be done?" is a question of "When will you discover the solution?" There is no way to tell.
This can be a frustration for a manager, who feels his managerial competence is perceived by his ability to get things done and satisfy exterior demands to meet quotas and deadlines. In the IT sphere, the task of the manager is generally more in the nature of negotiating with outsiders to control expectations rather than whipping his staff to work faster.
Estimates Are Always Wrong
Just as the time required to make a discovery cannot be rushed, neither can it be estimated with accuracy.
It's not that geeks don't want to provide a precise answer, but that they simply cannot - and it can be very uncomfortable for them to admit that there's something they don't know. If they are punished (or rewards are withheld) for inaccuracy, this will only increase their reluctance.
The reluctance to provide a firm estimate, and then meet it, is often misinterpreted as stubbornness, laziness, or incompetence by executives who are accustomed to getting more reliable information from other business units.
In general, geeks who are more experienced can provide better estimates, and tasks in the near-term can be estimated with greater accuracy than those further in the future - but in the end, a task will take as long as it does, which may require much less or much more time than was originally expected.