Developer Hegemony: The Future of Labor

by Erik Dietrich

I spend time with a wide variety of large organizations. Based on what I’ve seen working with these places, and based on my understanding of industry trends in general, I think I know what will give. Those companies will move away from employing software developers as wage laborers. The economics simply don’t make sense. Don’t get me wrong. These companies will absolutely continue to want and to need software and automation. They just won’t continue to staff it with salaried exempt employees in the same kind of numbers. Large organizations, especially ones that do not directly sell or monetize software, have a number of factors working against them. I’ve spent this chapter talking about the titanic downward pressure exerted on wages, and that reigns as factor number one. All of the rules about what employees have to make relative to one another completely evaporate when it comes to

contractors and custom app...

But it goes deeper than that. Massive companies have bureaucracies in place that serve two principle purposes: risk mitigation and communication at scale. Both of these considerati...

The crunch to which I refer is the one that will effectively expel developers from the ranks of large, unwieldy organizations. It will happen in fits and starts and will appear slow to develop, to the naked eye, but make no mistake. It’s in progress and will continue.

The trend will drive software developers to three main camps: large software companies, startups and small product companies, and custom app dev shops (including solo freelancers).

Over the long haul, I think you’ll even see fewer d...

for massive tech companies, since they have their own forms of bureaucracy and risk aversion, albeit less obtrusive. When you really dig into the tech titan organizations, they tend to innovate via merger and acquisition more than by homegrown gro...

And in that world, a new entity reigns supreme: the autonomous developer opportunist.

The developer opportunist, an entity apart from salaried development in the corporate world, cedes none of these. To meet these criteria, she most likely operates as a free agent of some sort. But she might instead job hop so frequently as to resemble a free agent. Or she might operate as part of a highly unorthodox corporate structure.

Nietzsche believed that the next step in human evolution would be categorized by those that rejected preconceived moralities in favor of their own. Rather than call for moral bankruptcy, the

message could be interpreted as this: let’s say that you remove God and any concept of objective morality. The ubermensch is the person who staves off nihilism by filling the resultant void with morality that results from a love of life. The ubermensch, then, radiates morality in the absence of an externally defined and imposed morality. Think of him as the moral equivalent of a rogue planet in deep space with its own, internal heat source.

Identifying prospective employers and doing the interview dance requires a lot of effort. If you’re doing it with any frequency, you’re already spending time managing the pipeline.

If you’re just starting to do this as a wage employee, the best way to get off the ground is to simply identify whether or not the work you’re being given is good for you and your career. Once you’ve established a habit of critically qualifying your work, you can set about adding progressively better options to your pipeline.

Developer opportunists have options.

When options come to you with relatively little effort, it has a multiplicative effect on the flexibility with which you approach work. It means you’ve diversified your portfolio, as I discussed earlier, in Part 4. And if you’ve diversified, even when you seek out options, any particular one becomes less drastically important.

Developer opportunists do not get caught flatfooted the way a single prospect employee would. They continually cultivate and maintain options so that they can opportunistically choose from among them and create their best situation.

When you get down to brass tacks, all of the non-programming activities they take on are about option generation. They self-market, building names for themselves in the industry. They create content and grow their networks. They keep their eyes open for what opportunities may come along, in any form and from any angle. And they actively oil their work pipelines.

The developer ubermensch needs the world less than the world needs her.

She’s in such demand not necessarily because she’s the most skilled, smartest, or most technically knowledgeable. She’s in such demand because she does an incredible job of identifying what others value and positioning herself uniquely to deliver that value. Superior technical prowess helps, but developer opportunism, predicated upon options and granting autonomy, comes from understanding of and fluency with business.

Let’s take a look at what this looks like applied to our world, in the form of a single freelance software developer. Product/service creation (“I write code.”) Operations/delivery (“I’ll deliver the code to you by January twenty-fifth and check in with you every two weeks in the interim.”) Accounting (“When I’ve delivered the code, I want you to pay me, and I’ll keep track of whether you have or not.”) Sales (“I charge $100 per hour, but I’ll offer a weekly rate of $3,500 and a monthly rate of $12,000.”) Marketing (“Check out my blog and website for tips on writing good code.”)

