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…
To become a software consultant, avoid letting clients pay you for code (2017)
21–30 of 135 posts
Re: To become a software consultant, avoid letting clients pay you for code (2017)
#22Earlier quoted context omitted.
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!
Re: To become a software consultant, avoid letting clients pay you for code (2017)
#23By 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…
Re: To become a software consultant, avoid letting clients pay you for code (2017)
#24As 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.
Re: To become a software consultant, avoid letting clients pay you for code (2017)
#25Earlier quoted context omitted.
> 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…
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"""
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.
Re: To become a software consultant, avoid letting clients pay you for code (2017)
#26By 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…
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.
Re: To become a software consultant, avoid letting clients pay you for code (2017)
#27By 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…
Some people work to make money. If providing solutions to bureaucracies pays well, why not do it?
Re: To become a software consultant, avoid letting clients pay you for code (2017)
#28By 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…
I'm genuinely curious, why do you believe scrum to be "stupid and horrible"?
And don’t even get me started on why Agile is emphatically and unequivocally not a different thing than Scrum itself.
Re: To become a software consultant, avoid letting clients pay you for code (2017)
#29By 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…
Some people work to make money. If providing solutions to bureaucracies pays well, why not do it?
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
Re: To become a software consultant, avoid letting clients pay you for code (2017)
#30Very 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
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.