Engineering Managers Hold the Key to Effective Team Collaboration

Some people love daily standup meetings.

Others hate them with a passion.

I love them.

And if you don't, it might be because you're managing them wrong — or worse, the wrong person is running them.

For years, I've watched teams struggle with standups that feel like a waste of time. The problem isn't the meeting itself; it's how it's approached.

As someone who's built and scaled multiple tech companies, I've learned that standups can be powerful drivers of collaboration and accountability... when led by the right person.

The Big Myth: Standups Are Just Status Updates

First, let's address a common misconception:

Daily standups are NOT for status reports.

If that's all you're using them for, you might as well cancel the meeting and have everyone post updates in Slack or update their Jira tickets.

The real purpose of standups is far more valuable. They should drive:

• Collaboration between team members

• Quick identification and removal of blockers

• Knowledge sharing and team alignment

• Accountability without micromanagement

But achieving these goals depends heavily on who's running the show.

Why Engineering Managers Should Lead Your Standups

After trying different approaches across multiple companies, I've become convinced that engineering managers are uniquely positioned to make standups work.

Here's why:

1. They Can Read Between the Lines

An engineering manager doesn't just listen to what's being said - they notice HOW it's being said.

When a developer gives an update, an engineering manager can detect:

• Hesitation in their voice

• Lack of confidence in their approach

• Frustration with a blocker they're reluctant to admit

• Confusion about requirements

These subtle cues often reveal problems before they become project-killers.

A good engineering manager asks: "Are you feeling confident about this approach?" or "You sound hesitant - do you need help thinking through this solution?"

2. They Understand Technical Risk

Project managers focus on timeline risk. Engineering managers understand technical risk.

When a developer says, "I'm done with the authentication feature," a project manager checks the box and moves on.

An engineering manager thinks about:

• Has this been tested against edge cases?

• How will this perform at scale?

• Are there security implications we haven't considered?

• Does the implementation match our architectural standards?

This deeper understanding prevents the "it works on my machine" syndrome that can lead to production nightmares later.

3. They Can Solve Technical Blockers Immediately

When a developer hits a roadblock, timing is everything.

If they mention a blocker in standup, an engineering manager can:

• Provide technical guidance on the spot

• Connect them with another team member who solved a similar problem

• Make an immediate architectural decision to unblock progress

• Allocate additional resources if needed

A project manager or product owner would likely need to: "Let me check with the technical team and get back to you" - adding hours or days of delay.

4. They Foster Psychological Safety

Developers, especially junior ones, often hesitate to admit they're stuck.

Engineering managers who understand the technical challenges create an environment where it's safe to say:

• "I'm confused about this requirement"

• "I'm not sure about the best approach here"

• "I underestimated this task"

When developers feel safe being vulnerable, problems get solved faster, and the entire team learns.

When Product Owners or Project Managers Run Standups

Let me contrast this with what typically happens when product owners or project managers run these meetings:

Focus on timeline, not technical substance

They ask about status and dates but lack the technical context to understand the nuances.

Efficiency over collaboration

They often rush through the meeting, treating it as a status checkpoint rather than a collaboration opportunity.

Missing technical discussions

They may shut down valuable technical conversations because they don't see their immediate relevance.

Limited ability to remove blockers

They can note blockers but often can't resolve them without bringing in technical leadership.

This doesn't mean product owners and project managers aren't valuable - they absolutely are! But their strengths lie elsewhere, not in facilitating the technical collaboration that makes standups truly effective.

The Founder Advantage in Early Startups

In early-stage startups, technical founders have a unique superpower when running standups. They understand both the product vision AND the technical implementation.

As the founder of multiple tech companies, I've experienced this firsthand. When I run standups, I can:

• Answer any product question immediately

• Make architectural decisions on the spot

• Provide context about why we're building certain features

• Set priorities based on both business and technical considerations

This dual perspective is why technical founders can drive development at incredible speeds.

I learned this lesson the hard way at one of my previous startups. When I handed standups over to our product owner (who was excellent at his job), I became a passive participant. I'd join the call but wasn't as engaged, and we lost that founder advantage of instant decision-making and direction.

Can You Run Effective Standups Without Engineering Managers?

Absolutely, but it depends on your team.

If you have senior developers who take ownership, communicate openly, and have developed psychological safety with each other, they can run effective standups themselves.

But this requires:

• Developers who are comfortable being vulnerable with peers

• Strong communication skills across the team

• A culture where asking for help is encouraged

• Senior engineers who think beyond their individual tasks

This approach rarely works with junior developers, who are more likely to stay quiet about challenges they're facing rather than risk appearing incompetent.

The Bottom Line: Standups Are About Collaboration, Not Status

Regardless of who runs your standups, remember this: if you're using them just for status updates, you're missing the point.

The real value comes from the moments when:

• A developer realizes they've been working on the wrong thing

• Someone offers help with a problem they solved last week

• The team spots a dependency they hadn't considered

• A blocker gets removed in real time

These collaborative moments drive productivity far more than simply knowing what everyone is working on.

So if your standups feel like a waste of time, don't blame the meeting format. Look at who's running them and how they're being approached.