There are several reasons, [and] probably chief among them is that a significant portion of software developers are terrible marketers. [They’re] not only terrible at knowing and articulating their worth, but [they’re also] emotionally tied to an idea that marketing is beneath them.

The

corporate world is all too happy to indulge our demand, pay us a third of what we’re worth, and let us exist in a bubble of illusory superiority.

Our value proposition is that we provide expertise in efficiency. “I help you have more time and money.” Or, at the risk of sounding a tad overly dramatic, “I help raise the standard of living.” Sounds pompous, but that’s what we do—eliminate jobs of drudgery and create ones of knowledge work. I’d say that time and standard of living as by-products of our work put us on par with those offering services around rights and health.

James Grenning, likewise, had an interesting answer. The corporate world does not know what programming is. They view it as labor (more hours equals more output, cheaper hour rate means less cost), not knowledge work (problem solving takes time and some people are better at it than others).

This has given rise to all manner of ceremonies and strategies for cross-discipline collaboration. In fact, the recent love affair with the concept of DevOps illustrates this perfectly.

But no one is saying that business people and developers should be the same people. Except me. I’m saying it now. Efficiencers are to business and software development what DevOps is to development and operations.

In Scrum parlance, you could think of an efficiencer firm as one that convinces the client to delegate product ownership to a member of the firm. Your client would say, “Hey, Efficiencers Inc., we have the goal of automating customer orders, and you’ve told us that you’ll take on the project and deliver a system that lets us process ten times as many orders per hour as we currently do. The gig is yours—go!” With this mandate, “product owner” is clearly something the efficiencer firm arranges to be internal. After all, they’re the ones with the vision for the 10X speedup, so why wouldn’t they own any decisions relating to any software that needs to be written to achieve the goal?

To put this concretely, if you started an efficiencer firm, you would not take specs, and you would not

take wireframes, and you would not take direction on software. Software (and by extension, automation/efficiency) is your area of expertise, not your client’s. In the future, thi...

If you find yourself in the unfortunate position of getting divorced, you start asking people you know for referrals to divorce attorneys. If you have problems with your foot, you call up someone with the title “podiatrist,” meaning “foot doctor.” Those autonomous knowledge work professions organize themselves according to the problems their prospective customers have. They advertise in terms their customers understand.

Software developers and app dev firms fail spectacularly in this regard. We organize ourselves and sell labor on the basis of what tools we use while our customers tell us what to do. Think about how a moderately sized app dev consultancy might look for employees and advertise to clients. “We’re an agile Ruby shop that works with small and medium sized companies.” This is like an OB GYN practice saying, “We’re a practice that does epidurals and Cesarean sections for young to middle aged women” instead of “We help you give birth.” Current app dev shops also wash their hands of any real expertise in business. Instead of telling our clients “the baby hasn’t turned and you’re going to need a C-section,” we say, “All right, just give us a spec for how the birth needs to go, and we can do anything you want!”

Well, the first step is to stop organizing ourselves into groups of people that use common tools and then selling “We’ll do anything you tell us” to customers. When you do that, you’re selling neither a good nor a commodity nor a service. You’re selling humans in the form of pseudo employees. That’s called staff augmentation. And make no mistake: even if you supply an entire team that doesn’t physically sit at the client’s site, you might still just be doing staff augmentation. Staff aug is not a question of how many people you supply or where they work, and you don’t get out of staff aug mode by simply offering advice about what you’re doing and calling that “consulting.” Staff aug is a matter of whose vision you execute. If it’s anyone’s other than yours, you’re augmenting their staff.

When we advertise as a Ruby shop that can build anything you like using Ruby, we’re making two efficiencer mistakes. First, we’re involving the customer in something it shouldn’t know or care about: our tool of choice. Second, we’re leaving ourselves out of a matter we should know and care about: what we’re building and why. Understanding this truth is the first step toward forming efficiencer firms. It’s also a step toward getting clients that don’t just ask who you think you are when you have a frank conversation about whether they even need the software they want.

