Developer Hegemony: The Future of Labor

by Erik Dietrich

I can see that you’ve gone to a lot of trouble to create an RFP and all of those specs, so I can definitely understand that you want to proceed along those lines. Unfortunately, we don’t advise that course of action based on our experience with these sorts of initiatives. If you want to do that, I’d suggest going with another vendor, but keep us in mind down the road if you do. What usually happens to clients in situations like yours is that they issue an RFP, get about five bids, pick the second-least expensive one, spend six months arguing about fonts and colors, and wind up paying 50 percent more than the firm quoted for something you’re not thrilled about. If you sense that happening, let’s talk.

You can be politely firm about your position and demonstrative of a lot of experience all rolled into one conversation. It’s also powerful when you’re able to read

or forecast your prospect’s pain points and when you refuse to be the ...

I foresee companies springing up to offer all sorts of services to tiny software development shops. For instance, accounting firms and marketing firms could easily niche into helping only small custom app dev shops. Legal is another big one as well. A company could propose that, for $1,000, they will incorporate you, start you off with a set of boilerplate contracts for clients, and

give you a road map for keeping yourself out of any legal jams.

The sky is the limit with these sorts of things, so it’s not like I’m giving away billion-dollar trade secrets. More and more, software developers are going the freelance route. Even more than that are flirting with the idea. Removing barriers to entry wi...

If you want to see some early signs of this transition—of the rise of efficiencer firms and developer entrepreneurs—look no further than people selling things to developers. Scratching our own itches is the beginning of developer hegemony because it’s a low friction way to cut out needless interposition.

As efficiencers, I propose that we avoid viewing margins on other people’s work as the only (or even a desirable) way to scale. With that central assumption cast aside, we can revisit others.

Here are my principles: Efficiencer firms are bootstrapped and self-sufficient, meaning they’re profitable from the outset. The members of efficiencer firms are partners. All members execute on the organization’s value proposition and have skin in the game. Instead of employing pragmatists, they delegate to vendors. They don’t rely on absurd practices like job interviews to scale up their delivery capabilities. That happens via trial, recommendations, and networking. Everyone’s contributions to the organization’s profits can easily be measured. They only grow as long as that remains true. In short, the firm is comprised of opportunists. Anyone who would normally be a pragmatist is instead a vendor. This in turn eliminates the need for an overenthusiastic buffer of managers and senior people.

When I consult with companies, I frequently explain that trying to automate a process as you figure it out is a mistake. Get the process right first, then simplify it to core principles. Only then do you automate.

And I think you might see a shift in what recruiters do. Instead of trying to staff developers at MegaTech Corp., they may start matchmaking between efficiencer firms looking to scale up and down for projects.

For instance, consider something I’ve always thought of as a great conceptual alternative to the programming interview: hire someone for a week and see how it goes. Currently, that’s unworkable. Few staff software developers will want to quit their current job to try out another one for a week when the new one might not work out. But imagine if thousands of firms hired this way. Now the risk is gone, since you can just temp-hire

on at a different one each week until you find a good landing spot. This, in a nutshell is the sort of critical mass paradigm I’m talking about. The more people that leave standard arrangements, the easier it will become for you to leave as well.

I’m saying that they can scale, but with some stipulations: They avoid venture capital They don’t employ pragmatists and idealists. They don’t scale sloppily (e.g., via job interviews). They don’t obscure individual contributions as they grow.

One is a freelancer who has about ten customers, with the largest being no more than 25 percent of his income. The other is an employee with ONE customer who gives him 100 percent of his income. Who is more at risk? The employee.

We humans have a cognitive bias known as the endowment effect, wherein we value things more when we own them than if we were buying them.

An efficiencer program could be longer. It could give you enough time to start with the bigger picture concern of identifying automation and efficiency opportunities. It could send you forth into partner companies to interview people working there and discover pain points. Once you’d gathered up those needs using the interview techniques you were taught, you could bring them back to home base. There, people would show you how to identify good and bad candidates for automation. They could show you how to write user stories and tell you why you do this, instead of just teaching you teh agilez. They could also show you how to write value stories that express your proposed automation in terms of the

amount of money it would save your client, and over how long. They could also show you how to value price the offering and perhaps generalize it for other prospective clients.

I mainly think that the efficiencer firm will start to replace the staff of developers that you see at non-software companies: banks, manufacturing companies, retailers, and the like. At organizations like that, software development (and IT in general) is what’s called a cost center. That term describes a department within an organization that costs money to operate but does not directly contribute to revenue generation. Other cost centers include things like human resources and accounting. Incidentally, at any decent size, all layers of management are also cost centers.

