To become a software consultant, avoid letting clients pay you for code (2017)

There's another important point to make:

Im generalizing a bit here but if you write code it's relatively easy to find full-time long-term engagements. On the other hand if you're a strategic consultant you're going to spend most of your time blogging, networking, searching for leads, and selling.

$20k/week rate is nice but if you only bill 1 week per month you're still making the same annual income as a $5k/week software contractor.

The only difference is that you spend most of your time selling while the contractor spends most of their time engineering.

Like someone else in this thread said — pick your poison.

Does the author ever actually say what you should do? AFAICT all he says is "don't let them pay you for code" and never really got clear about what you should do instead. Did I miss it?

This notion of the distinction between contractors and consultants as a career status strikes me as similar to the distinction we make between developer and manager. And then, this is useful advice if what you want to do is manage, and code less.

I've been consulting professionally since 2005, and I think I've gotten pretty good at it? And my take on this is, graduating from "IC" to "manager" in the eyes of your client is presumably one way to ratchet up your status. But there are others, and I think they can be more lucrative.

Two straightforward alternative approaches to leveling up a consulting business that you've started by freelancing IC-type work:

1. Scale it out. Take on more work, find trusted people to subcontract it out to, eventually bring on a partner, standardize and methodologize what you do, get to the point where you can train other people to do it, start hiring people. You will probably find that when you get to the point of hiring consultants to work for you, your business accelerates naturally --- one of the most overlooked and important value components of most consulting businesses is on-demand availability, which is expands as your roster does.

2. Specialize. Start looking for commonalities between the projects that you do. Build tooling for them. Maybe publish some open source stuff. Build a specialty practice around that. You can do this repeatedly, for different areas; eventually, you'll do it for business verticals. In both kinds of cases you'll find that you become attractive to different kinds of companies when you change from generic to specific.

In neither case do you stop coding, or reposition yourself from the kind of company that writes code to the kind of company that tells other people how to write code.

We agree about hourly billing, though!

In American english tariff is usually used as "tax". Especially in the context of import & export taxes on goods and services. (E.g. The American colonies revolted over the tea tariff.)

We've been doing the exact same thing for the past 10 years out of the midwest US, and I agree with everything you've said.

We view technical startups as hybrid companies in terms of market and industry. They're half web and software, and half whatever it is that startup does. We team up with non-technical founders who are trying to solve a problem in an industry they know, and we bring the web and software [and startup] expertise.

I usually tell founders that, as a best-case scenario, most developers and consultancies will build exactly what you ask for. The problem is how often you're going to ask for the wrong thing. One of the biggest values we provide is what we help you avoid building.

Consistent with your experience, this has been working well for us.

The other thing I kept thinking while reading the post, was that the clients who are likely to value non-coding software consulting enough to explicitly pay for it as a completely separate line item from the software development itself, are probably the same clients that do value and listen to the feedback from the opinion+coding consultants. So, it seems the author has found a way to identify those clients up-front, but at the cost of making the client find someone else to fulfill the coding role.