What I’ve learnt from two years of being an expert hands-on technology consultant

What led me here?

A couple of years ago, I decided I needed a change.

I was wrapping up 2.5 years as a VP of R&D at a medical imaging startup, building deep-learning-based solutions for the radiology domain.

I was leading a group of 35 engineers and DL researchers, in a very complex and uncertain environment. The main challenge was scaling the team, work processes and methodology so that the company can deliver multiple products concurrently and predictably — while the team can maintain autonomy and get the support they needed.

After 2.5 years in this role, I felt like my hard work has paid off — the team was churning out FDA grade products with high predictability and traceable process. The R&D leadership team was comprised of phenomenal people who actually liked working together, and most of the time, people were feeling cared for and committed.

But something was missing.

Being a technology expert was always a part of my personal and professional identity, and it was clear to me that continuing down the path of senior R&D leadership, could mean giving up on this part of my identity for good.

I was not willing to let this happen.

I had 20 years of experience in engineering, architecture and leadership, and I needed broad scopes and challenges. Also, I absolutely had to have a very high degree of autonomy.

This meant I can only really move laterally.

I decided to try my hand at technology consulting. I didn’t know what to expect really so it had a sense of adventure to it.
I figured I will give it a year and see how I felt.

Since then I’ve had many people reach out and ask for advice about becoming consultants themselves.

I decided to write a “README” based on my learnings as an exercise.

Most of this is not specific to my specialization or domain, I think.

Here goes!

Why do you want to be a consultant?

There are many different motivations for becoming a consultant.

• Some people take to consulting trying to maximize their income.
• Some like the idea of flexible, part-time income, either to have more free time or to perhaps fund some other venture they are building.
• Some seek freedom from an office and a boss.

Others, like me, seek an environment that will challenge them technically and enable them to learn continuously, while being well-compensated and autonomous.

Different motivations and goals will impact many of your choices as a consultant.

For example — in order to maximize income, you typically try and fill your schedule with as many billable hours as possible, at the highest rate possible, and with the least amount of overhead/challenge in delivering your offering.

Your biggest risk is having an empty calendar, so you will prioritize as much biz-dev as possible to ensure your pipeline of customers and booked hours is always full.

If what you are after is having more free time while making a decent living, you might look for 1–2 clients that supply you with regular work delivered at predictable times, amounting to say 60% of your time in total, and the rest spend on whatever else you are interested in.

In my case, I optimize for learning and challenge.
So I would rather skip a project that isn’t challenging than earn “easy money” or do “more of the same”

Identifying your value proposition

Whatever it is you are offering as a consultant, it needs to be something that enough organizations will want to buy from you rather than build in-house.

This typically means having expertise that is hard enough to come by, that has sufficient demand in the market.

You want your offering to be reasonably narrow and specific — this makes it easier for companies to understand what you can help them with, and also the more likely you are to have convincing reference projects that demonstrate your expertise.

Of course, it needs to be broad enough for there to be enough demand in the market.

So “Python and Spark data engineering expert” is good since it's narrow enough to be clear.

“Highly experienced all-around software engineer” is less clear and focused.

Maintaining differentiation

You need to work to maintain your value proposition — keeping on top of your domain and continuously learning.

I also like to make sure I have a differentiated value proposition — both compared to other consultants and of course compared to the customer’s current or future staff.

I like to take on projects and focus on areas where my position is very differentiated — for exmaple the my ability to combine long term architecture, planning, and guiding teams and projects with full hands on skills in cutting edge ML technologies.

Overcoming the bias to *not* hire consultants

I found that many potential customers that really need help are not crazy about the idea of hiring consultants. They strongly prefer running projects with full-time employees, even when these lack the ability and move jobs every few months anyhow.

I know. I was one of these people before turning to consulting myself.

I believe the bias against consultants is based on the following line of thought:

“Since consultants are by definition part-time and transient — they have no skin in the game. They dispense advice or build code, get paid, and leave you to handle the consequences.”

Being a successful consultant requires you to completely disprove these doubts, not only before the engagement, but more critically 6 months after you’ve already left.

In reality, consultants’ goals are completely aligned with those of their customers.

Happy customers = good reputation = successful consultant

As an independent consultant, the only thing that can help you generate your income next month or next year is not your experience and qualifications, it’s your reputation.

Due to the biases against hiring consultants, you need to maintain an impeccable reputation, one that positions you as the no-brainer choice for consulting projects in your field.

Your reputation is driven by one simple thing — solving problems for your customers, leaving them very happy with the solution, ROI and the general experience of working with you.