In these sorts of organizations, corporate IT typically serves two purposes. One is internal cost-saving automation. For example, IT at a bank might be asked to automate the help desk system as much as possible to save on phone support salary. IT’s second purpose is product enhancement. Developers, for instance, might be asked to implement a “manage your account” website because customers consider that a fundamental service of modern banking. This is not the bank’s product, per se, so it qualifies as product enhancement—it makes the actual products, like savings accounts and money markets, more attractive to customers.

One important consideration throws a Paul-Bunyan-sized wrench into the spokes; the only thing more expensive than a good software development team is a bad software development team. The colloquialism that comes to mind is penny wise and pound foolish. It describes cost center IT quite effectively.

One thing I’ve seen time and again in my travels through enterprises is a pair of sequential aha moments. “Aha! We’re really bad at this, so let’s bring in some consultants to figure out what’s wrong and demonstrate how to do it right.” And then, “Aha! Those consultants are really good at this—let’s just pay them to do it instead.” As those “ahas” blink into existence like stars across the night of the corporate landscape, staff software developers will flow out of those organizations and into efficiencer firms. There, they’ll flip from cost centers to revenue generators. And they’ll participate directly and meaningfully in the running of the business. So goes the rise of the efficiencer firm.

That settled, let’s talk now about the fate of non-efficiencer firms in a future of developer hegemony. These consist of three interesting types that will

