If We Solve the Software Generalist Anti-Pattern, Who Writes the Code?

I am, strangely, not an expert in my own history.  Chronicling my own exploits through digests and Prime Photos have helped somewhat in this regard, but I nevertheless struggle to remember the sequence of my life.

So I think it was 2015 when I was writing about the tales of Emma in Developer Hegemony.  And I think it was a few months later that I first dreamed up the strange neologism of “efficiencer.”  I think, but I’m not positive.

What I do know, however, is that it was a few years ago now.  And I also know that my thinking has evolved somewhat since then.  So I’m going to answer a couple of reader questions today with the benefit of having acquired additional experience since writing the book.  I’ve moved away from management consulting, started a business, and helped a lot of nascent product companies with marketing and positioning.

I haven’t really made any reversals, so if you bought and enjoyed the book, don’t worry that I’m disavowing any points in it.  Rather, I’ve refined how I think so-called efficiencer firms should market themselves.  And, as you can probably infer from the title, it should categorically not involve any whiff of generalism.

Let’s Look at the Reader Question

Alright, so what have readers asked me?  Well, quite a while back (2017, in fact — yes, I have a long reader question backlog), someone asked me this.

The efficiencer model looks a lot like management consulting except the consultants here can do the automation as well. What has changed to make this path more suitable for developers to follow?

And, more recently, someone asked me a question in response to a post I wrote about how any firms that sell custom app dev are selling staff augmentation.  I see a logical progression for software developers, for the most part, moving from staff to staff augmentation to, well, efficiencers.  This prompted the question.

Say we work for an efficiencer firm, and we avoid writing code for pay. In the end someone needs to write code; who is that? Are we back to architects vs. programmers & UML handoffs? Or is this an interim solution?

So we have a question that is literally about who writes the code, and another that, at its core, really asks how software developers can be taken seriously offering consultative expertise.  All of this feeds into the general theme of the division between expertise and labor, and who should furnish each.

What is an Efficiencer, Anyway?

Let’s do a little housekeeping.  Assuming you didn’t click the link to the post in which I defined this term, let me provide a brief explanation.

An efficiencer is what I’m calling someone who understands and offers (wittingly) the core value proposition of software development: improved efficiency.  In the software development industry, we tend to talk in terms of our experience tuples — how many “years of Javascript we have” and things of this nature.  But those aren’t value propositions; they’re overly-detailed minutiae.

To understand the distinction, here’s an obvious contrast.  Confronted with a pizza place looking for a website that allows online ordering, here’s how each reacts.

• The traditional, stack-oriented software generalist says “sure, no problem, do you want a SPA, or would you prefer a more traditional navigation structure?”
• The efficiencer initiates a conversation about how the pizza place owner thinks the new channel will provide new business, and what metrics he’ll use to judge success of… whatever the efficiencer eventually recommends, website or otherwise, to help him capture this business.

(Now, before you excoriate me in the comments for a false dichotomy, please bear in mind I’m doing this on purpose, to draw a contrast.)

Clients look to the traditional app dev outfit for labor.  And they look to the efficiencer firm for expertise (and, perhaps also labor, if the firm recommends it and the client agrees).

So, Who Writes the Code?

It is at this point that readers naturally wonder who, I think, should write the code.  I advocate that developers leave staff positions at non-software firms in favor of staff augmentation roles.  And then I suggest that they move on to non-staff-aug, non-labor positions allowing them to furnish expertise.

The natural and obvious ‘solution’ here is the architect/coder dynamic that one of the questions mentions.  Become an expert, and leave the labor to someone else.

But that’s really not what I’m advocating.  Instead, I’m advocating that the expert and coder become one and the same.  These efficiencer firms, as I envisioned them, are equity partnerships among equals, along the lines of law firms and doctor practices.

So nobody collects a wage in exchange for the labor of writing code.  Instead, they collect a revenue share for doing it.  And they do it on their own terms, per their own recommendations, if and when they think it makes sense.

Fine, But What’s Your Problem with Generalizing?

Up until this point, my brief mention of generalists probably seems like some kind of grudge-driven non sequitur.  And if you’re a reader of this blog, you know that I’m no advocate of staying a generalist, since I cover topics like how to move away from being a generalist and how to develop a specific value prop.

But I do have a specific and highly relevant objection here.  To understand what that is, let’s return to the example of our pizza place project.

A generalist efficiencer firm would likely come into this project with no knowledge of pizza places, having focused instead on building miscellaneous web apps for miscellaneous companies.  They’ve built similar-ish web apps for nail salons, real estate agents, dog catchers and plumbers.  Do any of the websites they’ve built for those varied outfits help them make or save money?  They have no idea.  And they have no idea if the website will help the pizza place, either.

But consider a specialized efficiencer firm — perhaps one that specializes in helping food establishments with automated ordering.  They’ve helped plenty of carry out places, including pizza parlors.  They’ve gotten to know web applications, sure, but they’ve gotten to know those customers, their domain, and the state of the art in that space.

The specialized efficiencer firm’s partners can serve simultaneously as programmers and experts because they build expertise with cumulative domain work.  The generalist firm can’t do this because they’re off coding all over the map, keeping up with technologies rather than an industry.  They need business people and tech people because they can’t count on their tech people to accumulate knowledge about anything but tech.

The Staff-Staff Aug-Efficiencer Firm Progression

It is for this reason that I harp on the idea of specializing.  And I harp on specializing not in some specific technology or framework, but rather in the solving of some specific business problem.  Efficiencers develop skill and expertise in serving some specific market and making it more efficient.

As I zoom out and think of where I’d like our industry to go, all of this lends itself to a natural progression.  Staff generalists (the kind that I used to be for more than a decade, so no judgement here) bounce around from company to company, keeping up with techs, but capturing no meaningful, lasting domain knowledge.  And, at non-software companies, they’re generally commoditized cost centers, evaluated mainly on the basis of “can I find someone to do this for less money?”

The first step for our industry is, clearly, out of roles like that.  But leaving a role like that and flipping them to client of your efficiencer firm is no small feat.

So the first step I see is externalizing the cost center dynamic.  We leave places where we’re staff cost centers and go to places that bill us out as staff augmenting profit centers.  We learn some things about business, and we deliver more value than we otherwise would.

But we also don’t stop there.  We find a specialty/niche/industry that we can serve well, and we find that our cumulative work brings us not only technical experience, but domain and business expertise as well.  We start firms with specialized knowledge and focus, and we serve as architect, programmer, technical expert, and “the business” all rolled into one, because we can.

Do Efficiencers Make Products or Provide Services?

Hopefully, this provides some clarity as to how I see the world shaping up.  You might partner up with a handful of folks and go around helping pizza parlors take advantage of online ordering.

And maybe this involves custom app dev, but it also might involve nothing more than a Shopify template or a WordPress plugin or whatever.  As you get better at delivering this service, you’ll learn about more options and focus on taking the best option, delivering it, tweaking it, and improving it.  Instead of saying, “which of today’s 6 new Javascript frameworks should I learn to be employable,” you’ll focus specifically on the technologies that promise to help your pizza ordering efficiency firm better serve its customers.

And this leads me to an interesting and fun conclusion.  You might wonder whether the efficiencer firms will build products or deliver services.  Maybe productized services?

The answer is, “yes.”

You’ll deliver all of these things as they make sense.  And, do you know why?  Because who better to make strategic decisions about software delivery than a business expert that is also a tech expert?

And that’s what, to me, the efficiencer concept and developer hegemony is really all about.  It’s about removing this preposterous artificial division between tech and domain expert.