fidzu : cms

Lots of people working in technology have a choice between working for clients or working for consultants. We work on one side of the relationship thinking how nice it would be to have the advantages of being on the other; the preverbal grass is always seems greener.

I spent a little more than ten years as a client before I became a consultant. I spent just a bit longer as a consultant before becoming a client again. There are things I've learned in each role that help me do the other better. To ensure a mutually beneficial engagement it is helpful to understand the perspective of the other team.

Why is understand both sides useful?

The goals of a consultant and a client organization are misaligned. That doesn't mean you can't do great things together, but if you don't understand the goals of your partner you are likely to step on each other's toes.

The goals of clients

Client looks to consultants for one of two primary reasons:

• Add to team capacity
• Solve a problem

We either need to complete a project that our team does not have the time to tackle, or we need expertise it does not make sense for us to keep on staff. Sometimes we're looking to reduce costs by having a group of part time people fill the roles of a smaller number of fulltime team members.

I like to have my team's staffing level sufficient to complete all day-to-day tasks and to bring in outside help to take on special projects. Other people like to have consultants around consistently to provide the outside perspective and the diverse expertise that consultants bring. Both of those strategies are foundationally aimed at those two needs.

A smart client wants to spend the money needed to be successful, but not more. We want the most value for our money we can possibly get.

The goals of consultants

Consultants have a different pair of primary goals:

• Record billable hours and/or ensure profit margin
• Have a happy client who refers more business

Some consultants will protest that they have the goal to solves client's problems through good work. My perspective is those are way to achieve those two goals. Some clients are happy when you do good work (but not all). All clients are paying to have a problem solved (see above).

Profit motive isn't evil or wrong - even when supporting nonprofits and other socially beneficial institutions (having spent much of my career in nonprofits, we think about this a lot). Consultants need to make money to stay afloat. A consulting firm has people to pay, overhead to manage, and founders/investors to reward. Independent consultants need to eat, pay their mortgage, and so on. The larger the firm, the more pressure there is for larger profit margins.

To get new clients, consultants need "referable" clients. That means having clients who are so happy with the work done they will serve as a reference. I wish that always meant creating the best solution possible. What it means in practice is building the solution that makes the client happy. As a consultant I gave clients my best advice, and when they disagreed and insisted on a different solution, we build that instead. If they ran out of money along the way we still tried to keep them happy, even if we had the duct tape the last bits.

In the end, consultants build what clients pay for, and that's not always the best solution.

Finding the balance

With consultants trying to make the most money they can, and clients trying to get a successful solution for the least money, there is an inherent tension in the system. Still, there is a balance to be had, where everyone wins, and great things happen. The trick is to make it a healthy tension that forces everyone to be better. Finding that balance doesn't require that everyone involved has spent time on the other side the relationships, but it certainly helps.

When you understand the needs and goals of the other side of the relationship you can adjust your approach to make sure everyone is aligned to win.

Lessons to take from being a client

One of the things I learned along the way was that a lot of the advice given to new consultants contradicts what I knew from being a client. Spending time as a client gives you insights into how to best serve customers that many pure consultants don't understand.

Be the consultant you want to hire

When you work at an organization that hires consultants you see different approaches taken by different firms. You learn your preferences about what you like and don't like in a consulting partner. While no one style is the best fit for everyone it's unlikely that you are so unique that there aren't lots of other people who like that same style.

Default to the Golden Rule: treat clients the way you wanted to be treated by consultants.

You can't always do that 100% of the way - sure as a client I want everything free, but that's not reasonable. But by approaching the client the way I would have wanted to be treated consistently went a long way to helping smooth over challenges.

Start there, and over time you'll learn to adapt your approach when specific clients prefer a different style.

Be honest about your limitations

Do. Not. Lie. To. Me.

Do not guess without admitting it. If I wanted made up answers, I'd ask an AI.

Consultants always want to appear to be the expert in the room, and so they feel they have to answer every question. Too often that leads to consultants making up answers to show how smart they are; clients will catch you eventually.

