Address
0162, 49a Chavchavadze avenue, Tbilisi Georgia 

Work Hours
Monday to Friday: 10AM - 7PM

Just Talk to the Dev

Cutting the Middle in Engineering Teams

When do we lose the most time in software development?

Not during coding. Not during testing. Not even during debugging.
It’s during the communication relay races — when instead of devs talking directly, we involve an endless loop of middlemen.

Let’s say I need to implement Feature A.
I ask my manager for documentation.
My manager talks to the other team’s manager.
That manager talks to a dev on their team.
Eventually, I get the doc.

But surprise — it’s outdated.

So I ask a follow-up question.
The cycle repeats.
A day (or two) goes by. I finally get an answer.
Guess who knew it the whole time?
The other dev. The one who built it.

This is what kills speed and clarity.

The people who actually know the details are devs.
And we’re often just a message away from each other.
So why not just talk?

What Are We Optimizing For?

If we’re trying to ship good features fast — and do it with confidence — we should optimize for clear, accurate, real-time information. Not chain-of-command rituals.

Middle managers aren’t bad. But they shouldn’t be message brokers. Their job is to unblock, not become the bottleneck.

Direct Communication is the Cheat Code

Cross-team feature? Talk dev-to-dev.
Got a question about an API? Message the person who built it.
Need clarity on a contract or flow? Ping the engineer who owns it.

Less ceremony. More progress.

The best teams I’ve seen?
They cut through the noise.
They know that behind every great product is a bunch of devs who trusted each other enough to talk directly.

A Simple Fix That Works: 3-Way Chats

Here’s something I’ve implemented on my team that works really well: 3-way chats.

When a dev on my team needs to work with someone from another team, I don’t act as a middleman. Instead, I ask them to create a group chat that includes both devs and me.

This setup hits a sweet spot:

  • Devs talk directly — fast and clean.
  • I stay in the loop passively.
  • I can jump in only if things go off the rails or clarity is needed.

It’s not about control — it’s about support.
90% of the time, I say nothing. But when I do need to step in, I’m already in the thread. No backtracking.

This approach has made a massive difference in speed, accuracy, and mutual respect between teams.

Great software doesn’t come from long chains of command — it comes from humans solving problems together.

Schedule a call