Stories about Software


Starting a Tech Firm in the Era of the Efficiencer

For this week’s reader question, I’m going to cover a subject that I’ve covered before, but not for a while.  People have asked about this in a variety of media.

Also, a normal reader question, submitted through the site.

I was thinking about a boutique consulting firm. Wondering about your thoughts on that as a viable path forward, and the difficulty around ramping one up. Obviously I also need to find the right niche and was curious if you thought specializing in particular enterprise level software implementations (e.g. SalesForce) was a good idea.

And, frankly, a lot of people ask this in miscellaneous interactions that I have no way of capturing to quote.  So let’s talk about that this week.  Where are these efficiencer firms hiding?  How do we start tech firms that are efficiencer firms?  And so on?

What Is an Efficiencer?

Because this is a neologism of mine, you might rightly find yourself asking “what in the world are you talking about, crazy-person?”  Efficiencer is a firm that I coined in my book, Developer Hegemony.  I’ll offer some excerpts here, rather than re-invent the wheel.

I now owe you a definition of this term “efficiencer.” In short, it’s the name describing the service that we as software developers provide. “Software developer” is descriptive, but it suffers the fate of being entirely too procedural and focused on details. We perpetuate this problem by being, ourselves, far too focused on details. The value proposition that we offer the world, notwithstanding what we write on our resumes, is not “five years of Python, three years of JavaScript, etc., etc., etc.” The value proposition that we offer has deep roots in efficiency.

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 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.

And How Do We Get There?

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. We stop receiving wireframes. And 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.”

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.

Charting a More Specific Course

I suppose I could write an addendum to the book.  Or I could release a new version where I go into more detail on the mechanics of founding efficiencer firms, rather than talking in broad strokes.  In the book, I focus more on the individual’s path out of subordinate roles and on citing examples of technologists who have done that.

Luckily, though, I can always write more words on the subject.  So I’ll do that today.

Let’s look at what it might look like for you to start an efficiencer firm.  I’m going to focus today on the sort of firm I describe in narrative form at the beginning of Developer Hegemony, with Emma as the protagonist.  This looks like a standard app dev team that you might find working in any number of places, but with a few key differences:

  • No project managers or other non “team member” roles.
  • The team operates legally as a partnership entity working for itself.
  • All non-development tasks are either absorbed by the team members or delegated to contractors reporting to the team (i.e. the way a law firm operates)

First, Do Legal Stuff for Your Tech Firm

Alright, so you want to start a tech firm like this.  You want to be Emma (or one of her teammates).

This may sound strange, but the absolute first thing that you should do is lay the groundwork for your venture.  I know that you’re probably dreaming of some kind of egalitarian thing.  You and 5 buddies (or colleagues) all go in as equal partners, delegate the work fairly, and start together.  But if you go that route, you’ll never actually go anywhere.  It’ll just be endless talk over lunches about how awesome it will eventually be.

You have to overcome a lot of inertia.  So overcome that inertia and invite people to join you once you’ve done so.  Setup the following things.

  • Establish a niche, value proposition, and pitch.
  • Build a website and start marketing activities.
  • Get infrastructure in place for finances (bank account, invoicing template, billing model, etc).
  • Legally incorporate with a specific partnership arrangement.

That last one is going to be interesting.  You should consult with an attorney, in all likelihood.  Partnerships have operating agreements, but you’re going to need one specifically tailored to your needs, which include purposely bringing on several more, equal share partners.  The attorney can also help you figure out provisions for buying out other partners and the like.

But the important thing is to do the legwork.  When you try to entice your colleagues, you’re already asking them to absorb a ton of risk compared to 9-5 labor.  Don’t also ask them to absorb confusing logistics.

Get Serious about a Niche and Outcomes

I want to come back to my line item about “establish a niche.”  That’s really not optional here.  You need to bring something more to the table than miscellaneous app dev if you want to succeed in this model.

Think of it this way.  Who is going to hire your team of 5 local software developers in a partnership.  Sure, plenty of demand exists.  But you’re big enough that you’d compete with an in-house software development staff and also with much bigger app dev/staff augmentation firms that can offer 5 warm bodies and then even more warm bodies when they need to scale.  You’re not going to do well competing this way, which means you’ll have to spend a disproportionate amount of time marketing, wheedling, selling, and begging.

Don’t go that route.  Establish a niche, as the reader question suggests (and Salesforce implementations might be a decent one).

