Over the past few months, I’ve been doing a lot of personal reflecting on my role as an engineering manager, particularly around how I set expectations for my team and how we handle the day-to-day friction that comes with operating in a complex organization.

Looking back, I realized I had fallen into a subtle trap.

I wanted my team to maintain a high level of execution on our core objectives, but I was also allowing us to absorb ad-hoc, cross-functional issues that came our way. We were being helpful. We were solving problems. We were keeping things moving.

But over time, that helpfulness started becoming something less sustainable.

I saw a familiar pattern playing out:

1. My team would step in to help with an urgent issue outside our core domain.

2. We would help again because we had already built up the context to handle it.

3. Eventually, partner teams started coming directly to us with similar issues.

Before long, what started as a temporary favor had become an unofficial operating model.

My team wasn’t necessarily the natural owner of the problem. We had simply become remarkably good at absorbing it.

Reflecting on My Own Expectations

Earlier in my management journey, I probably would have viewed this as a positive thing.

My engineers were stepping up. They were being responsive. They were helping other teams. They were getting difficult problems across the finish line.

But during this period of reflection, I started looking at it differently.

If I continually reward the people who jump in and catch whatever falls between the cracks, I can unintentionally create a system where those same people become the safety net for everyone else.

The broader system learns:

Someone will catch it.

And if that keeps happening, the underlying ownership problem never really gets addressed.

That realization forced me to look at my own role in it.

I had to acknowledge that I was expecting a lot from my team without fully accounting for the cost of context switching, operational interruptions, and work that wasn’t part of their core responsibilities.

Being helpful has a cost.

Every interruption consumes some amount of attention. Every unexpected request creates context switching. Every problem a team absorbs is capacity that can’t be spent somewhere else.

And when a team’s capacity is already largely consumed keeping the operation running, there isn’t much room left to improve the operation.

That was an important realization for me.

Resetting the Baseline

I had to reset my own expectations.

I couldn’t continue adding improvement goals on top of a team that was already operating at full capacity without changing something else.

If we wanted to improve how we worked, we had to create the space to do it.

That meant taking a step back and getting clearer about our core domain boundaries.

What do we own?

What don’t we own?

Where does our responsibility end?

Where should another team take over?

Those questions aren’t about building walls between teams. Quite the opposite. Clear boundaries actually make collaboration easier because everyone understands where they fit.

Our objectives can provide directional alignment, but objectives alone don’t protect a team’s capacity.

Clarity around ownership does.

Learning to Focus on the Low-Hanging Fruit

Another thing I’ve been reflecting on is how I approach improvement itself.

Earlier in my management career, I sometimes thought operational improvement required sweeping transformations or major structural changes.

I’ve come to see it differently.

Sometimes the biggest improvement isn’t the biggest project.

A perspective my director shared with me helped reinforce this: operational improvements don’t always have to be radical to be effective.

In fact, trying to transform everything at once can create another problem.

If a team is already stretched, asking it to completely redesign how it works can become one more source of pressure.

So I’ve started paying more attention to the low-hanging fruit.

Small changes that remove recurring friction.

Small improvements that eliminate unnecessary manual work.

Small adjustments that make ownership clearer.

Small changes that reduce interruptions.

Small process improvements that prevent the same question or problem from coming back again and again.

Individually, none of these changes may look revolutionary.

But that’s not really the point.

If you remove enough small sources of friction, you eventually change the experience of doing the work.

And sometimes that’s where meaningful transformation starts.

Protecting Capacity Is Part of the Job

This has also changed how I think about protecting my team’s capacity.

Capacity isn’t just a planning number.

It’s attention.

It’s context.

It’s cognitive energy.

It’s the ability to stop reacting long enough to think.

When engineers are constantly responding to interruptions and fighting operational fires, they may still be incredibly productive, but they don’t necessarily have the space to think about architecture, reliability, automation, or how to make the system better.

That’s something I need to account for as a manager.

My job isn’t simply to give my team more things to accomplish.

