When the Floor Stops Looking to You
I remember sitting with an operations head last year, a few weeks into a major system migration at a mid-sized logistics company. She was sharp, experienced, and had been leading that operation for several years before the transition began. Her team respected her deeply, her numbers were consistently strong, and she had every reason to feel confident walking into the implementation phase. But when I sat with her and mapped out how decisions were actually flowing during the transition, a very different picture emerged. Most of the day-to-day operational decisions were being routed through the project team. Escalations that should have landed on her desk were being absorbed by the implementation partner’s programme manager. Exceptions that her team leads had always handled within the operations function were now being resolved in project stand-up calls that she was not consistently present for. And over time, quietly but unmistakably, her team had started looking to the external implementation partner for direction on the floor rather than to her, not because they had lost confidence in her, but because the signals they were receiving about where answers lived had gradually shifted. The operation was still running. The system was progressing toward go-live. But the authority that held the operation together had been redistributed without anyone making a single deliberate decision to allow it.
What struck me most about that situation was not the outcome itself but how naturally and innocuously it had unfolded. It had not happened because of a governance failure, a leadership mistake, or any conflict between the operations function and the project team. It happened organically, the way authority always shifts during periods of significant organisational change: through habit, through convenience, and through the natural gravitational pull toward whoever is most visibly and energetically driving the work at any given moment. The project team was focused, mobilised, and in constant motion. The vendor was present, responsive, and positioned as the primary source of answers about how the new system should behave. And the operations head, managing the genuine complexity of keeping the business running at performance while simultaneously supporting the demands of the migration, had simply allowed the centre of gravity to shift without noticing how far it had moved until the distance was significant. By the time she recognised the pattern clearly enough to address it with intention, rebuilding the natural flow of authority back through the operations function required considerably more time, deliberate conversation, and consistent visible effort than preventing the drift would have needed in the first place.
This dynamic is one of the most consistent, most consequential, and most underestimated risks in enterprise system transitions, and I say that having been involved in technology migrations across multiple industries, geographies, and organisational scales over the past fifteen years. I have seen it surface in companies with strong operations leaders, experienced project management offices, and well-resourced implementation teams. The moment a major implementation begins, operational decision-making tends to gravitate toward whoever is most visibly driving the migration, unless there is a conscious, sustained, and active effort by the operations leader to hold that line and keep it visible to the team. The project team is not attempting to absorb authority that does not belong to them. They are simply filling a space that appears available because the person who should occupy it is stretched across too many competing demands to maintain consistent presence in all the places that matter. Understanding this dynamic not as a failure to prevent but as a natural organisational force to recognise and manage is the most important reorientation an operations leader can make before any implementation phase begins. How authority flows during the transition determines the health of the operation long after the project team has left and the vendor has moved to their next engagement.
The Distinction That Most Transition Plans Miss
One of the most practically important things an operations leader can own during any system transition is the distinction between a system going live and an operation being genuinely ready to function sustainably within its new environment. These are not the same condition, they do not arrive at the same time, and treating them as equivalent is one of the most consistent sources of post-migration difficulty I have encountered across the enterprise transitions I have been involved in throughout my career. A system can pass every technical acceptance criterion on the project’s readiness checklist, clear every integration test, and successfully complete every data migration validation, while the operation built on top of it is still absorbing the change, still recalibrating its team leads, and still developing the operational confidence and embedded workflow capability needed to perform at its historical standard within the new environment. Technical readiness and operational readiness are two distinct organisational conditions, they require different assessments and different owners, and conflating them is a governance decision that costs organisations far more in post-migration stabilisation time than the brief additional clarity of acknowledging the difference would ever require.
Technical readiness is typically defined and owned by the project team, and appropriately so. It covers the conditions under which the technology can be considered functional and ready for production deployment: data migration has been completed and validated within defined tolerance parameters, system integrations are performing within specification under test conditions, user acceptance testing has been signed off by the designated stakeholders, the infrastructure is stable, and the go-live environment is ready to support the volume of the live operation. These milestones belong to the people who designed and built the implementation, and they are the right people to define and confirm them. But operational readiness sits in an entirely different dimension. It asks whether the people who will operate within this system every day, across every shift and every scenario, are genuinely confident in the new workflows or whether they are performing confidence because they understand that the project timeline requires a green light. It asks whether the exception-handling paths that will carry the most complex and consequential operational work have been tested under realistic pressure conditions or whether they have been documented in a process guide that the team has walked through in a training session. It asks whether the team leads who will be making dozens of consequential decisions per shift have had sufficient genuine exposure to the new system to make those decisions independently, without defaulting to the implementation partner for direction every time something unfamiliar appears in their workflow.
This distinction belongs entirely to the operations leader to define, to communicate clearly, and to defend consistently throughout the transition, including in moments when the project timeline is creating pressure to treat the technical green light as sufficient clearance for full operational deployment. I consistently advise the operations leaders I work with to develop their own operational readiness criteria before implementation begins, written independently of and running in parallel with the project team’s technical criteria. These criteria should be specific enough to be measurable, grounded in how the operation actually functions on its most demanding days rather than its average days, and sufficiently concrete that a team lead on the floor could confirm whether each condition has been met based on what they are observing in real time. They should be shared with senior leadership early in the process so there is alignment from the beginning that a technical go-live confirmation and an operational readiness confirmation are two separate assessments requiring two separate sign-offs. And they should be treated as living criteria throughout the transition, because the conditions that define operational readiness in the first weeks of an implementation will need to be recalibrated as the operation encounters the actual complexity of the new system in ways that planning sessions and test environments cannot fully anticipate. The operations leader who owns this definition owns the most consequential conversation in the transition: the one about when the change is genuinely complete and the operation is genuinely ready to stand on its own.
Decisions Are the Currency of Operational Authority
System transitions create a powerful and almost universal tendency for teams to defer decisions outward. When familiar workflows are being replaced with processes that feel unfamiliar, when the procedures that team leads have executed confidently for years are changing shape, and when an external team with deep knowledge of the new system is consistently present and available, even experienced and capable operators begin routing questions and judgment calls away from their own assessment and toward whoever appears best positioned to resolve them quickly and correctly. This is not a reflection of weakness in the team. It is a rational human response to operating within genuine uncertainty, particularly when the consequences of a wrong decision feel amplified by the visibility and stakes of a major transition. But this tendency, left unrecognised and unmanaged, is precisely how operational capability erodes during a migration without anyone intending for that erosion to occur. The cumulative effect of dozens of small decisions being routed through the project team or the implementation partner, week after week through an extended implementation, is an operation that has quietly stopped trusting its own collective judgment and developed a dependency on external direction that will not survive the transition period on its own terms.
The decisions that matter most during this period are frequently the ones that appear too minor to warrant explicit protection or deliberate governance. How exceptions are classified and escalated when the new system produces an output that does not match the team’s expectation of what a correctly processed transaction should look like. How team leads communicate a system-side processing issue to their direct reports in a way that maintains operational confidence rather than creating unnecessary anxiety about whether the platform can be trusted. Who is authorised to approve a temporary procedural workaround when a process step is not functioning as designed and the volume of work cannot wait for a formal change control decision. How daily performance shortfalls are reported, discussed, and resolved within the operations structure rather than being absorbed into the project team’s issue log and managed from there. These are not technical decisions, they require no specialised knowledge of the system’s architecture or configuration, and they should be resolved by operational leaders at the appropriate level of the team regardless of what state the system beneath those decisions happens to be in at any given moment. Every time one of these decisions flows through the project team instead of through the operations structure, a small but meaningful signal travels through the team about where authority actually resides during the transition. Those signals accumulate faster than most leaders realise, and they shape team behaviour and team expectations in ways that persist well beyond the migration and into the normal operating environment that follows.
What I have learned stepping into organisations across 14 countries and through more enterprise technology transitions than I can count precisely is that teams take their most important directional cues from how their leaders behave during periods of uncertainty, not from what their leaders communicate in formal all-hands sessions or written transition updates. An operations head who continues to make clear, timely, and visible operational decisions every day during the migration period, who holds her team leads accountable to the performance and behavioural standards that applied before the system change began, and who communicates through the consistent quality of her daily decisions that the operation is still owned here regardless of the level of external activity at the project layer, does something that no governance document or communication plan can replicate. She signals to every level of her team that the change happening around them is significant and requires their full engagement, but that it does not alter where they look for direction, who makes the decisions that keep the operation moving, or what standards define the quality of their work. Decisions are the currency through which operational authority is expressed and experienced by a team. Leaders who keep spending that currency consistently through the full arc of a transition emerge from the other side with their authority not merely intact but demonstrably reinforced.
Presence Is the Most Strategically Underused Tool in a System Transition
Visibility during a system transition is almost universally framed as a morale practice or a communication discipline, something that thoughtful leaders do to keep their teams engaged, informed, and motivated through a period of significant change. That framing captures a real benefit, but it substantially undervalues what consistent operational presence actually accomplishes in a live migration environment. The operations leaders who are most visibly present on the floor through the full arc of a transition are not primarily there to reassure their teams, though that is a genuine and valuable outcome of their presence. They are there because floor-level engagement is the single most effective mechanism available for staying accurately and continuously informed about how the transition is actually being experienced and absorbed by the people who have to operate within it, as distinct from how the project status reports and vendor updates say it is progressing. The gap between those two pictures is almost always material, and it almost always carries operational implications that the formal governance channels are not well-positioned to surface or to address.
Real-time awareness of how a system migration is landing in the daily operational reality of the people who have to execute within it does not emerge reliably through formal project governance. Status meetings report on milestones achieved, issues logged, and risks rated. Vendor updates focus on the technical performance of the platform and the project team’s progress against scope. User acceptance testing captures structured scenarios executed under controlled conditions that are inherently different from the pressure and variability of full production volume. None of these channels consistently surfaces the qualitative operational texture that determines whether the transition will hold under real conditions: whether team leads who appear confident in training sessions are genuinely ready to operate independently or are performing readiness because they understand the project needs to move forward; whether the informal workarounds that have quietly become standard practice among the team are being reported through the project issue log or absorbed into daily procedure without documentation; whether the exception-handling paths that carry the most operationally complex and consequential work are functioning as the process documentation describes or whether they are relying on individual improvisation that will degrade in consistency as the individuals who developed it cycle through shifts and are eventually unavailable. That information lives on the floor, in the texture of daily operations, and it becomes accessible to the operations leader who is consistently present within it in a way that it never becomes accessible through reports, dashboards, or weekly governance calls.
There is a third dimension to presence that I have come to believe matters as much as information access and decision quality: the effect that consistent operations leader visibility has on the team’s sense of continuity and identity through the transition. When a team sees their operations leader present on the floor through a major system change, making operational decisions, holding standards, and engaging with the work at the level of daily execution rather than managing the transition from a distance, they receive a signal that is more powerful than anything that can be communicated in a message or a meeting. They receive the signal that this operation exists and functions independently of whatever technology sits beneath it, that the standards that define the quality of their work are not suspended while the system is in transition, and that the person who is accountable for the operation has chosen to be present during the difficult period rather than observing it through reports. After fifteen years of this work, one empirical pattern holds more consistently than almost any other across the transitions I have been involved in: the operations leaders who maintained the most deliberate and consistent floor presence through the full migration period led teams that performed most strongly in the three to six months following go-live, when the project team had stepped back, the vendor had transitioned to maintenance mode, and the operation had to find its own performance level within the new environment entirely on its own terms. Presence during a transition is not symbolic. It is one of the most consequential strategic choices an operations leader can make.
Owning the Outcome Narrative Before Someone Else Frames It
There is a moment that arrives at the conclusion of every enterprise system transition, a moment that most operations leaders do not adequately prepare for and that carries far more lasting consequence than its apparent simplicity suggests. It is the moment when the organisation’s senior leadership steps back from the migration, surveys everything the transition required in terms of time, financial investment, and organisational energy, and asks the questions that will shape how accountability and operational capability are understood for years afterward: what did this transition actually achieve, how did the operation perform through the change, and who carried the work through to its conclusion? The narrative that is told in response to those questions, in that specific moment, determines how senior leaders understand the operations function’s capability and how they extend operational autonomy and resources in future transitions. It shapes budget conversations, resourcing decisions, and the credibility that the operations function carries into the next significant organisational change. It is, in other words, one of the most significant leadership moments in the entire transition arc, and in a pattern I have observed consistently across organisations, it passes without the operations leader claiming it.
What happens in its place is almost reflexive in the organisations where this pattern is established. The project director presents the migration completion summary to senior leadership. The vendor provides a formal transition closure report that naturally emphasises the technical milestones reached, the system performance metrics achieved, and the implementation team’s execution against the original project scope. These are accurate accounts of what the project accomplished, and they deserve to be told. But the operations leader, who carried the actual weight of keeping the business performing throughout the entire period of disruption, who made hundreds of consequential decisions that never appeared in a project report or a vendor status update, and whose team absorbed the operational complexity of the transition while continuing to meet the commitments that the business depends on, is present for that senior leadership conversation but is not the person shaping the narrative it contains. The story that reaches the executive level is structured as a technology delivery story. The operational story, the one that most directly reflects the capability, resilience, and leadership quality of the operations function, is either told as a supporting element within the project director’s account or is not told at all with the clarity and specificity that would allow senior leaders to genuinely understand what the operations team accomplished.
Operations leaders who consistently emerge from large enterprise transitions with their authority, credibility, and senior leadership relationship fully intact and strengthened are the ones who treat the post-transition outcome narrative as something to be actively prepared and deliberately owned, not something that will represent itself accurately if left to emerge organically from the project closing process. They document operational performance through the transition period with the same rigour and specificity they would apply to any strategic review: tracking the decisions made at every level of the operations function, the standards maintained against the pressure of the migration, the exceptions managed and resolved within the operations team rather than escalated externally, and the trajectory of team confidence and performance through each phase of the change. When the moment arrives to account for the transition to senior leadership, they are not in that room to respond to the project director’s summary or to supplement the vendor’s report. They are in that room to lead a clear, evidence-grounded, and confident account of what the operation achieved through the migration: the decisions it owned, the standards it held, the performance it sustained, and the specific ways in which the transition has positioned the operation for stronger performance in the environment that follows. That account does not compete with the technical narrative. It completes it. And it establishes with clarity and precision where the real operational leadership work of the transition was done, which is the only foundation on which genuine, lasting leadership credibility can be built.
A Practical Checklist for Operations Leaders Entering Any System Transition
Across the enterprise technology transitions I have advised as a Fractional CTO and technology advisor, working with operations leaders in organisations across fourteen countries and multiple industries, the leaders who navigate migrations most effectively share a consistent and specific set of commitments that they establish before implementation begins and hold with discipline through every phase of the transition. These are not formal project deliverables, they do not appear in a governance framework document, and they require no special authority or additional resources to implement. They are the decisions an operations leader makes about their own role and conduct during the migration, the commitments they make to their team about how authority and accountability will flow through the change, and the standards they hold for how the operations function will participate in the transition without allowing that participation to dilute the clarity of who leads and who decides. Stating these commitments explicitly before implementation begins, sharing them with the team and with senior leadership where relevant, and returning to them consistently through the most demanding periods of the migration is what transforms them from good intentions into functional operating principles that the team can see and trust.
- Define operational readiness in writing before the project defines technical readiness. Establish the specific, observable, and measurable conditions under which you will consider the operation genuinely ready to function within the new system at full performance, and share those criteria with senior leadership before the implementation phase begins. The operations leader’s readiness criteria should run in parallel with the project’s technical criteria and should be explicitly acknowledged as a separate and distinct milestone requiring separate confirmation.
- Map the operational decisions that must remain within your team throughout the transition. Before implementation begins, identify the exception-handling processes, escalation pathways, daily performance decisions, workflow authorisations, and team lead accountability standards that belong to the operations function regardless of system status or project activity. Communicate that map clearly to your team leads and to the implementation partner so the boundaries of the project team’s decision-making scope are understood without ambiguity from the first week of implementation.
- Establish a daily operational review that functions entirely independently of the project governance structure. Even when project stand-ups, vendor calls, steering committee meetings, and transition workshops are consuming significant time in the daily schedule, the operations function should maintain its own performance rhythm: its own daily review of operational metrics, its own exception management conversation, and its own internal escalation path that does not route through the project team for resolution. That independent rhythm is how the team maintains its operational identity and its functional coherence through the full duration of the change.
- Schedule deliberate and consistent floor presence through the entire transition arc, not only the go-live window. The period of highest operational complexity in most enterprise migrations is not the go-live week, which is typically well-resourced and heavily managed. It is the four to eight weeks following go-live, when the project team is winding down its involvement, the vendor is transitioning from active implementation to maintenance support, and the operation has to find its performance level within the new environment without the full weight of the project infrastructure behind it. Plan your floor presence for that period with the same deliberateness and commitment as any other milestone.
- Document operational performance and the decisions your team makes throughout the full transition period. Keep a structured and specific record of the standards maintained, the decisions made at every level of the operations function, the exceptions managed internally rather than escalated externally, and the team’s performance trajectory through each phase of the migration. This documentation is the factual foundation of the outcome narrative you will present to senior leadership when the transition closes, and its quality will directly determine the quality of the account you are able to give.
- Prepare your operational outcomes presentation independently before the project completion report is produced. Do not enter the post-migration senior leadership review as a respondent to the project director’s summary or as a secondary voice in the vendor’s closure report. Know your operational story, own your team’s performance numbers, and be prepared to present them with the confidence and the specificity that only comes from having been present, engaged, and making decisions throughout the entire transition.
These principles are not complicated, and none of them require extraordinary effort or special circumstances to apply. What they require is the conviction that operational authority is genuinely worth maintaining through the full weight and complexity of a system transition, and the consistent daily discipline to act on that conviction from the first day of implementation through the final debrief with senior leadership.
The Kind of Leader the Transition Reveals
The operations leaders who emerge from enterprise system transitions with their authority fully intact, their teams measurably stronger, and their credibility with senior leadership genuinely deepened are not, in my experience and observation over fifteen years of this work, the ones who had the smoothest technical migrations, the most accommodating implementation partners, or the most generously resourced project teams. They are the ones who made a clear and deliberate decision before the first implementation meeting to remain the visible, engaged, and active decision-making authority within their operation, and who held that commitment with quiet and consistent discipline through every phase of the change, including the phases when the complexity of competing demands made it genuinely difficult to maintain. They understood that a major system transition is not a temporary suspension of operational leadership. It is one of the most demanding tests of it, precisely because it presents so many legitimate and plausible reasons to defer, to step back from daily operational decisions, to allow the project team to carry more weight than is appropriate, and to manage the transition from the level of governance and reporting rather than from the level of daily operational engagement where the real work of the change is being absorbed and carried out.
What I have observed consistently in the organisations where this approach has been most deliberately and fully applied is that it creates a compounding effect that extends well beyond the transition itself. When the operations leader maintains clear and visible authority through the migration, the team maintains its confidence and its sense of operational identity. When the team maintains its confidence, performance holds through the most difficult phases of the change rather than degrading as the complexity of the transition peaks. When performance holds, senior leadership’s understanding of the operations function’s capability is deepened by direct observation rather than by inference from project reports. And when the transition closes, the operations leader is positioned to own the outcome narrative, to define what the next operational phase looks like, and to carry into future transitions the full weight of a team that has navigated a major change and emerged from it stronger, and a senior leadership relationship that has been built on demonstrated capability rather than on the successful completion of a project scope. That is the compounding return on the investment of maintaining operational authority through a migration, and it is a return that no vendor, no project team, and no implementation partner can create on behalf of the operations leader who chooses to earn it.
Operational authority during a system transition is not something that is taken from operations leaders who fail to protect it assertively enough. It is something that is gradually and almost imperceptibly set down by leaders who are managing too many competing demands to maintain consistent presence in all the places that matter, until the accumulated weight of decisions that have moved elsewhere becomes heavier and harder to reclaim than it needed to be. The leaders who understand this, who recognise the drift before it becomes a pattern and hold the line before it becomes a recovery effort, tend to arrive at the other side of their transitions with something that no project team can deliver and no vendor can provide: an operation that has been led through significant and genuine change by someone who never let go of it, and a team that knows exactly what that kind of leadership looks like when it matters most.
