How did you communicate the need for a major change to the team?

Question

Anonymous · Accepted Answer

One example was when I had to communicate a significant change to a
manufacturing project that affected the equipment, process, and project
timeline.

Before communicating the change, I first made sure I understood the technical
and business impact. I gathered the data, identified the root cause, compared
the available options, and quantified the impact on cost, cycle time, quality,
safety, and timing.

Then I communicated it to the team in a structured way. I started with why the
change was necessary, rather than simply telling people what they needed to do
differently. I explained the problem using facts and data, showed what would
happen if we did nothing, and then presented the recommended solution.

I also made sure the team understood what was changing, what was staying the
same, who was responsible for each action, and what the timeline was. I
encouraged questions and concerns, especially from manufacturing, quality,
controls, suppliers, and the operators who would ultimately be working with the
process.

For people who were directly impacted, I followed up individually to make sure
there were no unresolved concerns. I also documented the decision, action items,
owners, and deadlines so that everyone was working from the same information.

The result was that we were able to implement the change with much less
resistance and keep the project moving forward without compromising quality or
the overall launch objective.

My approach is: explain the why, support it with data, involve the people
affected, clearly define the actions, and then follow up until the change is
fully implemented.

Anonymous · Answer

💬 Question: How did you communicate the need for a major change to the team?

---

⭐️ Answer:

Yeah, that's a good one. So at CBRE, when we were scaling Ellis AI from 100K
documents to 1M+ documents, we realized our existing data pipeline and retrieval
strategy wasn't going to cut it. The latency was creeping up, and we were
starting to see quality issues in our search results.

I knew this was going to require a significant shift in how we indexed,
validated, and ranked documents — basically a complete infrastructure rethink.
And that meant asking Engineering to deprioritize some feature work they were
already committed to.

Here's how I approached it. First, I didn't just say "we need to change." I
showed the data. I pulled adoption metrics, latency trends, and user feedback
showing where we were losing people. I mapped out the specific workflows where
the system was breaking down. That gave everyone a shared understanding of the
problem — not my opinion, but the reality.

Then I brought Engineering, Data, and the customer success team into a working
session. I asked them what they were seeing on the ground. The engineers had
already spotted the bottlenecks. Customer success had heard the complaints. So
when I proposed the solution, it didn't feel like it came out of nowhere — it
felt like we were solving a problem we all saw.

The key was being transparent about the trade-off. I said, "If we do this, we're
pushing back these three features by a quarter. Here's why it's worth it — we
unlock 1M documents, we cut latency by 40%, and we unblock three new customer
use cases." I gave them the business case, not just the technical case.

We got alignment, shipped it, and it worked. But the lesson for me was: don't
announce change from the top down. Build the case collaboratively, show the
data, and let the team feel ownership of the decision.

How did you communicate the need for a major change to the team?

Practice this question with AI

Go Premium

Community Answers

Unlock Full Access

Unlock Full Access

Practice More Questions