It’s also to make sure we’re not spending our limited capacity on work that doesn’t create enough value.

Sometimes that means asking whether a process can be simplified.

Sometimes it means automating something.

Sometimes it means clarifying an ownership boundary.

Sometimes it means redirecting a recurring problem to the team that is actually in a position to solve the underlying cause.

And sometimes it means saying:

Not everything that needs to be done needs to be done by us.

That last one can be surprisingly difficult.

The Balance Between Running and Improving

There’s another tension I’ve become much more conscious of.

Every organization has to maintain the current operation while also improving it.

You can’t stop today’s work because you’re planning for tomorrow.

But you also can’t spend all of your capacity dealing with today’s problems and expect tomorrow to look different.

I’ve started thinking about this as a balance between running the operation and transforming it.

And transformation requires tradeoffs.

If a team is genuinely at capacity, we can’t simply keep adding improvement work and assume we’ll somehow absorb it.

Something has to change.

We have to eliminate work.

Automate work.

Change ownership.

Reduce scope.

Add capacity.

Or decide what gets deprioritized.

That isn’t a failure of execution.

It’s management.

Pretending there is unlimited capacity doesn’t make the work disappear. It just pushes the cost somewhere else usually onto the people doing the work.

What I’m Trying to Change

I’m not trying to build a team that says no to everything outside its boundaries.

That’s not collaboration.

I want my team to be helpful. I want them to work across organizational boundaries. I want them to solve difficult problems.

But there’s a difference between helping solve a problem and becoming the permanent owner of a problem that isn’t yours.

That’s the distinction I’m learning to pay more attention to.

I’m also trying to move away from measuring success purely by how much work gets completed.

Sometimes the better outcome is removing work altogether.

Sometimes success is preventing the same problem from returning.

Sometimes success is making ownership so clear that a problem no longer needs to be escalated through three different teams.

And sometimes success is giving an engineer the uninterrupted time to work on something important because we eliminated five smaller distractions.

Those improvements may not always show up as a dramatic project announcement.

But they matter.

A Different Definition of Leadership

This reflection has changed something fundamental in how I think about my role.

I don’t want to be the manager whose team is known for catching everything.

I want to be the manager who helps build a system where fewer things need to be caught in the first place.

That means clarifying ownership.

It means challenging processes that exist simply because they’ve always existed.

It means focusing on outcomes rather than activity.

It means reducing unnecessary work.

It means protecting the team’s capacity to think and improve.

And sometimes, it means being willing to say that a problem belongs somewhere else not to avoid responsibility, but to put responsibility where it can actually lead to a solution.

I’m still learning how to do all of this well.

That’s probably the most important part of the reflection.

Management isn’t about finding a perfect operating model and implementing it once.

It’s about continuously looking at how the organization is working, noticing where the system is creating unnecessary friction, and then reflecting and resetting.

For me, the principle I’m taking forward is simple:

You don’t fix a complex organization by personally absorbing all of its problems. You change the system so problems get owned by the people who can actually solve them.

And perhaps just as importantly:

Protecting your team’s capacity isn’t about doing less. It’s about making sure their energy is spent on the work that matters.

That’s the kind of environment I’m trying to build, one where my team can be helpful without becoming the safety net for every problem, where accountability is clear without becoming blame, and where we have enough space to do more than simply keep the operation running.

We should have enough space to make it better.

Sami Joueidi holds a Master’s degree in Electrical Engineering and brings over 15 years of experience leading AI-driven transformations across startups and enterprises. A seasoned technology leader, Sami has led customer adoption programs, cross-functional engineering teams, and go-to-market strategies that deliver real business impact.

He’s passionate about turning complex ideas into practical solutions, and about helping teams bridge the gap between innovation and execution. Whether architecting scalable systems or demystifying AI concepts, Sami brings a blend of strategic thinking and hands-on problem-solving to every challenge. © Sami Joueidi and www.cafesami.com, 2025. Feel free to share excerpts with proper credit and a link back to the original post.