Skip to main content
Back to Insights

Operations

How to Think Like an Operations Manager Before You Have the Title

By Hellen Ouma 6 min read Operations
Open notebook and pen beside a mug and an open laptop

You do not need an operations manager title to start thinking operationally.

Operational thinking shows up in the questions you ask when work becomes messy. Why does the same problem keep returning? Where does ownership become unclear? Which handoff creates delays? What information does the team keep asking for? Which decisions depend on one person when they should not?

Those questions move you beyond completing the work in front of you. They help you improve the way the work happens.

Formal operations roles vary widely, but the common thread is responsibility for how people, processes, resources, and priorities come together. You can start building that mindset long before the title catches up.

Look for patterns, not isolated problems

A task-focused response solves what is urgent today. An operational response also asks whether the same issue is likely to happen again.

A customer did not receive an update. You can send the update and close the issue.

Or you can look one step further. Was there a clear owner for the follow-up? Was the commitment recorded somewhere visible? Did the handoff between teams include the information the customer needed? Is this the first time the problem has happened?

The second approach helps you see recurring friction.

This does not require turning every mistake into a large improvement project. Start by noticing repetition. If the same clarification, delay, customer complaint, scheduling conflict, or missing document keeps appearing, there is probably a process worth examining.

Trace the work from start to finish

Many operational problems become visible at the handoffs.

A sales process may look organised until the contract is signed and nobody is sure who starts onboarding. A meeting may run well but produce little progress because decisions are never assigned. A customer request may be answered quickly but still remain unresolved because the follow-up lives in someone’s inbox.

When a process feels unreliable, map what actually happens.

Ask:

  • What starts the work?
  • Who owns the next step?
  • What information do they need?
  • Where does the work move after that?
  • What decisions can they make themselves?
  • What should trigger escalation?
  • How do we know the process is complete?

You do not need specialised software to do this. A simple written sequence is often enough to expose missing ownership, unnecessary approvals, duplicated work, or steps that depend on memory.

If the workflow needs to be repeated consistently, turn it into a practical standard operating procedure.

Make ownership visible

Work slows down when everyone is involved but nobody is clearly responsible.

Operational thinking separates participation from ownership. Several people may contribute to a project, but one person should still know whether the work is moving, what is blocked, and what happens next.

The same principle applies to decisions.

If every routine exception has to return to a founder or manager, the process may have an ownership problem rather than a staffing problem. Clear decision boundaries allow people to act while preserving escalation for situations that genuinely need senior judgement.

Before adding another tracker or meeting, clarify who owns the outcome.

Improve the system before adding complexity

A common response to operational friction is to add something: another meeting, another approval step, another tool, another person, another spreadsheet.

Sometimes that is necessary. Often, the existing process simply needs clearer ownership or fewer steps.

Before creating something new, ask what is already happening and where it breaks.

Could two updates become one? Could a recurring approval be replaced by a clear threshold? Could information be captured once instead of requested repeatedly? Could a weekly meeting become a short written update with a decision log?

Good operations reduce avoidable effort.

Use documentation as working infrastructure

Documentation becomes useful when it helps someone act.

A process guide should answer the questions people actually have. A tracker should make the next action obvious. A meeting note should show what was decided, who owns it, and when it is due.

Documents that exist only to look organised create maintenance without creating much value.

Pay attention to the places where people repeatedly ask for clarification. Those questions tell you what the operating system is failing to make visible.

Build feedback into the process

A process can work perfectly on paper and still fail in practice.

The people doing the work usually see problems first. A template may ask for information nobody uses. An approval may create a delay without reducing meaningful risk. A customer handoff may require context that the receiving team never gets.

Operational thinking includes checking whether the process still works.

When something changes, update the system around it. New tools, team members, services, customer expectations, and responsibilities can all make an old workflow less useful.

The goal is a process the team can rely on today, not a document that records how work used to happen.

Measure what helps you make a decision

You do not need a dashboard for everything.

Start with the question you are trying to answer. Are customer handoffs becoming more reliable? Are projects getting stuck at the same stage? Are routine questions returning to the founder? Are deadlines being missed because ownership is unclear?

Track information that helps you see whether the problem is improving.

A simple measure can be enough: overdue actions, unresolved handoffs, repeated escalations, turnaround time, or the number of exceptions that require senior intervention.

The measure should help you decide what to change next.

Think one level above the task

The most useful shift is learning to see the system around the work.

When you complete a task, notice what made it easy or difficult. When a problem appears, ask where it entered the process. When a team member asks a recurring question, look for the missing instruction or decision boundary. When a customer experience breaks down, trace the internal handoffs behind it.

That is operational thinking in practice.

The title may come later. The mindset starts when you stop treating every problem as a one-off and begin making the work easier to run the next time.

If you are building that kind of operating discipline around a founder or growing team, see how I help.

Sources

© Hellen Ouma. This article was originally published on hellenouma.com. You may quote brief excerpts with attribution and a link to the original article.

Related content