While I’ve been working as a consultant for more than 10 years, only 3 of those years went into DevOps consulting. If you’re curious, my other consulting experience was in recruitment, HR and Management Consulting.
Here I want to share my observations specific to DevOps and more broadly IT and software consulting as well as some parallels with Management Consulting.
Table of Contents
Beyond the Facade
Typical consulting requests in DevOps are somewhat advanced. In example, this could be about some processes or functionality on Kubernetes infrastructure or a request to migrate to cloud-native from a legacy stack.
However, when starting on a project it frequently appears that the organization would most benefit from something much more basic.
I would say the number one issue I see way too frequently is not enough familiarity with Git. To the point that I believe if every software team out there – which yet does not have good experience with Git – would allocate 2-3 weeks for its developers to study Git Book thoroughly – this could easily become one most significant boost in productivity they will ever see.
Prioritize Sprints, Prepare for Marathon
A software project will always take longer than anticipated. This is the most important axiom I learned from The Mythical Man-Month as well as from years of working with or in technology startups.
Now, when doing consulting it is always nice to have a short project with a well defined scope and a higher hourly rate. However, the reality is that short projects almost always uncover something much bigger.
Therefore I came to conclusion that as a consultant I should have a strategy to respond to requests where a scoped project becomes a larger project and be ready for these negotiations early on.
Another angle on the same problem is that clients rarely have good view of what is the actual time frame of their project. Therefore, managing expectations and giving clear picture of the current state of the things is a very important aspect of the consultant’s job.
In example, if I propose a brilliant solution that would reduce the time it takes to build a software solution from 15 to 5 years – this is a 3x increase and sounds fantastic. But if the client expected the project to only take a year, this will instead make them feel angry. So establishing common reality as early as possible becomes number one priority.
Generally, conversations about time frames, deadlines and required resources are possibly the most delicate part of the consulting process in Software Development and Operations. Here I prefer the combination of radical honesty – clearly stating the time it takes for the project as early as this can be possibly established – with giving alternatives, such as for example what features can be dropped or what things can be done later.
Few times I ran into funny scenarios, where a client would try to defer an absolutely must have component required for the workflow optimization – in order to “save” time for the product features instead. If my explanations why this cannot be deferred do not work, I just politely refuse such project.
Consulting Fees Must Be as High as Possible
The more you charge per hour, the more you are valued and the more your advice is followed. This happens with few exceptions that mostly prove the rule, and this phenomena is purely psychological in nature (see Influence for details).
Now for me personally, sometimes I prefer to do discounts if the project aligns well with what we can do using Reliza Hub – as we are growing the product – or for some other reasons. However, in any case it is important to stay at the top of the range for what the client can pay, otherwise psychologically the client would see the services as less valuable.
Another interesting aspect here is that sometimes same people that are willing to pay me pretty high consulting fees would be hesitant to try out Reliza Hub – which is a product that benefited from a large number of my hours – and which usually comes at a much lower rate if this is factored in. This is something I can’t fully explain yet – just leaving it here as an observation.
Where an Advice Becomes a Consulting Project
I like giving advices, I’m also running online DevOps Community at devopscommunity.org where I have a chance to give a lot of them.
However, I found it important to set a clear boundary for myself on what can be given as a free advice and where a consulting project starts.
Here is how this works for me:
As long as I’m answering a question or giving general direction or simply saying what I would do in a particular situation, this can be given as a free advice. But the moment somebody asks me to work with them on a specific solution, edit their code or configuration or go on a call with them to review architecture or a specific implementation – this is where consulting starts and I would ask for a fee to be paid.
How DevOps Consulting Compares to Others
My last observation is how DevOps Consulting relates to other types of consulting which I experienced, particularly Management Consulting.
Generally, I must say that DevOps Consulting intertwines with Management Consulting a lot. Where we talk about processes, relationships and project planning those 2 types are pretty similar. With a notable exception that software itself is tricky.
In my opinion, the trickiness comes from the concept of software quality. In software there are too many layers of quality which are hidden from the client, such as for example cybersecurity or coding practices. Therefore, high level of technical expertise is needed to balance quality of software and operations with customer expectations from one side and with team processes and relationships from the other side.
All in, I believe that DevOps Consulting these days is more demanding than Management Consulting. That is because proper DevOps Consulting requires all the Management Consulting skills plus technical expertise. I believe this in itself is a good justification of a price tag for DevOps Consulting.
Summary Thoughts
Last thing I want to mention here is that over time all Consulting flavors related to process architecture and optimization blend into one single idea. It is about figuring out what the client needs the most right now and what course of action is best to achieve this goal. Sometimes those actions would be in the technical domain, and sometimes they should be taken elsewhere – for example in HR.
It is precisely the job of a consultant to see the biggest picture possible and figure out where and how to use limited resources. And that is quite interesting.