The Communicator You Didn't Know You Signed Up For
The Communication Pillar
After 10 years leading projects across construction, manufacturing, and design, I learned something that no textbook ever fully prepared me for: being a good project manager has almost nothing to do with schedules and budgets, and almost everything to do with how well you communicate.
This is the first post in a new series I'm calling the Communication Pillar. Over the coming weeks I want to dig into what it actually means to communicate well as a project manager, why it matters more today than it ever has, and what separates a document or a message that lands from one that gets ignored, misread, or quietly resented. I'm building this series the way I build most of my work, by pulling from research and books on the subject, pausing on the parts that hit home, and adding my own perspective from years in the field. So let's start at the beginning.
Why Communication Became the Job
Somewhere along the way, communication stopped being a soft skill and became the job itself. Nearly every company today runs on email, and that is just the baseline. Layer in Slack, Teams, texts, project management platforms, and social media, and you get a workplace where the sheer volume of communication has exploded even as the time available to craft it carefully has shrunk. Being a strong communicator is no longer a nice to have for a project manager. It is the core competency that everything else depends on.
Here is where it gets interesting for those of us in project management specifically. Technical communication is not the same animal as the writing you did in school. Think back to a paper you wrote in high school or college. Your audience was one person, your professor, and your purpose was singular, get a good grade. Simple, closed loop, low stakes beyond the classroom.
Now flip that. Your audience is your peers, other departments, vendors, customers, sometimes the public. Your purpose is no longer to satisfy a single grader. It is to convince, motivate, and shift attitudes toward a decision, a risk, or a course of action. Technical communication in project management is persuasive by nature, even when it looks purely informational on the surface. Every charter, every status update, every risk memo is doing quiet work to move people toward alignment.
What Is the Project Manager's Role as a Communicator
If you strip away the job titles and the methodology jargon, a project manager wears three communication hats at once.
First, you are a document creator. Business cases, charters, scope statements, risk registers. The paperwork of a project is not busywork, it is the connective tissue that keeps a project moving in one direction instead of five.
Second, you are a member of the project team, which means you are inside the conversation, not just broadcasting into it. You are shaping decisions in real time alongside the people doing the work.
Third, and this is the one people underestimate, you are the information resource for everyone touching the project, inside and outside your organization. Departments, suppliers, vendors, customers. You become the translation layer between groups that often do not speak the same operational language. A supplier does not think like your finance department. Your finance department does not think like your site crew. Someone has to move information across those gaps without losing meaning, and that someone is usually you.
Of the many technical documents a project manager touches, the ones I find myself drawn to are the front end documents, the business case and the charter. These set the tone for everything downstream, and if you get the communication wrong here, no amount of polish later fixes it.
Six Characteristics of a Strong Technical Document
Whatever form the document takes, a genuinely strong technical document tends to share six characteristics.
It addresses a particular reader. Not a vague audience, a specific one, with specific needs and specific blind spots.
It helps the reader solve a problem. If it does not move someone closer to a decision or an action, it has not done its job yet.
It reflects the organization's goals and culture. A document that ignores the culture it lives inside will get read but not trusted.
It is typically produced collaboratively. The best technical documents are rarely a solo effort. They are shaped by input from the people who will live with the consequences of the decisions inside them.
It uses design to aid readability. Formatting is not decoration, it is function. White space, headers, and structure carry as much meaning as the words themselves.
And it uses words, images, or both, whatever combination actually gets the message across, rather than whatever the writer happens to be most comfortable producing.
Eight Measures of Excellence
Beyond the structure of the document itself, there are eight measures that separate excellent technical communication from mediocre technical communication.
Honesty comes first, and it should. A technical document exists to help people make wise choices, and that only works if the information inside it is accurate and presented in good faith.
Clarity matters just as much. If your reader has to work to understand what you meant, you have already lost some of them.
Accuracy is non negotiable. Small inaccuracies confuse and annoy readers. Major inaccuracies can be dangerous and expensive, and in project work, that is not an exaggeration.
Comprehensiveness means giving readers everything they need, not everything you know. There is a difference.
Accessibility is about structure, breaking information into sections so it flows logically and a reader can find what they need without hunting for it.
Conciseness keeps a document useful to a busy reader. Nobody has time for a document that could have said the same thing in half the length.
Professional appearance is the one people dismiss as superficial, but a document that looks neat, uses proper margins, and follows a recognizable format earns trust before a single word is read.
And correctness, the grammar, the punctuation, the spelling, is the quiet signal that someone cared enough to get the details right. If you cannot be trusted with a comma, why would anyone trust you with a budget.
Where This Leaves Us
Technical communication in project management is not a checkbox skill. It is the medium through which trust, alignment, and decision making actually happen. Every document you produce is either building credibility or quietly spending it down.
This series is going to keep digging into that idea, one piece at a time. I would love to hear from you as we go. What is the technical document you find yourself wrestling with most, the charter, the status report, the risk log, something else entirely? Drop a comment and let's compare notes.