Hacker News new | past | comments | ask | show | jobs | submit login
To become a software consultant, avoid letting clients pay you for code (2017) (daedtech.com)
332 points by fagnerbrack on Oct 16, 2018 | hide | past | favorite | 132 comments



Author makes a valid point, but what about folks who actually like writing code (among other things)?

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.


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.


I would argue that your main selling point is that you are good writers and communicators judging from your website. I bet you are getting hired because of these business skills and not because of your code. It's great that you can do both!


I love writing code. Ive gone out of my way to study health of eyes and tendons so I can code as long as possible. I never want to be the manager.


I just look at your website and it's amazing ! Just clean UI and good pitch.

I love that it's clear that you guys are doing great code just by looking at your website.


Looks like they've read the old "useit" blog, which NN/g sadly "fixed".


How do you find new customers?


Can't speak for the OP, but as we do the same thing, figured I'd contribute our answer.

We're not great at "sales", so it's been completely organic growth and word-of-mouth. I went to a lot of events and meetups for startups, and talked to people about what they were doing and what we do. I've also done a lot of open source development, including working on the Rails core team and building our own projects like Dynatable.js.

This took a lot of time to cultivate a sales pipeline. The company was just me for the first 4 years, occasionally sub-contracting as needed. Then over the next 6 years, we grew to 6 people, and are currently in the process of finding a developer-consultant to join as our 7th.


For the past couple of years our average engagement was full-time and 8+ months long, so we only needed to look for new customers once or maybe twice a year.

We took some time to create our consultancy website and make sure we're communicating our value and principles at least somewhat effectively.

It also helps having satisfied past clients who will speak well of you when someone calls them up.

We don't really do any speaking, blogging, traveling to conferences to network, or anything like that. I just advertise on a couple of websites like HN who wants to be hired, for hire subreddit, angel list, startupers.com, etc to let people know we're on the market looking for a new project. We usually find someone who is a good fit within a couple of weeks.

We are also involved in the local tech community and in the past we would get some projects through word-of-mouth, but those were at lower rates near the beginning of our careers.

You could also try platforms like codementorX and moonlightwork until you manage to connect with someone yourself.


Thanks for taking the time to reply. I have a lot of work through word of mouth at the moment. I was more curious how someone in central Europe (Croatia?) finds high paying customers in the US. You make it sound much simpler than I anticipated.


It is simpler than we anticipated as well. I will say that many of our past clients had something in common — a recent ugly experience with one or more other development teams.

So far we have a history of delivering on what we promised (knock on wood), and we make sure to communicate that there is a very high chance that we will be the last team they will have to hire to solve their problem.

There's one more thing... A couple of years ago we created a passion project (https://news.ycombinator.com/item?id=8547351) that experienced quite a lot of traffic. I'm not sure how much influence (if any) this had on our ability to find clients, but a few of them did tell us how cool it was.


It certainly helps when you live in a country with very low cost of living and, if you've properly set things up, you can avoid paying most of the taxes. Not to mention being young and without a family to support.


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!


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

