Live data from Hacker News

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

daedtech.com

61–70 of 135 posts

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

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

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

#62
post #53

Earlier quoted context omitted.

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 thin…

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

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

#63
post #33

Earlier quoted context omitted.

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.

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

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

#64
post #53

Earlier quoted context omitted.

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 thin…

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

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

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

#65
post #23

Earlier quoted context omitted.

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…

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

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

#66

Earlier quoted context omitted.

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

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

#67

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, b…

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.

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

#68

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…

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.

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

#69

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.

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

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

Post reply on HN