Your Job Title of Tomorrow: Efficiencer
Your Job Title of Tomorrow: Efficiencer
You might be surprised to hear someone say that devs' true value proposition isn't the code the create. Read on to find out what they really bring to the table.
Join the DZone community and get the full member experience.Join For Free
Since I boasted about this on Twitter, I have to follow through. I’m going to do “Developer Hegemony Week” on my blog, leading up to the book launch on May 2nd (I suppose this makes Developer Hegemony Week a misnomer of sorts since we’re talking about 9 days of posts). I can think of no better way to kick this off than to talk about “the efficiencer.” For those of you not familiar, Developer Hegemony is the book I’ve written and am launching on Amazon soon. In it, I coin the term efficiencer.
Okay, so let me explain why I’ve coined a word and why you should care. For the rest of this post, I took an excerpt from the book and modified it a bit. I’m now offering it here as a canonical definition for the blog. And in it, I explain why we need to go from shrugging when presented with wire-frames and specs to saying, “I understand the business problem you’re trying to solve — let’s talk revenue goals, and you can leave the specs to me.”
I’m Glad You Called — I’d Love Some Unsolicited Financial Advice!
My cell phone rang about mid-morning, and it presented me with the ultimate conundrum for an introverted entrepreneur/consultant: an unrecognized phone number from my area code. On the one hand, it could have been a prospective client or generally someone whose call it would make sense to take. On the other hand, I didn’t recognize the number, which usually signals some kind of solicitor or scam. I decided to answer because I thought I’d seen the number before. Either someone really wanted to talk to me or I’d have to tell them to put me on their do not call list to get them to leave me alone.
I instantly regretted my decision to answer. A criminally cheerful voice said, “Is this Erik Dietrich?!” You’d think he’d just gotten his personal hero on the phone.
I sighed, recognizing the forced, chipper tone of someone who lives by the motto, “Always be closing.” “Yes,” I said guardedly.
He told me that one of my friends had referred him to me, saying that I was someone that would potentially be interested in his services. He was a financial planner, you see, who specialized in helping young couples achieve their dreams — couples like my wife and me, as my luck would have it. “When is a good time for us to get coffee?” he asked after blithely glossing over this dubious introduction (my friend never had, in fact, briefed me that this guy would call).
Do you see what he did there? It’s a classic sales technique wherein you don’t give the mark prospect the option of saying no. This bit of slicked-back-hair salesmanship is a close cousin of the “loaded question” logical fallacy. “Have you stopped cheating on your taxes?” “Yes, I mean, no, I mean—hey!!” No matter how you answer the question, you implicitly concede a point made by the asker. In the case of our used-car salesman cum financial planner, answering his question politely leaves me no choice but to agree to meet him.
I sighed again. Briefly, I thought about setting a meeting at some Starbucks in the area and then never thinking about him again. But that seemed disproportionately cruel, so I broke script and told him that I wasn’t interested. After taking one more stab at me with a, “When is a good time to follow up to see if you’ve changed your mind?” he’d exhausted his slimy script and hung up on me with no fanfare. Class act from start to finish. I should call him back, say I’ve reconsidered, and set up that phony meeting after all.
Software Developers Let Skepticism Become Opting Out
We software developers present as an unusually marketing/sales-averse group. We’re skeptical of crap like this, and the world reinforces that skepticism. On top of that, we also tend to be fairly clever, so we get good at sniffing these things out. “Oh, heavens yes, I could use some unsolicited financial planning from you, stranger,” isn’t something you’re likely to hear out of the same mouth that says, “You should use the builder pattern in that module.”
We connect such instances of disillusionment with the seedier side of commerce, and we use the scars they produce to inform our preferred roles within organizations. We don’t stop to consider that not all sales happens equally. Imagine that I had a buddy sitting next to me when I got that sales call, and he’d listened to the exchange. When I got hung up on, say this buddy said, “Oh, dude, I wrote this app a while back that’ll make sure no guy like that ever calls you again. It’s only $12.” I’d have sprained my wrist grabbing my wallet with too much force.
We don’t really think of those helpful types of interactions as sales. More importantly, we don’t tend to think about how we might apply our own world views to disciplines like sales — what sales would look like if developers ruled the world. Instead, we regard these other professions the way most of us regard the vocation of plumbers specializing in sewage. It needs to exist, but I want to stay as far from it as possible and not think about it.
Efficiencers Have the Leverage to Change Things
Developer hegemony will come from using our leverage to remake facets of business, like sales, according to our preferences. If you don’t like sleazeball sales, weird accounting practices, and sloppy organizational operation, don’t complain, and definitely don’t ignore them. Take over and fix it. We’re not trying to bamboozle suckers into generating commission for us in our roles as middlemen. We have too much leverage for that to be necessary. And we have this leverage by virtue of the fact that we’re efficiencers, whether we realize it yet or not.
As software developers, we automate things. This is easy to see when you contemplate a team that saves money for an organization by writing line-of-business web services and the like. It’s a team that’s automating away the need for manual data entry. That automation enables the organization to do more work in the same amount of time without hiring additional people or buying additional resources. And output as a function of time is — you guessed it — efficiency.
Time Savings as the Software Developer’s Actual Value Proposition
Efficiency equals stuff divided by time. Thus, our true vocation takes two basic forms. We allow people to do more stuff in the same amount of time, or we allow people to do the same stuff in less time. In both cases, we increase the value of efficiency in that equation. This is obviously true with things like automating data entry, but it extends to all facets of programming, including virtual reality or games. We allow people to “visit” the Grand Canyon without spending money on plane tickets and wasting time traveling.
For games, consider fantasy football. My uncle played fantasy football in the nineties before the internet really took over. He was an extreme early adopter because playing fantasy football back then involved league participants manually collecting statistical information from newspapers, compiling it, and using it to score the league’s games. That’s a huge time investment. Now fantasy football takes place in pretty much every corporate office in the US because it’s more efficient to play it.
Time is perhaps the most important commodity of the digital age. If you grab any modern human and ask them to list their current biggest problems, lack of time is sure to rank highly. Books upon books upon books have been written about how individuals can wring a few more spare minutes out of each hour or day by being more productive. When businesses look to do the same, the stakes become immeasurably higher. And that’s what we, as efficiencers, sell. We sell efficiency to business, thus granting us incredible leverage as part of the workforce. And, to individuals and businesses alike, we sell the ability to increase profits, to expand, and to scale.
We Currently Fail to Explain Our Value
If you were to ask a lawyer about his core value proposition, he’d say that he provides expertise in the law: “I help you claim and defend your legal rights.” If you were to ask a doctor about her core value proposition, she’d say that she provides expertise in your health: “I help you live longer and have a better quality of life.” But if you ask a programmer about his core value proposition, he will probably say something about knowing ASP and helping you build websites. “I help your company build nice, responsive design websites that function on a whole variety of blah, blah, blah….”
Wrong. 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.
But we don’t really have the same sort of place in the world as doctors and lawyers, do we? At least, not yet. Why is that?
And We Currently Fail to Claim Our Place
The reasoning for this is no doubt complex. But I think we can start by considering the history of the corporation. The Industrial Revolution gave us the rise of efficiency as a serious concern. Until that time, vendors were basically artisans that would compete with individual quality. Then the Industrial Revolution occurred, allowing competitors to compete via scale and efficiency. By the time the first computers came into existence, they provided a natural path toward the ever-mounting demand for efficiency. The vocation of “programmer” thus emerged from the belly of the corporation, as a result of the quest for optimization that was already well underway. Notwithstanding academic research projects, it was the corporation that gave birth to the modern programmer, and it did so at the grunt level.
Contrast this with doctors and lawyers. Both vocations predate the Industrial Revolution and have a lengthy history of being consumed en masse by individual citizens. These professions evolved over the centuries, outside of the crucibles of industry and Taylorism. They have rich histories of individuals and partnerships hanging out shingles and dealing directly with customers.
Consider a law firm. Do the founding partners go out and hire a Lawyer Manager to order them around, and then do they hire a VP of Lawyering to order the manager around? Do they then hire a CEO to rule over everyone and a CFO to handle the finances and a COO to schedule court dates and such? Of course not. There’s no historical precedent for all that fluff. Rather, they handle facets of the business themselves. What they can’t or don’t want to handle, they delegate to subordinates that they hire. The partners don’t specialize in finance, sales, marketing, or operations. That would be silly. But they understand enough about it to act as the boss.
Achieving Bureaucratic Escape Velocity
More established knowledge work professions first encountered the corporation as a customer and not a master. Not so for us, as programmers. We came into this world as miscellaneous corporate employees that happened to figure out Microsoft Access pretty quickly. Before we really knew what was happening, the Senior Director of Something was telling the Manager of Whatever to tell us to do some stuff to the Access database that would make them not have to hire an intern to manually enter data all summer. We’ve historically automated and saved time at the behest of operations strategists that understood how to translate our skills into cost savings and revenue generation.
The time for that is over.
As an industry, we’re at that crossroads that happen in sci-fi movies, where the robot achieves self-awareness. The corporate world has become so utterly, irrevocably dependent on ever-increasing efficiency that it absolutely cannot live without what we provide. If we now alter the terms under which we furnish that efficiency, no one is in any position to argue. That is our link to the older knowledge work professions.
Is someone being sued in a position to demand that an attorney fills out a TPS report? Or is a sick person in a position to order his doctor to participate in a daily status call? Is a company whose service delivery costs more than its revenue really in a position to demand these things of us?
Autonomy, Expertise, and The Coming Bureaucratic Exodus
The next phase of our profession’s evolution involves us leaving large organizations, keeping our own counsel, and hanging up our own shingles. On those shingles, we will say, “We specialize in making your business more efficient.”
In concrete terms, this means a subtle shift in our focus. Without this shift, you have the same sort of staff augmentation firms engaged in the same sorts of low-leverage commerce that define the app dev consulting space today. We stop accepting specs and we stop receiving wire-frames. We stop dealing with prospective clients that come to us and say, “We’ve had our business analysts figure out everything we need to do, and now we just need some geek to actually write the code.”
“No, no, no,” you say. “That’s not how we do business. You don’t come to us when you’ve planned the details of your site. You don’t even come to us when you think you need a site. Rather, you come to us the moment that someone says, ‘It’d be a lot easier if our customers could order stuff online.’ You’re talking there about making your operation more efficient, and efficiency is our specialty. We’ll be the judge of whether you need a site or not and if you do, how it should work and what its ‘spec’ needs to be.”
Efficiencers Understand “The Business” Well Enough to Run It
But you only get to have conversations like that when you can understand and wield your leverage. And you only get yourself in a position to understand and wield leverage by becoming serious students of business — all components of the business. As efficiencers, we recognize that code is a means to our end only and that sometimes our clients are better served by not commissioning any code at all. Geeks will rarely tell you not to pay them to write code, even if that’s the right call. Efficiencers will always make the right call.
And on top of that, efficiencers will be savvy enough to start and run firms the way lawyers and doctors do. They’ll partner up and run the business themselves, delegating the parts that don’t make sense for them to handle. They still don’t need to worry directly about, say, sales, if they choose not to, but they call the shots. That means that efficiencers can (metaphorically) slap and (actually) fire people that act like my would-be financial planner. They can chart a course of which they approve, instead. And best of all, efficiencer firms will have an utter monopoly on making their own marketing, finance, sales, and operations more efficient. Not only can they dictate and replace. They can automate as well.
I’ve offered up a lot of words for one day, so I’ll wrap here with a “stay tuned for next time.” I wanted to lay things out in the abstract and explain the concept of efficiencer and why I dreamed it up. But I think I can drive it home by going from abstract to concrete, using examples. So look for a follow-up post this week on a tangible vision for efficiencers.
Published at DZone with permission of Erik Dietrich , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.