But when you establish your niche, don’t focus on your tooling.  “We specialize in embedded this” or “our focus is distributed, backend, that.”  That’s actually sort of counterproductive since it takes you from “app dev generalists” to “picky app dev generalists.”  You need instead to focus on your prospective clients and the outcomes they way.  So think of niches like:

  • We help small businesses without app dev shops turn the MS Access things they’ve built into proper web apps.
  • We’ll build iOS and Android applications for startups that have received two rounds of funding.
  • Our customers are enterprises that need to smartly sync Salesforce with their custom line of business software.

Notice something subtle.  Your niche is about what you help your customers do — not what tools you use.

Start with Content Marketing While You Get off the Ground

Eventually, you’re going to get up to ramming speed.  You’ll have people that you’re partnered with all working together on both what you deliver and on running your business.  But as a small firm, you’ll be running lean, and your marketing can’t be you going to endless trade shows, soliciting business.  You need to get people to come to you.  And you do this by positioning yourself as an expert.  (Luckily, this works just as well for going solo).

Start making content.

As soon as you’ve got your niche figured out, start making content.  If you’re going to help replace Access databases, start writing all about doing that.  Learn the ins and outs of doing this and the implications for businesses that have these things.  Speak to that, and speak to it in blogs, at trade shows, or wherever you can, when you have the time.  Try to get noticed.

And don’t speak to your peers.  Don’t write posts that go way down into the weeds about MS Access database corruption.  The people will hire you don’t care about those details — they care about what those details mean to their bottom lines and how you can help them not have to care.  So write instead about what MS Access databases cost business every year when they extend beyond their intended usage.  Write about the glories of not using them.  You get the idea.

Get Clients and Expand

So far, everything I’ve talked about works equally well for becoming a freelancer and for starting an agency.  And what you’re really doing, at the brass tacks level, is starting an agency.  It’s just that you intend to start an Emma style agency, wherein you expand through partnership rather than command and control management.  You’re “partner” instead of “managing director” as you grow.

Land yourself some business first.  If you can land a huge contract that will require you to bring on several more people, then great.  If not, do a few yourself first, even part time.  Build momentum and experience.  Continue with the content marketing and actively identify potential clients based on need.  And make sure you dedicate something like 10 hours per week to prospecting — you can’t just do that haphazardly.

At some point, you’ll hit that knee point where you can no longer do it alone.  And then you’ll be ready to expand.  In some senses, this will be easier for you since you’re looking to bring on partners, rather than employees.  It’s a sweeter pot for them.  But in some senses, it will be harder.  You’ve built this thing yourself, but now you have to cede total control and enter a democracy.

Steady State

If you really, truly want to work with a standing, partnership-structured team, you’ll have to embrace that democracy.  I think it’s probably worth it for a lot of folks.  I’ve always said personally that I want partners and not employees, so I like it.

I’ll close out by saying that you’ll need to think beyond your current client.  In the book, Emma was prospecting even as her team worked toward the end of a project.  You’ll need to do a LOT of this.  If you’re looking for serial app dev work, this means that you need to time it perfectly — next thing lined up when current one wraps.

To do that, you need to be so good that people wait for your schedule, or you need to have so many leads that you can let most go and take one that lines up perfectly.  In either case, you need some seriously non-trivial sales and marketing going on.  This is why early content marketing is so critical.  If you become visible experts in the field, clients will come to you and they’ll wait for your availability.

It’ll take some pioneers, but there’s absolutely nothing to stop you from creating an efficiencer agency today.  It won’t be easy.  But honestly, I think the biggest barrier isn’t any of the structure or logistics.  I think the biggest barrier is getting us as software developers to stop obsessing over tools and “stacks” and to start thinking of what problems we solve for others.

Fire Away with More Questions!

If you have a question, please feel free to ask:

No Fields Found.

And, by the way…

If you like the wisdom here, such as it is, you can get a whole lot of that more in my recently released book, Developer Hegemony.  If you want a sample of that, you can sign up to download some chapters below.

Want more content like this?

Sign up for my mailing list, and get about 10 posts' worth of content, excerpted from my latest book as a PDF. (Don't worry about signing up again -- the list is smart enough to keep each email only once.)

Newest Most Voted
Inline Feedbacks
View all comments
6 years ago

I took the leap. I am owner of an app dev shop. I am changing to partnering with my top 3 developers. We have a large and long term project, but will be reaching out to many prospective clients, so we can ‘perfectly time’ a transition from current project to our first efficiencer project. We are still working the administration details, but we are on our way. Thanks for all the great and timeless advice and guidance on your blog and in your book.