Consultants and Employees
Employees and consultants are wired differently. Employees excel at BAU work, while consultants always work "on the edge" (transforming stuff). Most people are wired for exactly one of these
For someone who has worked as both an independent consultant and an employee for a considerable period of time over the last two decades, this realisation has come rather late - that consultants and employees are fundamentally wired differently, and operate differently.
I know this is a broad generalisation but fundamentally - employees work on “business as usual” (BAU) stuff while consultants work on “special projects” or transformational stuff. And the two require fundamentally different sets of skills and mindsets. That you have been successful as a consultant doesn’t mean you will be as an employee, and the same applies the other way round as well.
If you look at a list of the most popular kinds of consulting projects, you will know that consultants operate “on the edge” (for whatever reason I’m thinking of level- and edge-triggered flipflops now!) — AI transformation, systems integration, process upheaval, organisation redesign, M&A due diligence — the list is full of “transformative” or “special project” stuff. It is extremely rare that a consultant (either from a firm or freelance) is called in to do something that is not transformational - the economics for that simply don’t work out (it’s cheaper and much more sustainable to hire full time for that role).
Most “jobs”, on the other hand, are for “BAU stuff”. Yes, you might have some specific special project teams such as corporate strategy or "internal consulting”, but those aren’t there in every company (and are usually the first to get cut down during times of stress and distress). Most regular corporate roles, though, require you to do things in a steady manner, making steady progress and making sure you don’t fuck up.
If you think of it, the criteria for success or failure also differs massively between BAU and transformational stuff. For BAU, the upside is sort of capped (unless, let’s say, you’re in a sales or R&D role), but downside is immense. Your job primarily is to ensure that “lights are always on” - maintain uptime, have redundancies, don’t mess up, make safe decisions, etc. And the downside can be immense - shit literally hitting the fan.
Since BAU roles have this particular kind of incentive, they attract a certain kind of employees (who thrive under such incentives). Thus, when the company needs to do a big change or some sort of “transformation” or “special project”, they invariably bring in consultants. The internal people closes to the job don’t have the right skills to do that.
With consultants, the payoff changes. The consultants need to show you a positive result (achieve the change that they’ve promised they’ll achieve) for you to be happy. And if they fail to achieve that, the most you have lost is the fees that you have paid them (you declare the project as a failure and move on; nothing particularly adverse happens to your company).
(Yes - they could delete your database or leak your data (I’ve had an intern who deleted all of the company’s EC2 servers), but largely the damage consultants can do to you, if you’ve done your homework before hiring them, is limited)
In any case, now you know why someone who is used to being a consultant will struggle when you make them an employee - now a phenomenal amount of their time and effort needs to go into simply ensuring “the lights are on”, something they have hardly spent time on.
For example, take my own domain (data science). A consultant is used to largely doing “sexy” work - building new models, providing transformational insights, etc. Once they are an employee, though, they need to also look at things like continued model performance and maintenance, and make sure these models stay abreast with any upstream tech changes.
It runs the other way as well - employees are used to BAU work and spending lots of time and effort doing things to make sure nothing gets messed up. When asked to do more transformational work, this approach can massively slow them down, and leave the transformation dead on arrival.
There is a lot of unlearning and relearning to do if one wants to transition from being an employee to being a consultant, or vice versa. And there is also a mindset issue - some people are simply better at doing BAU stuff and some at transformational stuff. It helps to know that the skills in the two are different, and knowing which of them one is more comfortable with!
There are other tradeoffs as well - as an employee, you may not work on “transformational” stuff, but your job is far more stable and predictable (you continue to do pretty much the same thing over a long period of time). Also, you can take it from me that constantly working on transformational stuff (one after another) can be rather mentally exhausting.
You can seldom do a “common minimum programme” (interesting enough, pays well enough, not too painful, not too bad working hours - basically nothing spectacular but clears the cutoff on most parameters) job that is transformational.
Then again, you see people making transitions back and forth - consultants suddenly crave stability and trade off some boredom for it. Employees get bored of BAU stuff and want some excitement, and turn into consultants (internal or external). Nevertheless, most people are fundamentally wired in one of these ways. And the more the stick to it, the better they do!


Well written! I wonder if companies differ in what proportion of their workforce they want to have in KTLO vs innovation/ change. Companies like Meta or Google don't require many employees for keeping the light on, but still have a huge workforce. At Meta, for example, there is a lot of focus on coming up with ideas and initiatives from every employee. In that sense, everyone is expected to be a consultant as not many normal employees are required. I wonder if the approach is like VC/PE - hire talented folks and get new ideas from them, even if few click, it's big win for the company.
Well explained!