What I Look For in the First Week When Auditing a Team's Delivery Process
Every engagement I've started — whether as an employee joining a new company or as a consultant brought in to fix something specific — begins the same way: a week of observation before any recommendations.
This isn't caution. It's method. The presenting problem is almost never the actual problem, and the proposed solution that a team arrives with is almost always a solution to a symptom rather than the root cause.
Here's what I'm looking for in that first week.
1. How Does Work Actually Enter the System?
Not how it's supposed to enter the system — how it actually does.
In a healthy team, there's a single intake path: a ticket is created, triaged, prioritized, and picked up when capacity allows. In practice, most teams have three or four informal intake channels running in parallel: the official one and the back channels that formed because the official one was too slow, too formal, or too unfamiliar.
The back channels are the interesting part. They tell you where the official process broke down and what people needed badly enough to route around it. At MoveUp, work arrived through Slack messages, email threads, verbal conversations on calls, and occasionally a ticket in the right system. Each back channel represented a stakeholder who had learned that the official path didn't reliably deliver results.
Fixing the intake isn't about eliminating the back channels — it's about making the official channel good enough that the back channels stop forming.
2. Where Does Work Slow Down or Disappear?
I track a few items through their full lifecycle in the first week. Not to measure velocity — to find the specific points where things stall.
Common failure patterns:
The review bottleneck. Work completes but sits waiting for approval from a specific person who is too busy to review promptly.
The dependency gap. A ticket can't move forward until something from another team is ready — and there's no mechanism for tracking or communicating that dependency.
The definition-of-done ambiguity. Work reaches "Done" and comes back because the stakeholder's definition and the engineer's definition were different.
The forgotten queue. Work that's been deprioritized but never formally closed or deferred — sitting in the backlog, taking up cognitive space, gradually becoming outdated.
Each of these has a different fix. Identifying which pattern is present before proposing a solution is the whole value of the observation week.
3. How Are Priorities Set, and Who Has the Authority?
Priority-setting in most teams is implicit and contested. Everyone has a theory of what the most important thing is, and those theories are usually correlated with whose work it would be.
What I'm looking for: Is there a single person or body with clear authority to set priorities? Is that authority exercised consistently? When competing priorities collide — and they always do — how is the collision resolved, and how long does the resolution take?
4. What Does the Team Complain About?
The informal conversations in the first week are often more diagnostic than the formal ones.
What engineers complain about in passing — "we're always context-switching," "stakeholders keep adding to the sprint," "we never have time to fix the real problems" — maps almost directly to the structural issues in the delivery process. They've lived with the dysfunction long enough to have accurate intuitions about where it comes from.
I take notes on these complaints without reacting to them in the moment. By the end of the week, the pattern is usually clear.
5. What's Not Being Measured?
The things a team can't measure are the things they can't improve.
In my first week at MoveUp, there was no measurement infrastructure at all — no ticket tracking, no response time data, no deployment frequency. The team had accurate intuitions about what was broken, but no data to validate those intuitions or track improvement.
The first operational data we had came from the systems I built after I arrived. That baseline — however rough — is the foundation of every meaningful process improvement that followed.
What Comes After the First Week
The first week produces a diagnosis, not a solution. The diagnosis shapes everything that follows: which practices to introduce first, which problems to address immediately versus over time, where the organizational resistance is likely to come from.
The teams I've seen implement process improvements most successfully are the ones where the PM spent enough time understanding the current state that the recommendations felt inevitable rather than imposed.
The first week is the investment that makes the difference.