The inverse is also true:

Missing the mark is not really an option, as it can destroy trust and damage your reputation.

This is a first principle that influences many of my other advice further in this article.

Maximizing customer ROI = clear differentiation = higher rates

Part of what makes your service attractive is delivering a great return on investment for the customer.

Not only are you a person with rare skills, you are able to use them to deliver value incredibly quickly, visibily saving the customer time and effort.

Some people think that all consultants “pad” their bills with various charges and extras since they can get away with it.

I do the opposite.

I sometimes write off off up to 20% of the project cost — in case I had to spend a significant amount of time learning new skills in order to deliver the project.

This might sound counterintuitive, but think about it:

• The customer gets great bang for the buck
• I focus on challenging and novel work and get the chance to learn
• I can charge more per hour of my time since every hour is very effective

This principle of creating good ROI also guides almost every single decision I make when taking on consulting work.

Defining your service offering

When talking to customers, it’s very useful to have a clear description of what is it you do exactly.

• What is your field of expertise exactly?
• What type of projects do you do?
• Are you selling your “advice” on particular issues?
• Are you selling working software that you build yourself or with a team?
• Are you integrated as a (part-time) member of the company, either as an IC or as a leader?
• How many hours per week are you willing to work for one customer?
• Where will you do your work, on-site or remotely?

It’s likely your customers will now know exactly what to expect, so it’s great to have this thought out in advance.

Pricing model

Your pricing model needs to be attractive enough to the customer while making sure you get compensated fairly for your efforts and contribution.

The compensation model needs to account for overhead and unforeseen events that require your effort and time.

hourly

My preferred method of billing. I provide each customer with a worksheet with a detailed report about what I did each time I worked for them.

I think this gives maximum transparency to the value I provide.

project-based

Some folks bill per project/deliverable.
While this is also a reasonably solid approach, in practice there are always unknowns that prolong or complicate your work, and so consultants typically protect themselves by taking buffers in their price.

I think this buffer is not as transparent as hourly work and is designed to work in favour of the consultant vs. the customer, so I don’t work in this way.

Retainer

Some consultants allocate a certain number of hours per week for one or more customers. If the retainer is 20–30 hours weekly, I call this “part-time work” which is more like contracting.

While this provides maximum predictability and somewhat of a guaranteed income, I found the downsides to be very unattractive: there’s a good risk you will get absorbed into the company’s hierarchical structure, and be exposed to various internal issues that will quickly reduce your productivity and impact.

Consulting cost misperception
The cost structure of hiring a consultant gives companies a much clearer view into what they are paying for, compared to a full-time employee.

While this should be a good thing, it also makes companies compare the cost of consultants to that of full-time employees, and this often creates the impression that consultants charge a lot of money for their services.

There are numerous logical arguments to disprove this misconception — but the best way to is by to make sure you know what you are worth and asking for it — while ensuring the customer does get excellent value for money they pay you.

Creating a pipeline of inquiries and leads

I don’t have much to say about this since, for whatever reason, I didn’t need to do much to create this pipeline.

I do tend to write or comment about things I am interested in on LinkedIn and write technical blog posts on Medium, but the rest tends to happen by itself.

Discovering what the customer is looking for

In an initial exploration conversation, the goal is to understand if there’s a fit for a joint project.

Listening carefully can tell you a lot of interesting information about the type of company, tech. stack, level of technical expertise, and sense of urgency that brought the customer to contact you in the first place.

There are many strange reasons people reach out to consultants, and the initial call is the right opportunity to pick up on what they are actually after.

Don’t hesitate to say thanks but no thanks!

Does the opportunity fall in your area of interest?
Are you an expert in this field?
Does it optimize your goals?
Would you like to work with this company/people?
Do you have time for this?

When you are starting out, you tend to compromise somewhat in order to get some mileage under your belt.

This is ok, as long as you are sure the customer will be happy in the end!

If you have real doubts about your ability to deliver, or strong doubts about the customer — avoid the project altogether!
Even if you are “hungry” to get going!

I usually make sure to give one or two pieces of useful advice even in the early inquiry calls. Even if I don’t take on this project, it never hurts to help if you can.

Setting a clear short term goal with measurable outcomes

I’ve learnt early on not to take on any project without first creating a very clear understanding of the objectives and what success looks like.

Later, I realized there’s tremendous value in defining a small milestone and delivering that first, before continuing to a longer-term engagement.
This milestone needs to be very clear and provide stand-alone value to the customer.

Here are the advantages:

