In my last post, I introduced the efficiencer in detail. But I took an admittedly philosophical tack in that post, offering more rhetoric than specifics. Today, I’d like to get specific instead. I want to talk more pragmatically about the efficiencer firm.
In order to do that, I’m going to start by talking about inefficiency. After all, as efficiencers, we ought to have a keen eye for such things.
My Stint Making Hearing Aid Fitting Software
Years ago, I went to work for a company that manufactured hearing aids. This included several brands under the umbrella of the parent corporation, and all of them had international distribution networks. So, at the end of the day, the company does everything needed for the manufacture and global distribution of hearing aids.
Operationally, this includes something you might not consider at first blush. Hearing aids need something called fitting software. The people responsible for prescribing hearing aids to the population, audiologists, use this software to program the devices. This includes configuring different gains at different frequencies and setting up so-called “programs” that wearers can use in different environments. For instance, you might have a “restaurant” program with a much different array of settings than a “home watching TV” program.
Since you didn’t come here to learn the particulars of the hearing aid business, I won’t keep going with further detail. But I could. A lot. As I would learn during my tenure there, developers in this space face a steep learning curve. The complex nature of sound and gains mixes with the bureaucratic world of medical devices and regulations for a rich tapestry of arcane complexity. Months passed before I got my bearings there.
Hiring for Fitting Software Development
That company hired the way most companies hire. I don’t single them out today because of their hiring process at all. Rather the domain complexity serves to make them a prime example of the inefficiency in question here.
At some point, before I started, the company worked with its architects and stakeholders to pick C# and WPF for the next generation fitting software platform. This happened circa 2007, so WPF defined the bleeding edge at the time. With this important decision in place, the company did what all companies do. Working with some recruitment firms, they defined a bunch of experience tuples and started hiring .NET developers.
This makes for a straightforward enough proposition. First, you go out and find software developers of varying experience. Then, you pay them an average of $50 per hour in salary. And, finally, you invest hundreds of thousands of dollars teaching them your domain over the course of six months to a year.
And, naturally, you do not do this as a one-time, up-front cost. Software developers, particularly skilled ones, tend to move around a lot. So you seek to hire generalists with the right experience tuples. And then you perpetually train them at great expense.
Inefficient? Let Me Count the Ways
I’ve focused thus far on the expense of turnover as it relates to developer training in the domain. A manufacturing company has an explicitly or implicitly heavy budget for training software developers in the business. Theoretically, they could avoid this expense by staffing experts in fitting software, but they don’t (not for lack of interest — they sometimes call me about contracting work simply because of my domain knowledge and experience, even years later).
But it gets worse. Today’s software industry consists of legions of code slinging commodity generalists and their experience tuples. Because the hearing aid company optimizes developer hires on the basis of the (.NET, C#, WPF, XML, etc.) experience tuple, it must also employ a layer of people that sort of understand that stuff, but really understand the business. These folks vary considerably in role and title, earning designations like business analyst, project manager, product manager, program manager, and probably many more. And they know how to make actual, productive use out of the generalists with their experience tuples. So the company now must employ two flavors of specialist: coding resources and domain knowledgeable people that know how to teach those resources and deploy them to some kind of strategic end.
And, finally, let’s not lose site of macroscopic inefficiency. A manufacturing company knows manufacturing. This means industrial engineering, distribution, materials, and a lot of other things. But, generally speaking, those things aren’t software. So not only does this company need to staff and endlessly train a cadre of generalists, and not only does it need to staff and retain expensive personnel to manage and translate for them, but neither of these things lies anywhere near its core competency.
Enter the Efficiencer Firm
With the inefficiencies I’ve described in mind, let’s look at a new way of doing things. You’ll need to embrace some cognitive discomfort here because what I propose constitutes a fairly significant departure from the way we’ve always done things. That comes in the form of the efficiencer firm.
The company for which I used to work doesn’t have a global monopoly on hearing aids. Other manufacturers make these things as well. So what if a software development firm emerged, specializing not in miscellaneous app dev using a certain programming language stack, but with a clear niche? This firm, an efficiencer firm, could specialize in automating the configuration of hearing aids.
What tech stack would they use? Who cares? That’s their business. They have deep expertise in the domain of hearing aids, understanding industry regulations, the complex workings of the devices, and the most efficient ways to interact with them. Keeping up with modern technical trends as they pertain to hearing aids becomes part of what they have to do to remain competitive. Companies don’t come to them talking about tech stack — they come to them talking about the needs of their stakeholders and the nature of their product. They say, “help me.”
Now the hearing aid company doesn’t staff an entire department orthogonal to its expertise. So, obviously, it now doesn’t hemorrhage money training a revolving door of people in this department. Instead, it contracts with an efficient expert firm.
Understanding Efficiencer Firms
To understand the efficiencer firm, you need to understand defining target markets, at least at a rudimentary level. Most software developer employees, software developer freelancers, and custom app dev shops have a target market of “everyone.” The only differentiation tends to happen on the side of the development, by tech stack. So, you may have a target market of “anyone, as long as they let me do Java.”
This feels comfortable, but it makes little business sense. By doing this, you don’t bring any expertise to bear that has value to your client at all. The client only cares about tech stack because you make them care (though them having to care has become so standard that they take no umbrage). And when you operate this way, you’ll perpetually find clients handing you specs and saying, “go off and do this, and let me worry about strategy.” That’s the only option because you bring no other expertise to the table.
An efficiencer firm changes this game by picking out a more specific target market and developing expertise in automation within that market. It then only targets clients in that specific market. This narrows the client pool considerably, but it positions the efficiencer firm as a strategic partner and not miscellaneous unrelated labor.
What Does This Mean for Me?
In Developer Hegemony, I talk in much more detail about the efficiencer firm and the path we have toward starting to operate this way. After all, you can’t single-handedly go out and redefine how the world contracts software development. But you can position yourself for the coming change.
Go through that target market Wikipedia page and do a bit of brainstorming. If you had to thin the available pool of people demanding your software development and automation skills, how would you do it? You could do it geographically, but think beyond that. Do you have a domain that really interests you or about which you have a great deal of knowledge? Start there.
Then start to think about a world in which you cater only to clients meeting that profile. What skills would you develop? How would you pitch yourself and distinguish yourself? What would you recommend strategically that went beyond writing code and into conversations about automation and efficiency of their business?
As a first step, start thinking this way and practice it. Down that path lies future leadership, consulting, and expertise. Down that path, lies the efficiencer firm of the future.