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

Here's what worked for me as a remote consultant who lives in a small central european country:

My partner and I currently position ourselves as "A high-grade self-managing team of two, specialized in mapping out, designing, and delivering complex custom-built web applications on time".

I suppose we might fall under the authors category of predictably positioned "opinionated developers".

Our ideal customer is a non-technical entrepreneur who needs someone to help them polish their idea, turn that idea into a high-grade working product, bring that product into the market, and start making traction and revenue.

I noticed that many entrepreneurs, especially non-technical folk, have a very difficult time building their first product — especially if it's a relatively complex piece of software. Most contractors are focused on using cool tech or writing clean code instead of helping people build successful businesses.

Our selling points are pretty basic: Learn about your client's business, be reliable, communicate effectively, deliver a great product on time. If needed also help with additional hires, validating PM-fit, marketing.

It's nothing revolutionary, but the fact that there are so many uninvolved developers on the market makes it very easy for us to find long-term engagements. The clients are happy and we're able to charge San Francisco-like rates. Just last year I put $1XX,XXX into my savings account.

We're in our late 20's so there's a long road ahead of us. Who knows, perhaps we'll get bored with programming in a couple of years.

But people should know that you CAN make very good money while still writing code most of the day.

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!

Yes, strategic work can be the way to big buck$, but there's also a shortage of reliable implementers of moderately-technical projects who don't disappear and communicate reasonably well.

Sure, you might not get to a $20k/week bill rate, but for many of us $4k/week isn't a bad start.

- The strategic consultant you describe manages to have a higher tariff, but the sales cycle is long and the downtime between gigs significant

- the 'software consultant' has an on average lower tariff (depending on the specialization), but little downtime and faster sales.

Pick your poison and do what you feel most comfortable with.

You have to remember what made you a specialist in the first place was coding at challenging projects. Our market changes too fast for you to stop doing that. Studying and trying out new things using a private lab will only get you so far, the real challenges are the ones which push you to really master something.

There is a lot of good advice out there. OP, Jonathan Stark (expensive problem), Philip Morgan (positioning), Double your freelancing, Patio11 etc

They all have read the same book: Positioning by Al Ries.

What the OP (and others) are saying makes total sense. If you move away from being a generalist and carve out a niche everything becomes easier: your marketing (no more job hunting, no more interviewing), the stress (no implementation "details" to deal with) and as you can charge much much more life in general.

The problem: no one can tell you how to get there. It's survivorship bias.

Some of them got there by luck or not at all (they just coach - J.Stark, for example, started with rare (at that time) mobile dev skills and now decided to do just coaching after his skills have become commoditized).

The advice can be summed up in network as much as possible, talk to lots of people, try to find common pain points and so on.

Please note: I'm not meaning to discredit anyone, I'm grateful for what they do and learned a lot from them.

I really would like to know how to not immediately be slotted as someone who is just a coding mercenary.

I suspect that people who are in a great niche got there by accident and that luck is a much bigger part than most want to admit.

I don't think a deliberate attempt to move into a great position will work.

As a UX designer who has positioned himself as consultant, I now have fewer projects but charge for value provider. There is more downtime in between projects but I actually end up making more money. If I get 2 or 3 projects at once, it's really nice.

Of course, I have to decline 98% of requests coming my way but it's well worth it. The businesses I partner with realize a good ROI and everyone is happy. Just so happens this process filters out a lot of the undesirable qualities in businesses I don't want to work with.

I had to eliminate every mention of client, freelancing and rates from every piece of content I have put out, because I think the moment you position yourself as subservient to your "client" the game is over. I see it more as a business parntership.

A similar piece of advice is in the often-submitted article by Patrick McKenzie.[1]

The common idea is that instead of being just a "code monkey", you position yourself higher up the value hierarchy to be more of a "solutions provider".

In my observations of programmers that successfully sell consulting vs earning a W-2 salary, both articles leave out the dispositions and natural inclinations of the reader. This affects how easy it is to move up the value hierarchy.

To do high-value consulting, one has to take an honest self-assessment:

1) Do you like to be somewhat entrepreneurial and "hustle" for work? (Some programmers would prefer to be given a set of defined tasks and then be left alone rather than scout for new jobs and projects. The act of "selling yourself" to prospective clients is uncomfortable.)

2) Do you accept that there can be cycles of feast or famine because of downtime between freelance contracts? (Some programmers would rather have the predictability of steady paycheck rather than stress over contracts and chasing Accounts Payable for past-due payments.)

3) Do you find "solving business problems" more interesting than programming languages? (E.g. some folks are more interested in Python 3 vs Python 2 differences or studying Lisp macros -- rather than tackling the domain knowledge and complexities of modernizing a hospital billing system, or the code to monitor container ship logistics, etc. The coder views the business stuff as boring but programming languages as interesting.)

Once you've done the "know thyself" exercise, you can then analyze how various types of "consulting" is sold in the marketplace and where to position your services.