One of the best ways to build trust with a client is admit when you don't know the answer to a question, and then come back later with the answer. Do not say "I don't know" and leave it there, go for some form of "I will need to go look that up/ask around/figure that out."

Great consultants find solutions, they don't always have the answer right away. We can wait for you to do some research when we stump you. That is a lot easier to explain than when you have to walk back having given us the wrong answer.

Focus on what the client needs to succeed

Clients should always have an outcome in mind that supports their work. Consultants are focused on the solution they are building. When everything is going well, that solution is what the client needs to support their work. If those stop being the same thing you have a very big problem.

Both clients and consultants can easily forget to consistently re-check that alignment. As a client and as a consultant I've been part of projects where the delivered solution didn't solve the actual problem - even when it fulfilled the spec and SOW. These moments frequently lead to energetic discussions that often become loud. No one wins when that happens.

Regularly check with the client, and with yourself, to see if the solution will solve the client's problem. When you see misalignment raise your hand early and often.

Lessons to take from being a consultant

Of course consultants know and learn stuff that isn't obvious to any given client. Consultants bring wider experiences, different perspectives, and a different energy to a project. That is part of what makes them valuable. Clients should hire a consultant they trust, and listen to their consultant. Think hard before deciding you know better.

Always learn new things, even if they aren't important today

As a client we tend to learn deeply about the tools we use and our work. Consultants work on a lot of projects with a lot of clients. Along the way they use a lot tools, and see at lot of ideas. That creates a culture and need for constantly learning. Often they are learning about things that don't seem useful right away.

The higher the role you have as a consultant, the more you are expected to be at least conversant about technology you haven't used yet. You also need to be conversant about the work of your clients. That's a lot of learning.

I had good learning habits going in to being a consultant. They served me extremely well as a consultant, and are serving me well again as a client.

The broad knowledge of a consultant is extremely useful and everyone benefits from more people knowing more stuff. Having that breadth of knowledge also helps when you do run into the places where you don't know something. It gives you the confidence that you can go learn the next thing you need to know quickly (see Be honest about your limitations above).

Know how to work to a deadline

Consultants are always working within time and budget constraints - usually tight ones. That forces them to learn to be efficient. Sometimes that means they cut corners (see next section) usually that just means they move fast. Good consultants have a high degree of dexterity with their tools, they learn to line up their work to knock out tasks, and they learn what's needed and what's just nice to have.

New consultants often feel like they are sprinting all the time, but experienced consultants learn to balance the sprints with jogging. The pace is nearly always high (at least if sales are going well), but it still ebbs and flows. Consultants learn to hit their deadlines, but rarely are ready to deliver early.

As a consultant if a deadline was far in the future it gave me time to do careful work, balance other clients, do research, or just time off. Far off deadlines gave me time to recover from sprints and make sure I had the energy for high intensity moment. That intensity is important to driving client success - but hitting the deadline is more important.

Hitting deadlines is also important for a client to do. Consultants need you to hit your deadlines so they can balance their workload to hit their deadlines. They may also have penalties embedded in the contract (see Read the Contract below) that could cost you time or money over the course of your project.

Perfect is the enemy of the good

Okay, this isn't something just consultants know, but it is something consultants often learn to deal with the hard way.

Consultants need a solution that meets the requirements, fits in the budget, and pleases the client. They are not there to create a solution that is perfect, or even elegant. In any project there is a balance to be had between carefully polished, and just barely good enough to be successful. Consultants learn to thread that needle. As long as the project is successful that's a good thing.

I have seen developers spend hours, days, even months, trying to build to the perfect level of abstraction, with the perfect naming conventions, and drive for the perfect code, only to have the project fail because it's overdue, over budget, and was outmoded by someone who worked twice as fast.

Yes, we all want good solutions to our technical problems. But no solution is going to be perfect. You should aim for perfection and know you are going to miss. When you learn to accept that, it'll be easier to move forward and be successful.

Things everyone should know regardless of role

