Leadership Under Pressure: How AI Helped Us Navigate a Last-Minute Executive Pivot

My story

Toward the end of a quarter, engineering teams tend to operate under a particular kind of pressure. By that point, the roadmap has already been negotiated, priorities are aligned, and the team is focused on execution. Most of the work is already in motion, and every remaining day matters for getting initiatives across the finish line.

That was exactly the situation my team was in when things suddenly changed.

At the time, I was leading a team both as a product and team manager. We were approaching the end of the quarter and preparing to deliver an initiative that had been planned for weeks. Then our data manager raised a concern about the outcome of the project. In his view, some elements of the initiative had not been clearly identified as out of scope, and if we released it as planned, the result would not meet expectations.

His suggestion was straightforward: we should add roughly two additional weeks of work before completing the initiative.

On the surface, this sounded reasonable. The difficulty was that none of this additional work had been defined. There were no specifications, no clear development scope, and no concrete description of the customer impact we were trying to achieve. The request was based more on concern than on a structured plan.

The Solution

Situations like this are common in engineering environments, especially close to delivery milestones. Stakeholders begin to worry about outcomes, new risks appear, and requests emerge at the last moment to adjust the plan.

The challenge is not simply technical. It is primarily about leadership.

When a late change appears without clear requirements, the team looks to their leader to interpret the situation. They want to understand whether the existing work is still valued, whether priorities have changed, and how the new expectations will affect what they are currently doing.

Handled poorly, these moments can quickly erode trust.

Teams begin to feel that their work is unstable. Stakeholders feel that delivery is uncertain. And the leader ends up acting as a messenger for conflicting pressures rather than a source of clarity.

I have seen this happen many times. A manager receives a late request and simply relays it downward: leadership wants more work, the scope has changed, and the team needs to adjust.

While that response may be technically accurate, it rarely creates alignment. Instead, it shifts frustration from one layer of the organisation to another.

In situations like this, leadership is not about shielding the team from reality. It is about taking responsibility for the response to that reality.

In our case, the first step was to take ownership of the conversation with the data manager. Rather than immediately committing to the additional work, I explained that I needed to review the situation with the team before confirming what could realistically be delivered.

This created space for us to evaluate the request properly.

Together with the team, we revisited the plan for the final two weeks of the quarter. Instead of asking whether the new request was possible in theory, we focused on a more practical question: if this concern needed to be addressed, what trade-offs would allow us to do it responsibly?

We reviewed our existing tasks, identified the work that could potentially be paused, and considered several different ways the initiative could evolve. From that discussion, we designed three possible paths forward.

Each option prioritized a different outcome.

One option focused on delivering the specific result the data manager was concerned about. Another balanced the original initiative with a partial adjustment to address his concerns. The third option preserved most of the original plan while addressing only the most critical risk.

Presenting the situation this way changed the nature of the conversation entirely.

Instead of debating a vague request, we were now discussing structured choices. When we presented the options, the message was simple and transparent: if outcome A matters most, here is the path that achieves it; if outcome B is the priority, this is the trade-off; and if outcome C is acceptable, we can preserve more of the current work.

By framing the decision this way, we made it easier for the stakeholder to understand the operational implications of each choice. What had initially been an unclear request became a clear decision.

At this point, however, execution speed became critical. Once the direction was chosen, we needed to reorganize the remaining work quickly without losing time to coordination overhead.

This is where AI played an important role.

Our meetings were recorded in Microsoft Teams, which automatically generated transcripts. From those transcripts, I was able to extract action items and decisions almost immediately. Instead of manually reviewing the discussion and summarizing key points, the essential information was already structured.

Preparing the follow-up communication with the data manager became a simple review process rather than a documentation exercise.

Once the data manager selected Option A, we moved into the next step: translating the decision into actionable work for the team.

Normally, converting planning discussions into Jira tickets requires careful interpretation. Someone needs to break the work into tasks, define acceptance criteria, and structure the tickets clearly enough that engineers can begin immediately. In many teams, this step alone can take several hours.

Using the action items captured from the meeting transcript, I asked AI to generate draft Jira tickets directly from the discussion points.

Within minutes, we had seven tickets ready for review.

The team went through them to ensure clarity and technical accuracy. Out of the seven tickets that were generated, only one required meaningful adjustments. The rest were already clear enough for the team to begin working.

What would normally have taken a few hours of coordination was completed in about twenty minutes.

The time savings were useful, but the more important impact was on focus. Instead of spending energy on administrative translation between meetings and task management systems, the team could concentrate on the actual work required to complete the pivot.

The Learning

In high-pressure situations near the end of a quarter, that difference can have a real impact on delivery.

Ultimately, we completed Option A within the remaining two weeks of the quarter. At the same time, we created a separate initiative to capture the elements that had been postponed as part of the trade-offs.

The pivot was handled without confusion or frustration. The stakeholder understood the implications of the decision, the team had clarity about the adjusted scope, and the operational effort required to reorganize the work was kept to a minimum.

What this experience reinforced for me is that AI is not simply about automation or productivity gains. Its real value appears when it supports leadership in moments where speed and clarity matter most.

When decisions can be captured instantly, action items extracted automatically, and tasks generated quickly, teams spend less time managing information and more time acting on it.

AI does not replace leadership. But it can make leadership decisions operationally scalable.

And in complex engineering environments, that capability is becoming increasingly important.

If This Is a Challenge You Recognize

I work with CTOs and engineering leaders to implement AI-enabled leadership practices that reduce management overhead while increasing clarity and accountability inside technical teams.

Through consulting retainers and workshops, I help organisations integrate AI into leadership workflows from decision capture to operational planning.

If this is something your team is currently exploring, feel free to reach out or follow me here for more insights on AI-enabled leadership and operational trust in engineering teams.