There's a strong temptation, walking into a new operations role, to arrive with a plan. You were hired because you know how to run things, so it feels like the job starts on day one, ideally with a process improvement and a new tool by Friday.
It's the wrong instinct, and it's an expensive one. Every operational mess you walk into was once somebody's sensible decision, made in a context you know nothing about. Change it before you understand why it exists and you don't look decisive, you look like someone who didn't read the room. Worse, you use up the one thing you can't earn back quickly, which is the benefit of the doubt.
So here's what I actually do instead. It isn't glamorous. Most of it is asking questions and writing things down.
Days 1 to 10: follow the work, not the org chart
The first job is to understand how work actually moves through the business, which is almost never how the documentation says it moves.
I trace it end to end. How does work arrive? Who decides what gets done and in what order? What happens between "agreed" and "started", which is where most organisations quietly lose weeks? How does it get handed over, and who picks up the pieces afterwards? I want the real version, including the bit where someone messages a particular person directly because the official route is too slow.
The org chart tells you who reports to whom. Following the work tells you who things actually depend on, and those two diagrams are never the same. The gap between them is usually where the interesting problems live.
While I'm doing that, I'm looking for three specific things. Where work queues, because queues mean a bottleneck and bottlenecks are usually a person. Where work gets redone, because rework means a decision was made too late or with the wrong information. And where knowledge lives in someone's head rather than in a system, which I have opinions about, having once been that person myself.
Ask better questions than "how's it going?"
Most new starters ask questions that generate polite noise. "How are you finding things?" gets you "yeah, good, bit busy". Useless. A few questions that reliably get you something real:
"What's the thing everyone complains about that never gets fixed?" People love answering this, and the answer is usually the third or fourth item on the list of things you'd have prioritised on your own, which is the point.
"What do you do regularly that you think is a bit stupid?" This finds the processes that outlived their reason. Somebody built that step for a good reason in 2022 and the reason left the company in 2023.
"Who do you have to wait for?" Politely phrased, this maps every bottleneck in the business in about a week.
"What happened the last time something went really wrong?" This tells you how the organisation behaves under pressure, which is the only version of an organisation that matters.
And then the uncomfortable one, asked of the person who hired you: "what were you hoping I'd fix that you haven't said out loud?" There's almost always an answer, and it's better to hear it in week one than to infer it in month six.
Measure something before you change it
Somewhere in the first two weeks, I try to get a baseline for one or two things that matter. How long work takes from request to done. How often it comes back. How much is in progress at once.
It doesn't need to be sophisticated. Counting things in a spreadsheet is fine. What matters is having a number from before you arrived, because in three months somebody will ask whether your changes worked, and "it feels better" is a poor answer from an ops person. It also protects you from the opposite problem: changing something, having it get worse, and not noticing for a quarter.
Fix one thing early, and pick it carefully
Around week two or three, I want one visible improvement delivered. Not a transformation. One genuinely annoying thing, gone.
The choice matters more than the size. Pick something that irritates the team every week, not something that impresses the leadership team once. Fixing a report that takes someone two hours every Monday buys you more credibility than any strategy document you could write, because it demonstrates the thing people actually want to know about a new ops hire: are you here to make our lives better, or to produce slides about us?
It also functions as a test. How hard was it to change one small thing? How many people had to approve it? That's your first honest reading of how the organisation handles change, and it will tell you a great deal about how to sequence everything that comes next.
Write down what you notice, immediately
This is the part people skip and later regret. Your fresh eyes have a shelf life of about a month. Everything that looks odd to you now, the weird handover, the tolerated workaround, the meeting nobody can justify, will look normal by week six. You will acclimatise, because humans do.
So I keep a running note of everything that seems strange, and I don't act on any of it yet. Half of it will turn out to have a perfectly good explanation. The other half is your roadmap, and nobody else in the building can write that list, because they've all been there too long to see it.
What I don't do
Worth being explicit about the restraint, because it's most of the discipline.
I don't introduce a new tool. Nothing says "I've solved the wrong problem" quite like a new tool in month one. Tools are the answer to a process question you haven't asked yet.
I don't reorganise anyone or anything. You don't know who's carrying what yet.
I don't announce a strategy. A thirty-day plan presented on day two is an admission that you wrote it before you arrived.
And I don't criticise the previous incumbent, even when invited to, and you will be invited to. Everything that looks like negligence usually turns out to be a constraint you haven't discovered yet.
Day 30: one short document
The output at the end of the month is deliberately small: a couple of pages, shared with whoever hired me. What's working and should be left alone, which is a section people forget to include. What's fragile, with the risks named plainly. What I'd change, in what order, and roughly when. And the one thing I've already fixed, mentioned briefly and without a fanfare.
That document isn't for show. It's the agreement that lets the next sixty days happen, because now the changes coming aren't a new person's opinions. They're a shared understanding with evidence attached.
The first thirty days aren't for fixing things. They're for earning the right to fix things, which takes about thirty days, and considerably longer if you skip them.