1. It demonstrates your abilities and offering
2. It gives both you and the customer an exit strategy if needed

The time you spend on defining the short term goal should be proportionate to the length of the project, i.e. short.

Making sure there’s someone on the other side

No matter how amazing you are, your work will need to fit in with something bigger your customer is doing.

To make an impact, you need to have someone on the customer side who is capable and is tasked with taking your artefacts and doing something with them — It can be acting based on your advice, or integrating your code with the system and taking ownership over it going forward.

Unfortunately, many companies start consulting projects without making sure they have this “person on the other side” for you to integrate with.

Not having someone on the other side might mean you delivered stellar results but no impact to the customer — which is not where you want to go.

Generally what you’re looking for is sufficient sense of urgency for the project to ensure internal resources *will* be aligned to it, but not such urgency that puts you in the critical path of the company execution when you’re working 4 hours a week for the customer.

Tailor to the specific needs of the customer

When designing technical solutions for customers, it’s imperative to customize the solution to the customer — be it their tech. stack, team size and skillset, risk averseness, timeline, etc.

For example, there is no point in building the state of the art cutting edge solution for a customer who has a tiny team with no experience, since there is no way the customer will be able to maintain it, and hence it will not be valuable.

This is also true regarding communication style, work processes, and asking for things.

Again, your goal is to have the solution to meet the customer where they are so that they can do useful things with it.

Going above and beyond while remembering you are not the final owner of the project

Once you’ve taken on the project, you need to balance two conflicting needs:

1. Delivering the best results possible including going above and beyond
2. Not taking responsibility for what is outside your control

Here I rely on my experience in leading teams and working on projects to judge what is the next most useful thing that can promote the success of the project I am involved in, taking into account a sense of the people and the hidden/soft issues that might derail them.

I am often willing to take on myself things that are not exactly within my “job description” as a one-off if I think they can really help the success of the project.

However, I avoid overstepping a line by taking responsibility on areas that are clearly outside my area of influence, or by putting myself in a role that should really be reserved for a full-time employee or manager.

Handling hiccups

Issues at the end of the project

You did all your due diligence, you were organized, kept all your promises, but somehow the customer is not happy.

For example, the customer signed off on the design and requirement docs but was surprised by your delivery despite it being 1–1 with the specs.

While you can demonstrate that the mistake was the customer’s, and the customer may be willing to admit it completely — it’s still a project you’ve delivered that didn’t meet expectations.

This happened to me once, and after some deliberation, I postponed other work I had and invested more time in making the alterations that the customer wanted, despite it being the customer’s “fault”.

Another example is — you’ve advised taking a certain direction, got a green light and spent time on it, only to find out the approach doesn’t work and you had to re-do it.

For full-time employees, these are all forgivable mistakes.
For me, I feel that I can only charge customers when creating value.

This happened to me once in a highly complex project where I’ve spent 2–3 days building something only to realize my approach wasn’t going to work well enough.

I took the bullet and didn’t charge for these hours.

Terminating engagements if there’s no fit

Midway through working with the customer, something doesn’t feel right. The communication is not good, the work isn’t interesting, or the customer is losing interest in the project.

This also happens sometimes, which is why a short-term goal is useful as an exit point.

I’ve also had the experience of working with a customer who hired me due to my expertise, with a high sense of urgency.

They got the most personalized, custom solutions that I really felt addressed their issues and gaps — but instead of leveraging my output, they second-guessed and overruled every suggestion I made.

I am not sure what was the cause for this issue, but I politely terminated the engagement, saying honestly that I didn’t feel comfortable getting paid for solutions that are not accepted and used.

Wrapping up a project

Asking for feedback on how to improve

Ask for advice about how to do better for the next customer.

You will definitely get useful insights, many times actionable suggestions that really work. Try it!

Keeping in touch and lending a hand

Often, even after the “interesting” part of the project is over, I stay in touch with customers to see if I can give them a small push to help get the benefit from the work I did for them back then.

First, I do it since I enjoy feeling like I’ve made an impact, and second, it really does help sometimes to give an hour or two to prevent the project from getting stuck on small issues.

Final words

There’s probably more I could write about my experience, I have many small rules and tricks for various parts of the lifecycle, but I might save them for another time.

Bottom line — I highly recommend every technology expert try their hand at consulting.

It’s definitely a refreshing and diverse challenge that can keep you at the bleeding edge of technology. When you’re seeing many projects in a short amount of time, you can really speed up your learning in many areas.

Happy to hear your thoughts here or on LinkedIn.