You can only fix what you can see
What I look for in my first weeks with a new team: the slow, odd processes nobody questions any more, and how I pick which to fix first.
When you join an existing team as its manager, people tell you about the problems they already know about, like the slow deploy or the flaky test. Those are real, and you'll get to them.
The problems that cost the most are often the ones nobody mentions, because nobody sees them as problems any more: a manual step that takes an hour every Monday, or a rule about not touching a certain service on Fridays that no one can explain.
You can only fix what you can see. So in my first weeks with a team, I try to look before I change anything.
Why the biggest problems go unnoticed
A process that's odd or slow rarely starts that way. It usually began as a sensible fix for a problem that has since changed or gone away. Then the team adapts. The workarounds become the process, and the one person who remembers why the extra step exists stops mentioning it, because everyone else just follows along.
Nobody owns the whole flow either. Operations sees requests going in and Engineering sees tickets coming out, but the path in between belongs to no one.
When you're new, nothing looks normal yet. The team lost that view long ago, and you'll lose it within a few months, so use it early.
Ways to find them
Write things down
The most reliable way I know to find a broken process is to try to document it. Writing a runbook forces every step into the open, and the strange ones stand out, like a step that only works if you run it twice. When I joined the DSP Processing and DSP Reporting teams in May 2026, one of the first things I set up was a shared engineering space with architecture pages, runbooks and a list of the acronyms everyone used but nobody had written down.
Read the support tickets
Support requests show you where the system and its users disagree. Read a few months of them and look for the ones that keep coming back. A request that arrives every month with the same fix usually points to a missing feature.
Sit with the people who use what you build
Operations and Business colleagues often run the strangest workarounds, because they're the ones living with the gaps. Ask them to walk you through a routine task while they do it.
Follow one request end to end
Pick an ordinary request and trace it from the moment someone asks for it to the moment it's done. Count the handovers, and the places where someone copies data from one tool into another.
Follow a change from laptop to production
Do the same for code. Trace how a change gets from a developer's machine into production, and note every step that only works because someone remembers it.
In my first weeks with the DSP teams, I followed how a change gets from a developer's machine into the image we deploy. Some of our Python dependencies were installed straight from git without a pinned version. That meant the packages on a developer's laptop could differ from the ones in production, and rebuilding the same commit could produce a different image under the same tag. I wrote it up as a short decision record with three options: leave it as it is, add a lock file, or move to a new packaging tool. The team approved the lightest fix, a lock file checked in the build pipeline, so the same commit always builds the same environment.
Ask why without judging
"Why do we do it this way?" can sound like criticism. Make it clear you're asking to understand. Often the answer is "we had a good reason in 2021", and that's useful to know: the reason may be gone, or it may still matter.
Keep a list first
Everything you find goes on a list, with a note on what it costs the team. Resist fixing as you go. In your first weeks you don't yet know which oddities protect against something you haven't seen.
After a month or two, pick the few items that cost the most and are cheapest to change. Fix those visibly, with the people who live with them. Early wins also show the team that the strange things can change, and that raising them is worth it.
One of the first things I changed with the DSP teams was the daily stand-up. It used to be a walk through the whole Kanban board, every ticket, every day. Most of that time went on status that anyone could already see on the board. I replaced it with a shared page for each day, where everyone notes what they did yesterday, what they plan to do today and anything blocking them, plus a list of pull requests waiting for review. The stand-up itself now focuses on the blockers. As the team grew, the stand-up got shorter rather than longer.
Keeping the habit
The newcomer's eye fades. The goal is to leave behind a team that keeps spotting these things without you. A few habits help:
- Give the team an easy way to flag friction, and act on some of it so people keep raising it.
- Keep the documentation up to date, so a newcomer can question a process without first finding the one person who knows it.