For all there are things that each side brings something to the table, there are habits that everyone should have as part of their role. There are lessons I learned, or was taught, in both roles that are super important.

Read, and understand, the contract

Everyone on a project benefits from having working knowledge of the contract. In the end, when push comes to shove, all that matters is the words on the paper. You can usually avoid the pushing and shoving by understanding what everyone agreed to up front.

The biggest issues I've seen on consulting projects was when one side, or the other, didn't pay attention to the agreement.

Sometimes this happens because everyone is working in good faith, and no one remembers to amend the agreement when needs changed. In those cases you can often recover by continuing to work with each other in good faith.

Sometimes this happens when someone signed a contract they didn't read and understand. I once had a client yell at me because I added a paragraph to the contract outlining the resources they were responsible for providing and he didn't read it before we asked him for those resources (these clauses are really standard, and the one I wrote was extremely simple).

If everyone on the team takes the time to read and understand the contract it greatly reduces friction. Clients who understand the bounds and assumptions in a contract are able to get the most from their vendor without creating tension. Consultants who track the required deliverables of the contract don't frustrate clients by skipping required elements. It doesn't take long. The more you read them the faster we'll be at reading the next one.

Once you have read a bunch of contracts you'll know what's normal and what's not. At this point, if I don't understand the contract language I see that as a red flag even before I send it out for legal review.

Discuss problems and be solution oriented

Projects go best when everyone is open about what problems exist and then pivots to solving them.

Technology should be deployed to solve problems. That means starting by talking about problems. Being problem focused at the start makes it easy to be hung up talking only about those problems, or about new problems that come up while solving the first problem.

Having a good problem statement is critical to creating good solutions. But once you have the problem outlined you need to focus on solving it. Yes, raise problems, concerns, challenges, threats, weaknesses, etc. Talk openly about all those things. Then make the pivot into problem solving mode once the issue is well understood.

The best projects come together when when everyone collaborates on finding the best solutions to the problems at hand.

Quality matters

Everyone needs to focus on the quality of the outcome. Consultants, for all their fast moving creation of imperfect solutions, must still do good work. Clients should hold their vendors, and themselves, to high standards.

Every message that goes back and forth is a chance for misunderstand that gets in the way. Every input into discovery and every deliverable is a chance for gaps to form. If anyone takes their eye off the ball mistakes can happen and the solution no longer threads the quality needle correctly.

Mistakes will happen, and everyone will have to help course correct. But the higher the quality of the work done before the mistake, the faster it will be to recover and better and overall solution the client will get.

The Grass is Greener

One final note on the way out. If you are trying to decide between being a consultant or being a client, I recommend the switch - whichever you are today try being the other if you haven't yet. Not everyone loves both roles, and different roles have been right for me at different times.

As a client I loved what I did. We were helping make the world better. I was pushing things forward and helping the organizations succeed. But eventually the things they needed me to learn, and the pace I wanted to grow, weren't aligned to the organization's needs.

I'd been there a decade, I left on great terms, but it was time to go.

When I first became a consultant it was exciting. I got to work on a variety of projects, with more technologies than any one organization generally needs. The pace was higher and I was frequently pushing myself in new directions. Consulting gave me insights into how different organizations worked (for both better and worse). And I made more money.

Interesting work, exciting environment, more money, great!

As a consultant I spent less time in positions, the billable grind was exhausting, I missed being focused. When I returned to the client side, I got to focus again. I have one org to worry about, one set of organizational politics to understand, and so on. I get to learn the work of the organization deeply again and really understand the market we serve. In my case I, again, got more money - but that was at least partially luck as much as anything; consultants are often paid better than in-house team members.

Focused work, no billable hours target, calmer work environment, great!

Each really does have it's advantages. But so does understanding what it's like to be the person on the other side the relationship. Try them both, learn from both, decide what's the best fit for you.

31 Jan 2026 5:36pm GMT

My LocalGov Drupal contributions for January 2026

markconroy 30th Jan 2026

30 Jan 2026 3:44pm GMT

30 Jan 2026 2:09pm GMT