A Practical Guide to Effective Complaining

read

A Practical Guide to Effective Complaining

How to Diagnose Operational Issues by Feeling the Pain

AUTHOR

Michele Rochon-Wood

Over the course of my career, I've noticed something about technical consulting firms. When a team starts struggling, no matter what the reason, the conversation sounds remarkably similar.

People say they're drowning. Project managers don't have enough time. People don’t follow the process. We need somebody to coordinate this. We need a business developer. We need an administrator. Eventually, somebody says a sentence I've heard frequently:

"We need to hire someone."

When Capacity Isn't the Problem

Sometimes they're right, but not always. One of the reasons I find this fascinating is because department managers in engineering, architecture, environmental consulting, and construction are extraordinarily gifted at identifying capacity problems.

Every day they're balancing schedules, budgets, utilization targets, deadlines, staffing levels, client expectations, and technical delivery. Whether they realize it or not, they're constantly evaluating one fundamental equation: how much work needs to be done, and how many person hours are available to do it?

The challenge is that not every organizational problem is a capacity problem. From a distance, many problems look exactly the same but have different root causes.

Poor communication can look like a capacity problem. Disorganized onboarding can look like a capacity problem. Missing templates, knowledge hoarding, and chaotic project management systems look like a capacity problem. The pain is usually identical: people feel overwhelmed and frustrated.

The Business Developer Who Couldn't Fix It

Years ago, I was hired as a business developer and proposal manager for a consulting firm. During the interview process, I made a mistake that I have never repeated. I didn't ask enough questions about the team I would be developing business for.

Within my first few weeks, I realized something important. The firm didn't have a business development problem. They had an organization chart problem.

If you looked at the organization chart, it appeared like it had been used for target practice. Critical capabilities were missing. Stacked against the org charts in competing proposals, this one was insufficient – I knew because I’d worked at those firms.

The clients also said as much when we interviewed them during debriefs. We didn’t have the minimum required to be considered for the projects we were pursuing. The people who hired me weren't careless. They were trying to create growth and solve very real frustrations.

At the time they were delivering small, unglamorous projects with limited growth potential and trying to find a way out of that cycle. They felt the pain - they just misdiagnosed the cause. The assumption was that a business developer would generate the growth needed to fix everything else.

I found myself underutilized almost immediately. We no-go’d a lot of RFPs because we couldn’t scrape together the minimum requirements. The organization had correctly identified the pain – low proposal win rates. They had incorrectly diagnosed the cause.

I spent the time writing white papers about growth strategies for firms facing situations like the one we were experiencing. That’s how I roll. I solve problems hypothetically and write about them – it was therapeutic at the time given what I was faced with. One of those papers was published and eventually found its way to senior leadership. It received very positive feedback.

My proposed solution was to continue doing the unglamorous work. Get as much of it as you can. Then suck the marrow out of each project. Make the team you have into crack business developers. Get them out there on site, talking to people, asking questions. I even suggested swallowing our pride and teaming with competitors.

The objective is to build credibility with what you have. Eventually you’d be able to recruit more people. This would produce slower growth, but growth none the same. Submitting losing proposals would not.

The irony was that leadership appreciated the ideas in the white paper. But the underlying conditions that created the problem remained. They continued pursuing work they couldn’t compete on, demanding that I make the proposal more persuasive. We continued losing.

The diagnosis had been off from the beginning, so the solution never had much chance of succeeding. That experience taught me something. Some organizational frustrations originate somewhere other than capacity.

Turning Complaints Into Data

Organizations might be hiring people to solve symptoms instead of causes. The new hire absorbs some of the pain. Everyone feels relief for a little while. When leadership hears complaints they can say, "We hired someone," and the complaints stop. But six months later, the complaints return.

That realization, that the “inciting incident” in this story was probably complaints, eventually led me to create one of the most powerful diagnostic exercises on Twennie. I call it A Practical Guide to Effective Complaining. Complaints are pain points in the raw. They are the first way that pain is expressed – but complaining may be frowned upon and discouraged, so people self-edit and the impetus isn’t captured. We might not realize that complaints are organizational data.

So…yes, the exercise I designed is built around encouraging people to complain. Some leaders spend years trying to shut down complaining – they do it as a cultural measure, because complaining is thought of as unproductive. It can be, especially if it is excessive.

Under the right conditions, complaining can be like any other organizational data - unproductive until you use it. In this case, I flipped the cultural script and asked people to do more of it. In a controlled way.

Why Root Cause Analysis Matters

Something interesting happens at this stage. Many complaints fit multiple categories simultaneously. Consider a complaint common in proposal teams:

"Every proposal starts with two hours of detective work trying to find historical project information."

At first glance, it sounds like a capacity problem. People are wasting time. Therefore, we need more people. But maybe the real issue is information management. Or knowledge transfer, accountability, technology, process design. Or some combination of all five.

The complaint belongs in multiple categories simultaneously, which is exactly why organizational problems are misdiagnosed.

The most valuable part of the exercise comes next: root cause analysis. This is where many organizations inadvertently skip a step. They hear a complaint. They feel the pain. Then they jump directly to a solution.

Someone says they're overwhelmed; they're drowning. Someone says nobody has enough time. Before long, somebody says, "We need another person."

Maybe you do. But that's a solution. You haven't identified the root cause yet. The exercise deliberately forces participants to slow down and ask a different question: Why?

Suppose the complaint is that deadlines are being missed. That sounds serious, but it isn't a root cause. It's evidence. The real question is why deadlines are being missed.

Is it because project plans are unrealistic? Is it because priorities change? Is it because information arrives late? The goal isn't to immediately identify the correct answer. The goal is to generate possibilities before jumping to solutions.

One of the rules of the exercise is that participants generate at least three possible root causes for every complaint. The first root cause is often the most obvious. The second is usually more thoughtful. The third is where things start getting interesting.

This is when the complaint – the data – starts generating real strategic thought. For example, imagine the complaint is, "We spend too much time looking for information."

Why?

Because nobody knows where things are stored.

Why?

Because everyone stores files differently.

Why?

Because no standard exists, or they are not following it.

Now we're getting somewhere.

Notice how different the final explanation is from the original complaint. The complaint described wasted time. The root cause may actually be the absence of a standard operating procedure. Hiring another person might reduce the pain temporarily, but the underlying problem would still exist.

The Real Purpose of the Exercise

One of my favorite questions in the exercise is this:

"If I hired someone tomorrow, what part of this problem would remain unsolved?"

That question changes conversations. Because sometimes the answer is: most of it. The purpose of the exercise isn't to stop organizations from hiring. Sometimes the correct diagnosis really is capacity, and an overhead employee is the answer.

Sometimes you genuinely need a business developer, administrator, or project manager.

I've used variations of this flipped-script approach throughout my career because it consistently produces extraordinary results. People are taken aback when encouraged to do the opposite of what they’ve been told.

This signals the brain that the technique is different and therefore might have a chance at solving persistent problems that never seem to go away.

When they read, Operational Problems and Proposed Solutions, they expect a brainstorming session, a workshop and a lot of notetaking, extracting blood from stones and all that. They expect another lengthy meeting where shaky solutions only emerge after hours of awkward silences.

What they get with A Practical Guide to Effective Complaining is an engaging exercise that produces exactly what they were trying to do all along.