probably not ever become efficiencer firms: non-software companies, software product companies, and traditional app dev shops (“consultancies...

For non-software companies, we have an obvious answer that I can express rhetorically. Why would they? They have no more incentive to specialize in helping customers get more efficient than they do to help them extract molars or fight parking tickets. These companies will interact with efficiencer f...

Secondly, consider software product companies. Again, why would they become efficiencer firms? Granted, their motivations might be a touch grayer since they do have automation at their core and they do trade in efficiency. For instance, Amazon has a massive product/service that helps you buy things more efficiently. But the efficiencer firms of the future exist by fleeing the role of cost center and flipping their former employers to customers. Efficiencer firms will offer business specific solutions and play almost exclusively in the B2B (business to business) market. Software product companie...

representing the masses and have relatively low-touch engagements. Efficiencers partner with businesses in a higher touch cap...

Finally, consider the traditional app dev “consultancy.” This type of organization seems most ripe for the conversion to efficiencer firm, but I submit that most will never transition. Instead, they will live on as the perpetual budget-brand version of the efficiencer firm, taking in specs and spitting out m...

Traditional app dev consultancies bill hourly, and they grow by capturing margin on employee labor and reinvesting it in the company (or keeping it as owner/shareholder profit, but let’s forget about that for the time being). In other words, going back to the pyramidal organizational structure, they grow by adding more pragmatists at the bottom of the pyramid. They also need a proportional number of idealists to manage the margin generators at the bottom. Growth—nicer offices, new branches, additional lines of business—involves legions of pragmatists, a skeleton structure of idealists,

and the occasional (very busy) opportunist.

With traditional app dev shops, efficiencers will sometimes compete, sometimes partner. But they will fire a shot across the bow of all three types of organizations in the form of driving up the market value of software work. These firms will offer more profitable, more autonomous, more dignified, more fulfilling work to software people. And that, in turn, will make it more difficult for these other companies to staff software people.

First, the nine-to-five work day needs to go away. There are two principle factors at play here that tend to anchor this in place: child care and old men. The world has loosely agreed to a public babysitting service (school) that occurs during the work day, and that pressures people to conform to the mean. Secondly, old men are in charge of traditional corporations, and old men have circadian rhythms that get them up and going early.

Pillar provides consulting and app dev services to its clients, and I subcontract for them

sometimes. An executive there once described my arrangement elegantly, using a great analogy. He said that newspapers tend to have staff writers, who have traditional salaried jobs. But they also have contributing writers, who have a standing relationship with the paper but operate as independent contractors. He then described me as a contributing consultant, which I thought was wonderful. That’s a singularly progressive way to partner with people in a way that blurs the line between employee and independent.

If you want to escape the pathological Taylor concept, you have a few options: small, startup-like firms; smallish custom app dev shops; non-traditional outfits like GitHub and Zappos; and free agency. And you’re not going to find any of those (by and large) on the Fortune 500 list.

This is a human cognitive bias known as effort justification, wherein your value of the “in” crowd and its selection process goes up substantially in proportion to the barriers to entry. Here’s an example. If I ask you to eat a flavorless gelatin, you’ll turn up your nose. But if I ask you to whiteboard a doubly linked list in order to qualify to eat that same dessert, you’ll eat it and say, you know, it’s actually pretty good, and people really should have to do a whiteboard exercise to earn it.

First things first: you’re working toward autonomy, and working from home, by its very nature, grants you more of that. It starts to remove the “butts in seats” attitude of employers, at least as it concerns you. They’re less likely to evaluate your performance the same way they would the guy who takes orders at a pizza place. When presence melts away as an evaluation criterion, they get closer to reasoning about the value of your contributions. All of this has the effect of raising your profile in the eyes of those you work with—provided you still manage others’ perception of your contributions, of course.

I’ve saved this piece of advice for last because I consider

it perhaps the single most important thing that you can do. Take a product or productized service, build it entirely end-to-end, and sell it. I cannot understate how educational this is for grokking all aspects of a business and putting yourself in a position to call the shots. By doing this, you are graduating as an efficiencer in a way that even the playing-an-efficiencer-inside-your-company tactic won’t allow. You have built a business.

Build something small. Maybe it’s an online course, an e-book, or a little app that you sell in an app store. Just pick something and ship it. The amount of education that happens in that alone would amaze you. You’ll need to consider what sort of business entity to form and set up a way of dealing with your expenses and revenue. You’ll need to figure out how to market what you’ve done—how to get it in front of interested parties. On top of that, you might find yourself making sales pitches. The list goes on. Not all of that is the deeply technical work that we’re used to doing, but it’s complete, informative work.

In the years since then, the opportunist layer of organizations has long since gotten out of the efficiency business, except as consumers. Same goes for the

idealist middle management layer. Oh, they understand the broader notion that if they stopped paying people to do data entry, they’d save money. But they’re completely out of touch with the implementation. At the behest of the upper layers of the organization, we programmers have been dutifully automating legions of pragmatists out of jobs. The aforementioned data entry jobs are ephemeral and increasingly rare. Many factory jobs and manual labor tasks have gone the way of the dodo. And in coming years, more pragmatist jobs will follow suit: driving trucks, waiting tables, working as cashiers, and many others.

The opportunists delegated efficiency creation to idealists, who in turn delegated it to pragmatists.

Along with all of that delegation came the huge, unintentional windfall of also passing the means of efficiency production. Today, we live in a world where the pragmatist engineers, developers, and designers create all of the efficiency and have all of the means of production for doing so. This, in turn, means that we have all the leverage. Let me now state the implication that generates in no uncertain terms. We have absolutely no need for owners and managers, for traditional opportunists and idealists.

Idealists cannot exist without three essential components: faith in the wisdom of the corporate entity, pragmatists to compare themselves to in order to manufacture meritocracy narratives, and opportunists to manipulate their naivety. If we build a true efficiencer movement, we turn legions of pragmatists into opportunists. The idealist, then, just sort of fades into the background of history. The pragmatists exit, making overpromotion moot. The opportunists, many of whom are former-pragmatist efficiencers, recognize a more efficient path to ownership than pyramid climbing. They also exit. With the absence of the other two layers and the crumbling pyramid, the idealist faith will not

last.

Right now, pragmatists and risk-averse opportunists alike are dissuaded from the free-agent/efficiencer route. Going off on your own means spending a lot of extra time on risk management and the hustle. It’s like moving from a life of raising crops in a temperate climate to a life of nomadic hunting and foraging.

The programmer community, for whatever flaws it may have, is wonderfully collaborative and instructive. We flood the world with language guides, framework tutorials, codecasts, books, and everything else you can imagine. We may get a little elitist, but we help one another.

The same thing is happening with the efficiencer playbook. We’re branching out from the technical into the practical. People offer their stories as instruction: “Here’s how I went from building WordPress sites for $60 an hour to offering a product...

One of the biggest growth industries imaginable is going to be products and services that help make it easier to go efficiencer. This will include tutorials and guides, as well a service offerings to set up a corporate entity for you. But it will also evolve into more elaborate and complex offerings, such as single-payer benefit groups and risk-pooling mechanisms. What this looks like, I don’t know exactly. But it’s coming. The demand for lifestyle design is simply too high for it not to, when we’re talking about a population segment with all of the leverage and the means of production.