TL;DR, Growing engineering organizations get trapped in the “inner loop” — high-velocity execution that slowly drifts from strategic intent. An external consultant’s value isn’t superior knowledge; it’s lower latency to the truth. This post explores why speaking up is an act of service, not arrogance, and how the “outsider’s mirror” helps teams move from reactive execution to intentional alignment.

Introduction

There’s a specific kind of silence I used to keep.

In my earlier years as a consultant and architect, I often sat in rooms watching a project drift toward a bottleneck. A circular dependency quietly compounding. A team’s cognitive load creeping toward the red line. A platform that had outgrown its own architecture. I saw these things clearly — and I stayed quiet.

I didn’t want to be condescending or “looking down from above”, acting as if you know better than the engineers who are committing code every single day. I thought my restraint was humility.

It took me years, and more than a few broken pipelines that didn’t have to break, to realize I was wrong. Staying silent isn’t being polite. It’s being noncooperative.

When You’re Inside the Jar, You Can’t Read the Label

As an organization scales, it enters a state of high-velocity Doing. You’re shipping features, managing EKS clusters, running sprints, and hitting quarterly KPIs. The inner loop is loud and all-consuming.

When you’re deep in the inner loop, you focus on the individual pods, not the cluster’s health. You focus on the merge request, not the health of the delivery lifecycle. This is the “inside the jar” effect: when you are the one writing the logic, you are often the last person to see the systemic flaw.

I’ve worked with teams carrying years of legitimate technical debt — not because they didn’t know it was there, but because they were moving too fast to stop the line. The architecture that served them at 5 engineers starts to buckle at 50. The Terraform monorepo that shipped fast in year one becomes a cognitive bottleneck in year three. Nobody made a bad decision. The context just changed, and the organization was too close to the gears to notice the direction of the machine.

“The team isn’t failing. They’re just reading from inside the jar.”

An external consultant provides value not because we have superior technical knowledge — often the engineers I work with are sharper than I am in their specific domain. We provide value because we have lower latency to the truth. We aren’t tethered to the legacy decisions or the internal politics of why that tool was chosen three years ago. We walk in with fresh eyes and pattern recognition built across many organizations.

The Gap Between Doing and Being

Every company I’ve worked with that hits a growth plateau has the same underlying pattern: they’ve mastered the Doing but lost track of the Being.

Doing is the execution layer. It’s measurable, visible, and generates short-term feedback. Ship the feature. Pass the pipeline. Hit the SLA.

Being is the identity layer. It’s who the company is becoming: the platform they’re building, the engineering culture they’re cultivating, the technical decisions that will still matter in five years.

Doing + Being = Dobeing meaning to do you being

The tragedy is that the Doing, left unchecked, quietly erodes the Being. Not through bad intent — through pure momentum. Teams automate their chaos instead of their clarity. They scale processes that should have been redesigned. They build for where they were, not where they’re going.

This is where the outside-in view becomes structurally necessary. Not as a luxury, and definitely not as an ego exercise. As a diagnostic tool.

Think of it like k8sGPT running against your cluster: it doesn’t tell you anything the system doesn’t already know. It surfaces what the system can’t see about itself. The consultant is that diagnostic layer — but for the organization or team.

From Judgment to Collaborative Inquiry

The fear of sounding condescending usually comes from a mistaken mental model: the idea that a consultant arrives with “The Truth” and hands it down. That’s not consulting. That’s preaching, And it rarely works.

Real thought leadership in consulting is about Collaborative Inquiry, not dictatorship.

I learned to trade declarative statements for precise questions:

Let’s describe a few scenarios:

1. Instead of… ”Your architecture is inefficient”, Try… ”I’ve noticed a pattern here that often leads to developer cognitive load — is the team feeling that friction?”
2. Instead of… “You’re too focused on execution.”, Try … “It’s impressive how much this team ships. But what mechanisms do you have to make sure that all that is accomplished expresses the business goals you want to meet?”
3. Instead of… “This deployment process is broken., Try … “Walk me through what a typical Thursday deployment looks like — I want to understand the pressure points from your side.”

Most of the time, the team already knows where the bodies are buried. They know which service is the load-bearing mess nobody wants to touch. They know why the CI/CD pipeline has that one fragile step everyone works around. They just haven’t had the space to voice it officially.

By asking the tough questions, I’m not bringing new information. I’m acting as a circuit breaker — legitimizing the intuition the team already has, and creating the space for an honest conversation that the internal hierarchy sometimes can’t hold.

Why I Finally Stopped Being Quiet

This realization didn’t come from a management book. It came from watching a project I worked on nearly fail — not because the engineers were wrong, but because I had seen the architectural risk coming and said nothing. I didn’t want to overstep. I told myself it wasn’t my call.

It was absolutely my call to speak up, That’s what I was there for.

My clients weren’t paying for more hands on keyboards. They were paying for a set of eyes that weren’t attached to the organizational nervous system. If I spotted a misconfiguration in the organization’s direction and stayed quiet, I was just a very expensive internal hire with less context.

I think about it the way I think about kubectl describe on a crashlooping pod. The information is right there. The pod is trying to tell you something. The only failure mode is choosing not to look.

To my fellow consultants who still feel that shyness I used to carry: your silence is not humility. The organization brought you in specifically because you are standing outside the jar. If you don’t read the label, nobody will.

The Hard Questions Worth Asking (as a DevOps/Platform Engineer)

When I engage with a scaling organization, these are the questions I eventually bring to the table — not in the first week, but once I’ve earned enough context and trust to ask them meaningfully:

1. Does your “Infrastructure as Code” serve your mission, or are you automating your chaos?
2. If your three most senior engineers left tomorrow, how long would it take for the platform to degrade?
3. Are you building for where you are, or where you’re going?
4. What decisions made sense at 10 engineers that no one has revisited at 100?
5. What does your team already know needs to change but hasn’t had permission to say out loud?

None of these questions require external genius. They require the permission that comes with distance.

Conclusion

If a company is to evolve from a fast-moving startup into a sustainable engineering organization — or what I think of as an Agentic SDLC powerhouse — it must move from reactive execution to intentional alignment.

That shift requires someone to stand outside the jar !

Not to look down. Not to lecture. But to reflect back, clearly and without the distortion of internal politics, what the organization is becoming versus what it intended to be.

True humility in consulting isn’t staying silent. It’s realizing that the health of the system is more important than your own comfort. Speaking up isn’t about being the smartest architect in the room. It’s about making sure the Control Plane is actually in control. Your voice is a diagnostic tool. Use it.

Would love to hear your thoughts in the subject, feel free to reach out — you know where to find me ;)

Your sincerely, HP

Resources

• Dobeing — I’ve been influenced by this concept in the past 10 years at Tikal through a dear colleague Nir Golan.
• Team Topologies — Matthew Skelton & Manuel Pais — The foundational framework for thinking about organizational design and cognitive load
• Conways law — a great inside look into communication structure of organizations and the systems they design.
• The Five Dysfunctions of a Team — Patrick Lencioni — Classic on why teams avoid the hard conversations
• The engineering culture at spotify