It is weird how I get persistently drummed out of engineering because when I write cron jobs, SQL queries, and React dashboards I make special effort to connect them to business outcomes.

Businesses, to a first approximation, don’t care about their tech stack except to the extent that it drives business outcomes. Can you articulate those pros/cons in a way a business cares about? Can you impact your deliverables to reduced costs or (much better) increased revenue? Then you, too, can look forward to a bright future where HN tells you you’re not really an engineer anymore because your rates are too high.

Some folks get nervous when they have to justify the actual value of their work. Sometimes it’s because doing irrelevant work well or relevant work poorly. More often, I think the business impact connection is just difficult to make. The further you get from pure sales, the harder it is. Regardless, you should always consider answering this question as part of your job.

You really don't see why the example you gave above was marketing rather than engineering?

All of the recommendations you gave were related to selling the product, not improving it. That's not a bad thing; it just means it was a marketing consultation.

I think a clearer way to say what a lot of people are bothered by with that example is that in order to sell those recommendations you need:

a) to have a lot of marketing expertise

b) to be known well enough for your marketing expertise that people will take your suggestions as valid

Most tech people have neither one. Hell, most marketing people have neither one, half of the rest on my have b) but are actually incompetent in their recommendations, and only the last little bit have both.

Being a consultant is marketing, there is no way to be an engineering consultant. Engineers work for consultants, not as consultants.

If you want to make the big bucks, you have to do what businesses care about, not what you care about.

I've worked as a software engineering consultant. Sometimes I would do engagements that were just analysis and advice, but for most of them I would actually design or develop some software.

What was it like making the transition from software engineer to software engineering consultant?

I'll give you my perspective: it's tough. I tried to go from ML Engineer -> ML Consultant, and while I was able to find work at a reasonable rate, it was difficult, because most businesses don't have technical problems, they have business problems.

For instance, even though the root cause might be high latency, the actual problem is that the high latency is killing your retention.

If the business is sophisticated enough to value technical expertise, often they value it so much that they are willing to hire experts full-time, or they're so small that they can't afford to. So as a technical expert, you end up caught in a weird uncanny valley (in my experience). I think that patio11's advice is, as always, spot on here; the skills needed to become a technical consultant that charges $N/week are way higher than the technical skills needed to become a business consultant at $N/week, for any value of N. That isn't to say that technical skills aren't value, just that it's a tough sell to make, for a number of reasons that patio11, and others, have written at length about.

This is just a guess from what I've seen consultants contribute but there's usually some (at least the appearance of) low hanging fruit to cut costs on. Usually focuses on advice on how to get the AWS bill down.