Stories about Software


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.

Should I incorporate? The monopoly guy here thinks the answer is yes, and so do I.

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.


Newest Most Voted
Inline Feedbacks
View all comments
5 years ago

Well I think a programmer or software developer is in charge of that codes

Erik Dietrich
5 years ago
Reply to  SkyNaijaMusic

I’m not sure I understand what you mean.

5 years ago

I work mostly in infrastructure, automation etc., not directly developing applications – some clients insists on calling it DevOps which of course is wrong.

I think there is huge potential for increasing efficiency here and there is definitely demand, however that demand mostly comes in the form of “We’re looking for someone to build a CI/CD pipeline with Jenkins and Docker” instead of “Help us improve our software delivery”, with the client very often focusing on the wrong thing (buzzword technology, wrong diagnosis). I wonder if it’s possible to somehow turn those overly specific requests into genuine consulting relationships.

Erik Dietrich
5 years ago
Reply to  Nils

I think it’s possible, but difficult, at least in the short term. By the time you hear “we need a CI/CD pipeline with Jenkins and Docker” you’re typically hearing the result of a strategic/buying decision that has already been delegated. The buyer — someone like a CIO or a director — has made it part of the department’s yearly plan to “improve maturity” by getting to, say, weekly deployments. Buyer is willing to invest $X and Y person-hours in the effort. At this point, buyer delegates this to line manager or architect or something, who says, “oh, yeah, we can… Read more »

5 years ago
Reply to  Erik Dietrich

Yes, and quite the challenge that is. I’m currently reading “Million Dollar Consulting” and it is mentioned that one trait of a successful salesmen is assertiveness. That’s not really an attribute that I would ascribe to myself, so I’m probably in trouble there.

5 years ago
Reply to  Erik Dietrich

It’s from Chapter 13, “Creating a Company”, under “The Rainmaker as an endangered species”: The behaviors required for sales in this business [consulting] [..]: A high degree of assertiveness, a slightly lesser but high degree of persuasiveness, moderate patience and slightly below average attention to detail. Maybe I’m hung up on the term assertiveness as a personality trait instead of what he calls “behavior”, but it’s definitely something I’ve struggled with – it’s sort of a Catch 22,I can’t get the clients I want which leads to my doubting myself which leads to not being able to get the clients… Read more »

Matthieu Cneude
5 years ago

This is a brilliant article. I read this blog pretty often and it’s the best explanation you did about the idea of “efficiencer”. My main problem stays the same to me: I can’t really find a niche. I have some in mind of course, but the domains are pretty boring to me or it implies that I would work with awful companies and I would have to consume their very bad “API”. The problem when you’re leader on your market I suppose. I’m sure I will find something at one point. Meanwhile to see a maximum of business model (and… Read more »

Mikhail Kuleshov
Mikhail Kuleshov
5 years ago

Hi Erik, Thank you very much for the posts on the topic, as they really helped me to better understand what I want to do with life/career and plan personal growth. I wonder however about the parallel you’re drawing with lawyer/doctors. I can see how this does work for smaller firms, but I do not understand if that can work if you scale. As an successful enterpreneur at a small efficiencer firm you would definately want to scale as soon as there are more clients than you can handle with your current people. So I can imagine you’ll end up… Read more »

Erik Dietrich
5 years ago

I think this is a sufficiently complex topic that I’ll tackle it in the future as a blog post. I do appreciate the question — it’s an important one.

I think the shorter form answer that I’ll offer here, in the meantime, is to ask why scaling up is inevitable or desirable? If, as a solo consultant, or a partner in a small firm, you can sufficiently stack your incoming work pipeline and/or develop some kind of passive income stream, why the need to scale?

Mikhail Kuleshov
Mikhail Kuleshov
5 years ago
Reply to  Erik Dietrich

Thanks for your answer. Looking forward to seeing more on the topic in your blog. Yeah, I think one can probably make this decision that they “have enough” for now, but I what I geneally see is that there are two things driving scale: 1) Demand. If you do well and more clients learn about you, you’re getting popular and get more orders and I don’t think it’s easy to refuse them, because… 2) Money. Maybe it’s too naive, but it is really tempting to get more than you have now. There might be something else, too, like just growing… Read more »

5 years ago

I think scaling is something of an obsession in our culture of optimization, and this constant striving towards optimization is very unhealthy. Building a firm is about building something you can sell eventually or that produces passive income for you so you don’t have to work. If you enjoy your work and have a good work-life balance, why would you want to quit/sell? Why would you want to deal with all the issues surrounding staff (legal, financial, personal)? If your work makes you happy, there is a limit to the amount of money that would make you happier – a… Read more »