If you're just a generalist programmer in (e.g. C++/Java/Python), it will be difficult to sell that as "consulting" to companies. You have to go up the value chain and sell "solutions". This is easier if you have expertise in a specific business niche that interests you. As for examples of selling general consulting that covers the spectrum from "bodyshop of programmers" to "solutions providers", that would companies like Infosys (India H1B), Pivotal Labs, Thoughtworks, Accenture, IBM Global Solutions.

Some exceptions to selling small scale "consulting" without being a being a solutions provider would be web freelancing and maybe cybersecurity auditing. Otherwise, generalist programmers either need to work for the solutions providers above, or become a solution provider themselves, or find contract gigs on marketplaces like Upwork and Dice. However, selling your programming skills on Upwork is the probably the opposite of the advice given in the 2 essays.

[1] https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-pr...

Wish I had understood this concept of positioning long ago...

Because of this and the reactions here, I'm sure I'm missing something and I think others may as well.

Is the author essentially saying "outsource the development?

As a consultant, I'm expecting to sit with the client, figure out their problem, and provide a solution. I charge based on the project and provide a breakdown of how much they'll pay for each deliverable and when it'll be available. The customer doesn't have to care who does the work (it'll probably be me), provided the deadlines are met, and at anytime the client can stop (they'll pay for any in-progress work).

Is that what the author is saying? Or are they saying to avoid taking any responsibility over the development process? Subcontracting is always an option, so if there's too much work, outsourcing is an option. I just don't feel comfortable just delivering a design, but I can if that's objectively better.

First, lumping all consulting firms together is a mistake. The main lists here cover the big brands, and I've added a couple more. Each has their strengths, weaknesses and approach to the market:

- Pure technology consulting: Accenture, IBM, Cap Gemini, Tata, Cognizant and Infosys

These firms usually win because of their reputation for solving large scale technical problems. They can mobilize large teams of relatively qualified people and often have exclusive or at least preferential treatment from software providers who are eager to sell into their distribution channel.

- Prestige strategy firms: McKinsey, Bain, BCG

Very little technical knowledge. Almost no implementation. Usually bought for political reasons that require "hiring the best." A true Veblen service. Still, they often are the right choice for a question that has an unknowable answer and requires panache and persuasion.

- Big Four: Deloitte, EY, KPMG, PwC

Outside of government practices, these firms win because they have a monopoly on the CFO relationship. This entree into board conversations around audit and financials is powerful enough to build a relationship that can lead to strategy, technology, supply chain or myriad other consulting projects (SarbOx made it illegal to sell both audit and consulting at once, but once Deloitte made it clear that some hand waving and compliance measures were sufficient to fend of regulators, as long as services weren't sold at the same time, the rest jumped back into consulting).

- Niche players: Aon, WTW, AT Kearney, CapCo, ATT, Verizon, Marsh, Sapient and Booz

This heterogenous group often wins because of a specific strength, relationship or reputation. For Aon, Marsh and WTW it is around insurance and the CRO. For ATK, they are known for logistics.

Finally, to address the article itself, one of my earliest observations about the corporate world is that the less work one does, the more one gets paid. Partners delegate work and even proposal writing to focus on selling. Those who get promoted most quickly are those who sell the most work. Relationships are what lands deals and working is in conflict with schmoozing, so it is important to do very little actual work.

Furthermore, what people are saying about bureaucracy and management being inherent to an organization is correct, although I'm less jaded on this point than I was while working for somebody else. Sclerotic organizations need third parties to make change because inertia is such a powerful force, and a combination of risk aversion and other fallacies can do harm to one's career unless there is somebody else to blame. See Rene Girard on this point to fully understand why scapegoating is a feature, not a bug.

The last thing I would say, is that having real expertise and experience is crucial to making a convincing sale. My field, cybersecurity, is still professionalizing so credentials don't mean as much as past work experience. Social proof is everything and competing on price in markets with information asymmetry is a sign of bad quality.

There are a few ways to get to the place that was laid out by the OP. The first, and most desperately needed, is somebody with deep technical knowledge who can develop and implement processes. The second, and almost as important is somebody who can create documentation that ties everything together and explains code, networks, data and systems at various levels of granularity (C-suite, middle management, engineering lead, devs, network engineers, etc.). While the latter should be the responsibility of a good engineer, it often gets left behind and is almost never prepared for different audiences. Third and final is where we are positioned, risk management. We assess, mitigate and quantify risk in terms leadership can understand and act on. Whether a bank is worried about regulatory pressure and needs to demonstrate a good faith effort to comply or a due diligence team needs a financial quantification of the current cybersecurity risk in an acquisition, the greatest value here is being fluent in business and technology. Translating between lingo, goals and most importantly culture is easier said than done.

For example, Scrum is a pretty stupid and horrible thing, at least as stupid and horrible as Waterfall and often quite worse.

Anybody who thinks it’s important to give consulting advice about whether to adopt Scrum is someone to run away from. It’s like a daisycutter of common sense.

There are great, small places to work where you can be paid well _and_ have your technical opinion respected and considered as an implementer.

You can’t do that in places that are brainfucked with politics and bureaucracy, and the willingness to hire outside “solutions” consultants is a pretty big indicator that a place is brainfucked with bureaucracy and politics.