Consulting is different

Developing software as a consultancy is different from what most product companies experience. Tradeoffs, costs, revenue, and decisions are different. Still, little writing and discussion exist about how we, as consultants, can improve and challenge the status quo of software development as a third party in today’s world.

When reading articles and books about organizational design, software architecture, and teamwork, I often reflect on how to apply what I have learned to my consulting organization.

How would you apply team topologies, build psychological safety, create products, work with PRs, do dynamic reteaming, build product teams, and more in a consulting organization? Here are some reflections from transitioning back into consulting after spending many years in product companies.

This post raises more questions than it gives answers, but I’m curious about examples of how others have approached similar problems and want to reach out to the wider software community for feedback and experience sharing

Different how?

There is no one-size-fits-all consulting company. They are all different, working hard to be perceived as unique. They have different specialties, different ways of operating, different market focuses, and various business models, but there are common traits.

We sell knowledge

Most consultancies sell knowledge. In some shape or form, they sell hours with a consultant. It is not a digital product; it is an actual human being spending time advising, coding, facilitating, or doing something else you need. There can be many reasons for buying what consultancies are selling, but besides the more political reasons, what I have mostly observed is

• You need the expertise. The consultants hold knowledge that you do not have access to.

• You need a job done. You need hands and feet to complete a job that you don’t have the time/people/skill to do.

• You need a product. One that helps your business or meets the competition. At the same time, it makes little sense for your organisation to build the skills to create this product.

One of the upsides of this business model is that it is easy to understand. Consultants are paid by the hour, product, or some other transparent measure. Product companies can have very complex business models, making it hard to understand how they earn money.

Creating products

Many consultancy companies create products for their customers. But the product creation process is different from how a product company works. Consultancy often starts and stops with projects, not the continuous flow many product companies aspire to.

The customer holds the idea, the vision, and the direction, and then gets the consultants on board to realize them. Any good consultancy will still utilize processes like discovery and iterative development, but the ownership of the product lies with the customer. Consultants can advise on the path forward for the product, but the decision lies with the customer. Consultants are only involved with the product as long as the customer is paying. This often means the consultancy works for multiple clients, with multiple products.

To me, this is the beauty of consulting. Being asked to quickly gain a lot of experience in a new environment, understanding diverse businesses and problems. You can cross-pollinate the learning, see the patterns and similarities. But you don’t have a long-term organization built around a product.

By Marty Cagan’s definition, consultants are the mercenaries you want to avoid.

Specialists vs generalists

In my experience, most consultants are generalists. There are a few exceptions where a consultancy company is very narrowly focused on a specific expertise.

Most skilled consultants will meet the customer where they are. They will adapt to the context, the business, and the tech, to focus on solving problems for the customer. That means many consultants need to be ready to adapt, land in new environments, learn quickly, and leverage prior knowledge and experience.

In many product organizations, people know that tech and business environments don’t change that quickly. This allows them to become specialized. If a whole product is built in Java, it makes sense to focus on building skills in writing good Java code. On the other hand, if your current client is using Java, there is no guarantee that the next project will. Hence, as a consultancy, you have to focus on good engineering skills and be ready to build software using any technology your customer, for whatever reason, is using.

If anything, this puts an even higher requirement on software craftsmanship, because it is so easy to get away with sloppiness.

No team

Product companies often work in teams. These teams own a part of the product or user journey. Product companies make investments (to various degrees) to build high-performing teams that work together and deliver software.

Most consultancy companies don’t have teams. They might call them teams, but they seldom work together to solve problems. Instead, they have some variant of a matrix organization where consultants move between customer projects but report to a consultant manager. Reporting lines might be cut according to skills (backend, frontend), geography, type of customer projects (CMS, Cloud, app), or something else.

But if you are not solving problems together, you will never have a team (in the Five Dysfunctions of a Team definition). Since most consultancies sell hours of the individual consultant, it is more about building individual skills than building team skills.

Making money

The most notable difference between a product company and a consultancy is how they make money. And how their margins work.

Consultancy is easier to understand. Consultant A earns salary X per month. If they charge the customer Y per month, the company earns Y-X-(all other costs). There are many variables (such as how big the other costs are, how many hours the consultant can charge, the rate, and more), but it all comes back to a simple equation where a consultant who charges the customer earns the company money.

A consultant who doesn’t have enough billable hours costs money for the consultancy firm. I used to have a consultant manager who would remind us around Friday lunch that we had just reached break-even for the week, and the last hours were a profit for the company. This means most consultancy companies have to be very focused on what they spend their time on. Spending half a day in an internal workshop with 10 consultants will be very costly.

A product company earns money from the product (if they earn money at all, or rather, are burning VC cash). This means you can either charge customers more, get more customers, or reduce costs (of which salaries usually are the biggest) to get better margins. This all goes back to the company strategy (or lack thereof). A single engineer seldom affects margins (aside from costing money). Attending a workshop or conference won’t make much difference to the company’s bottom line.

This difference is especially visible within engineering. In most product companies, engineering is a cost center. In most consultancies, engineering hours equal profit.

Estimates

I have been waving the #NoEstimates flag for years, even when winds were blowing hard. I have worked in product companies without having to do estimates, but still being able to hold reasonable discussions about when things will be done, what progress looks like, and create plans.

