The reason I believe it is sometimes wise not to raise concerns too quickly is that, in many cases, issues have a way of resolving themselves. A client who initially seems difficult might become more cooperative as the project progresses, missing data or specifications may eventually fall into place, and so on.

This brings up an important question: how do you know when to raise an alert and when to remain patient?

To illustrate, let me share an example from early in my consulting career. I was tasked with migrating a reporting system to a new technology. To do this, I needed to understand the old system, but there was no documentation, and the data model was highly complex. I repeatedly tried to flag this issue to my supervisor, but due to time constraints, he wasn’t able to provide clear guidance. I considered whether we should request documentation from the client because reverse-engineering the database from scratch would be time-consuming. However, a few weeks later, my supervisor went on vacation, leaving me without direction or documentation.

Press enter or click to view image in full size

At that point, I took the initiative. I studied the existing SQL code, mapped out the database schema, and created a detailed PowerPoint presentation. When my supervisor returned, he was impressed, especially since this client had never before seen a visual schema of their data. I proceeded to develop the new system, and when we delivered it, the client was not only satisfied with the final reports but also appreciated the thorough documentation I provided.

Of course, this was a gamble. I could have found myself in a difficult position for spending more time than budgeted on this project. But in this case, there were no competing demands on my time, and my supervisor appreciated that I had taken the initiative to keep things moving in his absence.

Another, more recent example involved a long-term client. A new team member had joined their project, and I disagreed with many of their design choices.

However, company hierarchy required that I follow their direction. I complied, and as expected, their approach didn’t work. We eventually implemented the architecture I had proposed from the start. Here’s how I protected myself: I documented everything — not just in emails, but in concise, 1- or 2-page slide decks that clearly outlined my proposed architecture versus the client’s request. This ties back to the previous lesson: “Show your work.”

When the time came to reevaluate the design, I simply re-sent the original email with the slides I had prepared months earlier. I had a ready solution, and the client could see that I had proposed it long before. Today, my architecture is the one in place. Had I refused to follow the client’s initial request, it could have led to conflict. Instead, by documenting my concerns and demonstrating that their approach wouldn’t work (in a low-effort, quick phase of the project), I avoided confrontation while proving my point.

What I’ve learned is that sometimes, problems resolve themselves if you stay focused and continue doing your part. I’ve also learned to document my work carefully — showing my engagement and concerns without being argumentative. This approach allows me to manage client expectations and protect the integrity of the project without unnecessary conflict.

I hope this piece encourages you to continue working hard and smart, even when you don’t agree with the project’s direction. All while documenting things and showing your work.