Realities of Software Consulting

Introduction#

When I first started my software development career, my first job as a software engineer was with an IT consulting company. I didn't really know what a consulting company was back then though. At that time, I was very green when it came to software development and I didn't really know anything about what it meant to be a software consultant. I was just excited to have a job as an engineer in the first place. It didn't really matter to me what kind of company it was. Fast-forward to a decade later and I've spent the majority of my career in the software consulting industry with a few companies. As it would turn out, software consulting has specific realities that you don't really find in traditional companies. My goal is to shed some light on these realities, so let's get to it.

Software Consulting in a Nutshell#

The short version is that software consulting boils down to simply providing software-related services to another company. Let's go a layer deeper. Those services I'm referring to could be building a whole new application to automate a manual process, training internal engineers on software development practices, or providing overall direction in regards to the next steps in developing software.

Project Molds#

My experience in the software consulting industry has led me to see some of the same types of projects and they fit a few different molds.

The number one type of project I seem to always see is that a client is currently doing some process internally where multiple people are trying to interact with related data at the same time, but they are using applications not designed for multiple users or the data is distributed in multiple places. The answer almost always turns into helping build an application that will centralize a place where all the users can work on the same data at the same time.

Another project I see is where the client has internal software engineers and the client wants more out of them in terms of performance and efficiency. This generally leads to a project that is based around coaching and training those internal engineers based on modern software development best practices.

There are also cases where the client has a legacy application that needs to be replaced for some reason. This might lead to building a new modern application while taking into consideration what they liked about the old application and also what they didn't like.

Outside of these high-level project molds, everything else seems like a one-off project that has a very specific need. In general, consulting is understanding the problem the company is experiencing and helping them find a solution.

Expectations of the Consultant#

When working as a consultant, expectations always exist even if nobody says them out-loud or on paper. The two main players when it comes to having expectations of the consultant are the company that the consultant works for (the employer) and the company the consultant is providing services to (the client or customer).

Employer Expectations#

First and foremost, the employer expects the consultant to be billable. What that means is that the employer bills a client for services the consultant is providing. If the consultant isn't providing services to a client then the employer isn't making any money. There is always overhead for the consultant that covers things like the consultant's salary, benefits, and training. The employer's goal is to charge a billable rate to the client that is high enough to cover the consultant's overhead and also provide the employer with a high enough profit margin.

Unless the consultant is self-employed then the reality is that the consultant doesn't have a whole lot of control over whether they are billable. Typically, a consulting company has salespeople or a growth team that are responsible for getting new projects for the consultant. The most important way that a consultant can help maintain some control over how billable they are is by making sure they grow themselves. This means improving soft skills, learning new languages/technologies, and having an understanding of software development best practices. This is what makes a consultant somebody that the consulting company can easily throw on any project.

Another expectation is that the consultant is going to be flexible in terms of joining projects. The reality is that the consulting company has financial goals and sometimes those don't always align with what project you are able to join. If you've put yourself in a position where you can easily be added to any project and there is more than enough work to go around then you can be picky and request different projects and decline other ones. However, there are times when projects are limited, you are a consultant on the bench and therefore not billable, or there just isn't a project available that makes a good fit for your skill-set. In these cases, you have to be able to say yes to projects that may not be very exciting. You have to make the most of it and realize that these are the ebbs and flows of software consulting.

Client Expectations#

When it comes to the client, the expectations are that the consultant delivers results. The client is paying a lot more for the consultant than if they were to hire their own internal engineer. This means that the client wants to get their money's worth. As a consultant, you will want to understand what those expected results are and make sure you keep that as a focus. Sometimes the results that are expected change. Because of this, communication between the consultant and the client is extremely important and is the difference between a good relationship with the client and a bad one.

The client also expects that they don't need to train or pay for the training of the consultant. In reality, training of the consultant is something that just happens throughout the course of developing an application in the first place. However, training is something that is rarely said out-loud in terms of dedicated time or formally communicated to the client. This is kind of an unwritten expectation and is usually something that tends to have consultant discretion attached to it.

Consultant Impact Roles#

Lots of companies rely on software consultants to provide something that they don't currently have in-house. Some companies just want capable engineers that they don't have to train that can be added to an internal team and start contributing to an application already in development. Essentially, they want warm bodies that can code. The other extreme is that the client has no internal software engineers. In this case, a team of software consultants might be tasked with providing all software-related services to the client.

With the different software consulting companies that I've worked at, my role has depended on the needs of the client and what my employer was able to provide at that time.

For instance, I worked at one consulting company where we had only three software consultants. Each of us handled our own projects by ourselves. We also had multiple projects that we were working on at the same time. My employer at that time didn't have a large pool of software consultants and our clients had small enough projects where only one software consultant could handle a given project.

Another example is where I worked at a company where we had a few hundred software consultants and we had clients that had projects that called for teams of software consultants. In this case, I would work with a team made up of 4–5 software consultants to deliver a project for a client.

Software consultants will inevitably be thrust into consulting roles where they have a different type of impact. There are different experiences and dynamics to being the only one working on a project versus working with a team on a project.

Another experience entirely is when you are added to a client's project made up of mostly internal software engineers or maybe even software consultants from a different software consulting company.

Throughout a software consultant's career, they will likely experience all of these roles at some point when working on projects for clients. The reality is that you won't always be on a team of software consultants that are all contracted by your employer, so be prepared for different experiences with the projects you might work on.

Opportunities Abound#

The ability to transition from developing one application to developing another application is hit and miss in a traditional company. You'll see this in smaller companies more, but larger companies typically keep engineers on teams for years.

Software consultants have a lot of opportunities to join projects often. Some projects only last a couple of weeks to a few months while others last a few years. Because of this, burnout on projects happens infrequently, but it does happen.

In software consulting, you will have opportunities to be on a project for years, but the longer you stay on a project then the less the consultant and the client will benefit. Consultants will benefit from rolling off projects and joining new projects in cycles as this helps consultants grow and learn new things. The client will benefit because it will force them to avoid single point of failure situations where any one of the consultants knows everything about the application and is irreplaceable. This is necessary and is something the client will only realize when suddenly that person is no longer available.

Sometimes consultants will really hate the project they are on. There will be reasons that frustrate them and it will feel like the project is a sinking ship. All consultants will experience this in one way or another. Rolling off the project to another project will help improve a consultant's morale as well as provide fresh perspectives to a client project. In other cases, projects that consultants don't enjoy are also opportunities for the consultant to step up and speak out in regards to what they think needs to be different. This, however, will always depend on the current relationship with the client and should be handled delicately. Seasoned software consultants know how to do this. Less experienced software consultants tend to just abandon ship.

The reason that I've stayed in the software consulting industry is that I like to change things up every now and then. Software consultants will have many opportunities to work on many different projects in several different industries throughout their careers. They will find industries that they enjoy better than others. In many cases, software consultants will eventually develop some type of specialty and that will become part of their identity. The opportunities in the software consulting industry are plentiful and will always become a career where you will continue to influence what your experience will be.

Conclusion#

These realities of working in the software consulting industry are things that I see repeated through working at different companies that offer consulting services. Some of these realities are inconvenient truths for consultants and others are great opportunities to forge your own destiny as a consultant. Take what you will from my experience with these realities, but my hope is that I've at least shed some light on what can be expected as a software consultant.