In the last couple of years, I have worked with methodologies inspired by ShapeUp.

But consulting is different. Often, the customer has a set budget (usually the root of many problems). And they have a reasonable ask. How much will it cost to build what I want? Or, how much can I get for my bag of cash? This question is reasonable because the department has a limited budget.

I prefer dividing the process into phases or slices. Starting with a discovery that helps customers understand what they need and agree on the problems to be solved. Once we know what to build, we can figure out how to build it, and with that, have an idea of how long it will take, the complexity of the software, and the skills required.

Often, we build something novel. Often, we put together a new team with a diverse skillset. So we have no historic data, we probably have never built something like this before, and we cannot be sure if what we build will solve the customer’s problem. This is a recipe for disaster if we also make promises on estimates.

But the customer has a reasonable ask. When will it be done, and how much will it cost me?

Service company

The closest comparison to how a consultancy operates that I have found has been with service companies. Consultancies provide services and serve customers who come into the business to buy consultancy hours.

In this environment, you can apply systems thinking methods like the theory of constraints, queue theory, and more.

Here is a great example of how these methods can come into play for a service company.

Most of the literature on service companies deals with call centers or their like. A consultancy engagement is very different. Serving the customer takes everything from a few hours to years of engagement.

Still, what Seddon mentions in the video is also true for consultancy organizations. Trying to manage costs will make the costs go up, and trying to reduce variance will make the organization struggle to handle new customer cases.

Challenges

Recently, I’ve come across a few challenges in the consulting world. Some of these have documented solutions for product companies, but I have struggled to find an agreed-upon solution for consultancies. I don’t believe there are any best practices here, as most of these challenges lie in the complex domain.

I am looking for examples of how other consultancy companies have solved these challenges in the past: books, articles, and talks that point to how consultancies have learned and improved these practices over time.

Organize

The challenge: Consultant organizations seldom have stable teams over time. People often contribute to several projects at a time (bad practice, I know, but it is the reality in most consultancy companies).

Many consultancy organizations have employees with a varying degree of experience across several locations and multiple tech stacks. They typically serve customers in multiple locations and in a variety of businesses, solving vastly different problems. Still, they need people to be able to help each other with tech and build domain knowledge over time.

In a product company, I look to ideas like Team Topologies, Dynamic reteaming, or DDD to find team boundaries. However, in most consultancy companies, more than these methods are needed to solve the demands of an ever-changing customer base.

Questions:

• In what ways can a consultancy company be organized to ensure effective delivery of projects, while still having slack in the system and an environment for learning and sharing?

• How do you create teams that solve problems together in the consulting world?

• What kinds of problems could the team share and be accountable for, especially when clients want to keep a strong ownership of the product definition?

Process improvement

The challenge: In any consulting business, there is a limit to how much time can be spent on improving internal processes. No customer will pay for those hours, so they need to be an investment from the company’s side. This requires bold leadership, especially if you are choosing between consultants spending their time invoicing hours or working on internal processes.

As a result, most consultancy companies have skilled consultants who can help customers optimize their processes, but their organization runs on square wheels. The value of internal improvements is long-term and strategic.

In a product company, most of these strategic initiatives are started from the top. There is an idea that waste and costs can be reduced by improving the way the organization works. In engineering, there is consensus in the literature that investing in process improvement will lead to gains across the whole value chain.

Questions:

• How could the value of internal process improvement be visualized in a consultancy organization?

• What is a good balance between working on internal, strategic initiatives and invoicing hours for a customer?

Create space for good engineering practices

**The challenge: **By definition, consultancy companies do not own the software they build. They build products or sell hours to another organization. They do not own the outcome or the value that the software delivers.

Consultants are seen as experts, but they can only give advice. In many cases, the customer writes the requirements for the software. Consultants can advise about good engineering practices, but the choice is up to the customer. In this environment, it can be a challenge to stick to good engineering practices. To invest long-term in high code quality, test coverage, observability, and more. Many tech departments face the same challenge with internal stakeholders. The difference for consultants is that there are always competitors willing to take shortcuts and go for short-term gains to underbid. Most consultants have experienced a customer coming back from an engagement with a short-sighted consultancy, asking for more skilled consultants to fix the mess that was created.

Similar challenges apply to things like infrastructure setups and running on-call services. The long-term, strategic investment is always a tradeoff with the short-term gains.

In many product companies, there are talks about technical debt and how to reduce it. There are known areas that often break, have a lot of reported bugs, or are cumbersome to work with. The company might get direct value from investing in improving these areas. In contrast, a company that builds a product for another company will only reduce technical debt if the client pays for it. The builders can advise on the investment, but the decision lies with the client. In my experience, most clients don’t understand or are unwilling to pay to improve something they have already paid to have built.

Questions:

• How do you create a space for good engineering practices in consultancy?

• How do you make those practices part of your operating model, and explain their value to customers?

• How can you educate sales and business, both in your consultancy and at the customer, about the value of good engineering practices?

Help

As you can see, I have left you with more questions than answers. I would be happy for any pointers, tips, or thoughts on the topic. Or simply theories for why these topics are talked about so little.

This text was originally published as part of the Global Agile Summit proceedings. Thanks to Vasco Duarte for helping me edit the text.