A former manager of mine, who had some consulting background, once told me that the big management consulting firms like McKinsey do something like this. They compile tons of detailed case studies from former engagements (that's what consulting gigs are called in that field) and then reuse the hell out of them for new gigs, thereby saving a lot of their staff's working time on those. Also probably surprise the clients (who may not know about this practice) by being able to come up with results sooner due to this.


Haha, I was a consultant and you paint a very idealistic picture of the situation. It usually went something like this in my experience:

1. Partner hears client is interested in a certain type of engagement

2. Partner promises that their firm has extensive expertise in the area

3. Partner commits to writing a proposal for the potential project

4. Lower level staff scramble to talk to other consultants in their firm (same industry) and dig through old case studies to figure out if #2 is actually true

5. Staff hurriedly compiles a proposal deck from a mish-mash of slides from other projects that are mildly relevant

6. Multiple iterative feedback loops where the partner gives vague suggestions on improvements and staff makes the changes

7. Send finalized proposal to design/production team

If you win the proposal, you use some lead time before the project to build an approach using past projects. In rare cases there would be a firm-sponsored template or framework (often when there is associated whitepapers or other marketing materials), but in general the situation was a more reactive "I do not have time to start this from scratch, so what can I gather from past projects?" and less of a proactive "let's build a template to reuse for new projects"


>Haha, I was a consultant and you paint a very idealistic picture of the situation. It usually went something like this in my experience:

1. I did not claim to "paint" the full picture. 2. I did not paint the picture. Was saying what my ex-manager said to me. 3. The plural of anecdote is not data.

Interesting to hear of your experience, though.

Regardless of your experience, systematically collecting and analyzing data on prior projects, with a view to applying the learning to future ones, is useful, for any discipline, not just management consulting or software engineering. That's part of how progress in any field happens.


Also, I'm well aware of the "golmaal" (Hindi slang term) that goes on in any field. Hey, it's common knowledge. But that does not invalidate work of the good actors in the field.


Sorry, I didn't explain what golmaal means in English, also may have used the wrong word. I meant something like skullduggery, but golmaal means chaos or confusion (according to Quora, at least).


I think it comes to the same thing, as I start to try and get ventures off the ground I'm finding that there's nothing like experience to improve your chances of success. Put another way: 90% of success is being successful.


I think the biggest failures at the software consulting houses I've worked at have come from not building adequate tooling and not establishing a framework for knowledge/skills transfer. A close runner up would be failures related to trying to build actual products. The problem with consulting though is scalability. You can make a product and recoup your NRE with the first x units, and then most of what you sell beyond that is pure profit which can roll in while you sleep. Scaling a consulting business is tough. You just have to increase billable hours and that is a lot tougher than it sounds(especially in the current market).

I made a lot of money in consulting over the years, but at the middle of my career I find myself looking for a product company to call home. Consulting can be great... or it can be terrible. My friend is now charging $165/hr for his solo corp... but sometimes the invoices never get paid and you have to swallow a loss(I'm owed over $14k currently and will probably never see it).


$165/hr is not particularly high (in addition to the fact: don't bill hourly). A $3200 day is not unusually high.

Product development is in some ways more gratifying than consulting. But consulting has its own rewards, too.


Sure, you could charge a lot more depending on your role and resume. My friend is getting $165/hr doing Sr. Software work, writing code for satellites. It's a steady 40ish hour/week role, so I think that, compared to salaried senior devs in the area(i.e. not silicon valley or NYC), he's doing quite well.

For comparison, I know a local engineering staffing/design services firm that charges $200/hr for principal engineer time. You're getting more out of that sort of company though.


Seems backwards, your friend should be the one making 200+


Why? He doesn't have to pay a sales team, marketing department, IT guy, etc. He also doesn't have a building full of engineers who he can query if he runs into something he can't handle. I would never pay an individual, regardless of whether or not they're a corp, more than I'd pay a company which provides engineering talent.


Not that the specific number is worth litigating, but worth mentioning: a sales team, marketing department, IT guy, and all that are part of the competing consultants cost basis, and not so much the value they offer clients. Unless you're selling gypsum, for the most part, nobody is buying based on your cost basis. You're either doing something worth $X, or you're not.


Not going to litigate the number but I will say that sales teams often do add value. They provide a human point of contact to escalate issues and manage customer expectations. They also may act as a single point of contact for flexible staffing needs - i.e. if they need a second body to meet a schedule, they don't have to hit the open market but can simply buy more engineering talent.

That said, I've often felt like the sales team doesn't provide much value. It depends on the company.

I will say though that companies are generally more comfortable paying a higher rate to another company vs. one guy working out of his house. There is a greater expectation of responsibility. Also, many companies will not even deal with you as an individual corporation unless certain rules are met. One rule might be that no more than, say, 30% of your income can come from the company looking to hire you. They want to see a diverse revenue stream and a well established business.


I’ve just started out in a niche that I thought richer than average, and I charge less than a third of that.

Where have you seen people charging that much?


$3200 per day? Where do I find those people... This is Dev consulting?


Yeah, I call bullshit. Unless you're one of the top 1% of engineers in the valley or in FinTech you're not getting near that.


Yeah, you're wrong about this, and I'm not just talking about my own field.


That's fine, but I'm not buying it without evidence. I don't expect you to bend over backwards trying to convince a stranger on the internet so I think we're done discussing it.


Well, for starters, that number is less than my bill rate was at NCC.


For any devs worried they're missing out because they're not in the "strategic" role described here: There's still a boatload of money to be made just doing the coding.

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.


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.


I was able to stay this route. Started at $4k/week and worked my way up to $6k/week and still rising. If you can manage a project/have technical lead skills/have a hyper specialty (e.g. AR/VR, cryptography/security, AI/ML) I've seen rates anywhere from $150-300/hr.


I've worked with some "strategic" consultants. Believe me, these guys did some pretty diagrams and wrote a couple of nice word docs, but they didn't do any real, useful work. It was almost laughable.


And yet, they get paid more and treated better than contractors and "consultants" who write code. Is the joke on them? Or us?


Having seen all type of consultants over the year:

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


I disagree. I fit into the “strategic consultant” category and my sales cycle from referral to signing is a few weeks, with zero downtime because I work on several projects at once.

The great thing about being independent is you can design your engagements however you want. Not happy with amount of downtime? Find a way to do two (or more) projects at once. Not happy with sales cycle length? Simplify your offerings. And so on...


What does this mean exactly? Do you essentially build the specs and someone else does the work? Or do you see the project to completion (you design and implement the product)?

I'm really confused because I really didn't see anything meaty in the article other than "talk about problems, not implementation". I thought the article was going to be about "licensing" vs "copyright transfer", but instead got a lecture about something far more nuanced.

Is the difference just terminology and how you present yourself? If so, what terminology to people look for, and how does a project work from start to finish for you?


> Do you essentially build the specs and someone else does the work?

Yes, something like that. See: https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-pr...

That post goes into much more details and reasoning for this argument.


When you say tariff do you mean price?


I think this is a British-ism. I'm British. The parent's post used tariff in a way I found normal. Google tells me:

  tariff - noun:

  BRITISH
  a list of the fixed charges made by a business, especially for use of gas, electricity, or a mobile phone.


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


Indeed. Tariff is a dirty word in American English.


Fwiw US telco-speak still uses tariff to mean price.


Sorry for the confusion, I think the correct term is 'hourly rate', what you charge as a consultant for your time.


All is good and well until 5 years down the road you don't have experience implementing the newnosql.js stuff that is all the rage. You try to conform it to what you already know and end up with a myopic view of the solution. Since you are already respected people listen to you when defining architectures. Coders think you are a moron, impostor syndrome sets in. The doctors prescribe the new and improved treatment, but the new balm doesn't work as well as the goop for some cases.

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.


Or, you could stick with a higher level consulting role.

Or, you could stick with a sane "boring" domain (e.g. C, embedded, etc) that's not changing every 5 years with some new BS "rage" tech.


Do you think the VPs and CTOs know how to implement newnosql.js? The biggest challenges involve more that to get solved.


We are talking about consultants, but CTOs should have this knowledge if they if they are the ones making system architecture decisions. I have been at positions in which I had to explain to hierarchical superiors why a decision was bad or why some architecture was preferable. I was also overruled in some of these occasions, and in these cases we hit obstacles I predicted and had to change on the fly, ended up with delayed deliverables and a sub-optimal solution.


It's not realistic to expect CTOs to know the intricacies of all the latest widgets and libraries. I'm talking about CTOs of mature companies, not "CTOs" of a 10-person startup.


I have been thinking about this for a while.

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've only been at it a year but I find this to be nearly impossible. 95% of my income this past year was writing software. Whenever someone saw me as a "software consultant" they thought "well why don't we pay him to implement it too?" But I also made more than double what I made when I was full-time.

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


Don't take the work, or subcontract it.


So the breakdown I saw this past year was:

* 5% consulting (e.g. reports, audits, et al)

* 10% subcontracting to other devs

* 85% direct software development

The highest margins were certainly on that 15%, but the volume was not nearly high enough to be able to make it work.

Would a scenario be something like:

Prospect wants work done. Instead of turning them down because my rate is too, subcontract that to someone who is maybe less experienced and can do it at less than the advertised rate and bake in a margin there?


This is how body-shops make the big bucks: squeeze production prices down so you can carve more profit.

The alternative, I believe, is to find niches with higher margins or that scale better (white-label products, saas, and so on). Facebook makes $640k for each worker they employ, and they certainly don’t skimp on salaries.


Very true sentiment in this article. Also a corollary to this would be to deliver based on the value you provide the client, not the time it takes you to complete the problem. I've written about this before on HN: https://news.ycombinator.com/item?id=14942561


I read your linked comment, and it's important to distinguish that you are a consultant in the "not on a W2 sense," rather than a consultant in the "people pay me fat fees just for advice sense."

It's great that you are successful at getting contracted to build apps, and I'm envious because I hope to do something similar one day, but I regard it as a different job from the consulting described in the article, where you are paid to advise an existing team, not build something by yourself.


True, i also build but its a smaller part of my job since as i have employees etc that do the labour work. But the biggest part of my job is to listen to a problem and come up with a solution, more often than not, my company also delivers that solution, but i get paid for the answer to the problem, not the time taken to build it.


I think that provable deep expertise in some niche is a pre-requisite to this kind of positioning. Is there a market for general purpose software consultants? Who is the target audience?


What I have seen is that some people/consultants have the ability to talk to C*O or VP level in their own language. Once you get these people to trust you, you can hire people with expertise you need. You can probably also get contracts because of your specific domain expertise but I believe the ability to communicate with high level management is more important for a successful consulting business.


Do you have any tips on how to do that or to grow the ability to talk to C-level in their own language? I feel that that's what's holding me back at the moment.


No, I have been struggling with my whole life. Let me know if you find out something.


> Is there a market for general purpose software consultants?

Certainly is, as indicated by the continued success of for Accenture, McKinsey Digital, Deloitte Digital, IBM, EY, KPMG, PwC, Aon Hewitt, and probably a million more smaller consultancies and agencies.

Its certainly a suitable career choice if you enjoy a mix of technical solutioning, ideation and development work across a range of clients, geographies and technical domains. The caveats of course being sometimes your skills stagnate or the work-life balance isn't there when comparing service-organisations with product-organisations. But, depending on where you want to build your career, this kind of work for those kinds of places can be quite an accelerator.


These companies/people are paid not for their general purpose skills/consulting. They are paid for trust/brand. """No one got fired for choosing McKinsey/BCG/Deloitte/IBM/MS etc"""


I've seen a number fired over the years for picking Cap Gemini, Tata, Cognizant, Infosys, ATT Global Services or IBM Global services. Some of these are becoming anti-brands as they burn too many people with slow, shoddy work, disorganization and poor communication.


I feel that "no one gets fired for choosing X" is such a pervasive non-sequitur.

A brand's goodwill (trust and so forth) is a function of its ability to deliver success for the client. Success establishes that trust. People who run projects internally, and use consultancies or agencies, still have business requirements like any other team (whether internal or external). I can't imagine a team would be immune to scrutiny of a project failure (i.e. from shareholders) simply because they relied on a third-party. The same argument doesn't make sense if Amazon AWS suffered downtime, for instance?

I can't imagine a CTO or VP of Engineering turning around to a team that failed to deliver as a result of poor partner selection, and saying "nah, you're all good, we'll blame them." As blaming a third-party doesn't re-coup the millions in lost opportunity, shareholder backlash, press, etc.


No need to imagine. It happens all the time. More the rule than the exception, really.


Except in South Africa where Bain etc are under heavy fire for facilitating government corruption on an unprecedented scale during the Zuma years


I'm working on a new consultant biz, oriented toward "freelance CTO" for early-stage startups. It's general purpose but provide a non-technical client a better view of the technical aspects of their product. I'm convinced it has a lot of value for this kind of clients.


I tried this a bit myself. You are right that you can provide tremendous value, but early-stage startups either don't have, or aren't willing to spend, the money that you deserve for the value you'd provide. Maybe there's a niche you can target that I was unaware of. Hopefully you have more success!


Seems actually a better use case for paying in stock (compared to regular employees). You only work a short time for them, so you can spread your bets more like a VC, and your influence can have a decisive impact on their success, so it's not just a lottery ticket.


Those days startups take ~10 years to get to IPO.

Even if we assume that they are willing to part with stock for consulting engagements, can you afford to wait years to get paid?

Can you afford to pay taxes on that income this year? (to you it's paper money that might never to turn into real money; to IRS it's as good as payment in cash).


Restricted and illiquid shares are rightly valued at a discount to the same shares with a liquid market, so while you pay taxes on them, it's on their fair market value (which can be low as above).


Same, this business model is broken. Tremendous value is relative to the size of the business. Nontech founder = small business = high stakes work for low absolute comp. You make way more as an actual CTO (cash, equity, whatever) because you can grow the size of the pie, often rapidly.


I'm not so sure about the lack of funding.

A number of startups really start having this issue once they start seeing some traction.

Maybe they're actively looking for new or additional senior technical leadership or just scaling the team.

Either way the opportunity is certainly there for companies to hire temporary technical leadership.


I've also done this and can agree with the parent of this comment.

The problem here is once they have traction and funding, they likely have a full-time CTO. Fractional CTOs are generally needed at the seed stage when the technical solution hasn't really come together and they don't have this skill-set in house. They also don't have money. It's a slippery slope, and you're better off being a technical advisor (low effort, low equity, low risk) than working underpaid and overworked.


This is why I decided to offer the same fractional CTO service but to focus on small cap listed companies.


One way to get clients to respect your input is to charge a lot.


Easier said than done. They may respect you but they'll also likely not hire you. They have to respect you AND know you. It's hard to justify paying someone a lot if they are an unknown quantity. I checked out your HN profile: do you think you can hire more because you specialize in Computer Vision/Graphics? I'd also imagine your clientele is highly-targeted as well?


"I checked out your HN profile: do you think you can hire more because you specialize in Computer Vision/Graphics? I'd also imagine your clientele is highly-targeted as well?"

Sorry, I didn't answer your question. Yes, to some extent, they just can't find someone else to do their project. I've got a kind of bizarre mix of skills I guess.

I'm not sure what you mean exactly by "highly-targeted". I don't look for clients, they just fall in my lap. They probably fall in my lap because I have those skills (and some others). The typical job goes something like this: someone I've worked with before asks me if I'm available and if I could do something like X. I tell them, "Why yes, I'm an expert in X, as far as you know." (Just kidding.)


As long as someone hires you, you are much better off. The clients that want "cheap" are generally not great clients. It's counter intuitive but charging more gets you better clients and more respect (in addition to more money).


I should have asked what you believe is more. $75-100 is definitely in the "cheap" range, $100-150 I see for senior generalists, and $150-300 I see for the principal/architect/specialist rates. At some point the number isn't sustainable unless you're like a brand-name entity (e.g. John Carmack, Jeff Atwood, John Resig, and I'm just guessing here).


Good point. For context, I'm outside of Boston, not a web developer and I charge a very reasonable $150-$200 hour. This weeds out the clients that expect something to "take a couple of weeks" but have no idea what is involved and then don't appreciate/value the work once it's done. ("My kid cousin could have done this.")

Many contract shops would be happy to tell you that "no one will pay that", pay you $65 hour and then turn around and charge $130+.


> Many contract shops would be happy to tell you that "no one will pay that", pay you $65 hour and then turn around and charge $130+.

or $55/$150 in my case :(


How do you market yourself? Personal network?


That the weird thing. I don't (market myself). I made website but I don't get leads from it. It's just a portfolio. I am very friendly and I do keep up with people I worked with decades ago but that is the extent of my "networking".


Interesting. I've heard that before, it does seem to be mostly a matter of building up a solid reputation over time and getting referrals. Thanks for the info!


I’m naturally friendly and I keep in touch with people I’ve worked with. I go out to lunch with them every now and then, etc. I keep in touch with them because I really do like them but a happy side effect is that decades after I last worked with them, they’ll contact me with work.

I know some people can go 30 years and not have any friends they used to work with. At the very least, you should make contact on LinkedIn for your (former) colleagues when you leave a job. Drop them a line once in a while. “Ping” them a text at Christmas, etc. You don’t want to wait until you need work to start building your network.


Veblen services.


True. Even when working as a full time developer.


This article suffers from too many analogies. After the long DaVinci analogy, he goes into a medicine analogy. Please just say your point clear and up front. I don't think analogies are necessary to explain each point.


Agreed. I think I understand what he was getting at, but when I read the analogies, I start to second guess whether I really understand the message.


What I got out of it can be summarized pretty succinctly. Freelance programming is not the same thing as software solution consulting. If you want to do more consulting, don't write code for the same clients for whom you're designing high-level solutions.


How do I go from general software developer to domain specialist if I don't have domain knowledge in the first place (or want to get out of the domain I'm working in)?

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.


To answer your first question: you simply sacrifice your free time to do it. No magic bullets sadly. Or, if your day job is very boring, get a fixed slice of your workday and utilize it for your future prospects / education. So many people do it and yet it's a largely denied phenomena. One of the so-called "public secrets". :)

A deliberate attempt to move into a higher position is just an intention and nothing else. The real hard part is changing the way you think and view yourself. You can start with reminiscing all the times in your career when you had a much bigger advice to offer outside of the usual coding monkey trope: "this feature will be done in 2 days". In this regard I believe the author hits the nail on the head: it's all about how people view you. If they view you as a coding monkey then they will not listen.

Start thinking about the advice you have given and which was ignored.

The process of self-transformation can take anywhere from several weeks to decades (and many people never achieve it). It seriously depends on the person. I am currently in that hard transition and I have to tell you -- it's exhausting and it will challenge a ton of preconceptions you didn't even know you had just a week ago. Be prepared to put anything and everything in your life philosophy in question. It's more than most human egos can endure.

I am still a programmer, damn good one at that. But I regularly get rejected based on "cultural fits" or half-arsed excuses where they have no idea how to twist the fact that they don't want somebody with my rates or my resistance to BS. And I started having other people market me as not-only-a-programmer. I am in no-man's-land right now but I can feel the attitude of several people changing -- and see a few new ones coming with a drastically different one compared to what I am used to when people hear I am a programmer.

TL;DR: It's extremely hard and the main limitation and hurdle is you. Sucks to admit but it's better for one fo be a realist. Remember the amazing "Cloud Atlas" movie:

"All rules are conventions and are meant to be transcended. One can only transcend a convention if they first imagine of doing so."

---

And yes, luck plays a huge part to it. But in one of the towns in my country people love saying "luck doesn't come to you, you go to it" -- which illustrates that if you keep trying eventually you will bump into the right people and conditions.


You can't slice out a portion of your day to learn niche domain knowledge. You get it by working in the industry or studying under a professor from the industry. You can't learn the payments industry from a bookfir example. All the information is tacit and passed verbally. Arcane is a good word.


Oh I agree what you say is true for many areas. But what I say is also true for others. It depends on what the person is aiming at.

My general point was that there are no magic bullets. I was always to irritated at the Hollywood trope of the person who hates their job and decides to change their life... and then we fast-forward to them having a villa at the sea and working only when they want. I was trying to show that a lot of hard work is involved, and that some sacrifices have to be made.


Reminds me of the art of value podcast that talks all about positioning yourself to provide value, not services.

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.


Another way of looking at this is to focus on the what the client is buying, rather than what you are selling. We all lives in our own worlds, so by default we tend to think the client is buying what we are selling. If you can switch it around, then you can sell (and deliver) what they are buying.


>Don’t ever let would-be consulting clients pay you for code that you write.

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


When I got into consulting I read that MacKenzie article and answered an ecstatic "Yes" to all three and yet people see my resume and previous work and just immediately slot me into the "code monkey" territory. I am able to negotiate a great rate, so I've done very well, but I believe I could do better if I was able to get the higher value projects, but no one has yet to perceive me this way.


Is it possibly because you've positioned yourself in a such a way that you attract customers who will only ever see you as a coder for hire?

I love the look of your consulting website, but "We create beautiful, engaging applications" isn't a very strong positioning statement. Most generalist software shops have something similar on their site. And if you position yourself that way, whether online or in person, I think that most customers will inevitably see you as an implementer of software.

In smaller text, you write "If you’re a healthcare or fintech company, we can help you launch products faster with fewer resources to increase conversions and get results".

Now that's definitely a stronger positioning statement. Do you think it would be helpful to position yourself more strongly along those lines? Like, instead of your big hero text saying something general, could it be something more specific like "End-to-end app development for healthcare companies", or to narrow it down even more, something like "Dashboards for fintech companies".

That last one might seem really narrow, but that kind of narrowness also helps you build up a reputation as more than just a code jockey. It's hard to become known as the go-to person for beautiful, engaging applications, because there are just too many people who market themselves and their companies that way.

But it's a lot more doable to become known as the go-to person for reactive fintech dashboards. It takes a bit of time to establish your authority in a niche like that, though. But since you're already doing software consulting profitably, you're in a good position to move in that direction.

And once you're known as an authority in a specific area, you almost automatically become seen as more than just an implementer. Instead of coming to you with exact specs that need to be coded up, you'll have more conversations along the lines of "this is what we're trying to achieve; since you're the expert on this topic, how would you recommend we do it?".

Since you've completed customer projects successfully, you now have project management experience. In your marketing materials, and in conversations with potential customers, would it be possible to emphasize the project management angle? Because that could be a solid point of difference that works in your favor. Unlike most software developers, you have project management experience. You don't just deliver code. You deliver complete end-to-end solutions that don't require the customer to specify everything in excruciating detail. Instead, you're like an amazing machine to which customers only have to insert high-level business requirements.

Please note that none of this is intended as criticism. You're obviously already enjoying success! Over the years, I've just seen other people in the same position you're in, asking the same questions you are. And so I figured that sharing a few observations might be helpful.

If you haven't read it already, Philip Morgan's positioning manual covers this in a lot of detail: https://philipmorganconsulting.com/the-positioning-manual-fo...

I don't have any connection to him aside from being a customer.


Thank you so much for writing this. I've struggled with positioning for a long time, and although I have a niche, it was a challenge to communicate the value I offer in a succinct way. This nails it:

> You don't just deliver code. You deliver complete end-to-end solutions that don't require the customer to specify everything in excruciating detail. Instead, you're like an amazing machine to which customers only have to insert high-level business requirements.

Reading over the website, The Positioning Manual seems to have more actionable information than the sum of all other source I've found, so thank you for that too.


You're welcome! I'm glad it was useful.

If TPM seems useful to you, you'd probably enjoy signing up for Philip's newsletter. He sends out an e-mail every day, and I usually find them useful and insightful.

Along the same lines, you might like Jonathan Stark:

https://jonathanstark.com/

I haven't bought anything from him (yet), but I signed up for his e-mails and find them valuable.


This is super actionable and useful advice. I love it, thank you so much!


You're welcome! I'm happy it was useful.


> If you're just a generalist programmer in (e.g. C++/Java/Python), it will be difficult to sell that as "consulting" to companies

Difficult, but not impossible. You can sell coding training, basically do targeted lectures on areas where you see a company's coders struggling. The problem with this is that the improvement is long-term and practically invisible at the management level.


Exceptionally well written, and very believable advice.

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


I found it rather enlightening and quite enjoyable to read as well. Gonna go quit my job now ;)


I'm confused. The title made the think the article would be about licensing is IP transfer on project completion, but I got a lecture on what I consider to be a nuanced lecture about marketing.

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.


As a Deloitte alumnus and a current cofounder of my own cybersecurity services and advisory firm, I hope I am qualified to weigh in here.

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.


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?


Anyone else have trouble reading this site? The combination of low font-weight and color makes for really poor legibility.


That was a surprisingly well written article with a well articulated point.


Anyone here do UX consulting? How much or how do you charge?


By the time a business believes that a “solution provider” is not the same type of person hired for the technical implementation, the battle is already lost and you should leave. The idea of wanting to work in these situations as consultant or software engineer is all pretty crazy.

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.


Just to pick on the example a little bit (understanding it's not your main point).

A scrum consultant would have most likely failed at the first step anyway, because a consultant is going to sell scrum as a tried and tested, repeatable offering, and all it takes is to implement the framework.

That's not how 'organisational transformation' works at all, but the process piece is easily marketable and looks exactly like a checklist you can tick off item by item: standup? check. Sprint review? check. Jira? check. Self-empowered teams and servant leaders? Errrr, that's not on the list! Retrospectives? Hesitant check.

It takes a lot more effort to shift habits, empower teams, and reframe leadership expectations, and you need coaching and mentorship to make that happen. That's where the real work is once you've read the scrum framework instruction manual.

So on that level I can understand why scrum might seem so dreadful. I've dealt with enough of that kind of crap myself and it's stressful, but I've seen it done brilliantly too and it's been a fantastic way to work.


Some people work to make money. If providing solutions to bureaucracies pays well, why not do it?


Most people work to make money, even in IT, even in software development. If you don't believe this, stop paying them and lets see who comes next day.

Working in bureaucracy is great indicator/training ground for patience, and not really caring about meaningless things in life and instead focusing on those with true meaning. Yes, it wouldn't be work in that case.

'All we need is just a little patience...' music in the background


I was already assuming that was the goal here. Not talking about seeking creative control, idealism about a job, etc.


I'm genuinely curious, why do you believe scrum to be "stupid and horrible"?


Many years of experience with it across orgs of various sizes and ages. One-size-fits-all software management and metrics about planning and velocity are things that exist to give middle management surface area to tell whatever political blame/credit stories they want, and have not got shit to do with productivity, adjusting to change, or delivering anything.

And don’t even get me started on why Agile is emphatically and unequivocally not a different thing than Scrum itself.


No single methodology is right for everyone, but lean principles tend to be a better fit for most. And that's really what Agile and Scrum are.

The most important thing for teams is to establish a rapid feedback loop, and make sure someone is tasked with handling that data. Once you know your customers' needs, you can act to resolve them. If you're using a waterfall approach, you can miss the window, which delays your ability to get changes in front of customers, which delays feedback and increases the chance that you're wasting time.

Before we adopted an Agile-inspired process, we had several projects get scrapped after weeks or months of work because we misunderstood the customer's problem. When we adopted a new process, we built smaller MVPs (took days instead of weeks) and got customer feedback that indicated we needed to make a shift. Many of our features got smaller because we didn't get time to over-engineer them.

The major flaw, IMO, is technical debt. Our product is released on a schedule, but we get feedback from users with alpha products, so we have time to clean up the implementation once we get hands-on feedback from customers.

If we adopted Agile 100%, we likely would rack up more technical debt, and I've actually seen this happen in that same company as management made changes (I became trainer and technical lead instead of project manager).

If you drink too much of the kool aid, you'll get a stomach ache.


For one, Scrum is pure cargo cult.

As a field we simply don't have actual scientific research on these methodologies (just some joke papers that are as good as toss coin).


I've been in many companies including famous ones and I never seen scrum or agile deliver any value. It's just optics.


I've seen scrum work and not work. My biggest beef with scrum is that people think its a batteries included thing, and its not. I've also seen a lot of things called scrum, which were not scrum. That batteries not included part is the thing scrum calls a product owner, which is just an idealization of whatever requirements process is in place. If that requirements process does not deliver decent requirements in a prioritized manner, then good luck.

I've had much more success with feature driven development (Coad).


From my personal experience with scrum in an enterprise environment, I agree with you completely.


And that ladies and gentlemen is exactly how American IT became taken over by Indian outsourcing companies and the quasi ones like Deloitte , Accenture. American exceptionalism and a good education system might make you a great consultant but who turns that spec to code and does the grunt work ? Surely you aren't hiring American college grads because they have already been told this work is boring and shitty and they are special and should build domain expertise or salesmanship . Don't get me wrong - it's an excellent article but I think this is targeted towards developers with experience who also understand the big picture (accounting , P&L, systems). However doing implementations , turning spec to code , reusing it are great ways to enter the IT industry with solid pay and something that American college grads encouraged to take up for a solid middle class life . Infact community colleges and colleges should teach those skills similar to how it's done in India. (No I am not a Trump supporter).


Undertook a rewrite of grant tracking system for an NGO. The first solution was butchered by one these 'consulting' firms. They had set up fragmented Google Sheets, Trello and MSSQL and lots of repetition. Non-programmers shouldn't undertake this kind of work. The majority of the work was data cleansing to get rid of duplicates and normalising the database to 3NF. The rest is a user-friendly frontend to enter data and some data validation. Our solution worked out cheaper than the 'consulting' firm's and actually increased productivity.


I don't think that's true. Both paths he's describing are relatively lucrative. There are plenty of native born developers getting solid pay to do the less prestigious work of implementing specs.

It's just moving up the "value chain" is a lot more lucrative. The advice here applies to ambitious people who want to get paid even more.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: