In analyzing the economics and sociology of office-style Work, an inefficient set of institutional patterns that affects hundreds of millions of people, I’ve often had to ask the question, “Why are so many jobs so bad?” Plenty of positions are inaccurately or dishonestly advertised, many shouldn’t exist at all, and job openings that should exist often don’t. What’s going on with all this? And how should an individual person choose jobs, in light of the inefficient market? I’ve come to a conclusion that, despite the complexity of these issues, is refreshingly simple and, while failing to capture all cases, surprisingly powerful and appropriate to the vast majority of jobs. I might call it the Fundamental Theorem of Employment (FTOE).
A person is hired to do work that the hiring person (a) cannot do for himself, or (b) does not want to do.
Corollary: It is extremely important to know which of the two is the case.
These are, in general, two different cases. A person hires a maid to do undesirable work of which most people are capable, while he hires a doctor to do work that he can’t do for himself. It’s essential for each person to know which of the two cases applies to his or her job. Most jobs can be clearly delineated as one or the other. We’ll call the first category of jobs– a person is hired to bring expertise, skill, or capacity that the hiring manager does not have– “Type 1″; and the “boss doesn’t want to do” jobs, “Type 2″.
In a Type 1 job, you have leverage and you get respect because you’re delivering labor that the manager (a) does not have the ability to render himself, and (b) much more importantly, cannot accurately evaluate. Your boss is forced to trust you. Often, he will trust you just to reduce his own cognitive dissonance. In a Type 2 job, you rarely get any respect; you’re just there to do the worst of the work. You’re not trusted very far, and your manager thinks he can do your job just as well and twice as fast. In the career game, getting stuck in the Type 2 world is a losing proposition.
That seems simple enough, and the advice derived from it is fairly traditional. Build skills. Develop expertise. Become a “unicorn” (a person whose combination of skills makes her unusually rare and confers leverage). Get Type 1 jobs. The real world, of course, isn’t quite so simple; and it might be hard for an individual to tell which of the two possibilities applies to her job. I’m here to tackle some of the more complex cases that pop up in reality, and analyze which dynamic of behavior is more accurate to each.
Below are some cases that don’t necessarily fall into a clear Type 1 vs. Type 2 delineation, and require further analysis.
Excess capacity. Most large companies don’t hire for a specific role, so much as they increase (or decrease) their total headcount based on business needs, cash flow, and economic projections. Companies”don’t hire specifically for Type 1 or Type 2 work; they’re concerned with the economics, not sociology. Most people, in truth, are hired into firms to serve as “excess capacity”; that is, hired into a general-purpose labor pool so there is some slack in the schedule and there are internal candidates for vacancies. Whether a person ends up in Type 1 or Type 2 work isn’t driven by some abstract “general will” of the firm but by the needs of specific managers where that person lands. Unfortunately, this often puts a person into Type 2 work by default.
Depending on the company, the manager of the new employee’s team might not have had any input into the hiring of that person. Sometimes, the company just says, “here are some guys”, and that tends to result in a lot of undesirable work being offloaded onto them. Or, that person may have been hired for a position that was shortly after filled internally, or made redundant, leading to a need to make work for the new hire. The point of all this is that if you can’t identify (and preferably quickly) some X for which (a) a manager needs X, (b) the managers knows he needs X, and (c) you’re very good at X; you just become a fresh hire looking for something to do.
Simply being “excess capacity” isn’t necessarily bad. If there’s honestly about the fact, then management can set an appropriate arrangement. “You can work on whatever you want most of the time, but when you’re needed, you’re expected to be available.” Then, a person has the time and allowance to seek Type 1 work where he or she will add more value. Some companies explicitly set aside time for self-directed work (e.g. 20% time) in acknowledgment of the need for slack in the schedule. Others do not, and fall into a Type-2-driven default pattern of rippling delegation.
In large companies, people are hired for macroeconomic reasons that don’t conform to the Type 1 vs. 2 delineation explicitly, leaving the question unanswered: does the employee become a respected advisor whose expertise confers a certain automatic credibility, or a grunt to which the worst work is delegated?
Automation
Especially relevant to technical work is the role of automation. If work is undesirable, someone will try to “kill” it by programming a computer to do it faster and more reliably than a human. For many business processes, this is easy. For some, it’s quite hard. For example, it took years of research into machine learning before computers could accurately read hand-written addresses. At any rate, computers turn out to be perfect repositories for the worst of the Type 2 work that no one wants to do. They do it without complaint, and much faster. They’re cheap, as well. This is winning for everyone.
Computer programming has its own weird interaction with the FTOE. Business problems were traditionally solved with lots of low-paid and ill-respected manpower, so corporate growth mostly came down to the delegation of Type-2 labor as the beast grew. However, the magic of software engineering is that a small bit of more challenging, more fun work (automating painful processes so that the task is complete forever before the novelty of the new job wears off) can replace a larger amount of bland, tedious work. Most of business growth is about Type-2 hiring: bringing in more people to do the work that the bosses don’t want to do. A competent software engineer can take on the Type-1 task of automating all that junk work– if management trusts her to do so.
Management doesn’t, in general, care how the mountain of traditionally undesirable work is done. If it’s done well by ten bored humans who occasionally quit or fail but are easy enough to replace, that’s the familiar “devil you know”. If someone else can come along and perform the much more enjoyable task of automating that work for good, that’s better because it saves a lot of money and pain. Sort-of. There’s a problem here, and it’s one that every software engineer and software manager must understand.
The relationship between software engineers and management is fraught with conflict. There are few industries where there is more tribal dislike between workers and management than in software, and the problem isn’t the people so much as the interaction of incentives and risks. Software itself (like any industry) generates a lot of undesirable (Type 2) work; but in software, there’s almost always a way of automating the bland work away– a hard, Type 1, sort of job. The danger of that is that the automation of undesirable work might take more time than simply completing it, while the engineer’s impulse (which is almost irresistible) is automate immediately and without regard to cost.
This provides two very different paths to completion: one that is low in variability but boring, the other being more fruitful but riskier. What goes wrong? Without diverging into another subtopic, management participates more fully in an employee’s downside than upside risks– if the engineer does great work, it reflects on that engineer; but if the engineer fails expensively, it reflects on the management– so managers tend to favor low-risk strategies for that reason alone. It’s not that software engineers or managers or bad people; the risks are just improperly aligned.
Solving this problem– aligning incentives and structuring companies to take advantage of opportunities for automation, which almost always improve the firm’s success in the long term– would require another essay.
Defensive rejection
Above, I’ve proposed that people hire others to do work in one of two cases: undesirable work, and work that the person doing the hiring can’t perform. There isn’t always such a clean-cut distinction. Most people don’t have the humility to recognize their limitations, and so they tend to overestimate their ability to perform work that they know little about. The extreme case of this is defensive rejection, in which a person denigrates a class of work as being menial, unimportant, or trivial to compensate for a lack of knowledge about it.
Many software engineers are going to recognize that the attitude of “the business” toward their work is often a case of defensive rejection, and that’s right. But we, as a group, are far from innocent on that front. We tend to take the same attitude toward marketing and business people. The truth is that the good ones are highly capable in ways that most of us are not; most of us just lack the basic competence to separate the good ones from the bad. When one lacks visibility into a field of work, one tends to associate all people who do it with the average competence of the group, which usually leads to an unflattering stereotype for any high position (because most people in it are, in fact, unqualified to hold it). That leads to the incorrect conclusion (also seen with politicians, of whom the average performance is poor) that “none of them are any good”.
When defensive rejection is in play, the underlying truth is that the manager is hiring in type 1; the employee is brought on to do work that the manager can’t do for himself. Unfortunately, the manager’s insecurity and hubris generate a type-2 context of “I could do that stuff if I wanted to”. The subtext becomes that the work is bland, detail-oriented dreck that the manager is too important to learn. This is the most frustrating type of job to be in; one where the boss thinks he can do your job but actually can’t. It means you have to deal with unreasonable expectations despite low overall status and perceived value to him and to the company as a whole. That’s horrible, but it’s also freakishly common as far as scenarios go, and it leads to the engineer feeling set up to fail– asked to do impossible things, then treated poorly when inevitable failure occurs.
Apprentice systems
There’s one other scenario that doesn’t fit nicely into the Type 1 vs. 2 delineation: the apprentice (or protege) context. At first thought, apprenticeship might seem to be strictly Type 2, since most of the work that apprentices spend their time on is make-work that has ceased being interesting to superior craftsmen. However, apprentices bring a Type-1 function by being able to do one thing the master cannot: perpetuate the work (and, more importantly, the upkeep of a valued tradition or institution) through time. If you’re sixty years old, a twenty-year-old apprentice can continue the work forty years (on average) longer than you can.
Modern private-sector corporations don’t have much use for apprentice structures and guild cultures, because they no longer see that far into the future. No CEO gets job security by setting up a culture of mentorship that might yield excellence ten years down the road. In this next-quarter culture, apprentice systems have mostly been thrown overboard. Long-term vision is far out of style for most modern corporations.
That said, there’s a value in understanding this old-style system. Why? Because even managers are uncomfortable with the naked parasitism of Type-2 employment (e.g. “I’m just hiring you to do the crap I don’t want to do, while I fill my time with the career-building and fun work”) and often attempt to recast the role as an apprenticeship opportunity. That is, at least, how every subordinate job is presented; an opportunity to learn the skills necessary to get to the next step. There are varying degrees of earnestness in this– some managers truly see their reports as proteges, while others see them as mere subordinates.
In negotiation theory, this is sometimes called a standard: a promise that is understood not to be fully delivered (most people realize that most bosses just see their reports as repositories for undesirable work, and that the apprentice metaphor is mostly rhetorical) but that may still be cited in policy to get an arrangement more in accord with that standard than one might otherwise get (“appealing to the standard”). Even people in power are uncomfortable explicitly departing (“breaking the standard”) from something previously promised.
If you want to move from Type-2 to Type-1 employment (and, believe me, you should) then the first thing you have to do is get qualified for that kind of work; the best way to make sure your boss gives you appropriate work (to gain that qualification and validation) is to continually appeal to the standard of the master/apprentice relationship– and hope that your manager doesn’t have the audacity to break the standard.
Why is FTOE important?
It’s important to understand the Fundamental Theorem (and being trained as a mathematician, I know it’s not actually a theorem so much as an observation) of Employment, above, because people tend to discuss conceptions of “the job market” as if they were forces of nature. They’re not. A job exists because someone needs or wants another person to perform work, and the expensiveness of that generally means that one of two cases applies: the person doesn’t want to do that work, or the person cannot do that work. Regardless of the work itself, the social contexts that arise from those two subcategories could not be more different. It’s very important to know which one applies.
The advice that comes out of this is to find a way to qualify oneself for the Type 1 work. That’s harder than it looks. Becoming good at highly-skilled work is the first half of the battle, but there’s a social component that can’t be ignored. Software engineering is a prime example of that. The whole point of the bastardization of “object oriented programming” (which, by the way, has become the exact opposite of Alan Kay’s vision of it) that has grown up in the enterprise is to coerce software engineering into Type 2 commodity work. Having generating scads of low-quality, brittle code, it can be called a failure. Yet that mentality persists in the world of corporate software engineering, and it will be a while before the business starts to recognize software as Type 1 work.
While one is progressing through the validation process that is more drawn-out than building the skill set, I think there are two key strategic necessities. The first, again, is to appeal to the standard (as above) and re-cast any Type 2 social context in employment as a mentor/protege role. The second, and more importantly, is to always drive toward a Type 1 context. The question should be asked: “What am I here to deliver that no one else can?”