The first thing you need to do in order to start having these conversations is to put on your sales hat and articulate what you offer. It can’t be your labor. It has to be your expertise in making something more efficient. This will most likely take the form of a productized service. A productized service is a sort of pre-baked consulting solution to a tangible problem. For instance, consider the example problem to which I have referred a few times: an organization thinking a website will allow them to fill many times more orders than they currently can. Instead of making your selling point “We build websites in Ruby for sma...

Notice that we’ve flipped the script and avoided the two anti-efficiencer mistakes. We’re no longer involving the customer in something it doesn’t care about (what programming language we use) and we’re no longer left out of the client’s discussion of what they want and why since, by the very nature of what we offer, we’re automatically part of that conversation. This can work even as you transition your business model and develop the offering. If you interject...

presumptuousness, but the strategy behind these types of projects is actually a first-class offering of ours.” It’s a bummer to still have to say this in 2017, but adding that last part changes your rank from “coder” to “consultant,” and that makes them far more likely to listen instead of saying, ...

If you look at the panel of people to whom I’ve talked, you’ll find examples of productized services in the mix. James Grenning tells prospective clients, “I’ll teach your embedded software team how to test drive.” Sally Lehman has created a niche for herself that would serve well in a consulting capacity: “I can help you with email delivery.” But beyond that, look at the folks that offer products rather than productized services. Eugen and Thorben specialize in Spring and Hibernate, respectively, and offer courses. John Sonmez offers info products to teach software developers soft skills. They could all easily compliment their product offerings if they so chose by offering productized services around them. (It bears mentioning ...

If your firm adds productized services to...

it will, almost by definition, add an alternative billing model to its portfolio as well. And alternate billing models are another import...

Let’s consider how app dev consultancies bill their clients today. Generally, they have two standard options: fixed bid or hourly/time-and-materials. Fixed bid offerings mean that the customer comes to you with a spec or a request for proposal (RFP). You size it up, estimate that it will cost you about $300K to develop, and then say that you’ll do it for $500K. If the customer agrees, you now absorb all of the risk with relatively limited reward. After all, you’ll get the $500K from them whether it costs you $300K or thre...

That brings us to time and materials. In time and materials, you, as an app dev firm, say, “Gosh, I dunno—that’s a complex project. We’ll just start working and it’ll cost $100 per hour. We think it’ll take 5,000 hours, but that’s just a guess.” The customer now ...

Guess what. That makes the customer really interested in what you’re doing during those hours. It’s the only measure they have...

Heavy interest in what you’re doing each hour makes you look an awful lot like one of their employees and lands you right back in staff augmentation mode. As I explained earlier in the book, salarie...

But if you’re adding productized services to your offering portfolio, you enter a different mode of operation. You’re doing something repeatable enough that you don’t need to completely punt on effort/cost estimation. In other words, you’d never agree to build someone a massive custom website as a fixed bid project because no one has ever done that exact project before and neither party has the faintest clue what it wil...

Even better than quoting a price based on your cost is quoting a price based on the client’s realized value. For instance, let’s go back to the example of automating order processing. If you’ve done ten of these automation projects before, you might know that it takes you about two weeks a pop. If you’re accustomed to earning about $5,000 per week, you could quote a fixed rate of $10,000. B...

You could ask for $300K for the project, and they wouldn’t bat an eye. Neither party cares about your cost during pricing—only what the thing is worth.

This is called value-based billing, and while it’s a nice alternative to other billing models in its own right, I don’t mention it here to say that it’s a prerequisite for transitioning toward being an efficiencer firm. Rather, I mention it because it gives you yet another pretext for having the strategic “why” conversation for the project. You can’t attempt to ascertain the value of an initiative without having a strategic discussion. And again, if you explain that the strategic conversation is part of your discovery and quote process, clients will be a lot less likely to take it out of turn.

You can even continue to offer custom app dev as an upsell to your normal offering. That’s less strategic in and of itself, but the expertise required to furnish a productized service offering will ensure the discussions remain strategic. The most important thing is to position yourself as a business expert that can bring ...

expert productized...