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 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 love that it's clear that you guys are doing great code just by looking at your website.
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.
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.
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.
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!
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.
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"
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.
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).
Product development is in some ways more gratifying than consulting. But consulting has its own rewards, too.
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.
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.
Where have you seen people charging that much?
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.
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.
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
And don’t even get me started on why Agile is emphatically and unequivocally not a different thing than Scrum itself.
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.
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 had much more success with feature driven development (Coad).
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.
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.
- 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.
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...
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?
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.
tariff - noun:
a list of the fixed charges made by a business, especially for use of gas, electricity, or a mobile phone.
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 sane "boring" domain (e.g. C, embedded, etc) that's not changing every 5 years with some new BS "rage" tech.
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.
* 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?
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.
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.
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.
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.
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).
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.
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.
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.)
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 :(
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.
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.
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.
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.
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.
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.
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:
I don't have any connection to him aside from being a customer.
> 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.
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:
I haven't bought anything from him (yet), but I signed up for his e-mails and find them valuable.
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.
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.
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.